Skip to content
Financial Context Wiki

Token Standard

Token standards are shared interfaces for issuing, transferring, approving, and discovering blockchain tokens. This entry compares ERC-20, ERC-721, and ERC-1155, and explains what compatibility does and does not guarantee.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A token standard is a published interface that tells wallets, exchanges, applications, and other contracts how a token can be identified and used. It defines expected functions, events, and rules; it does not certify a token’s value, liquidity, code quality, or issuer.

The most common Ethereum standards serve different asset models:

  • ERC-20 represents fungible units: each unit is interchangeable with another unit of the same token.
  • ERC-721 represents individually identified, non-fungible tokens, such as a single collectible or title.
  • ERC-1155 can represent multiple fungible, non-fungible, or semi-fungible token types in one contract and supports batch operations.

Standardization lets an integration rely on a known interface instead of bespoke contract logic. Compatibility is therefore a systems property, not a safety guarantee: an implementation can follow an interface and still include malicious permissions, misleading metadata, transfer restrictions, or economic weaknesses.

How it works

Standards specify callable functions and emitted events. A typical ERC-20 integration checks balanceOf, totalSupply, transfer, approve, transferFrom, and allowance; an ERC-721 integration checks ownership and approvals through ownerOf, safeTransferFrom, approve, setApprovalForAll, and often tokenURI. ERC-1155 adds balanceOfBatch, safeBatchTransferFrom, and a shared URI convention for many token IDs.

ERC-165 lets a contract report which interfaces it supports through supportsInterface. Applications can use that signal to select an integration path, but they should still handle failed calls and verify the contract address. Standards describe the boundary between components; the blockchain still executes the specific contract code, access controls, hooks, and metadata logic behind that boundary.

Example

Suppose a marketplace accepts an asset advertised as an NFT. The application can first verify the network and contract address, detect the ERC-721 interface, read ownership, and simulate a small transfer. It should then inspect approval scope, transfer restrictions, upgrade controls, and whether metadata is mutable or hosted off-chain.

If the same marketplace also accepts game items, ERC-1155 may be a better fit because one contract can hold many token IDs and batch transfers can reduce transaction overhead. The standard helps the marketplace call the right methods; it does not establish that an item is authentic, scarce, liquid, or legally enforceable.

Risks

  • Non-conforming or deceptive implementations: a contract can expose familiar names while changing expected behavior or adding transfer restrictions.
  • Authorization risk: broad approve or operator permissions can let a compromised spender move assets; revoke allowances that are no longer needed.
  • Hooks and reentrancy: receiver callbacks in NFT and multi-token transfers create additional execution paths and contract interactions.
  • Metadata and identity risk: tokenURI or URI data can change, disappear, or point to content that does not match the claimed asset.
  • Administrative and economic risk: upgrade keys, pause or blacklist controls, royalties, fees, and shallow liquidity can dominate the practical outcome.

Crypto transactions are often irreversible. Confirm the chain, contract address, interface behavior, permissions, and exit liquidity before signing; an audit or a standard alone cannot remove these risks.

Common misconceptions

Does a standard make a token safe?

No. A standard describes interoperability expectations. Safety still depends on the implementation, privileged roles, upgrade path, token economics, front end, and the surrounding market.

Are ERC-20, ERC-721, and ERC-1155 interchangeable?

No. ERC-20 balances are fungible, ERC-721 ownership is tracked per token ID, and ERC-1155 can track many token types. An application must use the matching transfer, approval, balance, and event model.

Is a wallet or marketplace endorsement proof of authenticity?

No. An integration usually proves only that a contract matched an expected interface. Verify the canonical contract address, provenance, metadata behavior, and issuer or collection claims independently.

Sources

Navigation

Search the wiki...