OAK — OnChain Attack Knowledge

Worked example · 2026-05

Verus ⇄ Ethereum Bridge — missing source-amount validation (checkCCEValues) — 2026-05-18

Loss
~$11.58M drained from the bridge's Ethereum-side reserves: 1,625 ETH, 103.57 tBTC v2, and ~147,659 USDC, subsequently swapped into ~5,402 ETH (~$11.4M). Cost to the attacker: ~$10 in VRSC fees for the source-side transaction. The disproportion between the ~$10 input cost and the ~$11.58M extraction is the structural signature of an economic-value-binding gap (see below).
OAK Techniques observed
OAK-T10.002 (Message-Verification Bypass — the canonical anchor. Blockaid classifies the root cause as the same class as Wormhole-2022 and Nomad-2022: a source↔destination economic-value-binding gap. The bridge correctly verified everything it knew how to verify — the notarised Verus state root (8/15 valid notary signatures), the Merkle proof of the cross-chain export, and the keccak256(serializedTransfers) == hashReserveTransfers hash binding — but never verified that the source-chain export's totalamounts / totalburned / totalfees actually backed the payouts it released. See techniques/T10.002-message-verification-bypass.md). OAK-T10 (Bridge / Cross-Chain parent). OAK-T9.004 (cross-referenced — the underlying defect is a contract-correctness flaw, a missing validation predicate in checkCCEValues, mirroring how OAK cross-references Wormhole under both T10.002 and T9.004).
Attribution
pseudonymous attacker. The attacker EOA (0x5aBb91B9c01A5Ed3aE762d32B236595B459D5777) and the holding wallet (0x65Cb8b128Bf6e690761044CCECA422bb239C25F9) are observable on Etherscan. The EOA was funded with 1 ETH via Tornado Cash ~14 hours before the exploit — a pre-attack opsec / funding signal, not a downstream laundering chain. No public attribution to a named operator group. Blockaid identified and reported the exploit first; PeckShield independently confirmed it. The Verus team had not publicly confirmed the incident at the time of initial reporting.
Key teaching point
Verus is the canonical 2026 worked example of an economic-value-binding gap — a T10.002 sub-class distinct from the signature/proof-forgery sub-class (Wormhole's missing-guardian-account validation) and the trusted-root-initialisation sub-class (Nomad's 0x00 root). Here, every cryptographic check passed: the notary signatures were sound, the Merkle proof was valid, and the hash binding between the committed hash and the decoded transfer blob held. The flaw was that the bridge bound the payout to a hash of the payout blob but never bound the payout to the source-chain economic totals that were supposed to fund it. An attacker could therefore commit, via a legal 0.02 VRSC transaction, to a Cross-Chain Export whose payout blob promised large reserves but whose source-side totalamounts were empty — and the Ethereum side paid out anyway. The detection-signal locus is the audit / formal-verification layer: auditors must verify not just that a proof is valid but that the proof commits to a source-side conservation invariant (payouts ≤ source burns/locks).

Summary

Verus operates a trust-minimised bridge between the Verus chain and Ethereum. The Ethereum-side contract accepts cross-chain imports authorised by a notary-signed Verus state root: it verifies that a Cross-Chain Export was committed on the Verus side (via a Merkle proof against the notarised root) and that the serializedTransfers blob submitted on Ethereum matches the committed hash, then decodes the blob and releases the corresponding assets from its reserves.

On 2026-05-18, an attacker exploited the fact that the bridge never checked source-side economic backing. Per Blockaid's root-cause analysis, the attack proceeded as follows:

  1. The attacker constructed a 0.02 VRSC transaction whose vout[1] was a Verus Cross-Chain Export committing to keccak(payout_blob) — but with empty source-side totals (totalamounts / totalburned / totalfees). The Verus protocol legally accepts this transaction; nothing on the source side is malformed.
  2. The Verus notaries dutifully signed the resulting state root (8/15 valid signatures — no key compromise, no notary collusion).
  3. The attacker then called submitImports() on Ethereum with a serializedTransfers blob whose keccak matched the committed hash. The bridge verified the notarised root, the Merkle proof, and the hash binding — all of which were genuinely valid — then decoded the blob and paid out 1,625 ETH + 103.57 tBTC + ~147,659 USDC from its reserves.

The missing check lives in checkCCEValues: the function that should have validated that the export's source-side totals actually back the requested payouts. Blockaid characterises the fix as ~10 lines of Solidity. The attacker swapped the drained assets into ~5,402 ETH; the funds were reported sitting in plain sight on Etherscan, unmoved, shortly after the incident.

Blockaid is explicit about what the incident is not: it is not an ECDSA bypass, not a notary-key compromise, and not a parser or hash-binding bug. Every component the bridge was designed to verify worked correctly. The vulnerability is the absence of a source-amount-conservation check — the bridge trusted the destination-side payout instruction without ever confirming it was backed on the source side.

Why this is structurally significant

T10.002 (Message-Verification Bypass) has, after this case, at least three distinguishable sub-classes that share a downstream primitive (the bridge releases value against a message it should have rejected) but differ entirely in where the verification predicate fails:

  1. Trusted-root-initialisation sub-class (Nomad, 2022-08). A contract upgrade set the trusted root to 0x00, which matched the sentinel for "untrusted". The verification function consequently accepted every message. The flaw was in the initialisation of verification state.

  2. Signature/account-validation sub-class (Wormhole, 2022-02). A deprecated signature-verification path on the Solana side did not validate the guardian-account address, allowing a forged VAA. The flaw was in who the proof was checked against.

  3. Economic-value-binding sub-class (Verus, this case). Every cryptographic check — signatures, Merkle proof, hash binding — passed. The flaw was that none of those checks bound the payout to the source-chain economic totals that were supposed to fund it. The proof was valid; what the proof committed to was economically empty. This is the conservation-invariant sub-class: the bridge verified message authenticity but not message solvency.

The three sub-classes have different detection loci. Nomad's lives at the post-upgrade smoke-test layer (simulate an invalid message after every upgrade). Wormhole's lives at the pre-deployment audit of the signature-verification path. Verus's lives at the invariant-specification layer: the auditor must articulate and verify the cross-chain conservation invariant (sum of destination payouts ≤ sum of source burns/locks for the same export), which is a semantic property of the bridge, not a structural property of any single proof. This is the hardest sub-class to catch in audit because every line of verification code is individually correct — the defect is a missing line, and the missing line encodes a protocol-level economic invariant rather than a local correctness property.

Timeline (UTC)

When Event OAK ref
Pre-2026-05-18 Verus ⇄ Ethereum bridge operates legitimately; Ethereum-side contract verifies notarised Verus state roots, Merkle proofs, and keccak256(serializedTransfers) == hashReserveTransfers hash binding on each import (standing T10.002 surface)
2026-05-18 (~14h pre-exploit) Attacker EOA 0x5aBb91…5777 funded with 1 ETH via Tornado Cash (pre-attack funding / opsec signal)
2026-05-18 Attacker constructs a 0.02 VRSC transaction whose vout[1] is a Cross-Chain Export committing to keccak(payout_blob) with empty source-side totalamounts / totalburned / totalfees; Verus protocol legally accepts it; notaries sign the state root (8/15 valid) T10.002 execution (source-side commitment to an unbacked export)
2026-05-18 Attacker calls submitImports() on Ethereum with a serializedTransfers blob matching the committed hash; bridge verifies root + Merkle proof + hash binding (all valid), decodes blob, releases 1,625 ETH + 103.57 tBTC + ~147,659 USDC from reserves T10.002 execution (destination-side payout against unbacked message)
2026-05-18 Attacker swaps drained assets into 5,402 ETH ($11.4M); funds reported sitting unmoved on Etherscan in holding wallet 0x65Cb8b…25F9 T5 outflow / staging
2026-05-18 Blockaid identifies the exploit and reports it on X with root-cause analysis (missing source-amount validation in checkCCEValues); PeckShield independently confirms the ~$11.58M figure (third-party detection / forensic surface)

What defenders observed

  • Pre-event (verification-predicate layer): the bridge's import-verification path verified message authenticity (notary signatures, Merkle proof) and message integrity (hash binding) but contained no source-side conservation check. checkCCEValues did not validate that the export's totalamounts / totalburned / totalfees backed the requested payouts. This was a standing T10.002 surface from deployment. Defender lesson: a bridge's verification suite must include a solvency invariant, not only authenticity and integrity checks — "the message is genuine and well-formed" is necessary but not sufficient; "the message is backed on the source side" is the missing predicate.
  • At-event (on-chain signal): a submitImports() call released 1,625 ETH + 103.57 tBTC + ~147,659 USDC against a source-side export whose committed totals were empty. A bridge-monitoring indexer enforcing the conservation invariant (destination payout vs source-export totals for the same export ID) would have flagged the payout in real time. The disproportion between the ~$10 VRSC source-side cost and the ~$11.58M destination payout is itself the signal.
  • At-event (funding signal): the attacker EOA was funded with exactly 1 ETH via Tornado Cash ~14 hours before the exploit. A fresh, mixer-funded EOA interacting with a bridge's privileged import path is an elevated-risk pattern, though not by itself actionable (it is a common, legitimate privacy pattern as well).
  • Post-event: the drained assets were swapped into ~5,402 ETH and reported sitting unmoved on Etherscan, consistent with a staging position rather than an immediate laundering chain. The Verus team had not publicly confirmed the incident at the time of initial third-party reporting — detection and disclosure were driven by Blockaid and PeckShield, not first-party telemetry.

What this example tells contributors writing future Technique pages

  • T10.002 needs a documented economic-value-binding sub-class. Existing canonical cases (Nomad trusted-root-init, Wormhole signature-account validation) both fail at a structural verification step. Verus fails at a semantic one: every structural check passes, but no check binds the payout to source-side economic backing. Contributors should record which sub-class a new T10.002 case belongs to, because the audit and detection guidance diverges entirely.
  • "Verified everything it knows how to verify" is a distinct failure mode from "verification was bypassed." In Nomad and Wormhole the verification predicate was defeated; in Verus the verification predicate was incomplete. Forensic write-ups that describe Verus as a "verification bypass" obscure this — Blockaid's framing ("NOT a parser/hash-binding bug; IS a missing source-amount validation") is the precise one and should be preserved.
  • The conservation invariant is the load-bearing audit property for reserve-backed bridges. Any bridge that releases assets from a reserve against a cross-chain instruction must verify that the instruction is backed by an equal-or-greater source-side burn/lock for the same transfer. This is a protocol-economic invariant, not a local-correctness one, and is the kind of property most likely to be missing precisely because every individual line of verification code looks correct.
  • Cost-to-extraction ratio is a structural signal worth recording. Verus: ~$10 input → ~$11.58M output. The near-zero attacker cost is diagnostic of a value-binding gap (the attacker mints authorisation for free on the cheap source side) rather than a key-compromise or social-engineering vector (which carry real acquisition cost). The ratio belongs alongside notional-vs-realised loss as a T10 structural metric.

Public references

Discussion

Verus completes the v0.1 T10.002 reference set by adding the economic-value-binding (conservation-invariant) sub-class alongside Nomad (trusted-root-initialisation) and Wormhole (signature/account-validation). The three cases together establish that "message-verification bypass" is an umbrella for at least three structurally distinct predicate failures, and that the most dangerous of these — the Verus sub-class — is the one in which no individual verification step is wrong. The defect is the absence of a protocol-economic invariant (payouts ≤ source backing) that no single proof encodes.

The case pairs naturally with the April 2026 Hyperbridge incident (examples/2026-04-hyperbridge-merkle-proof-counterfeit-mint.md): both are reserve-/mint-side bridge failures where the cryptographic machinery functioned as designed and the attacker's leverage was a gap in what the verified message was bound to. Hyperbridge's gap was proof-to-message binding (an old valid proof accepted for a different message); Verus's gap is message-to-source-backing binding (a valid message accepted without source-side economic backing). Contributors building out the T10 bridge cohort should treat "binding gaps" — proof-to-message, message-to-source-backing, message-to-origin (CrossCurve, in examples/2026-q1-q2-crosschain-bridge-otc-cohort.md) — as a coherent family of failures distinct from key-compromise (T10.001) and replay (T10.003).

The Blockaid forensic thread is unusually precise for a same-day disclosure: it enumerates exactly what the bridge verified correctly, names the specific function (checkCCEValues) and the missing predicate, sizes the fix (~10 lines), and explicitly rules out the failure modes the incident is not. PeckShield's independent confirmation of the ~$11.58M figure satisfies the v0.1 standard of triangulation across at least two independent forensic providers.

Techniques demonstrated (3)