Token Standards, Metadata Storage, Royalties

What A Crypto NFT Is At The Technical Level

A crypto NFT is a token on a blockchain that carries a unique identifier, links to metadata describing the asset, and records ownership through a smart contract. That metadata typically points to an image, video, or other file stored off-chain.

The blockchain stores ownership and transfer history. The metadata stores the description and media. The smart contract enforces the rules.

Most people think of NFTs as art or collectibles. That misses the structure. An NFT is three components working together: the token standard that defines how ownership works, the metadata that describes what you own, and the storage layer that holds the actual files.

When any one of those three components fails, the income mechanism breaks. If the metadata storage provider shuts down, your NFT points to nothing. If the marketplace ignores your royalty function, you earn nothing on secondary sales. If you choose the wrong token standard, your NFT becomes illiquid.

This article explains how those three components work, what determines whether they survive, and how they affect your ability to earn from NFT sales and royalty revenue.

Token Standards: ERC-721 vs. ERC-1155

ERC-721 is the original NFT standard on Ethereum. Each token carries a unique identifier and distinct ownership record. ERC-721 tokens cannot be divided into smaller units. Each token has its own metadata URI, typically pointing to a JSON file stored on IPFS or a centralized server.

The tokenURI(uint256 tokenId) function returns a distinct URI per token. When a marketplace or wallet queries the contract, it gets a unique link for each NFT. This structure guarantees per-token metadata but requires one smart contract per collection, creating compatibility constraints and higher gas costs for batch operations.

ERC-1155 is a multi-token standard that supports both fungible and non-fungible tokens in a single contract. It allows batch transfers of multiple tokens at once, reducing transaction and storage costs by 15% or more compared to ERC-721. Certain optimized implementations of ERC-1155 have been tested for transfers of up to 150-200 tokens per second.

ERC-1155 uses uri(uint256 id) with a template string containing an {id} placeholder. Clients substitute the token ID to generate the metadata link. This approach reduces contract complexity but means all tokens in the collection share the same base URI structure.

The standard you choose affects secondary market liquidity. ERC-721 enjoys broader marketplace support. Some NFT platforms only recognize ERC-721, which affects your buyer pool access. ERC-1155 enables cheaper batch sales but has smaller liquidity pools because fewer marketplaces support multi-token bundles.

For high-volume projects or collections with multiple editions, ERC-1155 lowers costs and speeds up transfers. For one-of-one art or collections where per-token metadata uniqueness matters, ERC-721 remains the default. That choice determines gas fees, marketplace compatibility, and ultimately how easy it is to sell.

Most NFT projects store their metadata off-chain. Blockchains are optimized for small, consensus-critical state like ownership and transfers. Storing large strings or media on-chain is expensive and burdensome for nodes. Most systems keep token logic on-chain and put descriptive JSON and media off-chain for cost and scale reasons.

Off-chain metadata typically lives on IPFS, Arweave, or centralized HTTP servers. The smart contract returns a URI pointing to a JSON file, which in turn contains links to image, video, or other media files.

IPFS does not guarantee permanence by itself. Files put into IPFS will eventually age out of the system over time unless they are either frequently accessed or permanently pinned into one or more IPFS servers. Projects typically use pinning services like Pinata or NFT.Storage to ensure their metadata remains available. Those services charge recurring fees, typically $10-$50 per month depending on storage volume.

If the pinning service closes or the creator stops paying, metadata ages out within weeks. Between June and December 2021, only 3.91% of assets and 9.04% of metadata records hosted on IPFS had disappeared. That sounds small, but it represents thousands of NFTs. A majority of asset URLs (88.71%) and metadata URLs (80.69%) are hosted on non-IPFS domains, which means they rely on centralized servers.

Pinning one metadata component and forgetting the other is a common and silent failure. The metadata JSON might be pinned, but the image inside it is not. Or the image is pinned, but the metadata JSON is not. The contract appears functional until a marketplace tries to render the image and finds nothing.

Centralized HTTP storage introduces additional risk. About 80% of OpenSea NFTs from 2021-2022 still point to HTTP URLs. Many are now broken due to domain takeovers, server shutdowns, or companies going out of business. If an NFT’s media is pinned exclusively by one service, that service becomes a single point of failure. Should the company suffer a catastrophic data failure or be legally compelled to remove content, the data could disappear from the IPFS network.

