How AFX Bridge Lost $24 Million in Three Minutes—Without a Hack

On July 22, 2026, 24.15 million USDC—nearly all available liquidity—was drained from AFX Bridge on Arbitrum. Yet this was not a hack in the conventional sense: no encryption was broken and no code vulnerability was exploited. The bridge followed its own rules, treated the withdrawal as legitimate, and released the funds because the instruction carried five authentic signatures out of seven. The attacker had secured a majority of the votes held by the parties trusted to authorize transfers.

BitOK analysts reconstructed the crypto theft in detail. Here is how the attackers obtained $24 million in three minutes without breaching the bridge itself.

To understand the attack, start with three key terms:

The key facts:

A simple analogy helps explain what happened. Imagine a vault guarded by seven people, each holding a key. If guards controlling more than two-thirds of the votes hand over their keys, the system opens the vault automatically. The attacker presented five authentic digital signatures—the equivalent of genuine keys—so the order appeared perfectly legitimate. The vault opened willingly.

It is important to understand where the actual weakness lay. The attacker did not breach Arbitrum’s security or make the contract bypass signature verification. Instead, they exploited the keys—or the signing infrastructure—of the parties AFX trusted to approve withdrawals. The code worked exactly as intended; the failure was in the trust model and key management.

How the amounts changed at each stage, from withdrawal to the final address:

The active set of “hot” validators consisted of seven participants with nearly equal voting weights. Out of a total weight of 10,000, validators representing 7,142 signed the instruction—enough to exceed the two-thirds threshold.

Once the attacker received the USDC, they moved quickly, swapping the assets and changing where the stolen funds were held. The sequence was as follows:

The six CCTP transfers were as follows:

How the attacker moved the funds. The graph was built using BitOK's Graph tool.

Any operation of this kind requires a small amount of “fuel” to get started, such as gas to pay transaction fees. This is where analysts found a lead that may help identify who was behind the attack.

The initial gas did not come from Tornado Cash, a popular mixer often used to obscure fund flows. Instead, it came from the service wallet 0xe946…76cbA, which received 0.204 ETH on the day of the attack and then forwarded funds to the attacker’s operational address. The wallet behaves like a service wallet: it receives funds from many sources, pays many recipients, and sends precise, non-round amounts after fees.

Investigator’s note: the strongest working hypothesis links this wallet to the instant-exchange service ChangeNOW, or to an aggregator using ChangeNOW liquidity. The wallet history includes a direct deposit from an address labeled as ChangeNOW, as well as links to liquidity from HTX and Binance. Its ownership has not been conclusively established; confirming it would require the service’s internal logs.

A separate clarification concerns 0x370A…12cF, which appears in the gas-funding chain. This is a high-volume Relay Solver, a technical executor of cross-chain operations. Among other things, it transferred 0.1 ETH through MetaBridge and paid out approximately 0.099 ETH on Ethereum. It is neither the source of the funds nor the operator’s wallet, but a service address used by many customers.

A closer look at each conclusion regarding the funding source:

Four addresses form the core of the investigation:

Technical detail: the recipient address 0x2f29…FEefc uses EIP-7702, a relatively new Ethereum feature that allows an externally owned account to temporarily execute smart-contract code. This explains why the address appears to “call itself” during the CCTP transfers, but it does not reveal who controls it.

The attackers prepared gas and operational wallets in advance. They then presented the bridge with a majority of validator signatures, prompting it to release almost all of its liquidity. The funds were moved to another network, converted to ETH, and consolidated in one place less than 20 minutes after the withdrawal.

Investigator’s note: as of the July 23 review, the destination wallet still held all of the ETH it had received, and no confirmed outgoing transfers of the stolen funds had been identified. The central question remains unresolved: how the five signatures were obtained—through key theft, compromise of shared signing infrastructure, malware, or insider involvement. The attacker’s identity and jurisdiction, as well as the likelihood of asset recovery, also remain unknown.

One caveat for future monitoring: if the destination wallet later receives zero-value transactions carrying messages or unsolicited scam tokens, those should be treated as ordinary on-chain spam—not as movement of the stolen funds.

The main lesson is that a system can be robbed without a single line of code being broken. Compromising the trust on which it depends can be enough.

The good news is that the funds remain visible at a single address and have not entered a mixer. That alone, however, does not guarantee recovery. Recovering the assets would require action from relevant platforms and, in most cases, legal procedures. Preventing a theft is vastly cheaper than trying to recover assets after the fact.