What Is a BEP20 Address?

A BEP20 address is an account address on BNB Smart Chain (BSC), the network that was called Binance Smart Chain until its rename in February 2022. It starts with 0x, is 42 characters long, and uses the exact same format as an Ethereum address. If you can handle Ethereum addresses in your code, you can handle BEP20 addresses without changing a single line.

That sounds like the whole story, but two details trip people up in practice. First, BEP20 gets confused with BEP-2, an older Binance standard with a completely different address format. Second, the same 0x address exists on every EVM chain at once, which has real consequences when you send tokens. This guide covers the format, the EIP-55 checksum, validation code, and how to create BSC addresses programmatically.

The format: 0x plus 40 hex characters

A BEP20 address encodes 20 bytes (160 bits) as hexadecimal text:

0x71C7656EC7ab88b098defB751B7401B5f6d8976F

Three checks tell you whether a string can be an address at all:

• It starts with the prefix 0x.
• Exactly 40 characters follow the prefix.
• Every one of those characters is a hex digit: 0–9, a–f or A–F.

There is no separate address type for tokens. BEP20 tokens such as USDT, USDC or CAKE go to the same 42-character account addresses that hold BNB. Your Binance Smart Chain wallet address for BNB and your BEP20 address for tokens are one and the same string.

Where do the 20 bytes come from? An account starts as a random private key on the secp256k1 curve, the same curve Bitcoin and Ethereum use. The public key derived from that key is hashed with Keccak-256, and the last 20 bytes of the hash become the address. No registration happens anywhere. An address exists the moment the math is done, even before the chain has seen a single transaction from it.

Why it looks identical to an Ethereum address

BSC launched in September 2020 as an EVM-compatible chain. It runs the Ethereum Virtual Machine, so it inherited Ethereum’s account model, its key derivation, and its address format wholesale. BEP-20 itself is BSC’s port of Ethereum’s ERC-20 token standard; the function names (transfer, balanceOf, approve) are the same.

The only technical divider between the two networks is the chain ID: 56 for BSC mainnet, 1 for Ethereum mainnet, 97 for the BSC testnet. The chain ID goes into every transaction signature, which stops a transaction signed for one chain from being replayed on the other. The address itself carries no chain information at all. You cannot look at 0x71C7...976F and tell whether its owner uses it on BSC, Ethereum, or both.

BEP-20 vs ERC-20 vs TRC-20 side by side

Stablecoin payments reach real businesses over three networks, and most lost-funds support tickets involve two of them being mixed up. Here is what actually differs, with numbers as of mid-2026:

Two rows deserve a closer look. The address rows for BEP-20 and ERC-20 are identical because BSC copied Ethereum’s format down to the checksum algorithm. A validator that accepts one accepts the other and cannot tell you which network the user meant; only the surrounding context can. TRC-20 is the outlier. A TRON address fails EVM validation instantly, which sounds like an inconvenience and is actually protection, because a cross-pasted address gets rejected on format alone before any money moves.

The speed numbers have a short shelf life; the format rows do not. BSC halved its block time twice within eight months: the Maxwell hard fork cut it from 1.5 to 0.75 seconds in June 2025, and the Fermi hard fork brought 0.45 seconds in January 2026. TRON has held its 3-second interval for years, and Ethereum’s roadmap debates shorter slots for later upgrades. The three address formats, meanwhile, have not changed since the chains launched. Validation code you write today survives every fork. Fee tables you print today will need maintenance.

On cost, BSC is currently the cheapest of the three for a plain token transfer, TRON the most predictable (the fee is fixed in energy terms, not auctioned), and Ethereum the most expensive whenever the network is busy. If your customers pick the deposit network themselves, expect BEP-20 and TRC-20 to dominate and plan your fee handling around that.

The EIP-55 checksum: why some letters are uppercase

Hex is case-insensitive, so 0xab... and 0xAB... point to the same account. EIP-55, proposed in 2016 for Ethereum and adopted by BSC along with everything else, turns that spare degree of freedom into an error check.

The rule: take the address in lowercase (without 0x), hash it with Keccak-256, and walk through the 40 characters. If the hash digit at a position is 8 or higher, the address letter at that position is written in uppercase; otherwise in lowercase. Digits stay as they are.

The result is the mixed-case form wallets and explorers display. If a user mistypes one character of a checksummed address, the case pattern no longer matches the hash and validation fails, so the typo is caught before any funds move. An all-lowercase address is still technically valid, it just carries no checksum, and your code should treat it as unverified input rather than rejecting it.

A worked example

