What is a token standard?

A token standard is a technical specification that sets out which functions a token program should provide, what inputs it accepts, and how it reports results to wallets and other applications. It lets tokens created by different developers be recognized and called through one shared set of rules.

Think of a standard as an interface agreement: it specifies "how to communicate externally", but it does not decide any project's supply, purpose, administrative permissions or offchain rights. Two tokens can follow the same standard while using different code, holding different permissions and representing entirely different things.

What happens without a shared standard

If every token named its balance query, transfer and approval functions in its own way, wallets and applications would have to write a separate connection for each one. Even a new token that transfers correctly might not be displayed by existing wallets, or be callable by other onchain programs.

A shared standard sets uniform entry points for common operations. A wallet knows how to ask for a balance, an application knows how to request a transfer, a block explorer knows which events to read, and other programs can call multiple tokens in the same format. Developers do not have to know every specific token in advance to provide basic support.

What a standard improves is software compatibility, not token quality. Once interfaces are uniform, a faulty or malicious implementation may also find it easier to connect to existing applications, so anyone using one still has to verify the specific code and permissions.

What a standard usually specifies

The scope of a token standard varies by network and token type. Common content falls into the following categories.

Query functions

A standard can specify how to query the balance of an address, a token's total supply, or who currently controls a particular individual number. A uniform way to query lets wallets and applications display basic information.

Query results only reflect the data the program currently returns. A standard does not verify whether a display name is genuine, whether supply has offchain backing, and it does not guarantee that the additional material describing a token — its metadata — stays available at its link over the long term.

Transfer functions

A standard can specify how a sender transfers tokens to a recipient, which parameters a call requires, and how it should respond on success or failure. For tokens with individual numbers, a transfer also has to identify the specific number.

Some standards offer a safer transfer method that checks whether a recipient program knows how to handle the tokens it receives. That can reduce certain kinds of mistaken transfer, but it cannot prevent losses from a wrong address, a malicious approval or a program defect.

Approval functions

An approval lets a holder allow another address or program to act on their behalf within set limits. A holder can, for example, approve an application to transfer a certain amount of fungible tokens, or authorize an operator to manage a group of individually numbered tokens.

A standard specifies how to create, query and revoke an approval, but it does not decide whether a user should grant one. The size of the allowance, how long it lasts and how the approved program behaves still have to be judged from the specific implementation and by the person using it.

Events and record formats

When an onchain program carries out a transfer, mint or approval, it can emit structured events. An event is a signal about an execution record for applications to read, and wallets, block explorers and data services can use it to update interfaces or build an index.

An event cannot substitute for final state. An application still has to confirm whether the transaction succeeded and read current data under the network rules; seeing a single unconfirmed event, or one from the wrong contract, is not enough to prove a balance has validly changed.

Optional functions and extensions

A standard may list a name, ticker, metadata, or a function listing every individual number — enumeration — as optional, and it may also allow transfer fees, freezing, pausing or other extensions to be enabled. An application cannot assume every optional function exists simply because a token claims to adopt a given standard.

Extensions may also be incompatible with one another, or require wallets to adapt deliberately. Identical basic transfers do not mean an older application can understand every permission and data field added later.

A standard, an implementation and a token are not the same thing

A standard is an agreement about functionality, stating how a compatible program should respond externally. An implementation is the specific code a developer writes and deploys according to that agreement. A token is the onchain record and units managed by one particular implementation.

One standard can have many code implementations; the same implementation can also be used to create several different tokens. An implementation can further add fees, freezing, lists, upgrades or other logic beyond what the standard requires.

"Adopting a standard" therefore only indicates an intention to support one set of interfaces. It cannot prove the code is free of defects, nor show that every interface was implemented correctly. When integrating, an application has to check the deployed address, the actual returned results, any additional permissions and exceptional behaviour.

How a standard forms and gets adopted

A token standard usually appears first as a technical proposal, a specification document or a shared program. The authors set out the problem to solve, the interface requirements and the reasoning behind the design; after the community and developers discuss it, the proposal may reach a relatively stable state, or it may keep changing or stop progressing.

Document status and market adoption are two separate things. One proposal can be written out completely yet rarely used; another standard may already have numerous implementations before it is finalized. Whether wallets and applications support it depends on actual deployments, usage needs and developers' choices — not on the number itself.

A standard being updated also does not necessarily change tokens already deployed. An older contract may keep running on the older interface, while new functionality arrives through a new contract, a new version or an optional extension. When reading a standard, confirm the network, version, status and specific implementation at the same time.

The shared interface for fungible tokens

Fungible tokens are recorded by amount, and equal units can usually be exchanged for one another. Standards of this kind commonly specify balance queries, total supply, transfers, and an approval function allowing another address to transfer on the holder's behalf up to a set allowance.

