CT3 is moving to a new model for issuing NFT access keys. The main collection is being fragmented: alongside it, new collections are being introduced, each with its own smart contract and a specific dedicated volume of storage on the network. Keys from every collection, old and new, are accepted on ct-3.cloud with no action required from the user.

The platform is rebuilding its key-issuance layer so that each CT3 product runs on a contract designed around its own data model. Below we break down what has changed, why, and what it means for users.

What collection fragmentation is

Previously, every CT3 NFT key was minted into a single main collection governed by one smart contract. Keys can now be issued into either the main collection or a new one, and each new collection:

• runs on its own dedicated smart contract;
• is tied to a set capacity limit for files stored on its nodes;
• is fully compatible with ct-3.cloud and the existing access-verification model.

A capacity limit at the contract level makes utilization measurable and verifiable. Every file in a collection is represented by an NFT key with metadata, so the volume served by a given contract can be independently verified on-chain. Transparency here is not a statement. It is a property of the architecture.

Why fragment the main collection

The legacy key-issuance system was not built for dynamically changing NFT attributes

CT3 has begun testing the automatic backup upload system, where blue NFTs act as the access keys.

The legacy issuance infrastructure fully covers the needs of personal and corporate files: these keys do not require dynamic metadata. A user file does not change after upload, and the volume of corporate storage is not disclosed. In both cases metadata is fixed at mint and stays unchanged.

A backup NFT does not fit this model. It is a key to a file system assembled into an archive, and the weight of that archive can change during storage. This kind of key requires updatable metadata, which the legacy contract does not support.

Preparing the infrastructure for dApp hosting

The backup system is one step in a longer sequence. Next on the roadmap is the release of dApp hosting, which will need another class of NFT with a fundamentally different attribute model: attributes that change dynamically, appear, and are removed across the lifecycle of an application.

This update already accounts for the infrastructure changes required for the releases ahead. When dApp hosting ships, the key-issuance layer will be ready for it.

What this means for storage users

For existing users, nothing changes in day-to-day use:

• Old keys work exactly as before.
• The platform accepts both legacy keys and keys from the new collections.
• Main-collection keys still make up the vast majority of all new keys issued by CT3.

Some files uploaded through ct-3.cloud receive keys minted into the new collections. Access verification, transfer, renewal, and secondary-market trading work the same regardless of which collection a key belongs to. Owning the NFT remains owning the access, whichever collection the key sits in.

How CT3 decides which collection to mint into

The distribution of user NFT mints is balanced according to load on the main contract. In addition, a set share of mints is directed into the new collections as part of a gradual migration: each collection needs to reach its required supply of stored file volume.

The process is fully automatic. Users do not need to choose a collection or understand how the migration works. The guarantees behind a key are identical everywhere.

How an individual collection is structured

Each new collection is predefined by the volume of space allocated to it. That volume is fixed at the smart-contract level, and the collection's occupancy is kept at no less than 80%.

New contracts appear as demand grows: when network participants fund the creation of a new collection, this triggers the deployment of a separate smart contract and routes a portion of new uploads through ct-3.cloud into that collection. Network capacity grows in step with actual usage.

By composition, most collections look similar: they contain a backup NFT, and that NFT usually occupies the largest share of the collection's space. The remaining volume is filled by user keys, distributed automatically.

What comes next

Fragmentation changes the key-issuance layer, not the user experience. The main collection keeps running, while the new collections take on products that need dynamic metadata: backups first, dApp hosting after.

Testing of the backup system continues, and statistics on uploads and mint distribution will be published as data accumulates. We will announce backups leaving the preliminary stage, along with the next steps on dApp hosting, in separate posts across our social channels.

CT3 socials

Follow CT3 across our official channels to stay up to date on platform updates, new features, and enterprise milestones:

• Official website: ct-3.ltd
• Official storage website: ct-3.cloud
• Support (Telegram): t.me/ct3_support_bot
• Email: contact@ct-3.ltd
• LinkedIn: https://www.linkedin.com/company/ct-3-secure-storage
• ‍X (Twitter): x.com/ct3_io

If you discover any suspicious resources, fake accounts, or receive questionable offers, please report them immediately to our official support service.

‍

‍