opBNB 和以太坊上的 BNB，要不要算进 BNB 总供应量

整理 BNB 供给数据时，常见三处数字：BSC 上的总量来自官方销毁公告；opBNB 的区块浏览器上也有大量 BNB 在流动；以太坊上还有一个代币合约，名字就叫 BNB。三处一加，结果比官方公布的剩余总量多出一截。多出来的部分大多不是新发行，而是同一份 BNB 在另一条链上的对应记录。

所以答案是不加。opBNB 上的 BNB 是从 BSC 经官方桥存过去的，存入时原币留在 BSC 的桥合约里；以太坊上的 ERC-20 BNB 是 2019 年主网兑换之前的旧版本，换一枚、销一枚。下面把每一处的证据和查询方法分开列出，数字都能自己复查。

BNB 的剩余总量是在哪条链上数的

2026 年 7 月 15 日的第 36 次季度销毁公告写明：销毁后剩余总量为 133,166,127.91 BNB；由于 BNB Chain Fusion，这一季及以后的销毁直接在 BSC 上执行，BNB 被发送到 0x000000000000000000000000000000000000dEaD 这个“黑洞”地址。公告提到 BNB 可以用于 BSC 和 opBNB 上的交易，但没有把 opBNB 当成另一个供给来源单独列数。

核对时的底账因此是 BSC 上的原生 BNB。其他链上名叫 BNB 的余额，要先证明它和这本底账是什么关系，再决定放进哪一列。季度销毁本身的差额怎么算，见第 36 次销毁那篇。

opBNB 钱包里的 BNB，在 BSC 上锁在哪个合约

opBNB 是 BNB Chain 基于 OP Stack 建的二层网络，Gas 用 BNB 支付。官方存入说明要求先通过桥把 BNB 从 BSC 存到 opBNB，主网桥的地址是 opbnb-bridge.bnbchain.org。存好之后把钱包切到 opBNB 就能看到余额。BSC 这边，那笔 BNB 并没有消失，而是转进了桥的合约。

opBNB 协议地址页列出了 BSC 一侧的合约，其中 OptimismPortalProxy 的地址是 0x1876EA7702C0ad0C6A2ae6036DE7733edfBca519。在 OP Stack 的设计里，原生币的存入和最终提款都经过 Portal 合约；以太坊上的二层网络这样处理 ETH，opBNB 把同一套结构放在 BSC 上，原生币换成了 BNB。

这一点可以直接验证。向 BSC 公开节点 bsc-dataseed.bnbchain.org 发一个 eth_getBalance 请求，参数填上面的地址和 latest。2026 年 10 月 10 日 08:48（UTC），BSC 区块 126,798,474 时，返回值换算后约为 88,794.99 BNB。同一时刻，地址页上的 Proxy__OVM_L1StandardBridge（0xF05F0e4362859c3331Cb9395CBC201E3Fa6757Ea）余额为 0。也就是说，原生 BNB 没有停在标准桥合约，而是停在 Portal。这个余额每个区块都可能变，复查时记下你自己查询的区块号。

这 88,794.99 BNB 仍然是 BSC 上的原生币，已经包含在官方剩余总量里。opBNB 上对应的余额，是凭这份锁定才存在的。两边都算，同一份 BNB 就被记了两次。

反过来，也不要把 Portal 里的余额从 BSC 总量里扣掉。锁住不等于销毁：这部分 BNB 没有被送进黑洞地址，用户从 opBNB 提款并完成之后，它会从 Portal 转回普通地址。把锁定当成减少，总量就会被算小，错误方向正好和重复计算相反。

算一遍：存入 1,000 BNB 后，两条链上的数字各怎么变

假设只发生一件事：某个地址通过官方桥，把 1,000 BNB 从 BSC 存到 opBNB。为了看清结构，这里忽略 Gas。

1. BSC 上，这个地址少了 1,000 BNB，Portal 合约多了 1,000 BNB。BSC 原生总量一枚没变。
2. opBNB 上，这个地址多出 1,000 BNB 可用余额。
3. 如果拿“BSC 所有余额 + opBNB 所有余额”当总供给，结果凭空多出 1,000。

不重复的记法是：BSC 总量照旧；opBNB 那 1,000 记作“由 Portal 锁定支持的二层余额”，作为分布信息单列，不进合计。想粗略知道有多少 BNB 在二层上，读 Portal 的锁定余额，比把 opBNB 上的地址逐个相加可靠得多。

