What Is an NFT? Ten Beliefs, and What the Standard Actually Says

Few subjects in this industry have produced more confident wrong statements per paragraph than the ownership record known as a non-fungible token. The beliefs are consistent: that it is a picture, that the picture is stored on chain, that buying one transfers the art, that it cannot be copied. Each of those is true of something adjacent to the standard and false of the standard itself, which is the reason the discussion never converges. The way out is to fix the definition first and then check the beliefs against it one at a time.

The definition is short. A non-fungible token is an entry in a smart contract, identified by the contract’s address plus a number, whose standard defines how it can be transferred, how it can be queried, and what it may point to. Everything else that people associate with the word — art, profile pictures, concert tickets, domain names — is a use of that structure rather than a property of it. Ten commonly held beliefs follow, each with the piece of the standard it mistakes for the whole.

Belief one: an NFT is a picture

The picture is content. The token is a record that says one address holds a numbered entry in a specific contract. When a market displays the image, it reads the pointer in the record, fetches what is at the other end, and draws it for you; the display is a service performed by the market, not a property of the token.

This is not a distinction without consequences. A token whose pointer leads to a website that stopped paying for hosting will display nothing, while remaining exactly as valid on chain as it was on the day it was minted. The record and the appearance are two different things with two different failure modes, which is why two identical-looking screenshots can represent a token whose content is permanent and a token whose content is already gone.

Belief two: the picture is stored on the blockchain

Storing content in shared state is expensive by construction, because every validating machine has to be able to process what is written. That cost is why almost no image lives on the ledger itself. What is usually stored is a pointer: either a link to an ordinary web address, which can rot, or a content-addressed identifier computed from the file’s contents, which cannot be forged and does not by itself guarantee that anybody still has the file.

The practical difference between the two kinds of pointer is worth knowing before buying anything. A token pointing at an ordinary server is a token whose appearance depends on a company continuing to operate. A token pointing at a content-addressed identifier is a token whose appearance can be restored by anyone who still holds a copy of the file, which is a stronger promise and not an absolute one, since the file has to exist somewhere to be served.

Belief three: buying one transfers the copyright

Copyright is a legal right that belongs to whoever created the work, and transferring a token does not transfer it. What a buyer receives on chain is the ability to transfer the record and a public proof of holding it. What a buyer receives off chain is whatever the project’s terms say, and those terms vary from nothing at all to a broad licence allowing commercial use of the image.

The distinction becomes concrete when money is involved. A holder who licenses a character from an image they own a token for, without a grant permitting it, is selling something they do not have. A project that promises commercial rights in a tweet and grants nothing in its terms has made a promise that no court would enforce, and the terms are the document that matters, not the announcement.

A third category is worth naming separately: rights to things that exist outside the ledger. A token said to represent a physical object, a membership or a share of revenue is a claim whose enforcement depends on a contract with an entity, and the entity is not the token. Where the claim is undocumented, the holder has purchased an entry and a story.

Belief four: it cannot be copied

The content copies perfectly, at no cost, and anybody can do it. What cannot be copied is the entry: a specific numbered record inside a specific contract, pointing at a specific pointer, with one address as its holder. The value of that entry, where it has any, comes from its provenance and from the fact that the market for it recognises one contract and not another.

This is the same structure as a signed first edition of a book. The text is identical in every copy and the value is in the specific object and its chain of custody. Nobody who understands books finds that arrangement confusing, and the reason the token version provokes arguments is that the content is trivially copyable while the record is not, so the two intuitions — it is unique, it is everywhere — are both correct about different objects.

Belief five: it is all worthless

The standard is indifferent to value, in the way that a database schema is. What made the category famous was a speculative episode in which prices for certain collections rose by orders of magnitude and then fell, and it is reasonable to conclude from that episode that most of those prices were a bubble. It is not reasonable to conclude that the structure has no uses, because the structure is being used for things that never had a price to begin with.

The useful version of the sceptical position is narrower and harder to argue with: a token’s value comes from a market that recognises it, and a market can stop recognising anything. That is a statement about collectibles and about platform-specific assets, and it applies equally to a domain name on a network or an item in a game whose servers may close.

Belief six: this was a 2021 phenomenon and it is over

Two different things are being described by that sentence. As a trading category, the market contracted by orders of magnitude from its peak, and the speculative portion of it has not returned. As a technical standard, adoption continued: tickets, attendance credentials, membership passes, in-game items, naming records, and certificates issued by institutions are all deployments of the same structure, and most of them are designed to be non-transferable or transferable under restrictions.