EIP-55’s own test suite starts with this address. In lowercase, with the 0x stripped, and next to the Keccak-256 hash of that 40-character string:

address: 5aaeb6053f3e94c9b9a09f33669435e7ef1beaed
keccak:  d385650ce8fdc6db7ee3a091d34814dbc4ce18219ffae52182efff4034d707e5

Now compare position by position. The first address character is 5, a digit, so it stays 5 no matter what the hash says. The second is a, and the hash digit above it is 3, below 8, so it stays lowercase. The third is again a, but this time the hash digit is 8, so it becomes A. The fourth, e, sits under a 5 and stays lowercase. Carry that through all 40 positions and you get the checksummed form:

0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed

Two implementation details cause most of the bugs in practice. The hash input is the ASCII text of the lowercase address, not the 20 raw bytes it encodes, and not the string with 0x still attached. Get either wrong and every checksum you compute comes out garbage. As for how much protection the scheme buys: the EIP itself puts it at roughly 15 check bits per address on average, meaning a mistyped address slips through with a probability of about 0.0247 percent, one bad address in four thousand instead of guaranteed acceptance.

BEP-2 vs BEP-20: two standards, two address formats

This is the confusion that has cost users real money. Binance used to run two chains in parallel:

• BNB Beacon Chain, with the BEP-2 token standard and addresses starting with bnb1
• BNB Smart Chain, with the BEP-20 standard and 0x addresses

BEP-2 deposits to exchanges also required a memo field, and a forgotten memo was a classic support ticket. That era is over: Binance retired the Beacon Chain in 2024 as part of the BNB Chain Fusion, and BEP-2 with it. If a tutorial tells you about bnb1 addresses or memos, it is outdated. Today, “BNB address” and “BSC address” mean the 0x BEP20 format in practice.

The name survives in exchange withdrawal menus, where the network is usually labeled “BSC (BEP20)” or “BNB Smart Chain (BEP20)”. When you see that label, the destination must be a 0x address.

One address, many chains: why the network selector matters

Because BSC copied Ethereum’s derivation, the same private key controls the same 0x address on Ethereum, BSC, Polygon, Arbitrum, and every other EVM chain. That is convenient and dangerous at the same time.

Convenient: a user with a MetaMask or Trust Wallet account already has a BEP20 address. They add the BSC network in their wallet settings and their existing address works.

Dangerous: tokens with the same name live as separate contracts on separate chains. USDT on BSC and USDT on Ethereum have nothing in common except the ticker. If someone withdraws USDT from an exchange and picks the wrong network, the tokens arrive at the right address on the wrong chain. Two outcomes are possible:

1. The recipient controls the private key (self-custody wallet). Then nothing is lost. They switch their wallet to the other network and find the tokens there.
2. The recipient is a deposit address at an exchange or payment processor that only watches one network. Then the tokens sit in an account nobody monitors. Some exchanges recover such deposits for a fee, some don’t.

The practical rule for developers: always state the network next to the address you show, and verify incoming deposits on the chain you actually credit. An address string alone is ambiguous by design.

How to find your BEP20 address in MetaMask, Trust Wallet, and hardware wallets

Every wallet that speaks EVM shows you the same thing in the end, a 0x address, but the path there differs a little. The steps below stay deliberately generic, because menu labels move around between app versions.

MetaMask

MetaMask starts life connected to Ethereum only. To use it on BSC, add BNB Smart Chain as a network (chain ID 56, currency BNB); current versions list it in the built-in network catalog, so no manual RPC entry is needed. Your account address sits at the top of the main view and copies with one click. It does not change when you switch networks. Selecting BSC in the network menu changes where your transactions go, not who you are.

Trust Wallet

Trust Wallet supports BSC out of the box. Pick the asset you expect to receive, for example BNB or a token labeled “BEP20”, open the receive screen, and the app shows the 0x address as text and as a QR code. The network label next to each token matters more than the address itself: “USDT BEP20” and “USDT ERC20” resolve to the same address string in your wallet, but they tell the sender which chain to use, and that is the part that goes wrong.

Hardware wallets

With a Ledger or Trezor the private key never leaves the device, and BSC runs through the same EVM integration as Ethereum. The receive flow adds one step worth keeping: the device shows the address on its own display, and you compare it with what the computer shows before sharing it. That comparison defeats clipboard malware, which swaps addresses on the computer but cannot touch the device screen.

Whichever wallet you use, the copied string carries no network information. When you paste it into an exchange withdrawal form, the network dropdown next to it does the deciding, so check that it says BSC or BEP20.

