Token Standards Explained: ERC-20, ERC-721, ERC-1155 and More

A token standard is a published specification that tells a token contract which functions to expose and which events to emit. Wallets, exchanges and apps can then handle any compliant token without custom code for each one. This guide covers the standards you will meet most often (ERC-20, ERC-721, ERC-1155, and their equivalents on Tron and Solana). It also covers how ERC-20 decimals work and what to check before you integrate a token into a payment flow.

TL;DR

• A token standard defines an interface (functions and events) plus behavioral rules, so software can interact with any compliant token the same way.
• ERC-20 is for fungible tokens, ERC-721 for unique NFTs, and ERC-1155 for many token types in one contract.
• TRC-20 mirrors ERC-20 on Tron, and Solana uses its own SPL token program, so “same standard” never means “same chain”.
• On-chain amounts are integers. The optional decimals value tells you where to put the decimal point for display.
• Compliance is not guaranteed. Test each token’s real behavior before you rely on it.

Table of Contents

• What a token standard actually defines
• ERC-20: the fungible token standard
• ERC-20 decimals: handling amounts correctly
• ERC-721: non-fungible tokens
• ERC-1155: many token types in one contract
• Comparing the three Ethereum standards
• Token standards on other chains
• What to check before you integrate a token
• Perspective: why standards are only half the job
• Putting standards to work with Chaingateway
• FAQ
• Sources

What a token standard actually defines

A token is not a native coin. It is a record kept inside a smart contract: who holds how much, and what rules govern moving it. Without a shared specification, every token would expose its own function names and every wallet would need bespoke code to read balances or send transfers.

A standard fixes that. According to ethereum.org’s token standards page, standards define how tokens behave and interact, which keeps smart contracts composable and lets new tokens work with existing decentralized exchanges and applications. NIST’s overview of token design describes ERCs as providing function and event declarations, constraints and requirements, and sometimes reference implementations.

In practice a standard gives you four things:

1. Callable functions, such as reading a balance or moving tokens.
2. Events, which the contract emits so outside software can follow activity.
3. Data types and constraints, such as how amounts are represented.
4. Behavioral requirements, such as which calls must trigger which event.

On Ethereum, these specifications are proposed as ERCs, the application-level category of Ethereum Improvement Proposals. Other chains have their own processes and names, but the idea carries over.

ERC-20: the fungible token standard

ERC-20 was created in 2015 and defines a standard API for tokens within smart contracts, so wallets and decentralized exchanges can reuse them. “Fungible” means every unit is interchangeable with every other unit, like dollars or kilograms of gold. Stablecoins, governance tokens and most payment tokens follow it.

The interface, as listed in the ERC-20 documentation, includes:

Function or event	What it does
totalSupply	Returns the total number of tokens in existence
balanceOf	Returns the balance of one address
transfer	Moves tokens from the caller to another address
approve	Lets another address (a spender) move up to a set amount of your tokens
allowance	Returns how much a spender may still move on an owner’s behalf
transferFrom	Moves tokens on behalf of an owner, using an approval
name, symbol, decimals	Descriptive metadata, commonly present
Transfer, Approval events	Emitted on transfers and approvals

The specification says transfers must trigger the Transfer event and successful approve calls must trigger Approval. That rule is what makes payment detection possible: you can watch for events instead of polling every address. We go deeper on this in our guide to the ERC-20 Transfer event, and our ERC-20 standard overview walks through the full interface.

The approve and transferFrom pattern

The two-step pattern confuses newcomers. With transfer, the token holder sends tokens directly. With approve plus transferFrom, the holder first authorizes a spender, and the spender later pulls tokens. This is how a decentralized exchange or a subscription contract takes payment without holding your keys. If you only need to send tokens from a wallet you control, transfer is all you need. Our walkthrough on how to send ERC-20 tokens compares the wallet, code and API methods.

ERC-20 decimals: handling amounts correctly

Smart contracts do not store fractions. Every balance is an integer, and decimals tells you how many of the rightmost digits are the fractional part. The ERC-20 specification makes the method optional and gives an example: with 8 decimals, you divide the token amount by 100000000 to get its user representation.

That has three practical consequences.

Always read decimals from the contract. Do not hardcode a value for all tokens. Two tokens that both display as “1.00” can be stored as very different integers.

Do the math with integers or big-number types. Raw amounts can exceed what a standard floating-point number holds exactly. Use BigInt, BigNumber, or your language’s decimal type, and only format for display at the last step.

Treat a missing decimals method as a case to handle. Since the method is optional, a compliant token might not expose it. Decide on a fallback, such as rejecting the token or requiring manual configuration, rather than silently assuming a default.

A worked example: a token with 6 decimals shows a raw balance of 2500000. Dividing by 10^6 gives 2.5 tokens. To send 0.75 tokens you submit 750000, not 0.75. Submitting the display value by mistake would send a vanishingly small amount, and the transaction would still succeed.

ERC-721: non-fungible tokens

Where ERC-20 treats every unit the same, ERC-721 is an interface for non-fungible tokens, such as unique artwork or songs. Each token has a distinct identifier within its contract, so ownership is tracked per token rather than as a balance. Typical uses are collectibles, tickets, in-game items and proofs of ownership.

