Short answer
The answer in plain English
BounceBit retired its standalone Layer 1 after a protocol function allowed a caller to name another account as the source of funds without proving that account had authorized the transfer. The chain halted after 286.5 million BB moved across 14 transactions. Rather than rebuild an unsupported Evmos-based stack, BounceBit chose a pre-exploit snapshot and planned to reissue BB as a BEP-20 token on BNB Smart Chain.
Why it matters
What to understand
The incident was not a stolen-key attack. Signatures identified who submitted each call, but defective protocol logic failed to check whether that caller could spend from the named account. The recovery preserves balances from a chosen block, not the old chain itself, exposing both the usefulness and the governance cost of coordinated blockchain recovery.
Visual guide
How the pieces fit together
BounceBit’s incident is a clean example of a security distinction that often disappears inside the phrase “wallet hack.” The affected users did not lose BB because an attacker stole their private keys. BounceBit said the blockchain accepted transfers from accounts that had never authorized them.
The immediate failure was in permission logic. The broader reason the incident ended a Layer 1 involved inherited software, a discontinued upstream stack, the cost of maintaining an independent network, and a recovery process that could preserve balances without preserving the chain.
A signature is not a permission
Authentication answers who submitted this transaction? Authorization answers what is that person allowed to do? A secure transfer normally connects both checks: the signer must control the account whose balance will decrease, unless that account has granted a separate permission.
BounceBit said a function inherited through its Evmos-based stack let a smart-contract caller specify another account as the source of funds without correctly verifying that relationship. The attacker signed the call, so authentication still worked. The protocol then treated the named account as spendable, so authorization failed.
That difference matters to users. A stronger password, a fresh seed phrase, or a hardware wallet protects signing keys. None can repair a blockchain rule that accepts a correctly signed but unauthorized request.
What happened before the halt
According to BounceBit, 286,543,148 BB moved from nine mainnet accounts across 14 transactions between August 19 at 21:02 UTC and August 20 at 01:54 UTC. The chain stopped producing blocks at height 20,702,857 at 02:36:37 UTC, roughly 42 minutes after the last listed transfer.
A halt freezes change; it does not delete history. Validators stop publishing new blocks, applications cannot settle normal activity, and exchanges usually suspend deposits and withdrawals. The disputed transactions remain in the frozen ledger unless the community later adopts a repaired history or a different asset.
The snapshot replaces economic ownership, not history
BounceBit chose block 20,697,260, immediately before the first abnormal transfer, as the reference point for replacement balances. A snapshot reads the chain’s state at that block: account balances, staking positions, contract storage, and any other data included in the migration rules.
The plan is to issue BB as a BEP-20 token on BNB Smart Chain and allocate it according to that reference state. Because both chains use EVM-style addresses, the same private key can control the corresponding address on the new network. The attacker’s later balance can remain visible in the abandoned chain while the project, exchanges, and users agree not to treat it as economically valid.
This is different from rewinding the old chain. The old record is frozen; a replacement contract on another network becomes the recognized asset.
Snapshot boundaries create real edge cases
A snapshot is precise, but its boundary can be uncomfortable. A legitimate transfer after the chosen block and before the halt will not appear in a simple copy of the earlier state. Exchange wallets add another complication because one on-chain address may represent balances belonging to thousands of customers in an internal database.
These cases require reconciliation rather than automatic state copying. They also create a predictable scam window. A migration announcement can be imitated by messages asking users to connect wallets, enter seed phrases, or “claim” replacement tokens. Official contract details and exchange instructions matter more than urgency.
Why repair was not enough
BounceBit could have attempted to patch the affected function and restart. But the chain inherited code from the Evmos stack, and Evmos had already ceased block production after a shutdown proposal. That removes the comfort of a healthy upstream project testing fixes, reviewing related paths, and maintaining future releases.
A standalone chain also carries permanent costs: validators, staking incentives, RPC endpoints, explorers, wallets, monitoring, upgrades, exchange integrations, and emergency coordination. Repairing the line where one bug appeared would not prove that adjacent inherited paths were safe. BounceBit concluded that moving the asset to an existing network was the more credible route.
BB becomes a different kind of asset
On BounceBit Chain, BB was a native coin used for gas, staking, validator rewards, and governance. On BNB Smart Chain, BB becomes a token governed by a smart contract. BNB pays gas and BNB Smart Chain supplies consensus and network security.
BB may retain uses inside BounceBit products, but it no longer secures an independent BounceBit Layer 1. That is a structural change, not a cosmetic contract migration.
Technical finality and social finality diverged
Validators finalized the unauthorized transfers because they executed the protocol they were given. Technically, those state changes were valid under the buggy rules. Economically, they can lose meaning if exchanges, applications, developers, and holders coordinate around the replacement token.
That coordination can protect legitimate holders. It also places trust in the people selecting the snapshot, calculating allocations, securing the new contract, and resolving edge cases. Recovery demonstrates that blockchain systems are governed by code and by the institutions willing to decide which code and which ledger remain authoritative.
The durable lesson is narrower than “blockchains can be reversed.” A signature proves who requested an action. Security still depends on software proving that the signer was entitled to request it.
