The full tokenomics data room process, freeThe whole course, free67 videos, 174 filesSee the course
Free Strategy Call

NFT

An NFT is a token whose contract records one unique owner per token ID. In almost every collection that ownership record is the only part living onchain: the image, the traits and the description sit behind a URI the contract stores as a plain string, on infrastructure the contract does not control. ERC-721 and ERC-1155 define how ownership moves. Neither defines where the file lives, and neither enforces a royalty.

The chain settles one question and one only: who holds token ID 47. Whether the file that token points at still resolves in five years, and whether a marketplace pays the creator when it sells, were always somebody else's promise. Both of those promises have failed at scale.

What one NFT is actually made ofOwnership recordonchain, token ID to addresstokenURI stringonchain, a pointer and nothing elseMetadata JSONoff-chain, name, traits, image fieldMedia fileoff-chain, the thing people think they bought

Scroll to see the full diagram

Only the top two layers inherit the chain's permanence. The two beneath them are ordinary web infrastructure with an owner and a monthly bill, and that is where NFTs break.

What the contract stores, and what it only points at

ERC-721 is an interface, and a short one. It defines ownerOf and balanceOf so anyone can read who holds a given token ID, transferFrom and safeTransferFrom so ownership can move, and approve and setApprovalForAll so a marketplace can move a token on the holder's behalf. Underneath, that is a mapping from a number to an address. A registry of who holds what, and nothing more.

The metadata extension is optional, and it is where the interesting part leaves the contract. tokenURI takes a token ID and returns a string. The EIP says that URI may point to a JSON file conforming to an optional metadata schema carrying name, description and image fields.1 May. No schema is mandated, no image format, no storage medium. What a buyer believes they bought sits at the far end of a string the contract has no way to check.

Everything downstream of that string is a normal web dependency. It has an owner, a bill, an uptime record and a person who can decide to stop. None of those facts change because a token ID happens to be immutable.

Three hops from the ownership record to the picture

Between the token and the artwork there are usually three hops. The contract holds a URI. The URI resolves to a JSON document. The JSON document carries an image field pointing somewhere else again. Break any one of the three and the ownership record survives intact while the thing it describes stops loading.

A study by YourNFTs, independently verified by ClubNFT data scientist Nick Hladek and published by Right Click Save in June 2022, found that artwork and metadata for roughly 90% of NFTs are not stored on the blockchain: about 10% fully onchain, about 40% on private servers, and about 50% addressed through IPFS.4 Apply that split to a 10,000-piece collection and the arithmetic gets uncomfortable. Around 1,000 items whose art lasts as long as Ethereum does. Around 4,000 whose art lasts as long as somebody keeps paying a hosting invoice. Around 5,000 whose art lasts as long as at least one node keeps the bytes.

The mint transaction cannot tell you which bucket a collection is in. Reading tokenURI can, in about two minutes. Almost nobody runs that check before buying, and in our experience almost nobody runs it before launching either.

IPFS is content addressing, not storage

IPFS is the most common answer to the permanence question and the most commonly misread. A CID is a hash of the content, so it is a name that cannot quietly start pointing at different bytes later. That property is real and worth having. It is also not the same property as the bytes continuing to exist.

The IPFS documentation is direct about the difference. Storage on a node is finite, so nodes clear previously cached resources to make room for new ones, a process the docs call garbage collection. To ensure data persists and is not deleted during that process, it has to be pinned to one or more nodes.5 Pinning is a service somebody buys, and services get cancelled, lapse, or outlive the company that sold them.

So the failure is quiet. The token still exists. Transfers still work. The CID in tokenURI is byte-identical to the day it was minted. The gateway returns nothing, and no onchain event records that anything went wrong. This is the widest gap we see between what NFT holders think they own and what the contract actually delivers, and it closes for the price of a pinning contract plus one mirror on a second provider.

ERC-721 and ERC-1155 solve different problems

ERC-1155 was written for a different shape of collection. It specifies an interface for contracts managing multiple token types, where one deployed contract can hold any combination of fungible, non-fungible and semi-fungible tokens keyed by ID.2 It adds balanceOfBatch and safeBatchTransferFrom, so one wallet can hold 40 of item 3 and 1 of item 91 and move both in a single call. It also serves metadata from one URI template with the token ID substituted in, rather than storing a separate string per token.2

That is a design decision, not a preference. A collection of 10,000 genuinely distinct items, each needing its own approvals and its own metadata, fits ERC-721. A collection of 40 item types with hundreds of copies each, which is what game inventories, event tickets and open editions actually are, fits ERC-1155, and forcing it onto ERC-721 means minting and transferring every copy individually.

Neither standard touches the metadata question. Batch transfer is a gas story. Where the JSON lives is still your problem on both.

The royalty standard was never an enforcement mechanism

ERC-2981 is one function. royaltyInfo takes a token ID and a sale price and returns an address and an amount. That is the entire standard, and the EIP states that the royalty payment must be voluntary, because transfer functions such as transferFrom also cover wallet-to-wallet moves and executing one does not always mean a sale occurred.3

The same EIP says the exact mechanism for paying and notifying the recipient will be defined in future EIPs.3 Read that literally. The standard publishes a number. Something outside the standard has to choose to honour it. Every creator royalty ever paid on a secondary sale was paid because a marketplace decided to pay it.

Founders modelling a business on secondary royalties should sit with that sentence before they build a revenue line on top of it. Royalty income has always been marketplace policy rather than a contract right, and policy changes in a blog post.

How enforcement collapsed, and when

