OAK — OnChain Attack Knowledge

Worked example · 2026-05

Stake DAO — deployer-key compromise → LayerZero OFT peer redirect → 5.4T vsdCRV mint — 2026-05-27

Loss
~$91K realised (the attacker swapped ~16.83M vsdCRV for 43.7 ETH), against a notional mint of ~5.4 trillion vsdCRV (~$763B at face value) on Arbitrum. The realised figure is tiny relative to the mint because vsdCRV is extremely illiquid — its pools held only tens of thousands of dollars — so the unbacked supply could not be exited at scale. Stake DAO contributors secured the vsdCRV backing on Ethereum mainnet and closed the bridge, containing the incident to Arbitrum and preventing the attacker from reaching the mainnet collateral.
OAK Techniques observed
OAK-T11.001 (Third-Party Signing-Vendor / Operator Key Compromise — the canonical anchor. The Stake DAO deployer private key was compromised; every subsequent action used that key's legitimate authority. See techniques/T11.001-third-party-signing-vendor-compromise.md). OAK-T10.002 (Message-Verification Bypass — the compromised key was used to reconfigure the LayerZero v2 OFT (Omnichain Fungible Token) peer on the vsdCRV token contract, redirecting cross-chain trust from the legitimate Ethereum-side vsdCRVOFTAdapter to an attacker-deployed malicious contract; the Arbitrum token then accepted "mint" messages from the attacker's contract as if they were authentic cross-chain transfers). OAK-T9.004 (Access-Control Misconfiguration — cross-referenced: the OFT peer-configuration setter was a privileged function whose only gate was the deployer key, so a single key compromise reconfigured the token's entire cross-chain trust root). OAK-T10.009 (Cross-Chain Token Configuration-Role Capture — the attack reshaped the cross-chain authorisation graph rather than exploiting a logic bug in message handling. This case is the Technique's first documented anchor; it was originally cross-referenced to OAK-T10.006, which does not reach it — T10.006 requires a governance action approved on one chain and relayed to another, and here nothing was relayed and no proposal existed).
Attribution
pseudonymous attacker; suspected deployer-key compromise (Stake DAO's own framing). The malicious mint transaction is pinned on-chain (block 467160931, 09:17:58 UTC, 2026-05-27, ~5.45T vsdCRV minted from the null address). No public attribution to a named operator group. The incident is recorded as a key-compromise event consistent with Stake DAO's statements; the exact key-exposure vector (phishing, endpoint compromise, leaked CI secret) was not publicly established.
Key teaching point
Stake DAO is the 2026 worked example of an OFT peer-trust redirect — a cross-chain attack in which a compromised admin key is used not to drain a contract directly, but to **rewrite *which remote contract the token trusts as its mint authority.*** LayerZero's OFT standard lets a token on chain B mint when it receives a validated message from a trusted peer on chain A. If the peer-setting function is gated only by a single deployer key, then compromising that key lets the attacker point the Arbitrum vsdCRV at an attacker-controlled "Ethereum-side adapter," after which the attacker can mint arbitrary supply on Arbitrum by sending messages from a contract they control. Every individual cross-chain message validates correctly — the flaw is that the definition of "trusted peer" was mutable by a single key. The detection-signal locus is the cross-chain configuration layer: a change to an OFT peer (or any cross-chain trust root) is among the highest-privilege actions a token can undergo and must be governed by a timelock + multisig and alerted on in real time, exactly as a contract upgrade would be.

Summary

Stake DAO is a Curve-ecosystem DAO; vsdCRV is its liquid wrapper for vote-escrowed CRV, deployed cross-chain via LayerZero v2's OFT standard. The canonical backing lives on Ethereum mainnet (the vsdCRVOFTAdapter), and the Arbitrum-side vsdCRV mints/burns in response to validated LayerZero messages from its configured peer.

On 2026-05-27, an attacker who had compromised the Stake DAO deployer private key used it to reconfigure the vsdCRV token's LayerZero v2 OFT peer, redirecting trust away from the legitimate Ethereum-side adapter and toward an attacker-deployed contract. With the token now treating the attacker's contract as its authorised cross-chain mint source, the attacker minted ~5.4 trillion vsdCRV on Arbitrum (transaction at block 467160931, 09:17:58 UTC). The nominal value was ~$763B, but vsdCRV's on-chain liquidity was negligible; the attacker managed to swap 16.83M vsdCRV for **43.7 ETH ($91K)** before the market and the team responded.

Stake DAO contributors secured the vsdCRV backing on Ethereum mainnet and closed the vsdCRV bridge, which contained the incident to Arbitrum and stopped the attacker from seizing the mainnet collateral. Stake DAO stated its key products were unaffected and that the bridge was closed pending investigation.

Why this is structurally significant

Stake DAO sits at the intersection of two corpus families that are usually treated separately:

  1. Key compromise (T11.001). As with Step Finance, IoTeX, and Gravity (see examples/2026-q1-q2-key-compromise-cohort.md), the cryptography was sound and the attacker simply held a legitimate privileged key. The deployer key was the single point of failure.
  2. Cross-chain trust redirection (T10.002 / T10.006). Unlike a direct drain, the compromised key was spent on a configuration change — repointing the OFT peer — which then unlocked an unbounded mint on the satellite chain. The mint messages themselves validated correctly under LayerZero; what was corrupted was the peer definition that LayerZero validates against.

This makes Stake DAO the bridge-side analogue of a "trusted-root-initialisation" failure (Nomad), but achieved through post-deployment reconfiguration rather than a buggy upgrade: the trust root (the OFT peer) was mutable by a single key, so the attacker rewrote it. The lesson generalises to every cross-chain token: the peer/trust-root setter is a higher-privilege action than ordinary admin functions, because it controls what counts as an authentic cross-chain mint, and it must therefore carry upgrade-grade governance (timelock + multisig + monitoring).

The case also illustrates why illiquidity bounded the loss and why containment worked. The ~5.4T mint was worth ~$763B on paper but only ~$91K in practice, because the attacker had to sell into shallow pools. And because the backing lived on a different chain (Ethereum mainnet) behind a bridge the team could close, the team could sever Arbitrum from the collateral before the unbacked supply reached it. The structural takeaway: a cross-chain design where the satellite mint and the canonical backing are separable can contain an unbacked-mint event — but only if the team detects it and closes the bridge before the attacker bridges out. Detection latency is the whole game.

Timeline (UTC)

When Event OAK ref
Pre-2026-05-27 vsdCRV deployed cross-chain via LayerZero v2 OFT; Arbitrum vsdCRV mints on validated messages from its configured Ethereum-side peer (vsdCRVOFTAdapter); peer-setting gated by the deployer key (standing T10.002 / T9.004 surface)
2026-05-27 Stake DAO deployer private key compromised (vector not publicly established) T11.001 (deployer key compromise)
2026-05-27 Attacker uses the key to reconfigure the vsdCRV LayerZero v2 OFT peer, redirecting trust from vsdCRVOFTAdapter to an attacker-deployed contract T10.002 / T10.006 (cross-chain trust-root redirect via privileged config change)
2026-05-27 09:17:58 (block 467160931) Attacker mints ~5.45T vsdCRV from the null address on Arbitrum via messages from the attacker-controlled "peer" T10.002 execution (unbounded mint against redirected peer)
2026-05-27 Attacker swaps 16.83M vsdCRV for 43.7 ETH ($91K) into shallow Arbitrum liquidity T5 outflow
2026-05-27 Stake DAO contributors secure the vsdCRV backing on Ethereum mainnet and close the vsdCRV bridge, containing the incident to Arbitrum (operator response / containment)

What defenders observed

  • Pre-event (configuration-governance layer): the OFT peer-setting function was gated by a single deployer key rather than a timelock + multisig. A change to a cross-chain trust root is an upgrade-class action; gating it like an ordinary admin call meant one key compromise rewrote the token's mint authority. Defender lesson: treat OFT peer/trust-root setters as upgrade-equivalent — timelock, multisig, and a monitored alert on any peer change.
  • At-event (config-change signal): the LayerZero OFT peer of a live token was reconfigured to a freshly-deployed contract, immediately followed by an enormous mint from the null address. A monitor watching peer/config changes on cross-chain tokens would have fired on the reconfiguration before the mint; a supply monitor would have fired on the implausible 5.4T mint. Either alone buys containment time.
  • At-event (illiquidity as a natural cap): the ~$763B nominal mint realised only ~$91K because vsdCRV pools were shallow. The notional-vs-realised gap is the structural signature of an unbacked-mint event into an illiquid token.
  • Post-event (containment): because the canonical backing lived on Ethereum mainnet behind a closable bridge, the team severed Arbitrum from the collateral and limited the loss to what the attacker had already swapped. Containment success was a function of detection speed and architectural separability of mint from backing.

What this example tells contributors writing future Technique pages

  • OFT / cross-chain peer reconfiguration deserves explicit treatment under T10.002. It is mechanically distinct from message-forgery (Wormhole), value-binding gaps (Verus), and encoding collisions (Butter): here the messages are authentic and validate correctly, but the peer they validate against was maliciously redefined via a privileged config change. Record "trust-root reconfiguration via compromised admin key" as a T10.002 sub-shape that bridges into T11.001.
  • Config-setter privilege tiering is the load-bearing mitigation. The actionable rule is that cross-chain trust-root setters (OFT peers, mailbox/endpoint config, guardian sets) must carry upgrade-grade governance. Contributors should record whether a cross-chain token's peer-setter is single-key, multisig, or timelocked — it is the single most predictive risk field for this class.
  • Notional-vs-realised and containment latency are first-class fields. Stake DAO is a clean case where notional ($763B), realised ($91K), and "loss prevented by closing the bridge" (the mainnet backing) are all distinct numbers. Record all three; the gap between them is where the defensive lessons live.
  • A DAO with separable cross-chain backing can contain an unbacked mint. The architecture (satellite mint vs canonical backing behind a closable bridge) is what made containment possible. Record cross-chain-token architectures by their containability under a satellite-side compromise.

Public references

Discussion

Stake DAO extends the corpus's cross-chain coverage into a vector that the 2026 OFT/omnichain-token boom makes increasingly important: the trust-root reconfiguration attack. Where Verus, Butter, and Alephium all defeated or bypassed message verification, Stake DAO left message verification intact and instead used a compromised key to change what the verifier trusts — the OFT peer. It therefore links the key-compromise family (T11.001, alongside Step Finance / IoTeX / Gravity) with the bridge family (T10.002 / T10.006), and is best read as a key-compromise incident whose blast radius was amplified by a cross-chain configuration surface that lacked upgrade-grade governance.

The case is also a clean illustration of the corpus's notional-vs-realised discipline and of architectural containment. The ~5.4T mint was a ~$763B nominal event that realised ~$91K because vsdCRV was illiquid, and the canonical backing survived because it lived on a different chain behind a bridge the team could close. The defensive lesson is twofold: govern cross-chain trust-root setters like upgrades (timelock + multisig + monitoring), and design cross-chain tokens so that a satellite-side compromise can be contained by severing the satellite from the backing before the attacker bridges out — which only works if detection is fast.

Techniques demonstrated (5)