BNB on opBNB and Ethereum: does it add to total supply?

Put three numbers side by side and BNB seems to have more supply than announced: the BSC total from the burn notices, the BNB moving around on opBNB, and a token contract on Ethereum that is also called BNB. Most of that surplus is not new issuance. It is the same BNB recorded a second time on another chain.

BNB on opBNB arrives through the official bridge, and the original coins stay behind in a BSC contract. The ERC-20 BNB on Ethereum predates the 2019 mainnet swap; every unit converted was burned on one side and released on the other. Neither belongs on top of the BSC total. The evidence for each, with queries you can rerun, follows.

Which chain is the BNB total supply counted on?

The 36th quarterly burn notice of 15 July 2026 gives a remaining total supply of 133,166,127.91 BNB. It also says that, because of BNB Chain Fusion, this and future burns happen directly on BSC, with the BNB sent to the "blackhole" address 0x000000000000000000000000000000000000dEaD. The notice mentions that BNB is used for transactions on BSC and opBNB, but it does not list opBNB as a separate source of supply.

The base ledger is therefore native BNB on BSC. Anything named BNB elsewhere has to be tied back to that ledger before it goes into a column. For the burn arithmetic itself, see the 36th burn reconciliation.

Where the BNB in an opBNB wallet is locked on BSC

opBNB is BNB Chain's layer 2 built on the OP Stack, and it uses BNB for gas. The official deposit guide has you bridge BNB from BSC first; the mainnet bridge lives at opbnb-bridge.bnbchain.org. Switch the wallet to opBNB and the balance appears. On BSC the coins have not vanished. They sit in the bridge contracts.

The opBNB protocol addresses page lists the BSC-side contracts, including OptimismPortalProxy at 0x1876EA7702C0ad0C6A2ae6036DE7733edfBca519. In the OP Stack design, native-coin deposits and final withdrawals pass through the Portal. Ethereum rollups do this with ETH; opBNB runs the same structure on BSC with BNB.

You can check it with one call. Send eth_getBalance for that address with latest to the public BSC node bsc-dataseed.bnbchain.org. At 08:48 UTC on 10 October 2026, BSC block 126,798,474, the result converted to roughly 88,794.99 BNB. At the same moment the Proxy__OVM_L1StandardBridge listed on the page (0xF05F0e4362859c3331Cb9395CBC201E3Fa6757Ea) held zero. The native BNB rests in the Portal, not in the standard bridge. The balance moves block by block, so write down the block number of your own query.

Those 88,794.99 BNB are still native BNB on BSC and already sit inside the official total. The matching balances on opBNB exist only because of that lock. Count both and you have counted the same coins twice.

Do not swing the other way and subtract the Portal balance from the BSC total. Locked is not burned: these coins were never sent to the blackhole address, and once a user completes a withdrawal from opBNB they leave the Portal for an ordinary address again. Treating the lock as a reduction understates supply, the mirror image of double counting.

Worked example: deposit 1,000 BNB and watch both chains

Suppose a single event: an address bridges 1,000 BNB from BSC to opBNB through the official bridge. Gas is ignored to keep the structure visible.

1. On BSC the address loses 1,000 BNB and the Portal gains 1,000 BNB. Native supply on BSC is unchanged.
2. On opBNB the address gains 1,000 BNB it can spend.
3. Treat "all BSC balances plus all opBNB balances" as supply and 1,000 BNB appear from nowhere.

The non-duplicating entry keeps the BSC total as it is and records the 1,000 on opBNB as "layer-2 balance backed by the Portal lock", in a distribution column outside the total. For a rough view of how much BNB is on the layer 2, the Portal balance is a far better guide than summing opBNB addresses.

Withdrawing from opBNB to BSC: why the BNB looks present on both sides

The return trip is where totals drift. The OP Stack withdrawal specification describes the sequence: start on layer 2, prove the withdrawal on the layer-1 Portal, wait out a 7-day challenge period, then finalize on the Portal. We did not find a separate official statement of opBNB's own waiting time; the official bridge shows it when you withdraw.

While that clock runs, the BNB withdrawn on opBNB sits in the predeploy L2ToL1MessagePasser at 0x4200000000000000000000000000000000000016, out of the user's reach. At 10:47 UTC on 15 October 2026, an eth_getBalance query to the public opBNB node opbnb-mainnet-rpc.bnbchain.org at opBNB block 195,777,364 returned about 33.97 BNB for this contract; a different block will give a different figure. On BSC, the matching BNB stays in the Portal until finalization.

If you estimate layer-2 BNB by adding opBNB address balances, exclude this contract or every pending withdrawal is counted twice. The specification's interface includes a burn function, but the documentation does not say when it is called, so we draw no conclusion about where that balance goes.

Why the ERC-20 BNB contract on Ethereum still shows about 393,000 tokens

BNB started life as an ERC-20 token on Ethereum before moving to its own mainnet. BNB Chain's 22nd burn notice of 17 January 2023 explained the leftovers: roughly 16 million ERC-20 BNB went unconverted during the early migration; Binance.com kept accepting deposits of the older ERC-20 BNB; conversion burns the ERC-20 BNB and releases the same amount from the native BNB mint address; and those ERC-20 burns are not counted toward the quarterly burn.

The current figure is easy to read. Call totalSupply() on 0xB8c77482e45F1F44dE1745F52C74426C631bDD52 on Ethereum: at block 26,160,948 on 10 October 2026 it returned 392,908.128 tokens. The Etherscan token page shows the same number with a "Mainnet Launched" label.

How those 393,000 relate to the 133 million on BSC is not addressed in the 36th notice. The swap rule is clear, though: one ERC-20 burned, one native released, both sides always describing the same claim. It is not extra supply. Give it its own line with the query block and date, and keep it out of the total.

Quarterly burn figures leave this out as well. A tracker that adds shrinking ERC-20 supply to "cumulative BNB burned" is measuring a different scope from the official notices, and the two series should not be compared directly.

Tokens called BNB on other chains: three checks before you file them

Some bridges issue tokens named BNB, with the BNB ticker, on other networks. There may be full backing behind them, or nothing but the name. Before filing one, confirm:

• the contract address published by the issuer or bridge, and the locking method it describes;
• whether the locked side can be read directly from a public node or block explorer;
• whether the two sides move together, with every unit issued on one chain matched by a unit locked on the other.

If any of the three stays unclear, put the token in a "relationship unknown" column that neither adds to nor subtracts from the total. The general column method is in the supply ledger guide; this page applies it to specific BNB contracts.

A BNB distribution record that never double counts

Putting the pieces together, one workable order is:

1. Total: the remaining supply from the latest official notice, with its date. Currently 133,166,127.91 BNB, published 15 July 2026.
2. Distribution 1: the OptimismPortalProxy balance on BSC, with block number. It shows how much BNB backs balances on opBNB.
3. Distribution 2: the L2ToL1MessagePasser balance on opBNB, marked as withdrawals in transit and overlapping with line 2.
4. Note: totalSupply of the Ethereum ERC-20 BNB contract, marked as unconverted legacy tokens matched one-for-one with native BNB under the official explanation, outside the total.

Distribution lines answer where BNB is; they never change the total. When the next quarterly burn is published, update the total first, and re-query the distribution lines each time because they shift with every block. Past burn figures are collected in the burn archive.