从 opBNB 提回 BSC 的途中，为什么两边看起来都还在

反方向更容易算错。OP Stack 的提款规范写的流程是：二层发起提款，到一层的 Portal 上证明，进入 7 天挑战期，期满后再在 Portal 上完成提款。opBNB 的实际等待时间，本文没有找到它单独的官方说明，提款时看官方桥页面给出的时间。

等待期间，opBNB 上提走的 BNB 进了预部署合约 L2ToL1MessagePasser，地址 0x4200000000000000000000000000000000000016，用户已经动不了它。2026 年 10 月 15 日 10:47（UTC），向 opBNB 公开节点 opbnb-mainnet-rpc.bnbchain.org 查询 opBNB 区块 195,777,364 时这个合约的 eth_getBalance，换算后约为 33.97 BNB；换一个区块查，数字会不同。而在 BSC 上，对应的 BNB 在提款完成前仍留在 Portal 里。

用 opBNB 地址余额之和去估算二层上的 BNB 时，要把这个合约剔掉，不然在途提款会被重复记一次。规范列出的接口里有一个 burn 函数，但它什么时候被调用，官方文档没有写清，本文不对这部分余额的去向作推断。

以太坊上的 ERC-20 BNB 合约，为什么还有 39 万枚

BNB 最早是以太坊上的 ERC-20 代币，后来迁到自己的主网。BNB Chain 在 2023 年 1 月 17 日的第 22 次销毁公告里交代过这批旧币：早期迁移时约有 1,600 万枚 ERC-20 BNB 没有兑换；Binance.com 一直接受旧版 ERC-20 BNB 的充值；兑换方式是销毁 ERC-20 BNB，再从原生 BNB 的铸造地址放出等量原生币；这些 ERC-20 的销毁不计入季度销毁。

今天这个合约还剩多少，可以自己读。以太坊上合约 0xB8c77482e45F1F44dE1745F52C74426C631bDD52 的 totalSupply()，在 2026 年 10 月 10 日、以太坊区块 26,160,948 时返回 392,908.128 枚；Etherscan 的代币页显示同一数字，并标着 Mainnet Launched。

这 39 万枚和 BSC 上那 1.33 亿是什么关系，第 36 次公告没有提。能确定的是兑换规则：ERC-20 这边销一枚，原生那边放一枚，两边始终对应同一份权益。所以它不是“另一份供给”。表里给它单列一行，写上查询区块和日期，不进合计。

季度销毁的数字里也不含这部分。看到某个统计把 ERC-20 合约的减少量算进“BNB 累计销毁”，它统计的范围就和官方季度公告不同，两组数字不能直接比较。

其他链上也有叫 BNB 的代币：放进表格前先查三件事

一些跨链桥会在别的链上发行名称、符号都叫 BNB 的代币。它们背后可能有足额锁定，也可能只是同名。归类之前先确认：

• 发行方或桥项目公开的合约地址，以及它写明的锁定方式；
• 锁定那一侧的余额，能不能用公开节点或区块浏览器直接读到；
• 两边数量是否同步变化：一边发行多少，另一边就锁定多少。

三件事查不清，就放进“关系未明”一列，既不加进合计，也不从合计里扣。通用的分列做法在供应量对不上那篇里写过，这里只是把它落到 BNB 的具体合约上。

一份不重复计数的 BNB 分布记录

把上面几处放在一起，记录可以按下面的顺序排：

1. 合计：官方公告的剩余总量，写明公告日期。目前最新的是 2026 年 7 月 15 日公布的 133,166,127.91 BNB。
2. 分布一：BSC 上 OptimismPortalProxy 的余额，注明区块号。它反映有多少 BNB 正在支撑 opBNB 上的余额。
3. 分布二：opBNB 上 L2ToL1MessagePasser 的余额，注明是提款在途，和分布一有重叠。
4. 旁注：以太坊 ERC-20 BNB 合约的 totalSupply，注明旧版未兑换、按官方说明与原生币等量对应、不进合计。

分布行只回答“BNB 在哪里”，不改变合计。下一次季度销毁公布后先改合计行；分布行每次都重新查询，因为它们随区块变化。历次销毁的数字可以对照销毁档案。