BounceBit Chain's $3.1M Exploit: How a Wrong-Principal Authorization Check in the Evmos Vesting Module Forced a Permanent Chain Shutdown

At 21:02 UTC on August 19, 2026, an attacker began draining tokens from nine accounts on BounceBit Chain, the project's Ethereum-compatible Layer 1 blockchain built on the Evmos software stack. Over the next four to five hours, across 14 separate transactions, the attacker moved precisely 286,543,148 BB tokens — approximately $3.1 million at the time — to addresses under their control. The last unauthorized transfer was recorded at 01:54 UTC on August 20.

The exploit was not a wallet compromise. No private keys were stolen. No signatures were forged. No exchange accounts were breached. The vulnerability was entirely at the protocol layer: a pair of authorization check failures inside the Evmos vesting and lockup module, a built-in component of the Evmos stack that BounceBit Chain had inherited. The flaw allowed an attacker to designate any on-chain account as the funding source for a token transfer without that account's authorization, then execute the debit.

BounceBit detected the unauthorized activity and halted block production at block 20,702,857 at 02:36:37 UTC on August 20, stopping any further unauthorized movement. The team submitted exchange freeze requests against the attacker addresses and began coordinating with external security researchers. A pre-attack snapshot was taken at block 20,697,260 — the last block before the first unauthorized transaction — to serve as the reference state for user balance recovery.

BounceBit subsequently announced the permanent sunset of its Layer 1 chain. The decision not to patch and restart was driven partly by the Evmos stack itself being discontinued — meaning the underlying software would receive no further security maintenance — and partly by the recognition that a chain whose protocol layer had been exploited required a fundamental rethink, not a patch. BB tokens are being reissued as a BEP-20 token on BNB Chain, with balances restored from the pre-attack snapshot and distributed automatically to corresponding addresses. The products built above the chain layer — CeDeFi Strategy, Promo Vaults, Prime, and RWA — were not affected.

The Evmos vesting module is a protocol-level component built into the Evmos software stack, which BounceBit Chain used as its foundation. The module manages clawback vesting accounts — a specialised account type common to Cosmos SDK chains. In this model, tokens in a vesting account vest over time according to a schedule, and a designated funder address is recorded at account creation. The funder can contribute tokens to the vesting account and, in some configurations, claw back unvested tokens. Operations that involve moving funds between the funder and the vesting account require that the funder has explicitly authorised the relevant action.

The vulnerability consisted of two compounding authorization failures in the logic that was supposed to enforce this requirement. Understanding them separately is necessary to understand how they combined into an exploitable path.

Failure 1: The debited account's authorization was not verified

The first failure was a missing or ineffective check on whether the account being debited had actually authorised the outgoing transfer. The module accepted a message that named a funder account and a recipient, and began processing the transfer without confirming that the funder had approved the specific operation. The check that was supposed to enforce this approval either did not run or did not correctly validate the funder's intent for the transaction at hand.

// MsgFundVestingAccount allows a funder to provide tokens to a vesting account.
// The module is supposed to verify that the message signer IS the designated funder.

func (k Keeper) FundVestingAccount(ctx sdk.Context, msg *types.MsgFundVestingAccount) error {
    vestingAcc := k.accountKeeper.GetAccount(ctx, msg.VestingAddress)

    // The correct check: confirm msg.FunderAddress == vestingAcc.FunderAddress
    // AND that the signer has authorised this specific debit.

    // [BUG 1]: The authorization check on the debited (funder) account
    // was absent or incorrectly structured — the protocol processed the
    // debit without confirmed approval from the account being drained.
    if !k.hasValidFunderAuthorization(ctx, msg.FunderAddress, msg.VestingAddress) {
        // This guard either did not execute or passed when it should have failed.
        return types.ErrUnauthorized
    }

    // Execution reached here even for unauthorized callers.
    // Funds are transferred from msg.FunderAddress to msg.VestingAddress.
    return k.bankKeeper.SendCoins(ctx, funderAddr, vestingAddr, msg.Amount)
}

Failure 2: The second authorization check evaluated the wrong principal

A second authorization check — likely intended as a defence-in-depth control or a required prerequisite check in the message server flow — was evaluating the wrong address. Rather than checking whether the designated funder had authorised the specific operation, it checked a different principal: either the message sender, the vesting account itself, or another address in the call context. Because that alternative address had (or could trivially obtain) the requisite permission, the check passed, providing a false green-light to proceed.

// Prerequisite authorization check in the message handler.
// Should check: does funderAddress have an active grant authorising this operation?

