Three Design Decisions Before Using an NFT as a "Certificate"

Tomohiro Iida · Published June 4, 2026

An NFT is not "a mechanism where information can never be changed at all." More precisely, it is a mechanism that makes it easier for a third party to later verify the history of on-chain issuance, transfer, and updates, and the integrity of any data that has been pinned. Designing an NFT that holds up in production as a certificate means sorting out three points before you issue anything: where metadata is managed, how permissions are designed, and how persistence is guaranteed.

The situation (anonymized)

A small or mid-sized company selling direct to consumers asked us whether an NFT could work as an "authenticity certificate" for the products they sell.

The idea was to attach a serial-numbered QR code to each product; scanning it as a buyer would display an NFT showing the issuer, product details, distribution history, and authenticity information.

Their understanding at the time of the consultation, in summary, was: "once you issue an NFT, the content can no longer be changed afterward, so it can be trusted as a certificate."

They asked us whether that understanding was correct, and what to watch for in the design.

Three design decisions from a 30-minute consulting session

Decision 1 — where to pin the metadata

With an NFT, the token ID and its issuance, transfer, and burn history (rendering it permanently unusable — effectively deleting it) are recorded on-chain. Metadata such as a product image, description, and distribution history, on the other hand, is typically stored separately from the token itself. Where you pin it is what decides how trustworthy the certificate actually is.

Writing directly on-chain gives the strongest tamper resistance, but at a much higher cost and with tighter implementation constraints. For a mid-sized company's certificate use case, a hybrid design is the practical choice: pin the metadata (or a hash of it) and record the CID or reference in ipfs:// format on-chain.

One caveat: an IPFS CID is "an identifier for verifying that content," not something that automatically guarantees "that data will remain retrievable forever." In other words, IPFS is effective for tamper detection, but long-term availability needs to be designed for separately.

Decision 2 — who can change the metadata (permission design)

NFT standards (ERC-721, ERC-1155, and others) do not uniformly restrict whether metadata can be changed. ERC-721 commonly returns a metadata URI via tokenURI, and whether that URI or reference can be changed depends entirely on the smart contract's implementation.

For a certificate use case, the safer design is to treat the information at the core of the certificate as immutable in principle, and, when a correction is needed, to record the history via invalidating the old token (burning it or marking it as revoked) plus reissuing a new one. That said, burn-plus-reissue alone can leave a third party unable to see the reason for the correction or how the old and new tokens relate. In practice, you need to keep an old token ID, new token ID, correction reason, issuer, and correction date as an event log or otherwise inspectable record.

For use cases that need to append distribution history afterward — repair history, inspection history, ownership changes, customs records — a design where "only addresses with specific permission can append," "an append or its hash is recorded on-chain," and "an update event fires whenever metadata is updated" is appropriate. Even with mutability, keeping who changed what and when verifiable is what preserves trust as a certificate.

Decision 3 — how to guarantee persistence

Storing metadata on IPFS does not by itself mean it will "stay viewable forever."

IPFS issues a CID (a content identifier) for a piece of data. A CID is effective for confirming "has this data been tampered with." But if no one is storing the underlying data, the image or description text can become unretrievable even though the CID still exists.

For example, if the issuing company or an external pinning service is storing NFT metadata on IPFS, retrieval works fine as long as that storage continues. But if the issuing company stops maintaining it, or a contract with a pinning service ends, the NFT itself may still exist while the certificate content can no longer be displayed.

For a certificate meant to be used over a decade, or an authenticity certificate for a high-value product, IPFS alone is not enough. With long-term retention as the goal, you need multiple storage locations.

Concrete options include:

• Also using a storage layer built for long-term persistence, such as Arweave
• Using multiple IPFS pinning services
• Running your own IPFS node while also storing with an external service
• Having an industry association or a third-party body share responsibility for storage

What matters is deciding up front how many years this certificate needs to remain retrievable. A campaign NFT that only needs to be checkable for a year, and an authenticity certificate meant to last over a decade, need completely different storage designs. How much redundancy to build in should match the certificate's intended lifespan.

Three common misconceptions

Misconception 1 — issuing an NFT automatically makes it a certificate

NFT standards are mainly a standard for identifying, owning, and transferring tokens. What it is a certificate of, who issued it, whether the issuance process is trustworthy, and how it is tied to the physical item all need to be designed separately.

Misconception 2 — tamper resistance means nothing can ever be changed

More precisely, you need to separate "information that cannot be changed" from "information that can be changed, but whose history can be verified." Past on-chain transactions and events are hard to tamper with, but a metadata URI or reference can be made mutable or immutable depending on implementation. For certificate use cases, deciding which information stays immutable and which can be appended or corrected afterward matters. A certificate does not have to mean everything is immutable — inspection history, repair history, and customs records are examples where value comes precisely from being appended over time.

Misconception 3 — data placed on IPFS stays there almost permanently

IPFS uses content addressing to make it easier to verify whether the content a CID points to has been tampered with. But data placed on IPFS can become unretrievable unless someone continues to pin or serve it. If you are relying on long-term storage, be sure to consider a persistence-oriented storage layer such as Arweave alongside it, redundancy across multiple pinning services, running your own node, and a backup policy. IPFS is a mechanism for integrity verification, not something that automatically guarantees storage independent of any one business continuing to operate.

What happened after

For a company in this kind of consultation, the design often settles on something like: the product information at the core of the certificate is made redundant across IPFS and Arweave, the token is issued on an ERC-721 base, and if a correction is needed, the old token is invalidated and the reissue records the old token ID, new token ID, correction reason, issuer, and correction date.

What stood out was how the shift from "an NFT can't be changed, so it's safe" to "what do we make immutable, what do we make appendable, and how do we make that history verifiable" changed the priority order of the design decisions considerably.

In our consulting sessions, we focus on working through exactly this — how an initial assumption can steer design decisions in the wrong direction.

Q&A

Is an NFT really "tamper-proof"?

More precisely, it means that the history of past issuance, transfer, and updates recorded on-chain is hard to tamper with and easy to verify afterward. An NFT's metadata (name, description, image, and so on) can be made either mutable or immutable depending on implementation. If you are using it as a certificate, you need to decide at design time which data is pinned where, who is allowed to update it if updates are permitted, and how the update history can be verified.

Does pinning metadata to IPFS make tamper resistance complete?

IPFS uses content addressing (a CID) so that pinned content gets a different CID if it changes. Recording that CID on-chain makes it easier to verify whether retrieved data matches what was originally intended. That said, the underlying content itself can become unretrievable if IPFS nodes or pinning providers stop serving the data. For production certificate use cases, consider persistence-oriented storage such as Arweave, or redundancy across multiple pinning providers.

What should I watch for with mutable metadata (a Dynamic NFT)?

If you make it mutable, spell out who can change it (permission design), how the change history can be traced (event logs or an update-event design), and how you can compare before and after in your smart contract and operating rules. A transparent, mutable design can function as "a ledger that keeps a history." For that reason, for certificates like repair history, inspection history, or distribution history — where information accumulates over time — an append-only design can be a better fit in practice than making everything immutable.