The pattern is familiar from other technologies. A capability arrives with a speculative use because speculation is what pays for the infrastructure, and the durable applications show up afterwards with less attention. The durable applications of this one are mostly boring, which is the ordinary sign that something has stopped being a story and become a tool.

Belief seven: minting is environmentally ruinous

The environmental cost of a token is a function of the chain it is issued on rather than of the token standard. On a network that secures itself with computation, every transaction contributes to a continuous energy expenditure, which made the early criticism accurate. On networks that secure themselves with a bond, the marginal cost of an additional transaction is close to negligible, and most of the tokens issued today are on such networks.

The correct version of the claim is therefore specific and checkable: which chain, and what is its current energy profile. A statement about the category as a whole was defensible in 2021 and is not now, and treating it as a permanent property of the technology is a good example of how a correct criticism can outlive its accuracy.

Belief eight: a token can hold anything

Size is the constraint, and it is not a temporary limitation. Shared state is priced for scarcity, so a file of any realistic size cannot go into it at a cost anyone would pay. The available designs all route around the constraint: store the content elsewhere and commit to its hash, store a small generative program instead of an image, or store nothing and rely on a database.

Each of those is a legitimate engineering choice with a different promise. A generative token whose instructions live on chain produces its own image wherever it is rendered, which makes the artwork as durable as the network. A token with an off-chain pointer is as durable as the place the content lives. A buyer who knows which one they are looking at knows what they own.

Belief nine: it lives in my wallet

The wallet holds the key that can move the record; the record itself lives in the contract. That is why a token can be sent without the wallet’s owner doing anything, and why a wallet can display a token it does not control if somebody deliberately transfers one to an address the user owns.

Two consequences follow that surprise holders. The first is that a wallet’s display is a convenience rather than a custody statement, which is why an unsolicited token appearing in a wallet should be treated as a message rather than as an asset. The second is that the mechanisms that govern a token are defined by its contract, which may include the ability to freeze transfers, to pause the whole collection, or to change what the pointer points at, if the contract’s author included those powers. A record of ownership is only as final as the program that maintains it.

Belief ten: they are all the same kind of thing

Standards differ in ways that change what a holder can rely on. One standard defines a single unique item per identifier, which is what most people mean by the term. A second defines a system in which a single identifier can represent a quantity of identical units as well as unique ones, which is used for collections that mix both. And a third, a later addition, defines how a royalty percentage is expressed so that marketplaces can read it, which is information rather than enforcement: whether a royalty is paid depends on the venue and on the current norms of the market, not on the code.

The royalty question is worth understanding as a case study, because it shows how a technical feature with an obvious intent can be neutralised by the market around it. A standard that publishes a number cannot compel anyone to honour it, and competing venues discovered they could attract volume by not honouring it. The result is a divergence between what the token advertises and what it collects, which is a structural feature of any mechanism that relies on voluntary compliance.

How a transfer actually happens

Moving a token is a single call to a function on its contract, and the function performs four steps in order. It checks whether the caller is permitted to move that specific token, either as its current holder or as an address the holder has approved. It writes the new holder into the contract’s ownership mapping. It clears the previous approval so that an old permission does not survive the sale. And it emits an event so that wallets, marketplaces and indexers can notice the change without scanning the whole chain.

Two details of that sequence explain most of the incidents described as thefts. The first is that approvals are what the market uses to list an item: a venue needs either the token itself or the holder’s permission to move it, and the difference between those two arrangements is the difference between a counterparty risk and a signature risk. When a venue holds the token, the holder is relying on that venue; when the venue holds an approval, the holder is relying on nobody, and anyone who obtains the same approval can move the item.

The second is that the contract may impose additional conditions that were chosen by whoever deployed it. Some contracts allow the issuer to freeze transfers, pause the whole collection, or replace the address that the metadata points to. Those powers are visible in the contract’s code and are almost never mentioned in the sales pitch, which makes reading the contract the only reliable check before buying.

Provenance, series size and lazy minting

The provenance story begins with the transaction that created the token, and that record cannot be rewritten without rewriting the chain. What can be rewritten, depending on the contract, is everything downstream of it: the metadata, the pointer, and the conditions under which the token may move.

Series size is the other half of the scarcity claim and it is enforced by the contract rather than by the market: a fixed number of identifiers can exist, or the contract may allow the issuer to create more later. A buyer comparing two collections is comparing two sets of promises about that, and the promises live in code.

