BNB Chain BSC Token Hub incident, 2022-10-06

The Token Hub accepted cross-chain packages if they came with a valid IAVL Merkle proof that the package existed in the Beacon Chain's state. The proof verifier had a flaw in how it handled certain proof structures: the attacker could include an extra leaf whose hash was not properly accounted for, so a proof built around a fabricated package still produced the expected root (Verichains). With two such proofs, the attacker received 2M BNB that never existed on the Beacon Chain.

The response relied on centralisation: BSC's small validator set could coordinate a halt within hours and ship a patched client (GitHub PR #1121), which froze most of the funds. That containment would be impossible on a chain with a large, independent validator set — and it is exactly why critics questioned BNB Chain's decentralisation afterwards.

For bridge users, the important point is that a native "chain-to-chain" bridge is only as strong as its proof verifier. Light-client bridges are generally safer than multisigs, but a verifier bug turns them into an unlimited mint.

The amount the attacker could actually use was limited by liquidity, not by the bug: minting 2M BNB is easy, but turning it into other assets required moving it across bridges and lending markets, and the halt cut that off within hours.

At the time

During the halt users could not move funds on BNB Smart Chain at all. The sensible step was to wait for the validator announcement, not to bridge BNB out through third-party bridges at unusual prices, and to treat BNB on other chains with caution until the minted supply was confirmed frozen.

Now

When you see a chain halt, pause bridging to and from that chain and check the bridge's status page. Bridges that hold liquidity on an affected chain can be paused by their operators; our route pages show when a bridge stops quoting a route.