Strip out the art speculation and the token standard underneath is just a registry: a tamper-evident record of who holds what, with metadata attached. That registry is genuinely useful. A concert ticket that cannot be counterfeited. A membership that proves itself without a database call to a company that might go under. A provenance chain on a physical asset that survives the company that issued it. A professional credential that a third party can verify without phoning the issuer.
The standard is solid. The infrastructure most teams bolt onto it is not. The cheap implementation looks identical to the correct one on launch day and diverges about a year later, when the metadata 404s, the artwork is gone, and the holder is staring at a broken image where their access used to be.
We build the version that still works in year three. Here is what that takes.
The metadata problem nobody budgets for
Here is the part that surprises people: most of what makes an NFT useful is not on-chain. The token contract typically stores a token ID and an owner. The actual content — the image, the credential fields, the access rules, the trait data — lives behind a URI the contract points to. tokenURI(42) returns a link. What is at the end of that link is where the project lives or dies.
The naive implementation points that URI at a centralized server. https://api.ourproject.io/metadata/42. It works perfectly in the demo. It works perfectly until the company stops paying the hosting bill, the domain lapses, the S3 bucket gets reorganized, or the startup folds. Then every token the project ever issued is a pointer into the void. The asset that was supposed to be permanent and self-sovereign is now exactly as durable as a startup's AWS invoice.
This is not hypothetical. A large share of NFTs minted in the speculative years already resolve to dead links. The chain entry survives. The thing it pointed at does not. For art that is embarrassing. For a credential or a provenance record or a paid membership, it is a product failure with a refund attached.
On-chain versus off-chain: the actual decision
The question is not "should the data be on-chain or off-chain." It is "which data, and what guarantee does each piece need."
Putting everything on-chain is expensive and usually wrong. Image bytes do not belong in contract storage; the gas cost is absurd and the chain is a terrible file server. But the commitment to the content belongs on-chain. There is a clean middle path most teams skip.
Fully on-chain. The metadata and even the artwork are generated and stored in the contract. No external dependency, ever. This is the right call for credentials and access tokens where the data is small and structured — a few fields, a status, an expiry. It costs more to mint and it is permanent in the strongest sense. Nothing to 404.
Content-addressed off-chain with an on-chain hash. The content lives on IPFS or Arweave, and the contract stores the content hash, not a mutable URL. This is the version that holds. A content-addressed link cannot point at different data later, because the address is the hash of the data. If the bytes change, the address changes. The contract committing to a specific hash is the contract committing to specific, unforgeable content.
Mutable URL off-chain. The contract points at a regular server you control. This is the version that breaks. It is fine only when the data is genuinely meant to be dynamic and you have accepted that the issuer is a permanent trusted party. For a "permanent" credential, it is a contradiction.
The discipline is simple. If the promise to the holder is permanence, the link must be content-addressed and the bytes must live somewhere with a durability model — pinned IPFS with redundancy, or Arweave with its pay-once-store-forever model. A single pinning service you forgot to fund is a single point of failure dressed up as decentralization.
The storage layer that actually survives
"We put it on IPFS" is where most teams stop and where the real work starts. IPFS is content-addressing. It is not, by itself, persistence. Data on IPFS stays available only as long as some node pins it. If your one pinning provider drops the pin, the content is gone and the hash now resolves to nothing — same dead-link failure, dressed in decentralized clothing.
The version that holds pins to at least two independent providers and, for anything claiming permanence, also writes to Arweave, where the storage is paid once and economically incentivized to persist. The contract references the content hash. The off-chain layer is responsible for keeping that hash resolvable, redundantly. We treat the pinning infrastructure as production infrastructure with monitoring, not a one-time upload step someone ran from a laptop.
For provenance specifically — proving a physical or digital asset's history — the chain of custody is a sequence of these content-addressed records, each committed on-chain, each independently resolvable. We built exactly this kind of provenance system on Polygon where every record had to remain verifiable independent of any single host. See how we approached Sigil →
Verification: the part that makes it a credential
A token in a wallet is a claim. Turning it into something a third party trusts requires verification logic, and this is where utility NFTs earn the name.
Ownership verification is the easy half: a relying party checks on-chain that an address holds the token. The hard half is binding the token to a real-world fact and keeping that binding honest. A ticket NFT needs to be checkable at the door, fast, offline-tolerant, and resistant to one person screenshotting their wallet for ten friends. A credential NFT needs the relying party to trust the issuer, which means the issuer's address has to be discoverable and reputable, and revocation has to be possible — credentials get revoked, and a token that can never be revoked is not a credential, it is a tattoo.
So the infrastructure includes an issuer registry, a revocation mechanism the contract honors, and a verification flow that a relying party can run without trusting your servers. If verifying the credential requires calling your API, you have rebuilt a centralized credential database with extra steps and a gas bill.
The failure modes of cheap implementations
The same handful of shortcuts produce the same handful of year-two failures.
Mutable metadata URLs produce dead assets when the host goes away. Single-provider pinning produces the same outcome with a decentralized alibi. Storing the artwork at a plain HTTP URL while only the token ID is on-chain produces tokens that are real but point at nothing.
No revocation produces credentials that cannot be corrected when someone's status changes — the access that should have been pulled stays live. No issuer binding produces a verification flow where anyone can mint a look-alike token and pass it off as the real credential, because nothing ties the genuine one to a trusted issuer. Unbounded, unstandardized metadata produces tokens that render in your app and nowhere else, defeating the entire point of using a portable standard.
And the quiet one: minting logic with no access control or a hot owner key, where the issuer's wallet getting phished means an attacker can mint unlimited credentials. The contract was fine. The key was not. We have seen this end a project's credibility overnight.
What fixed looks like
A utility NFT system we would put our name on commits to its content with on-chain hashes, not mutable URLs. Permanence claims are backed by redundant pinning and an Arweave write, not a single service and a hope. Small structured data — credentials, access flags — lives fully on-chain where it never 404s. There is an issuer registry, a revocation path the contract enforces, and a verification flow a relying party runs without trusting your servers. Mint authority sits behind proper access control, not a single hot key.
A holder who checks their token in year three sees the same asset they minted, resolving from the same hash, verifiable by the same independent flow. The infrastructure outlived the launch hype, which was the entire point.
This is for you if
You are issuing tokens that carry real utility — access, provenance, membership, credentials — and a broken link or a forged look-alike would damage real users or real revenue. You want the version that survives your company's reorgs, not the version that demos well. The engineering scope for production utility-NFT infrastructure — content-addressed storage with redundancy, on-chain commitment, issuer and revocation logic, independent verification — runs $50k and up depending on how much data lives on-chain and how the verification flow integrates with your product.
This is not for you if you are minting a PFP drop for the speculation and the metadata only needs to survive until the floor price does. That is a different game with a different budget.