Many projects use centralized IPFS gateways like cloudflare-ipfs.com or infura.io instead of canonical ipfs:// links. If the gateway goes down, the NFT appears broken despite the Content Identifier (CID) still existing on IPFS. This is a presentation failure, not a permanence failure, but it affects marketability.

On-chain storage solves the permanence problem. On-chain projects typically encode metadata as a base64 data URI returned directly by the smart contract. When a marketplace or wallet requests the token’s metadata, the contract generates or returns the JSON and sometimes an SVG image from on-chain storage. The metadata and media are immutable and permanently accessible as long as the blockchain exists.

The tradeoff is cost and flexibility. On-chain storage is expensive. Deploying a 10,000-token collection with fully on-chain metadata and SVG images can cost tens of thousands of dollars in gas. Upload times are slow. And once deployed, the metadata is locked forever. You cannot update the image, fix a typo, or change the description.

Off-chain enables updates but introduces centralization risk that undermines creator control. On-chain guarantees persistence but locks metadata forever. A hybrid approach stores the metadata hash on-chain and the media on Arweave or IPFS. This provides roughly 87% of the security of full on-chain storage at about 15% of the gas cost.

The storage decision directly affects whether your NFT income survives. If your metadata disappears, your NFT loses all value. Flipping becomes impossible. Royalties stop because no one buys a broken asset.

How Royalties Work (And Don’t Work) At The Contract And Marketplace Level

NFT royalties shifted from automatic passive income to marketplace-optional payments between 2022 and 2026. The technical mechanism exists, but enforcement relies on marketplace policy, not smart contract logic.

ERC-2981 is the Ethereum standard that defines how a smart contract signals royalty information. The contract includes a royaltyInfo function that returns the creator’s wallet address and the percentage owed. When a marketplace queries the contract, it receives the royalty terms.

ERC-2981 standardizes how marketplaces interpret royalties, making it easier for creators to receive payment across different platforms. But the standard is informational only. Marketplaces can ignore the royalty function return value entirely. There is no enforcement at the contract layer unless the creator deploys additional restrictions.

ERC-721C, developed by Limit Break and widely adopted by 2025, embeds Transfer Validator contracts that make royalty enforcement mandatory. It restricts NFT transfers to compliant marketplaces only, preventing royalty bypass at the smart contract level. The contract maintains a whitelist of approved marketplaces. If a buyer tries to purchase the NFT on a non-compliant platform, the transfer fails.

This approach guarantees royalty payment but reduces liquidity. Collections using transfer restrictions can only trade on whitelisted marketplaces, creating a moat for compliant platforms but also constraining buyer access. Fewer buyers means lower sale prices and slower turnover, which directly affects creator income.

Over 80% of NFT contracts now deploy automated royalty enforcement, yet only 60-70% of secondary trades reliably pay royalties due to platform fragmentation. The gap exists because many buyers route trades through marketplaces that do not honor on-chain enforcement or that simply ignore ERC-2981 signals.

As of 2026, OpenSea charges a 2.5% marketplace fee on every completed sale and enforces creator royalties automatically on collections that use on-chain enforcement mechanisms like ERC-721C. For collections without on-chain enforcement, royalties follow the platform’s current policy. Blur charges a 0.5% marketplace fee on most Ethereum sales. Buyers on Blur frequently pay reduced or zero royalties on collections that have not deployed on-chain enforcement.

When marketplace fees drop below 1%, royalty payments become a negligible tax on secondary sales. Sellers route through Blur instead of OpenSea to save on fees, and creators receive nothing. About 22% of NFT collections have disabled royalties entirely, meaning those NFTs can be listed on Blur or other platforms without paying the original artist.

OpenSea originally enforced royalties via the Operator Filter Registry in 2023, then abandoned it later that year. This policy flip proved that smart contract enforceability fails without marketplace cooperation. Creator earnings on Ethereum fell over 90% after optional royalties became standard. Marketplaces like Blur and OpenSea made royalties optional, creating a $1.8 billion annual royalty shortfall as of 2024-2025.

