OAK — OnChain Attack Knowledge

Worked example · 2026-07

AFX Trade — five compromised hot-validator keys meet the bridge's two-thirds quorum, and a 200-second dispute window passes with nobody watching it — AFX Trade (Arbitrum) — 2026-07-22

Loss
~$24.15M USDC drained from AFX Trade's third-party bridge on Arbitrum — close to the protocol's entire TVL at a moment when deposits were at their peak. The proceeds were bridged to Ethereum and swapped into roughly 12,467.5 ETH, consolidated in a single wallet and, as of initial reporting, still trackable on-chain. This was the fourteenth crypto security incident recorded in July 2026 and took the month's running total from about $72.6M to roughly $97M.
OAK Techniques observed
OAK-T10.001 (Validator / Signer Key Compromise — primary, confirmed mechanism. Per Blockaid, five of the bridge's hot-validator signing keys were in attacker hands, which was enough to satisfy the bridge's two-thirds signature quorum. The withdrawal that emptied the bridge carried a genuinely valid, correctly-thresholded signature set. See techniques/T10.001-validator-signer-key-compromise.md). OAK-T10.004 (Optimistic Bridge Fraud-Proof Gap — cross-referenced, and the reason the loss was total rather than partial. The bridge contract implemented a 200-second dispute period during which the withdrawal could have been challenged. No challenge was filed, the window elapsed, and the contract released the funds exactly as specified. A fraud-proof window with no funded, monitored challenger is a delay, not a control). OAK-T7.003 (Cross-Chain Bridge Laundering — Arbitrum → Ethereum, then swapped to ETH).
Attribution
pseudonymous. No named individual or group, and no public link to a tracked OAK actor. The stolen USDC was bridged to Ethereum, converted into approximately 12,467.5 ETH, and consolidated into a single wallet under on-chain observation. The mechanism by which the five hot-validator keys were obtained has not been publicly disclosed; OAK records the compromise as confirmed and the entry vector as unknown rather than inferring one. Blockaid detected and analysed the incident.
Key teaching point
Two independent controls both existed, and each one silently depended on the other being sound. The quorum assumed that no attacker could reach two-thirds of the signers; the dispute window assumed that if one somehow did, a challenger would notice within 200 seconds. Neither assumption was tested against the other's failure, so when the first fell the second was already unmanned — the bridge contract executed correctly and paid out. Two lessons separate cleanly here. First, "hot" is the load-bearing word: keys that must be online to sign routine traffic are keys an attacker can reach through the infrastructure that hosts them, and a threshold across five always-online keys on shared operational footing is not five independent failures. Second, a challenge period is only a control if somebody is paid and instrumented to challenge — 200 seconds is far too short for a human to notice, verify, and act, so it is only meaningful if an automated watcher with standing capital and pre-authorised transaction paths is already running. AFX had the window and not the watcher.

Summary

AFX Trade is a perpetuals exchange deployed on Arbitrum. Its deposits were held behind a third-party bridge — not Arbitrum's native bridge — secured by a validator set whose withdrawals required a two-thirds signature quorum, followed by a 200-second dispute period before funds were released.

On 2026-07-22 at 21:30 UTC, a withdrawal request appeared carrying five valid hot-validator signatures, satisfying the quorum. The signatures were cryptographically genuine; the keys had been compromised. The contract accepted them, opened its dispute period, received no challenge, and after 200 seconds released approximately $24.15M in USDC — very nearly everything the protocol held, at a point when deposits had peaked.

The attacker bridged the proceeds from Arbitrum to Ethereum and swapped them into roughly 12,467.5 ETH, consolidating the position in a single wallet.

Offchain Labs co-founder Steven Goldfeder publicly clarified that the Arbitrum native bridge was not hacked or exploited in any way — the compromise was confined to a third-party protocol operating its own bridge on the network. This distinction matters for anyone reading chain-level loss tallies: the incident is an Arbitrum-hosted failure, not an Arbitrum failure.

Timeline (UTC)

