BEP20

BEP-20 (often written BEP20) is a technical standard for fungible-token smart contracts on BNB Smart Chain (BSC). “BEP” means BNB Evolution Proposal, and BEP-20 is an enabled standards proposal in the BNB Chain proposal repository. Derived from Ethereum's ERC-20 standard, its interface defines common methods and events for balances, transfers, and delegated spending.

Fungibility means that units tracked by one token contract are interchangeable rather than individually distinct. The contract records balances assigned to addresses and applies the same transfer rules to each unit. BEP-20 specifies how compatible contracts expose those operations to wallets, exchanges, other contracts, and indexing software. It does not prescribe a token's monetary policy, backing, governance, administrator privileges, market value, or security.

Interface

The standard defines the following public methods:

Method	Purpose	BEP-20 status
name()	Returns a human-readable token name	Optional
symbol()	Returns the token's ticker-like symbol	Required
decimals()	Returns the decimal precision used for display	Required
totalSupply()	Returns the total token supply reported by the contract	Required
balanceOf(address)	Returns the balance assigned to an address	Required
transfer(address, uint256)	Transfers tokens from the caller to another address	Required
approve(address, uint256)	Sets the amount that a spender is allowed to use	Required
allowance(address, address)	Returns the remaining approved amount	Required
transferFrom(address, address, uint256)	Transfers tokens using a previously granted allowance	Required

Compatible contracts emit a Transfer event for transfers and an Approval event when an approval succeeds. Zero-value transfers are valid and also emit Transfer. The specification requires callers to handle a boolean false result rather than assume that every call returning normally succeeded.

Balances, supply, and decimal display

The interface accounts for token amounts as unsigned integers. The decimals value tells user interfaces how to scale those base units for display. If a contract reports eight decimals, for example, an integer balance of 100,000,000 base units is displayed as one token unit. The setting does not create fractions in contract storage or determine the token's market value.

totalSupply reports the amount in existence under the contract's rules, while balanceOf reports the amount assigned to a particular address. Neither method establishes how supply was created. A contract may assign a fixed initial supply when deployed or implement additional minting or burning logic; those policies are outside the core interface. The specification says that creating new units should emit Transfer with the source set to the zero address, but it does not require a public mint function.

Transfers and allowances

A direct transfer request moves an amount from the caller's balance to a recipient. The contract checks and updates its own state and emits the standard event. A token transfer is therefore a call to the token contract; it differs from transferring BNB, the network's native asset.

Delegated spending uses three methods. First, an owner calls approve to set the maximum amount a spender may use. Software can read the remaining amount with allowance. The approved spender then calls transferFrom to move tokens from the owner's balance, subject to that allowance. This pattern allows another smart contract to act on a token holder's authorization without receiving control of the holder's entire balance.

Calling approve again replaces the current allowance; it does not add to it. The BEP-20 and ERC-20 specifications warn client developers about changing one nonzero allowance directly to another because transaction ordering can allow both values to be used. They recommend interfaces that first set the allowance to zero before setting another nonzero value. An approval grants spending authority; it does not itself transfer tokens.

Events and interoperability

The standard method signatures, return types, and events give applications a common way to interact with different token contracts. An application can use a contract's application binary interface (ABI) to query metadata, balances, supply, and allowances or submit standard transfer and approval calls without depending on the contract's internal storage design.

Transfer and Approval events allow explorers, wallets, and indexers to observe standard operations in transaction logs. Events help reconstruct activity, but current balances and allowances can still depend on the contract's exact implementation and state. Software should not assume that familiar metadata or an emitted event proves a token's identity or quality.

Relationship to ERC-20

BEP-20 preserves ERC-20's core transfer and allowance interface, allowing EVM-compatible software to interact with it in a familiar way. One difference in the current written specifications concerns metadata: ERC-20 treats name, symbol, and decimals as optional, whereas BEP-20 requires symbol and decimals but keeps name optional.

The standards do not define their networks' consensus, capacity, transaction fees, or confirmation and finality behavior. Those are properties of the underlying blockchains and their current configurations. BSC is EVM-compatible, and its native BNB token is used to pay BSC transaction fees. EVM compatibility permits reuse of many Ethereum-oriented tools and contract patterns, but it does not automatically share a token contract or its balances between BSC and Ethereum.

Uses and representation

BEP-20 contracts can account for interchangeable application units, voting weight, incentive or access units, claims designed to track another asset, or other fungible quantities. These are roles chosen by the implementation and its surrounding application, not separate capabilities granted by the standard.

In particular, the interface does not verify that a token is backed by another asset, redeemable, price-stable, controlled by a decentralized process, or accepted by any service. A wrapped or bridged representation also depends on mechanisms outside BEP-20 that issue and redeem it. The standard only makes the token contract's common operations recognizable.

BNB Beacon Chain history

Early BEP-20 material included cross-chain binding with BEP-2 assets on BNB Beacon Chain. BNB Chain retired Beacon Chain through the 2024 BNB Chain Fusion process, with the final sunset fork in November and validator shutdown scheduled in December.

The earlier interface also contained getOwner(), used for binding BEP-20 and BEP-2 tokens. BNB Chain removed it from the current BEP-20 specification in a change merged on 12 February 2025 because Beacon Chain no longer existed. Documentation or contract templates that still call getOwner() a BEP-20 requirement describe the retired workflow, not the current interface.

Token identity and network selection

A deployed BEP-20 token is identified by BNB Smart Chain and its contract address. Names and symbols are display metadata and can be duplicated, so they are insufficient to establish that a contract represents an intended asset. Wallet software may require the user to select BSC and import the exact contract address before displaying a token.

BSC and Ethereum use compatible address formats, but token balances exist in contracts on a particular network. Sending through an unintended network does not have one universal outcome: recovery depends on whether the sender or recipient controls the destination address and whether a custodian can assist.

Extensions and security limitations

BEP-20 compliance does not imply that every token contract behaves identically. Implementations may add minting, burning, pausing, transfer fees, blocklists, upgradeability, or privileged administrator functions. None is required by the core BEP-20 interface, and each changes the contract's security and trust assumptions.

The inherited interface also has no mandatory callback through which a receiving contract confirms that it can account for incoming tokens. A standard transfer to a contract address can therefore succeed even when the receiving contract has no mechanism to use or return those tokens. Applications that accept token deposits need an explicit handling design rather than an assumption that every contract recipient is compatible.

Conformance does not show that source code was reviewed, displayed metadata is truthful, supply or backing claims are accurate, privileged keys are secure, or an application is safe. The exact deployed contract, its bytecode and configuration, administrator capabilities, and interacting application must be assessed separately. BEP-20 standardizes interoperability at the interface level; it is not a certification of an asset or issuer.