func (k Keeper) checkFundingAuthorization(ctx sdk.Context, msg *types.MsgFundVestingAccount) error {
    grantee := sdk.MustAccAddressFromBech32(msg.FunderAddress)
    granter := sdk.MustAccAddressFromBech32(msg.VestingAddress) // <- intended

    // [BUG 2]: The granter (the party whose funds are at risk) and grantee
    // roles are effectively swapped or a surrogate address is used.
    // The check succeeds because it evaluates an address the attacker controls
    // or one that trivially satisfies the condition — not the actual funder.
    authorization, _ := k.authzKeeper.GetAuthorization(ctx, grantee, granter, sdk.MsgTypeURL(msg))
    if authorization == nil {
        return types.ErrNoActiveGrant
    }
    // Authorization found for the wrong principal — check passes.
    return nil
}

The combined effect: arbitrary account designation as funding source

With both checks failing — the first absent or ineffective, the second evaluating the wrong address — an attacker could craft a MsgFundVestingAccount (or equivalent vesting module message) that named any on-chain address as the funder. The protocol would process the message, debit the named funder account, and credit the destination the attacker controlled, without the named funder having approved or even been aware of the transaction. The attacker operated with two controlling accounts and approximately fifteen single-use contracts to route and obscure the flows.

The nine accounts drained were not random. They were accounts holding significant BB token balances — likely identified in advance through on-chain analysis of the chain's balance distribution. The 14 transactions executed over roughly five hours suggest the attacker spread the drain across multiple sequential calls, either to stay under monitoring thresholds or because each vesting account required a separate transaction to drain individually.

Why the chain could not be patched and restarted

The Evmos software stack on which BounceBit Chain ran has been discontinued by its developers. This is a critical operational fact: the vulnerable module was inherited from upstream software that will receive no further security patches, no maintenance updates, and no community support. Even if BounceBit had identified and fixed the specific flaw, continued operation on a discontinued software foundation would mean running with a growing backlog of unaddressed vulnerabilities and no upstream support to help identify or resolve them. The permanent shutdown was the technically correct response to this combination of a specific exploit on an unmaintained foundation.

The controls that would have prevented this incident are well-established in both Cosmos SDK security practice and general authorization system design. Their absence in inherited infrastructure reflects a gap in how third-party module risk is evaluated during chain deployment.

• Audit all inherited protocol modules before mainnet deployment. BounceBit Chain inherited the Evmos vesting module as a component of the software stack rather than developing it. Inherited code carries inherited risk. Every module included in a production chain — especially one handling fund movement — must be independently audited against the specific configuration and token economics of the deploying chain, regardless of what audits may have been performed on the upstream codebase previously.
• Verify authorization against the correct principal explicitly. The authorization check that evaluated the wrong address reflects a pattern where the caller and the debited party are conflated. Any authorization system that permits one party to nominate another as the source of funds must verify authorization from the nominated party, not from the initiator of the request. This distinction — grantee versus granter, caller versus debited — must be explicit in code and verified in review. It is a trivial mistake to make and a trivial mistake to catch with targeted testing.
• Write tests specifically for unauthorized debit scenarios. A test that attempts to execute a fund-vesting operation where the message signer does not match the designated funder, and asserts that this operation fails, would have caught both authorization failures directly. Authorization bypass vulnerabilities in module message handlers are reliably detectable through unit tests that assert rejection of malformed or unauthorized inputs. Their absence from the test suite is the proximate engineering failure here.
• Monitor and sunset dependence on discontinued upstream software. Running production infrastructure on a discontinued software stack is an escalating risk. Evmos's discontinuation was not an overnight event; it was a gradual process during which the signals of reduced maintenance were visible. Projects with infrastructure dependencies on externally maintained software must track the maintenance status of those dependencies and have a migration plan before the upstream project is abandoned, not after an exploit forces the issue.
• Restrict vesting module operations to whitelisted callers. For chains where the vesting module is used for a specific, defined set of operations — team token releases, investor allocations — the set of accounts permitted to initiate vesting module messages can be whitelisted at the chain level. Restricting the module's message types to pre-authorised callers would have limited the attacker's ability to invoke the vulnerable message handler regardless of what the authorization checks returned.
• Deploy on-chain anomaly detection for high-value module operations. Fourteen transactions draining nine accounts over five hours is a detectable pattern. An automated monitoring system watching for unusual volumes of vesting module activity — transactions that move more than a defined token threshold, or that involve accounts not historically associated with vesting operations — would have produced an alert long before the 286 millionth token moved.