One seed phrase, many addresses: HD wallets in two minutes

Modern wallets don’t keep a bag of unrelated keys. They derive everything from one seed, following three standards that stack on each other. BIP-39 turns 12 or 24 dictionary words into a seed. BIP-32 grows a deterministic tree of key pairs from that seed, so the same words always produce the same tree. BIP-44 fixes which branch belongs to which coin, written as a derivation path.

For Ethereum the registered path is m/44'/60'/0'/0/0, with 60 as the coin type. BSC never registered a coin type of its own; wallets reuse 60, which is the technical reason your wallet shows the identical address on BSC, Ethereum, Polygon, and Arbitrum. The last number in the path is an index. Increment it and the wallet derives a second address from the same words, then a third, with no new backup required.

Two consequences follow. Restoring the seed words in any BIP-44 wallet recreates every address you ever derived, so the words are the backup, the whole backup. And a platform that needs thousands of deposit addresses could in principle derive them all from one seed, though production setups usually generate keys individually and register them via API, so no single secret controls every customer deposit at once.

Checking an address on BscScan

BscScan is BSC’s block explorer, and thirty seconds there answer most “did it work?” questions.

Paste any address into the search field and you land on its account page: BNB balance, token holdings, transaction list. For a deposit address you just created, an empty page is normal. The address exists as math; the explorer only has something to show once the first transfer touches it.

Look at the label near the top of the page. Accounts with a “Contract” tag are smart contracts, tokens included. Funds should move to plain addresses, so if a counterparty asks you to pay a contract address, stop and ask why.

Token verification is the third use. Anyone can deploy a token named “USDT” on BSC, and search results list the fakes next to the real one. The ticker proves nothing; the contract address does. Compare it against the address the token’s issuer publishes, then glance at holder count and verified source code on the token page. Fakes rarely fake those well.

After a test transaction, search for the transaction hash instead. The detail page shows sender, recipient, token contract and amount, which together confirm the money went where you intended, on the chain you intended.

Before you send: a short routine against expensive mistakes

Three habits cover nearly every way BEP20 transfers go wrong.

Match the network label to the address era. Everything current is “BSC (BEP20)” with a 0x destination. A guide, form, or counterparty that mentions bnb1 addresses or deposit memos is describing BEP-2, retired with the Beacon Chain in 2024. Treat such instructions as outdated, not as an alternative option.

Read the withdrawal form twice: once for the address, once for the network dropdown. The address field validates the format, the dropdown decides the chain, and no validator catches a correct address on the wrong network. That is the failure mode from the section above, and it happens on the sending side, which means you can prevent it there.

Send a test amount to every new address. On BSC this discipline costs a few cents and one to two seconds of waiting, so there is no economic argument against it. Confirm the test on BscScan, then send the rest. Teams that handle payouts formalize the habit: a new payout address gets whitelisted only after a confirmed test transfer.

Validating a BEP20 address in code

The format check is one regular expression. In JavaScript:

function isValidFormat(address) {
  return /^0x[0-9a-fA-F]{40}$/.test(address);
}

The checksum check needs Keccak-256, for example from @noble/hashes:

import { keccak_256 } from "@noble/hashes/sha3";
import { bytesToHex } from "@noble/hashes/utils";

function toChecksumAddress(address) {
  const addr = address.toLowerCase().replace("0x", "");
  const hash = bytesToHex(keccak_256(addr));
  let out = "0x";
  for (let i = 0; i < 40; i++) {
    out += parseInt(hash[i], 16) >= 8 ? addr[i].toUpperCase() : addr[i];
  }
  return out;
}

function hasValidChecksum(address) {
  return toChecksumAddress(address) === address;
}

In PHP, the regex is enough for a format check, and the kornrunner/keccak package covers the checksum:

use kornrunner\Keccak;

function isValidBep20Address(string $address): bool
{
    if (preg_match('/^0x[0-9a-fA-F]{40}$/', $address) !== 1) {
        return false;
    }
    $hex = substr($address, 2);
    // All one case: format-valid, but no checksum to verify
    if ($hex === strtolower($hex) || $hex === strtoupper($hex)) {
        return true;
    }
    $hash = Keccak::hash(strtolower($hex), 256);
    for ($i = 0; $i < 40; $i++) {
        $expectUpper = intval($hash[$i], 16) >= 8;
        if (ctype_alpha($hex[$i]) && $expectUpper !== ctype_upper($hex[$i])) {
            return false;
        }
    }
    return true;
}

