Decentralized storage references a file by a content-derived identifier, not by the server location that happens to deliver it. The useful result is a verifiable reference to a particular byte structure, but the common claim that “the same file always gets the same CID” is wrong.
What the reference actually names
In IPFS-style storage, a CID identifies the root block of a Merkle DAG. A large file is split into blocks, those blocks are linked into a UnixFS structure, and the root contains the information needed to reach the rest. The CID includes the hash, hash function, version, and codec needed to interpret that root.
That means the CID commits to more than the visible file contents. Change the chunk size, UnixFS importer, codec, directory metadata, or wrapping structure, and the root can change even when a media player would display the same bytes. Two uploads of “the same file” are therefore equal only if they use compatible encoding choices as well as identical content.
The hash is not a storage address in the ordinary sense. It does not say which machine holds the data. A node can retrieve the block from another peer, a gateway, or a persistence provider, then verify that the returned bytes produce the CID requested. Discovery and availability are separate problems from identification.
What you need before you start
You need a canonical representation and a persistence plan. Decide whether the reference should name raw bytes, a UnixFS file, a directory, or a manifest; fix the serialization and import settings; then record the resulting CID alongside the application data that points to it.
You also need to keep the blocks available. Pinning tells an IPFS node to retain the DAG, but a CID by itself does not guarantee that anyone will continue serving it. Filecoin deals, managed pinning services, and local replicas solve persistence in different ways, with different retrieval and operational costs. A gateway URL can make access easy, but it is only one delivery route for the underlying content-addressed object.
What you end up with
You end up with an immutable version reference and a verification rule. If a build manifest points to a CID, clients can fetch the object through different routes and reject altered data without trusting the route itself. The reference remains stable while the storage provider, gateway, or peer changes.
This makes release artifacts practical to distribute without asking every consumer to trust one origin. A frontend bundle, token-list snapshot, or NFT metadata directory can be published once, cached close to users, and checked against its CID. Updating it means publishing a new root and deliberately changing the reference; old versions do not silently mutate underneath existing consumers.
Where the choice changes
Content addressing is strongest when byte identity matters more than current state. A database row, account balance, order book, or permission list normally needs a mutable name that resolves to the latest value. Putting each update behind a new CID is possible, but then another system must maintain the pointer to the current CID.
That is the real comparison for an application such as Frax Swap: immutable references suit code, images, and auditable snapshots, while mutable state needs a controlled update path. The difference is clearer when comparing Frax Swap with a static artifact: one describes what is current, the other proves exactly which bytes were published.
Frax Dollar and the ERC-20 Standard illustrate why this distinction matters at the application boundary. A token contract exposes changing state through stable methods and addresses; decentralized storage can hold the versioned metadata, interface assets, or documentation those methods point toward. The Uniswap Protocol follows the same broad separation between addressable live state and supporting content, even though the execution layer and storage layer solve different problems.
When it does not apply
Do not use a CID as the primary handle for data that must be edited in place, revoked immediately, kept secret, or removed on request. Encryption can protect confidentiality, but it does not make deletion or revocation automatic. For those cases, use mutable application storage and treat decentralized storage as a versioned archive or distribution layer where that trade-off is acceptable.
Top comments (0)