The income mechanism works like this: you deploy a contract with ERC-2981 or ERC-721C. If you choose ERC-2981 alone, you rely on marketplace policy. OpenSea might pay, Blur might not. If you choose ERC-721C, you guarantee payment but limit your marketplace to compliant platforms. Fewer platforms means fewer buyers, which means lower sale prices.

The tradeoff is direct. Royalty enforcement reduces liquidity. Optional royalties maximize liquidity but eliminate secondary income. There is no technical solution that delivers both. Regulatory pressure on marketplaces is expected in 2025 and beyond, but as of now, the decision is architectural: lock in royalties and lose buyers, or skip enforcement and lose income.

What Breaks When Storage Providers Fail

Metadata storage failure is the most common and least visible income risk in NFT projects. The contract remains on-chain, ownership records are intact, but the asset points to nothing.

The typical failure sequence starts with unpaid pinning fees. A creator deploys an NFT collection, pins the metadata and images to IPFS via a service like Pinata, and forgets to renew the subscription. After 30-60 days of non-payment, the pinning service stops serving the files. The IPFS CID remains valid, but no nodes host the data. The NFT appears broken on every marketplace.

Gateway risk is the second failure mode. Many projects use centralized IPFS gateways instead of canonical ipfs:// links. If the gateway domain goes offline, every NFT in the collection becomes unrenderable. The data still exists on IPFS, but the presentation layer fails. Buyers see blank images. Sales stop.

Silent cascading failures happen when metadata JSON is pinned but the image inside it is not, or vice versa. The contract returns a valid URI. The marketplace fetches the JSON successfully. But the image link inside the JSON points to an unpinned CID or a dead HTTP server. The NFT displays a title and description but no media. This is extremely common and often goes unnoticed until a buyer complains.

HTTP legacy problems affect older collections. Around 80% of OpenSea NFTs from 2021-2022 still point to HTTP URLs rather than IPFS. Many of those domains have been taken over, shut down, or repurposed. The NFT contract still exists, but the media is gone. One documented case is the DigitalDreams project, which lost 92% of its value in November 2023 when the metadata server went offline, affecting 4,382 tokens.

Content moderation and legal removal add another layer of risk. If an NFT project stores media on a centralized server or a pinning service subject to legal jurisdiction, a court order or platform policy change can remove the files. The blockchain cannot be censored, but the storage layer can.

The income impact is immediate. Broken NFTs do not sell. Marketplaces delist collections with high metadata failure rates. Buyers lose confidence. Royalty income stops because secondary trades stop. The only recovery path is re-pinning the files or migrating to a more permanent storage solution, which requires access to the original media and often to the contract’s admin functions.

Proof-of-permanence via content hash offers partial protection. Some projects store the metadata hash on-chain and the media on Arweave or IPFS. This structure allows anyone to verify that the off-chain data matches what the creator originally published. If the storage provider fails, the community can re-host the data using the on-chain hash as proof of authenticity.

This approach does not prevent failure, but it enables recovery. Without the on-chain hash, there is no way to distinguish authentic metadata from a fake re-upload. With it, the data can be restored and verified.

When Standard Selection And Storage Decisions Matter For Income

Standard selection matters most for high-volume projects and collections with multiple editions. If you plan to mint thousands of tokens or offer batch sales, ERC-1155 reduces gas costs by 15% or more per transfer. Lower costs make your secondary market more liquid because buyers pay less to acquire and resell.

ERC-721 matters for one-of-one art, high-value collectibles, and projects where per-token metadata uniqueness is central to the value proposition. Broader marketplace support means more buyers, which translates to higher sale prices and faster liquidity.

Storage decisions matter immediately and continuously. If you choose centralized HTTP storage, you take on single-point-of-failure risk in exchange for easy updates and low deployment cost. If you choose IPFS with pinning, you commit to recurring fees and monitoring to ensure the data stays available. If you choose on-chain storage, you pay high gas up front and lock the metadata forever.

For projects where income depends on secondary sales and royalties, permanence is worth the cost. A collection that loses its metadata loses all value. For experimental projects, test drops, or short-term campaigns, centralized storage is acceptable because the income window is short and the permanence requirement is low.