The dates matter, because this gets retold loosely. OpenSea launched the Operator Filter in November 2022, a tool that blocked collections from trading on marketplaces which did not enforce creator fees. On 17 August 2023 the company announced it would sunset the filter on 31 August 2023 and move new collections to optional creator fees. Collections that had opted into the filter kept enforced fees until 29 February 2024, after which fees were optional platform-wide.6

OpenSea co-founder and chief executive Devin Finzer framed it in the company's own announcement as creator fees not going away, only the ineffective and unilateral enforcement of them.6 That is a fair description. Enforcement required every marketplace to agree, a single marketplace declining was enough to route around it, and the filter had no way to compel anybody.

What is left is the option that was always available: put the restriction inside the transfer logic and accept a smaller set of venues, or publish the fee as a request. Collections that hard-restrict transfers to approved contracts keep enforcement and lose liquidity. That is the same distribution tradeoff permissioned security tokens make, reached from the opposite direction.

Royalty enforcement on OpenSea, as announced01Filter shipsNovember 2022,fees enforced02Sunsetannounced17 August 202303Filter switchedoff31 August 2023, newcollections04Grace periodends29 February 2024,fees optional

Scroll to see the full diagram

Sixteen months from launch to full sunset. Any revenue model that assumed enforced secondary royalties had that long to be right.

What to settle before you mint

Five decisions, and none of them are the art. Where the metadata JSON lives, and who is paying for that in year five. Where the media file lives, and whether a second copy sits with a different provider. Whether the collection is genuinely one-of-one items or editions, because that decides ERC-721 against ERC-1155. Whether any revenue line depends on secondary royalties, and what the model looks like when that line reads zero. And what right the token actually conveys, written down in one sentence.

The last one is where exposure comes from after launch, and it is not a technical question. A display licence, a membership benefit, an in-game consumable and a fractional claim on an asset's revenue are four different instruments that happen to share a contract interface. Which one you built decides which regulator has an opinion about it. Whether a specific collection was offered as a security turns on the Howey analysis applied to your own facts, and that call sits with your counsel.

Nothing here is legal advice, and nothing here is a recommendation to buy, sell or hold anything. It is design reference. The token is a registry. Whatever the registry points at is the product, and the product still has to be worth owning on its own terms.

Common questions

Is the artwork stored on the blockchain?

Usually not. ERC-721 stores an ownership record and a URI string; the image and metadata normally live off-chain. A study verified by ClubNFT and published in June 2022 found that roughly 90% of NFTs keep artwork and metadata off the blockchain, split about 40% on private servers and about 50% on IPFS, with only about 10% fully onchain.4 You can check any collection by reading its tokenURI.

What is the difference between ERC-721 and ERC-1155?

ERC-721 gives every token a unique ID with a single owner and one transfer at a time. ERC-1155 lets one contract manage many token types at once, including fungible, non-fungible and semi-fungible balances, and adds batch balance reads and batch transfers.2 Pick ERC-721 for genuinely one-of-one items. Pick ERC-1155 for editions, game inventories and tickets, where hundreds of copies of the same item exist.

Can an NFT disappear?

The ownership record cannot, but what it points at can. If metadata sits on a private server, it goes when the server or the hosting bill does. If it sits on IPFS, the content is deleted during garbage collection unless a node keeps it pinned.5 In both cases the token, the transfer history and the URI survive while the image stops loading, and nothing onchain records the break.

Do NFT creators still get royalties?

Only where a marketplace chooses to pay them. ERC-2981 publishes a royalty figure but states the payment must be voluntary, and leaves the paying mechanism to future standards.3 OpenSea sunset its Operator Filter on 31 August 2023 and ended enforced fees for legacy collections on 29 February 2024, making creator fees optional platform-wide.6 Treat royalty income as marketplace policy rather than a contractual right.

Are NFTs securities?

It depends on what the token conveys and how it was sold, not on the file format. A one-of-one artwork, a membership pass, a game item and a fractional claim on an asset's revenue share the same contract interface and sit in different places. In the United States the question runs through the Howey analysis applied to your specific facts and marketing, which is a matter for counsel rather than a technical property of the token.

See Tokenomics Design Services for how this applies in practice.

Sources

  1. EIP-721: Non-Fungible Token Standard
    Ethereum Improvement Proposals, 2018
    Defines ownerOf, balanceOf, transferFrom, approve and the optional metadata extension, where tokenURI returns a string that may point at a JSON file conforming to an optional schema.
  2. EIP-1155: Multi Token Standard
    Ethereum Improvement Proposals, 2018
    One contract managing any combination of fungible, non-fungible and semi-fungible token types, with balanceOfBatch, safeBatchTransferFrom and a single URI template using ID substitution.
  3. EIP-2981: NFT Royalty Standard
    Ethereum Improvement Proposals, 2020
    royaltyInfo signals a royalty receiver and amount. The standard states the payment must be voluntary and leaves the paying mechanism to future EIPs.
  4. The NFT Apocalypse
    Right Click Save (Jason Bailey), 2022
    Published 20 June 2022. Reports a YourNFTs study, independently verified by ClubNFT data scientist Nick Hladek: about 10% of NFTs onchain, about 40% on private servers, about 50% on IPFS.
  5. Persistence, permanence, and pinning
    IPFS Documentation, 2026
    Node storage is finite, so cached content is cleared by garbage collection. Data must be pinned to one or more nodes to persist.
  6. OpenSea Will Make Creator Royalties Optional for NFT Trades
    Decrypt, 2023
    Reports the 17 August 2023 announcement, the 31 August 2023 Operator Filter sunset, the 29 February 2024 end of enforced fees for opted-in collections, and Devin Finzer's statement from the company blog post.

Last reviewed 2026-08

Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.

Book a discovery call

100+ projects advised. Complete tokenomics in 4 to 6 weeks.