NFT Token Development: Choosing Standards and Designing the Token

An NFT is a token ID inside a smart contract, mapped to an owner address and a pointer to metadata. Developing one is mostly about choosing the right standard and extensions, deciding where metadata lives, and keeping admin powers honest.

This page is about the token itself. For contract engineering practice and security, see the smart contract NFT development guide.

What makes a token non-fungible

A fungible token, such as an ERC-20, tracks balances: you own 50 units, and any unit equals any other. A non-fungible token tracks individual IDs: you own token 4021 of a specific contract. The pair of contract address and token ID is globally unique. Everything else people associate with NFTs, such as images, traits and perks, is attached through metadata or application logic.

The main standards

ERC-721 defines ownership, transfer, approvals and the tokenURI function. ERC-1155 adds balances per ID and batch transfers, which saves gas when a player moves twenty items at once. A common mistake is using ERC-1155 for unique art because it is "more modern"; many collectors and tools still treat ERC-721 as the default for one-of-a-kind work.

Extensions worth knowing

• EIP-2981 (royalties). Lets the contract report a royalty recipient and amount for any sale price. Marketplaces may honor it; nothing forces them to. Read the spec.
• ERC-4907 (rentals). Adds a "user" role with an expiry, separate from the owner. Useful for game items and access passes.
• ERC-5192 (soulbound). Marks a token as locked to its holder. Good for credentials, attendance badges and membership that should not be resold.
• ERC-6551 (token-bound accounts). Gives each NFT its own smart contract wallet, so a character can hold its own items.
• ERC-4906 (metadata update events). Tells marketplaces to refresh metadata after a reveal or a trait change.

How metadata actually works

The contract stores a base URI or per-token URI. Calling tokenURI(id) returns a link to a JSON file with a name, description, image link and an attributes array. Marketplaces read that JSON to show the item. Where the JSON and image live is a durability decision:

• Your own web server. Easy to change, which is also the problem: you can alter or lose the asset.
• IPFS. Content-addressed, so the hash proves the file has not changed. Files must be pinned by someone or they disappear. See IPFS development for how pinning works.
• Arweave. Pay once for long-term storage.
• Fully on-chain. Image and JSON generated by the contract itself. Expensive for large media, ideal for small SVG or pixel art.

Design decisions before you deploy

1. Supply. Fixed cap, open edition with a time window, or issuer-controlled. Write it into the contract if you promise it.
2. Mutability. Can metadata change? Dynamic NFTs for games or tickets need it; art usually should not. If it can change, say who can change it.
3. Transfer rules. Freely transferable, soulbound, or restricted to approved marketplaces. Restrictions suit tickets and credentials, less so collectibles.
4. Admin roles. Who can mint, pause, change URIs, withdraw funds. Use a multisig for anything valuable.
5. Upgradeability. Proxies allow fixes but also allow the issuer to change rules later. Collectors often prefer immutable token contracts.

Use cases where tokens still earn their place

Ticketing and memberships, in-game items, credentials, loyalty rewards and records of vaulted physical goods have outlasted the 2021 boom because the token does something specific. Pure collectibles work when there is a real community, which is a marketing and product problem rather than a token-standard problem. If your token is fungible after all, for example a points system, an ERC-20 from the Ethereum token development guide may be the right tool.

Frequently asked questions