When Event OAK ref
(standing) AFX deposits sit behind a third-party bridge: two-thirds validator quorum, five hot signing keys sufficient to meet it, 200-second dispute period, no funded challenger monitoring the window (standing T10.001 / T10.004 surface)
(undisclosed, prior) Five hot-validator signing keys come under attacker control; entry vector not publicly disclosed T10.001 pre-positioning
2026-07-22 21:30 Withdrawal submitted with five valid hot-validator signatures; two-thirds quorum satisfied; contract accepts T10.001 exploitation
+200 seconds Dispute period elapses with no challenge filed; contract releases ~$24.15M USDC as designed T10.004 (unwatched window)
shortly after Funds bridged Arbitrum → Ethereum, swapped into ~12,467.5 ETH, consolidated into a single wallet T7.003
after Blockaid publishes analysis; Offchain Labs confirms the Arbitrum native bridge was not involved; July 2026 incident total rises from ~$72.6M to ~$97M (response / context)

What defenders observed

  • Pre-event (five hot keys are not five independent failures). A two-thirds quorum is a strong control only if the signers fail independently. Hot keys — online by definition, because they sign routine bridge traffic — typically share hosting, deployment tooling, secret-management, and operator personnel. The right pre-event question is not "how many signatures do we require?" but "what is the smallest number of compromises that reaches quorum, counting shared infrastructure as one?" (M11, M22).
  • Pre-event (an unwatched dispute window is theatre). The 200-second period was a real, correctly-implemented mechanism that contributed nothing, because a challenge window without a challenger is just latency. Operating one requires an automated watcher with independent view of what a legitimate withdrawal looks like, capital staged to post a challenge, and pre-authorised paths to submit it within the window. Any protocol running a fraud-proof window should be able to name who runs the watcher and demonstrate the last time it fired (M04, M05).
  • Pre-event (200 seconds is an architectural choice with consequences). Even a fully-staffed team cannot reliably detect, triage, and dispute in under three and a half minutes; the window length only makes sense paired with automation. Windows are set for user experience and then relied upon for security, and the two objectives were never reconciled here.
  • At-event (near-total TVL egress in a single transaction). One withdrawal taking essentially the entire bridge balance is the crudest possible anomaly signal and needs no signature analysis to fire. A per-transaction and per-window cap sized against reserve — a limit that no legitimate operation would approach — converts a total drain into a partial one regardless of how valid the signatures are (M04).
  • Response (traceability held even though prevention did not). The proceeds went to Ethereum and sat as ~12,467.5 ETH in one identifiable wallet. That gives exchange- and issuer-coordination a target, which is the residual recovery lever once the funds have left. It is worth noting that it is the only lever the design left available.

Public references

Discussion

AFX belongs to the same July cohort as examples/2026-07-wanchain-cardano-bridge-non-injective-encoding-signature-reuse.md, and the pair is instructive precisely because the mechanisms are opposites. Wanchain's validators were honest and its signatures meant the wrong thing; AFX's signatures meant exactly what they said and the validators' keys were not theirs. Both bridges satisfied their own security model at the moment they were drained. What the two share is that the security model terminated at signature validity — neither had a bound on how much value a single valid authorisation may move, which is the one control that would have limited both losses without needing to understand either mechanism.

The most transferable finding here is about the dispute window, because optimistic and semi-optimistic designs have proliferated far faster than the challenger infrastructure they presuppose. OAK already documents this asymmetry structurally in examples/2022-2025-arbitrum-one-optimistic-bridge-validator-set-gap.md; AFX is the realised version. The design was not naive — it anticipated exactly the failure that occurred and provided a mechanism to catch it — but the mechanism was unstaffed, and an unstaffed mechanism has a security value of zero while continuing to appear in architecture diagrams as a control. Defenders assessing any protocol with a challenge period should treat "who challenges, with what capital, on what trigger" as a hard question with a name-and-runbook answer, and treat "the contract supports challenges" as a non-answer.

Finally, the entry vector for the five hot keys was never publicly disclosed, and OAK deliberately leaves it unknown rather than assuming a phishing, endpoint, or infrastructure origin. That gap is itself worth recording: for a $24M loss, the industry learned that five keys fell but not how, which means no other operator running the same signer topology can check whether they share the exposure.

Techniques demonstrated (3)