A practice called lazy minting changes the timing of the creation event in a way worth understanding. The creator signs a permission rather than paying to create the token, and the token comes into existence when a buyer redeems that signature. The creator saves the cost and the buyer becomes the first holder, which works well until the signature’s conditions, its expiry or the creator’s willingness to honour it become the question.

Two quiet failure modes

Neither of the two problems that produce most of the disappointment after a purchase is an attack, and both are design choices visible in the contract.

The first is a mutable pointer. If the contract lets its owner change where the metadata points, then the thing displayed next to a token can change after the sale, while the record of ownership stays exactly as it was. A buyer who assumed the pointer was fixed has bought a permanent entry that may not point at a permanent thing, and the check is a single field in the contract’s interface.

The second is a pointer to nothing. Content hosted on an ordinary web address depends on that address continuing to serve the file, and a company that stops paying for hosting takes the appearance of a collection with it while leaving every ownership record intact. Content addressing mitigates this by making the pointer verifiable rather than revocable, and it does not guarantee that the file exists, which is why the durable version of the promise requires a rendering step that the token itself does not perform.

The market that grew around the standard

Tokens trade in a structure that is unlike any other market, and the differences explain most of what holders find surprising about prices. A venue is a contract plus an order system: listings are usually signed messages rather than on-chain transfers, and the transfer happens only when a buyer redeems a signature and pays the settlement cost. That design keeps listing cheap, and it means the visible market is a collection of signatures rather than a book of resting orders.

Aggregators then combine signatures from several venues into one view, which is where a “floor price” comes from. It is the lowest asking price visible across the sources the aggregator reads, not a price at which anything has to trade. The distinction matters when a collection is illiquid: a floor of a hundred units with no bids below it does not mean that selling is easy, and the realised sale price for a single item has historically been well below the floor when a holder needed to exit quickly.

Two practices distort those readings further, and both are visible on chain. Self-dealing between addresses controlled by one party can create the appearance of volume and of higher prices, which was used to attract rankings and reward distributions until marketplaces started discounting it. And a collection can be listed on several venues at once, so the total quoted supply may exceed the number of items anyone intends to sell.

The practical summary is that this market quotes intentions rather than executions. A reader who wants a price should look for completed sales of comparable items over a period rather than for a headline floor, because the floor is an asking price and the completed sales are the only evidence of what a buyer actually agreed to pay.

Where the structure is used without a price

The deployments that generate the least attention are the ones where the token is a credential. Event tickets that cannot be resold outside the issuer’s rules, attendance records that prove participation without revealing identity, membership passes that gate access to a service, and certificates that an institution can revoke if the underlying achievement is withdrawn: all of these are uses of the same structure, and several are uses that a database could not serve as well because the point is that the record is verifiable by a third party.

Naming records are a second category, where the token is the registry entry itself, which makes the analogy to a domain name exact and exposes the same dependency: the value of the name comes from the namespace contract, and the namespace belongs to whoever governs it. In-game items are a third, and their weakness is familiar: an item is only portable between games if the games agree, and agreement is a commercial matter rather than a technical one.

Read together, the non-speculative uses share a property. Each is a case where a third party needs to verify a claim about a person, an event or an asset, and where the issuing party benefits from a record it cannot quietly alter. That is a narrow and defensible application of an uneditable ledger, and it is nothing like the story the market told in 2021.

Three checks before buying anything

Three questions turn the beliefs above into a procedure. Who can interfere with the record — can the contract’s owner freeze transfers, pause the collection, or change the pointer? Where does the content actually live, and who is paying for it to stay there? And what does the licence permit, in the document rather than in the announcement?

The answers are usually available in ten minutes: a verified contract’s code shows what powers exist, a metadata record shows what the pointer is, and the project’s terms show what the licence grants. None of the three requires technical expertise, and all three are more informative than a floor price.

What the category taught the industry

Two lessons from this episode have outlasted the prices and are now baked into how digital assets are designed. The first is that content durability is a separate problem from record durability, and that promising the second while silently failing at the first is the most reliable way to disappoint a user. The record is the easy part, because the ledger holds it; the content is the hard part, and it lives where nobody’s ledger can protect it.

The second is that a standard can publish a rule without enforcing it, and that markets will find the configuration that suits them. Royalty information, transfer restrictions and even the immutability of a pointer are all properties that depend on who wrote the contract and who honours it. That is a different lesson from the one the market learned about speculation, and it is the more useful one, because it applies to every tokenised claim built since: read the contract, read the terms, and treat the interface as marketing until the documentation says otherwise.