ERC-20, BEP-20 and TRC-20 define similar functions for reading balances, transferring tokens and granting allowances. Solana’s Token Programs also define account fields for mint and freeze authority. These rules help wallets interact with tokens on each network; they do not make tokens interchangeable across networks or establish their backing. A holder still needs to inspect the particular contract or mint.
Nine functions, and three of them optional
ERC-20 was written by Fabian Vogelsteller and Vitalik Buterin, created on 19 November 2015, and now carries the status Final. Its summary runs to five words: “A standard interface for tokens.” The specification lists nine methods and two events, nothing else.
Six methods are required. totalSupply() returns the total token supply. balanceOf(_owner) returns one account’s balance. transfer moves tokens and must fire the Transfer event. transferFrom does the same on somebody else’s behalf, and the spec says the call should throw unless that account “has deliberately authorized the sender of the message via some mechanism”. approve grants that authorisation up to an amount, and allowance reports how much of it remains.
Three methods — name, symbol and decimals — are marked OPTIONAL, with a clause that reads oddly to anyone who assumes a token must announce what it is called: “interfaces and other contracts MUST NOT expect these values to be present”. A compliant ERC-20 token may decline to state its own symbol, which leaves a conclusion worth carrying around: any interface showing a symbol for such a token read it somewhere other than the contract.
Two further notes aim squarely at software rather than at readers, yet they shape what a holder sees. Callers “MUST handle false from returns (bool success)” and “MUST NOT assume that false is never returned” — a failed transfer can come back as a quiet false rather than a revert. And the approve entry warns that calling it again overwrites the previous allowance, with clients advised to set an allowance to zero before setting a new one for the same spender. Those two paragraphs are where the allowance behaviour behind a wallet approval prompt is actually written down.
ERC-20 does not specify who may mint, cap supply, schedule issuance or name an administrator. Both an issuer-controlled token with further minting enabled and a token with minting permanently disabled can implement its required methods. To distinguish them, inspect the contract code, which is where the supply and emission guide starts.
BEP-20 changes the required fields and supply wording
BNB Smart Chain’s token standard derives from ERC-20 and retains wording about transfers between BNB Beacon Chain and BNB Smart Chain. That wording describes a retired system: the BNB Chain Fusion documentation confirms that Beacon Chain shut down in December 2024. It is not a current transfer route. The nine methods and two events arrive in the same order, with the same wording in most entries.
Two optional methods become required: symbol and decimals. BEP-20 still makes name optional. The document explains the two requirements by reference to its historical cross-chain machinery; neither field establishes whether a token is backed or safe.
The other difference concerns totalSupply: the specification asks tokens using the former Beacon Chain connection to report circulation across both chains. This historical clause does not prove that any current contract reports a combined supply. To reconcile an explorer with an aggregator, check the deployed contract and each provider’s definition. The BNB record follows how that chain’s own supply figures are produced.
These documents get edited. On 12 February 2025, the maintainers merged the change removing getOwner, explaining that its Beacon Chain binding role was obsolete. Earlier versions of the standard required this function; removing it from the document did not remove it from deployed contracts. A quotation therefore needs a version as well as a source.
TRC-20: same calls, a different meter running
TRON’s developer documentation describes TRC-20 as its fungible token standard, compatible with ERC-20 at the interface level. Implementing the required functions and events lets software integrate a token, but does not guarantee a wallet listing, exchange listing or supported deposit route. The docs also describe bytecode compatibility and say most Solidity ERC-20 code needs only minimal changes. Reading token metadata and balances uses familiar calls such as name(), symbol(), decimals(), totalSupply() and balanceOf().
Identical calls, however, meet a different machine. Deploying a TRC-20 token costs TRX, bounded by a fee_limit expressed in sun and spent as energy; a transfer consumes the chain’s energy and bandwidth resources rather than gas priced the Ethereum way. The TRON record takes up why transfers there can look free, and the fee models table sets the chains beside one another.
One small item in TRON’s key facts deserves more attention than its placement suggests: decimals are “typically 6 or 18, declared by the contract”. Raw token amounts on chain are integers, and the same integer 1000000 reads as one whole token at six decimals and as a rounding fragment at eighteen. Explorers divide for you by reading decimals(). Anything that skips that step — a hand-written script, a pasted API response, a screenshot of raw call output — can be out by a factor of a trillion while every digit on display stays correct.
Solana keeps the token rules in a shared program
Solana arranges the same job differently enough that the comparison with the three above stops being like-for-like. Tokens there are not individually deployed contracts; the documentation describes them as data accounts owned by a Token Program, with the instruction logic living in that program rather than in each token. Two such programs are in use: the original Token Program, described as immutable and widely used, and the Token Extensions Program, Token-2022.
A token is identified by the address of its Mint Account, which the docs call a global counter for that token. The account’s fields are short enough to list in a sentence: supply, decimals, mint authority, freeze authority, plus an initialisation flag. The comment on the mint authority field in the program’s own source states the consequence directly — “If no mint authority is present then the mint has a fixed supply and no further tokens may be minted.” The freeze authority is defined as the account authorised to freeze tokens in a Token Account, preventing them from being transferred or burned.
Contracts on the other three chains can implement these powers in issuer-written code. On Solana, mint and freeze authority occupy named fields that explorers can read. An absent mint authority establishes that further minting is disabled; it does not prevent holders from burning units and reducing supply. Token-2022 extensions also need inspection for additional powers, such as a permanent delegate.
The account model costs holders a step in return. Holding a token means owning a Token Account for that specific mint, and the usual one — the Associated Token Account — sits at an address derived from the owner and mint addresses. Creating it “requires a refundable minimum balance for its account storage”, funded by whoever pays for the instruction even when another wallet ends up owning the account. That refundable deposit is why receiving an unfamiliar token on Solana can carry a small cost before anything arrives; the documentation points to its own ATA cost page for the current amount and the Token-2022 sizing differences.
Token-2022 then layers on optional features called extensions, each adding state to a mint or token account. The published enum includes a transfer fee configuration, a default account state for new accounts, a non-transferable setting, a permanent delegate and a transfer hook, among others. Two properties matter to anyone weighing up a token built this way: most extensions cannot be added after an account is initialised, so the issuer picked them at creation, and certain combinations are rejected outright — the docs cite NonTransferable together with TransferFeeConfig as conflicting behaviours. Capabilities chosen once, at the start, and readable afterwards.
One ticker on two chains, two separate ledgers
Follow the four specifications to their shared conclusion and a practical point falls out. An asset listed on two chains exists as two deployments: two contracts or mints, two supply figures, two sets of authorities, two transaction histories. Nothing in ERC-20, BEP-20, TRC-20 or the Token Program links them. The connection comes from an issuer who mints on both and keeps the books, or from a bridge holding one version while circulating another — the arrangement examined in who actually holds the original coin. BEP-20’s cross-chain supply sentence is the lone place where any of these documents even acknowledges the other ledger.
The network chosen on a deposit screen therefore settles which of those deployments receives the transfer, and an address format carries more information than the ticker printed beside it. The address format table covers how far that guess can be taken.
Four questions still need token-specific evidence: who currently holds mint authority, whether the contract or program can be upgraded, who can freeze or seize balances, and what backs the unit. Check deployed code, authority fields, extensions and any upgrade controls for the first three. Backing may involve on-chain collateral, off-chain reserves or both, as the stablecoin backing guide explains. A token-standard label describes an expected interface; the label alone verifies neither compliance nor safety.
Primary references
- EIP-20: Token Standard for the method list, the OPTIONAL marking on
name,symbolanddecimals, the false-return and allowance notes, the authors and the 2015 creation date. - BEP-20: Tokens on BNB Smart Chain for the derivation from ERC-20, the required
symbolanddecimals, the cross-chain wording ontotalSupply, and the February 2025 commit removing getOwner. - TRON developer documentation on TRC-20 for interface and bytecode compatibility, the 6-or-18 decimals note and deployment costs paid in TRX. Compatibility is not a listing or deposit-support guarantee.
- Solana documentation on tokens and token accounts for the two Token Programs, the Mint Account fields with their source comments, and the Associated Token Account deposit, with the extensions page for the Token-2022 extension list and its timing and compatibility constraints.
Specification wording quoted above was read in October 2026. Standards get edited — the removed getOwner entry is the example sitting inside this page — so a quotation describes a version, and an individual token’s deployed code outranks any standard it claims to follow. Where a contract diverges from the document, holders deal with the contract.