On Ethereum, for instance, application-layer standard proposals are called Ethereum Request for Comments (ERC). ERC-20 is the ERC standard specifying the basic interfaces for fungible tokens, letting wallets and onchain applications query balances, request transfers and handle approvals in a shared way.

ERC-20 does not require a token to use a fixed supply, and it does not prohibit developers from adding extra logic such as pausing, transfer fees or lists. Display information such as a name, ticker and decimal places also cannot substitute for a contract address in identifying a token uniquely.

The shared interface for individually numbered tokens

Non-fungible tokens (NFTs) require each number to be tracked separately. The corresponding standards usually specify how to query the holder of a number, transfer a specified number, and authorize another address to operate on a single token or a group of them.

These interfaces are implemented differently across networks. On Ethereum, for example, ERC-721 specifies basic operations such as holding, transferring and approving individually numbered tokens, while metadata and a complete list of numbers belong to optional extensions. Adopting that standard does not mean an image or other content is necessarily stored onchain, and it does not prove that the offchain object a token represents actually exists.

Some standards also let one program manage fungible units, individually numbered units, or multiple copies under the same number at once. They serve different record-keeping needs; this does not mean one standard is generally superior to another.

How different networks approach standardization

A token standard does not have to mean "deploy one contract per token, each implementing the same interface". Different blockchains can achieve compatibility through protocol rules, a shared program or optional extensions.

For example, Solana's token program provides instructions for minting, account records, transfers and approvals in one place. Each mint records a particular token's supply and permissions, while wallets and applications handle many mints through the same token program.

Solana also offers Token Extensions, a token program to which additional functionality can be added. When creating a token, a developer can select extensions as needed; some extensions cannot be added after initialization, and some may be incompatible with each other. That shows "using the same token program" is still not enough to conclude that two tokens behave identically.

When the same standard name or a similar interface appears across networks, do not assume addresses, permissions and transaction formats carry over directly either. A standard's scope is always tied to the specific network and execution environment.

Compatible does not mean behaviour is identical

When a wallet or application says it "supports a standard", that usually means it can handle the basic interfaces the standard requires. Actual compatibility can still be affected by the following:

• a token does not fully implement the required functions, or returns results in an unexpected way;
• a token adds transfer fees, pausing, freezing or list rules;
• an application does not support certain optional extensions;
• a recipient program cannot handle a particular transfer method;
• a proxy upgrade structure, which switches the executing code behind a fixed entry point, has changed the actual logic;
• identically named tokens are deployed on different networks or at different addresses.

Interface compatibility testing therefore has to address the specific code and the specific results of a call. A "standard-compliant" label is not a security audit in itself, nor a guarantee that future behaviour will not change.

What a standard does not specify

A token standard usually does not substitute for the following information:

• who can keep minting, freezing, pausing or upgrading the token;
• how the total amount is distributed and whether that will change;
• what practical use or market demand the token has;
• whether a name, icon and metadata are maintained by a trustworthy source;
• whether the reserves, physical goods or services a token claims to correspond to exist;
• whether a holder has redemption, governance or other offchain rights.

These questions require examining the specific implementation, permissions and offchain arrangements. A technical standard solves only part of the software interaction problem; it cannot carry the burden of proving authenticity, value or legal effect.

FAQ

Must a token follow a standard?

Not necessarily. A developer can create a custom interface, but wallets and applications then need extra adaptation. Adopting a widely supported standard usually makes basic compatibility easier to obtain.

Is a newer standard number better?

That cannot be judged this way. A newer standard may add functionality, but it may also have less support, still be changing, or be unsuitable for a given purpose. Check the proposal's status, actual adoption and the specific requirement.

Can one token adopt several standards?

Possibly. One implementation can support several interfaces at once, or add extensions on top of a base standard. Whether those interfaces work together correctly still requires checking the specific code.

Does following a standard mean a token displays in every wallet?

That is not guaranteed. A wallet also has to support the relevant network, the version of the standard and any optional functions, and recognize the correct contract or mint. Metadata such as a name and icon may also require an additional source.

Can a standard guarantee a token is safe?

No. A standard only specifies shared interfaces or behavioural requirements. Code defects, administrative permissions, external data, user approvals and the underlying network can all still create risk.

Related concepts

Continue with crypto token, smart contract, blockchain and crypto wallet, or return to the Crypto Glossary.

Sources

• NISTIR 8301: Blockchain Networks: Token Design and Management Overview — token data models, protocol and account operations, and the differing scope of standards.
• Ethereum.org: token standards — the role of token interfaces in compatibility between wallets, applications and onchain programs.
• Ethereum application-layer standards process — the ERC category, standard proposal statuses and the scope of application interoperability.
• Ethereum fungible token standard ERC-20 — basic interfaces for balances, transfers, approvals and events.
• Ethereum non-fungible token standard ERC-721 — holding, transferring, approving and optional extensions for individually numbered tokens.
• Solana Docs: tokens and extensions — the shared token program, mints, token accounts and optional extensions.