BEP-2

Overview

BEP-2 defined common token properties and management operations for the former BNB Beacon Chain. Tokens used chain-native issuance and transfer rules rather than EVM smart contracts, with symbols, supply settings, ownership, and optional mintability recorded by the network.

BNB Chain Fusion retired the Beacon Chain and moved the ecosystem toward BNB Smart Chain. As a result, BEP-2 should now be understood primarily as a legacy standard, and old addresses or token symbols may appear in historical records, migrations, or unsupported deposit instructions. Exchanges and payment services must not accept a BEP-2 label without checking current network support. Legacy deposits require exact address and memo handling, migration status, and platform policy. BEP-2 assets are not interchangeable with similarly named BEP-20 contracts. Implementations should validate normative requirements, encodings, error behavior, security conditions, and test vectors, including malformed and boundary inputs that ordinary happy-path tests miss. Conformance to BEP-2 requires more than matching a field name or example.

Teams adopting BEP-2 should track errata, compatibility changes, and the deployed software versions that enforce it. For BEP-2, a published standard does not prove universal adoption, safe implementation, or activation on a particular blockchain or payment network. This allows reproducible debugging when a later upgrade changes parsing, validation, signing, or interoperability behavior. Operational records for BEP-2 should retain the version and configuration used for each relevant transaction or message. BEP-2 should be implemented against an exact document revision, status, and activation context. Draft, final, optional, and network-activated specifications have different authority, and similarly named deployments may support different subsets or extensions.