The tradeoff is cost and complexity. Moving ten unrelated NFTs means ten separate transfers. For the interface details, see our ERC-721 standard guide.

ERC-1155: many token types in one contract

ERC-1155 is a multi-token interface. One deployed contract can represent any number of fungible, non-fungible or semi-fungible token types, each identified by a token ID that can have its own metadata and supply. The specification also supports transferring multiple token types in one operation.

That makes it a natural fit for games, where a single contract might hold a currency, a set of consumables and a few unique items. You deploy once, and you can batch movements instead of sending one transaction per asset type.

Comparing the three Ethereum standards

	ERC-20	ERC-721	ERC-1155
Token type	Fungible	Non-fungible	Fungible, non-fungible or semi-fungible
Tracks	A balance per address	An owner per token ID	Balances per address per token ID
Contracts needed	One per token	One per collection	One for many token types
Batch transfers	Not part of the standard	Not part of the standard	Built in
Typical use	Stablecoins, payment and governance tokens	Collectibles, tickets, unique assets	Games, mixed asset catalogs

Token standards on other chains

The names change from chain to chain, but the idea stays the same.

Tron: TRC-20 and TRC-10. TRC-20 is the fungible token standard on TRON and is compatible with ERC-20 at the interface level, so most Ethereum token contracts need few changes to run there. Tron also has the older, protocol-level TRC-10. We explain the practical differences in TRC-10 vs TRC-20.

BNB Chain: BEP-20. BEP-20 follows the ERC-20 model on an EVM-compatible chain, so the function names and event shapes will look familiar.

Solana: SPL tokens. Solana does not deploy a new contract per token. Tokens are created through the shared SPL Token program, and an NFT there is simply a token created with zero decimal places. The mental model differs from Ethereum, even though the goal of interoperability is the same.

Cosmos ecosystem: CW20. The CW20 specification handles balances and transfers using Uint128 integers and leaves decimal handling to the UI, which is the same integer-versus-display split as ERC-20.

A same-named standard on a different chain is never interchangeable with the original. A TRC-20 USDT and an ERC-20 USDT are different assets on different networks, and sending to the wrong network can lose funds. Always pair an address with its network in your data model.

What to check before you integrate a token

A standard describes what a token should do, not what every deployed contract does. A 2022 study in IET Software reported that ambiguity in the ERC-20 interface can lead to differing interpretations and compliance vulnerabilities among real-world token contracts.

The token integration checklist on ethereum.org is a good baseline. It asks developers to review:

• conformance and return values of the standard functions,
• optional functions and decimals,
• race-condition mitigation on approvals,
• external calls inside the token,
• fees or interest taken on transfer,
• upgradeability, minting, pausing and blacklisting powers,
• owner and team risks, and supply concentration.

For a payment product, the ones that bite most often are fee-on-transfer behavior (the amount received is less than the amount sent), blacklisting (a transfer can be blocked after the fact) and non-standard return values. Test each token you plan to support on a testnet with real transfers, and credit deposits based on the amount actually received, not the amount requested.

Perspective: why standards are only half the job

Standards solve the problem of how one token talks to one chain. They do not solve the problem of running a product across several chains. If you accept payments on Ethereum, Tron and Solana, you still face different address formats, different fee models, different event structures and different node infrastructure.

We built Chaingateway around that gap. Our view is that developers should not need to maintain chain-specific endpoints or run their own nodes just to know that a customer paid. That is why we return pre-decoded data, so a transfer arrives as readable fields instead of raw log topics, and why we estimate gas automatically. We sign webhook requests with HMAC so your backend can verify that a payment notification is genuine.

Our advice for teams starting out: pick the standard that matches your asset (fungible, unique or mixed), read decimals from the contract every time, and build your payment detection on events rather than polling. Everything else is plumbing, and plumbing is what an API should absorb.

— Bitblade

Putting standards to work with Chaingateway

If you are building payments or wallets on top of these standards, our Blockchain API gives you one REST interface to create wallets, send token and NFT transfers, fetch decoded transaction data and estimate fees across Ethereum, Bitcoin, Tron, Solana, Polygon, BNB Chain and Arbitrum. It supports the major token standards, including ERC-20, BEP-20, TRC-20 and ERC-721. Chaingateway Webhooks push real-time notifications when a payment arrives, so you do not have to poll.

Plans start at €49 per month for Plus, with Pro at €99, Premium at €249 and Enterprise at €499 per month. Annual billing is €490, €990, €2,490 and €4,990 respectively. See the pricing page for what each plan includes. For Ethereum specifically, our Ethereum API shows how to send ERC-20 tokens over REST without web3.js.

Sources

• Token Standards, ethereum.org
• Ethereum Development Standards, ethereum.org
• ERC-20 Token Standard, ethereum.org
• ERC-20: Token Standard, EIP-20
• ERC-1155: Multi Token Standard, EIP-1155
• Token integration checklist, ethereum.org
• Blockchain Networks: Token Design and Management Overview, NIST
• Conformance evaluation of the top-100 Ethereum token smart contracts, IET Software
• TRC-20 fungible token standard, TRON developer docs
• Token, Solana SPL documentation
• CW20 specification, CosmWasm

Recommended

• The ERC20 Token Standard
• The ERC721 Token Standard