Royalty enforcement matters when secondary market income is a significant part of your revenue model. If you expect most income from primary sales, skip ERC-721C and maximize liquidity. If you expect royalties to provide ongoing income, deploy transfer restrictions and whitelist compliant marketplaces. The liquidity cost is real, but the income protection is the only mechanism that works as of 2026.

For collections targeting flippers, maximize liquidity and skip royalty enforcement. Flippers prefer low fees and unrestricted marketplaces. For collections targeting long-term holders and communities, enforce royalties and accept the liquidity tradeoff.

The storage layer, token standard, and royalty mechanism are not separate decisions. They are three components of the same income architecture. Each choice constrains the others. ERC-721C requires whitelist management, which limits marketplace options, which affects liquidity. On-chain storage removes metadata risk but locks in the description and image forever. IPFS pinning requires ongoing payment and monitoring.

The projects that survive are the ones that match the technical architecture to the income model. If your revenue depends on secondary royalties, deploy ERC-721C and use Arweave or fully on-chain storage. If your revenue depends on high-volume primary sales, use ERC-1155 and IPFS with reliable pinning. If your revenue depends on flipping, use ERC-721 with no transfer restrictions and accept that royalties will be optional.

The Takeaway

A crypto NFT is a token on a blockchain that links to metadata describing an asset, typically stored off-chain. The token standard (ERC-721 or ERC-1155) determines gas costs, marketplace compatibility, and liquidity. The storage layer (on-chain, IPFS, or HTTP) determines whether the metadata and media survive. The royalty mechanism (ERC-2981, ERC-721C, or none) determines whether you earn on secondary sales.

Most NFT income failures trace to mismatched architecture. Collections deploy ERC-2981 without ERC-721C and lose royalty income. Projects pin metadata but not images and lose all value when the storage provider fails. Creators choose ERC-1155 for batch efficiency but lose access to ERC-721-only marketplaces.

The technical decisions you make at deployment determine whether your income mechanisms survive marketplace shifts, storage failures, and liquidity constraints. Those decisions are not reversible. Choose the architecture that matches your income model, monitor your storage layer continuously, and understand that royalty enforcement and liquidity are inversely correlated. You cannot maximize both.

Frequently Asked Questions

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

ERC-721 assigns a unique identifier to each token with distinct metadata per NFT, requiring one smart contract per collection and higher gas costs. ERC-1155 supports multiple token types in a single contract, enabling batch transfers and reducing gas costs by 15% or more, but uses a shared base URI structure. ERC-721 has broader marketplace support; ERC-1155 offers better efficiency for high-volume projects.

Why do NFT images disappear and how can creators prevent it?

NFT images disappear when off-chain storage providers shut down, pinning fees go unpaid, or centralized servers fail. IPFS files age out unless permanently pinned through services like Pinata or NFT.Storage. Creators prevent failure by using paid pinning services with recurring monitoring, storing metadata on Arweave for permanent storage, or deploying fully on-chain metadata and images despite higher gas costs.

Do NFT royalties automatically pay creators on secondary sales?

No. ERC-2981 signals royalty information but marketplaces can ignore it. Only NFTs using ERC-721C or similar transfer restriction contracts enforce royalties by blocking sales on non-compliant platforms. As of 2026, 60-70% of secondary trades pay royalties despite 80% of contracts having enforcement mechanisms. Blur and other low-fee marketplaces often skip royalties, creating an estimated $1.8 billion annual shortfall for creators.

What happens to NFT value if metadata storage fails?

NFT value drops to near zero when metadata or images become inaccessible. The blockchain ownership record remains intact, but marketplaces cannot render the asset. Buyers see broken images, sales stop, and royalty income ceases. Recovery requires re-pinning original files or migrating to new storage, which is only possible if the creator retained the source media and has contract admin access.

Should NFT creators use on-chain or off-chain metadata storage?

On-chain storage guarantees permanence but costs significantly more in gas and locks metadata forever without update capability. Off-chain storage via IPFS or Arweave reduces costs and allows updates but requires ongoing pinning fees and monitoring. Hybrid approaches store metadata hashes on-chain with media on IPFS or Arweave, providing 87% of on-chain security at 15% of the cost. The choice depends on income model, budget, and permanence requirements.