Note that a passing check only proves the string is well-formed. It does not prove anyone holds the private key, and it does not tell you which network the sender intends to use.

Creating BSC addresses through an API

If you run a shop, a SaaS product, or an exchange-like platform, you need more than one address: typically one deposit address per customer, so you can tell incoming payments apart. Doing that by hand in a wallet app does not scale past a handful of users.

With the Chaingateway REST API, you generate keys in your own environment and register them for use on BSC. Authentication uses a Bearer token in the Authorization header:

curl -X POST https://app.chaingateway.io/api/v2/bsc/addresses/import \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xYourGeneratedBscAddress",
    "privatekey": "<generated secp256k1 private key, hex>",
    "password": "<encryption password for this key>"
  }'

Add the header X-Network: testnet and the same call runs against the BSC testnet (chain ID 97), so you can test the whole flow with free test BNB before touching mainnet. Sending BEP20 tokens later goes through POST /api/v2/bsc/transactions/bep20.

A free 7-day trial is enough to build and test this; you don’t go through a KYC process to start. Setup steps are in the quickstart guide, and plans are listed on the pricing page.

Deposit addresses per customer, plus webhooks

The address is only half of a payment flow. The other half is finding out that money arrived without polling the chain yourself. The pattern:

1. When a customer starts a payment, assign them a dedicated BSC address and store the address-to-customer mapping in your database.
2. Register a webhook for that address. When a BEP20 transfer hits it, Chaingateway calls your endpoint with the transaction details.
3. Verify the webhook’s HMAC signature, then credit the customer in your own system.

Webhook deliveries are HMAC-signed so you can reject forged calls. Deliveries your server missed are not gone either: GET /api/v2/bsc/webhooks/notifications/failed lists them, and POST /api/v2/bsc/webhooks/notifications/{id}/retry sends one again. If your server was down, GET /api/v2/bsc/webhooks/notifications returns past notifications, so reconciliation after an outage is a single API call. The full setup, including signature verification, is in the webhooks guide.

The same pattern works on TRON, where the address format is entirely different; see What is a TRC20 address? for that side.

FAQ

Is a BEP20 address the same as an Ethereum address?

The format is the same: 0x plus 40 hex characters, derived the same way from a secp256k1 key. The same private key even controls the same address string on both networks. But balances are separate per chain. Holding 100 USDT on BSC says nothing about your balance on Ethereum.

How do I get a BEP20 wallet address?

For personal use, create an account in any wallet that supports BSC (MetaMask with the BSC network added, Trust Wallet, or a hardware wallet) and it will show your 0x address. For an application that needs many addresses, generate keys programmatically and register them via API, for example with POST /api/v2/bsc/addresses/import.

What happens if I send BEP20 tokens to an Ethereum address?

The transaction succeeds, because every Ethereum-format address is also valid on BSC. The tokens land at that address on BSC. If the owner controls the private key, they can add the BSC network to their wallet and access the tokens. If it was an exchange deposit address that only monitors Ethereum, the tokens are stranded and you depend on the exchange’s recovery process.

What is the difference between BEP-2 and BEP-20?

BEP-2 was the token standard of the retired BNB Beacon Chain, with bnb1... addresses and memo fields. BEP-20 is the ERC-20-style standard on BNB Smart Chain, with 0x... addresses. Since the Beacon Chain shutdown in 2024, BEP-20 is the only one that matters in practice.

Are BEP20 addresses case-sensitive?

No. Uppercase and lowercase spellings of the same hex digits reach the same account. The mixed-case pattern you see is the EIP-55 checksum: it encodes an error check into the letter casing, so wallets can catch typos before sending.

Do I need BNB to receive BEP20 tokens?

No. The sender pays the gas, so receiving costs you nothing. You need BNB the moment you want to move the tokens onward: a BEP20 transfer uses roughly 65,000 gas, paid in BNB, which comes to a few cents as of mid-2026. A wallet holding USDT but zero BNB is a classic support case; those tokens sit still until a little BNB arrives to cover the fee.

How long does a BEP20 transfer take?

BSC has produced a block every 0.45 seconds since the Fermi hard fork in January 2026, and finality follows within about a second. A wallet-to-wallet transfer is done before you finish switching tabs. Exchanges layer their own confirmation requirements on top, so a deposit may be credited later than the chain finalizes it.

How do I know a token on BSC is the real one?

Check the contract address, never the name or logo. Compare the contract address shown on BscScan with the one the issuer publishes on its official site, and look at holder count and verified source code as supporting signals. A token with the right ticker, a few dozen holders, and unverified code is a copy.