vsdCRV Incident Disclosure - 27-05-2026
Summary
On May 27, 2026, a deployer account holding the owner role on the vsdCRV LayerZero OFT contract on Arbitrum was compromised and used to forge an unbacked cross-chain mint of vsdCRV. By swapping the forged vsdCRV through the Curve pool, the attacker drained roughly 321,143 CRV and ~7.5 ETH of real assets and converted the CRV to ETH, realizing approximately 43.8 ETH (~$91,000). The backing of legitimate vsdCRV (approximately 1.33M staked sdCRV on Ethereum mainnet) was secured to the governance Safe within 47 minutes of the forged mint and was exposed to limited loss as a result of the incident. This was not a smart contract vulnerability: the contracts behaved as designed once the attacker held the owner key. The minting path was closed the same day, and all on-chain authority previously held by the compromised account has been reclaimed to the governance multisig. The Association intends to put forward a compensation plan for eligible affected users. Participation will be voluntary and subject to eligibility criteria, verification, and applicable legal and compliance requirements; details will be communicated separately.
Details
On May 27, 2026 at 09:17 UTC, the compromised deployer account sent a setPeer transaction on the vsdCRV OFT on Arbitrum, repointing the contract's trusted cross-chain peer to a malicious contract. Twenty-five seconds later, the malicious peer delivered a forged LayerZero message, which the OFT accepted as authentic and minted 5,446,744,073,709.55 vsdCRV to the attacker. The attacker swapped the forged supply through the Curve pool on Arbitrum for approximately 321,143 CRV and ~7.5 ETH, converted the CRV into ETH, bridged the resulting 43.776 ETH to Ethereum mainnet via Stargate, and subsequently deposited the funds into Tornado Cash.
Background
- vsdCRV is backed 1:1 by CRV or sdCRV deposited into the Curve boosted-vote strategy on top of the sdCRV liquid locker. Legitimate vsdCRV is minted only against deposits.
- On Arbitrum, vsdCRV exists as a LayerZero OFT: a cross-chain representation that mints tokens when it receives a valid message from a contract (a "peer") it trusts on another chain.
- The owner of the OFT can change which peer the contract trusts. This is the authority the attacker used: by repointing the trusted peer to a contract the attacker controlled, they could deliver a message the OFT accepted as a legitimate cross-chain transfer, minting vsdCRV with no backing behind it.
Root Cause Analysis
The root cause is an incomplete ownership handover, not a flaw in the contracts.
Stake DAO's deployment process treats deployer keys as transient: contracts are deployed from an EOA, and privileged roles are then transferred to the governance multisig. For the vsdCRV OFT on Arbitrum, that handover was never completed. The deployer EOA remained the owner of the contract from its deployment on March 1, 2024 until the incident, roughly 27 months, with no multisig and no timelock protecting owner actions, including setPeer.
Over two years of deployments, the same deployer account had also accumulated residual roles on other contracts across several chains, the large majority of them deprecated or unused. Nothing in the deployment process enforced the handover or retired this residue.
The compromise of the deployer key itself is the trigger of the incident, and the investigation into how the key was compromised is ongoing. We will not speculate on the vector here. The architectural point stands regardless: a transient deployment key should hold no live authority, and a single EOA should never have been sufficient to alter the mint path of a cross-chain token.
Attack Flow
Step 1: Repoint the Trusted Peer
At 09:17:33 UTC the attacker sent setPeer from the compromised deployer account, replacing the vsdCRV OFT's legitimate peer with a malicious contract.
Step 2: Forge the Mint
At 09:17:58 UTC, 25 seconds later, the malicious peer delivered a fake LayerZero message through the endpoint. The OFT accepted it as a genuine cross-chain transfer and minted 5,446,744,073,709.55 vsdCRV to the attacker.
Step 3: Swap and Bridge Out
The attacker swapped part of the forged vsdCRV into approximately 321,143 CRV through aggregator routers on Arbitrum and then swapped that CRV into ETH. Separately, the attacker burned roughly 3,200,000 forged vsdCRV through the LayerZero OFT in three transactions (1.0M, 0.9M, and 1.3M) to bridge it to Ethereum mainnet. Only the 1.3M message was delivered on mainnet; the other two never completed delivery. Either way, this bridged supply is unbacked and yielded no realized value.
Step 4: Bridge ETH to Mainnet
At 10:05:23 UTC, the attacker bridged the consolidated swap proceeds of 43.776 ETH from Arbitrum to Ethereum mainnet via Stargate.
Step 5: Move Proceeds Through a Mixer (Tornado Cash)
On May 31, between 20:04 and 20:17 UTC, the attacker deposited 43.9 ETH into Tornado Cash in 16 deposits (4 × 10 ETH, 3 × 1 ETH, 9 × 0.1 ETH).
Timeline of Events (UTC)
All timestamps are derived from on-chain transaction data.
Attack: May 27, 2026
| Time (UTC) | Chain | Event | Transaction |
|---|---|---|---|
| 09:17:33 | Arbitrum | setPeer from the deployer account repoints the OFT to a malicious peer | 0xf97ddff0... |
| 09:17:58 | Arbitrum | Forged LayerZero message delivered; OFT mints 5.45T vsdCRV to the attacker | 0x7489ec5f... |
| ~09:18–09:40 | Arbitrum | Forged vsdCRV swapped through Curve into ~321,143 CRV and ~7.5 ETH (6 txs), then CRV swapped to ETH (4 txs); ≥3.2M vsdCRV bridged out via the OFT (3 burns) | see appendix below |
| 09:45:35 | Ethereum | 1.3M vsdCRV from the bridge-out arrives on mainnet | |
| 10:04:59 | Ethereum | Response: vsdCRV backing (~1,329,056 staked sdCRV) secured to the governance Safe | 0xa553a532... |
| 10:05:23 | Ethereum | Attacker bridges 43.776 ETH (swap proceeds) from Arbitrum to mainnet via Stargate | 0xff79bec3... |
Movement of Proceeds Through Tornado Cash: May 31, 2026
| Time (UTC) | Chain | Event |
|---|---|---|
| 20:04–20:17 | Ethereum | 43.9 ETH deposited into Tornado Cash in 16 deposits (4 × 10 ETH, 3 × 1 ETH, 9 × 0.1 ETH) |
Attacker Transactions (Appendix)
- Swaps of forged vsdCRV into CRV (Arbitrum, 6 txs):
0xce66dac9...,0x2cd0ce1f...,0xfbf486c8...,0xb58637db...,0x915a89c9...,0x43d05c6c... - CRV swapped into ETH (Arbitrum, 4 txs, ~321,143 CRV total):
0x8ae11d46...,0x7d913c56...,0x25ad7f88...,0xfbc1606f... - Bridge-out burns via the OFT (Arbitrum, 3 txs):
0xe459d217...(1.0M),0x3473cef8...(0.9M),0x8b8a23ba...(1.3M) - Tornado Cash deposits (Ethereum, 16 txs): 4 × 10 ETH (
0x7a2c3323...,0x4f73d855...,0xbd69f412...,0x31719044...), 3 × 1 ETH (0x2da9bb90...,0x5c6f0a3a...,0x80c14a4f...), 9 × 0.1 ETH (0x65c7c530...,0x03200416...,0x06ff8e63...,0x5eeebaa2...,0xf7a61ebe...,0xdff4e765...,0x35ae05f1...,0xe71d8a9d...,0xf0ee1c77...)
Incident Response & Mitigation
The incident was surfaced by an external party who flagged the abnormal on-chain activity, not by an automated monitoring alert. The compromised OFT had not been onboarded to our on-chain monitoring, so the malicious setPeer and forged mint raised no alert of their own.
- The malicious peer was reset to the legitimate one, closing the minting path.
- The vsdCRV backing (~1,329,056 staked sdCRV) was secured to the vsdCRV governance Safe on Ethereum mainnet, 47 minutes after the forged mint.
- Ownership of the vsdCRV OFT was transferred to the governance multisig.
- The compromised account had, over time, held roles on roughly 120 contracts across 7 chains (the large majority deprecated or unused). Every one was reviewed: the few that still carried live roles had them transferred to the governance multisig, and all were screened to confirm the correct governance structure was in place.
- The asdCRV OFTs (an Aladdin-branded sdCRV token), which were exposed to the same attack class because the compromised account owned them, were proactively reclaimed to the governance multisig, closing that mint path before it could be exploited.
- The asdCRV LlamaLend market, whose oracle is derived from the asdCRV/vsdCRV/CRV pool on Arbitrum, was also a potential vector for further losses. Stake DAO promptly contacted the market's main users to ask them to repay their loans, and engaged the Curve Emergency DAO and LlamaRisk to take protective measures on the lending market. No loss occurred in the asdCRV lending market.
Current Status of Stolen Funds
What the attacker took was real value drained from the vsdCRV Curve pool: roughly 321,143 CRV and ~7.5 ETH, obtained by swapping in the forged vsdCRV. The CRV was then converted to ETH; the consolidated proceeds were bridged to Ethereum mainnet and deposited into Tornado Cash on May 31, 2026:
| Item | Amount |
|---|---|
| Bridged from Arbitrum via Stargate | 43.776 ETH |
| Deposited into Tornado Cash | 43.9 ETH (16 deposits) |
| Realized loss | ~43.8 ETH (~$91,000) |
The remaining forged vsdCRV supply on Arbitrum has no backing and no redemption value; the Arbitrum OFT is deprecated.
Separately, the backing itself took a limited loss: with the pool price depressed by the forged supply, a small amount of vsdCRV was redeemed against the backing before it was secured, totaling under 10,000 sdCRV (of roughly 1.33M).
Note: The amount deposited into Tornado Cash (43.9 ETH) modestly exceeds the ETH converted from bridged proceeds in this incident (43.776 ETH). The difference (~0.12 ETH) appears to derive from the attacker's pre-existing balance and is not attributable to the loss realized in this incident. The realized ETH loss attributable to this incident is approximately 43.8 ETH (USD ~91,000 as of 27 May 2026, per Etherscan).
The Association is conducting blockchain-tracing and sanctions analysis in respect of the addresses and flows described above and is monitoring the relevant addresses for further movement.
Law Enforcement and Regulatory Engagement
The Association treats this incident as the theft of digital assets by an unidentified third party. The Association has filed a criminal complaint with the competent Swiss prosecuting authorities and is preserving on-chain and off-chain evidence to support that process. With its advisers, the Association is assessing any reporting or notification obligations applicable to it (including in respect of the movement of proceeds and any data-protection considerations arising from the incident) and will make any notifications required under applicable law. The Association is prepared to cooperate with law enforcement and relevant authorities and to share information with affected counterparties and the ecosystem to support tracing and recovery. Certain details are withheld from this report to protect the integrity of the ongoing investigation.
Key Addresses
| Entity | Address |
|---|---|
| Compromised deployer account | 0x000755Fbe4A24d7478bfcFC1E561AfCE82d1ff62 |
| Attacker | 0xeF3C054d8F7eD0a7D61c8da56ff55F090577aa25 |
| vsdCRV OFT on Arbitrum (deprecated) | 0x62d5a59E0d67c0381aAd53B201B4A1B8Dcd2C833 |
| vsdCRV mainnet hub (not affected) | 0xE079ac07463ff375Ce48E8A9D76211C10696F3B8 |
| Governance multisig (3 of 5) | 0xB0552b6860CE5C0202976Db056b5e3Cc4f9CC765 |
| vsdCRV governance Safe (backing recovered here) | 0xf930EBBd05eF8b25B1797b9b2109DDC9B0d43063 |
| LayerZero endpoint (Arbitrum) | 0x31cae3b7fb82d847621859fb1585353c5720660d |
Remediation
- All privileged roles previously held by the compromised account now sit with the governance multisig (3 of 5). Based on the Association's review and the role transfers described above, the account no longer holds privileged on-chain authority over the Stake DAO contracts identified in this review.
- The deployment process is being amended so that the transfer of privileged roles to governance is an enforced step of every deployment, not a follow-up task.
- A periodic on-chain permission census will verify that no EOA holds privileged roles on any deployed contract, active or not.
- Every deployed contract, active or dormant, is being onboarded to our on-chain monitoring with alerting on privileged actions, so that no contract sits outside detection coverage and response does not rely on ad hoc external reports.
- The investigation into the compromise of the deployer key is ongoing.
Beyond This Incident
This is the second security incident affecting Stake DAO this year, after the Votemarket oracle incident of March 12, 2026. The two have different root causes: a sender-validation bug in peripheral oracle infrastructure then, an incomplete privileged-role handover in operational tooling now. Neither touched core protocol contracts or user deposits. But we do not read them as unrelated events. Both point to the same area for improvement: operational and key-management practices need to scale with the breadth of what has been deployed over time. We do not intend to let this become a pattern, and we are addressing the common layer, not just each incident in isolation.
- Compensation for eligible affected users. The Association intends that eligible affected users should not bear the realized loss from this incident and is preparing a compensation plan to that end. Any compensation will be subject to governance approval, voluntary, offered without admission of liability, and subject to eligibility criteria, identity and sanctions screening, and applicable law. Final terms, scope, and timing will be set out in a separate communication.
- Operational security review. We are conducting a full review across all Stake DAO products: key management and rotation, deployment and handover procedures, the inventory of privileged roles, and monitoring coverage. This goes beyond the contracts involved in this incident.
- Deprecation policy. Stake DAO has historically been slow to decommission products that are no longer in use or part of our plans. Dormant contracts that still carry live privileged roles widen the attack surface while providing no value to anyone; this incident's sweep of ~120 mostly inactive contracts is what that debt looks like. Products that are not in active use and not on our roadmap will be formally deprecated, with their privileged roles transferred to governance, renounced, or frozen.
Legal Notice
This disclosure is provided by the Stake DAO Association for transparency and informational purposes only. It reflects the Association's good-faith understanding of the incident based on information available as of the publication date and remains subject to revision as the investigation progresses. Nothing in this report constitutes an admission of liability, fault, or wrongdoing by the Association, its members, contributors, or service providers, and nothing herein waives any right, claim, or defense, all of which are expressly reserved. Statements regarding remediation, future processes, and compensation are forward-looking, reflect current intentions, and are not guarantees; actual outcomes may differ. This document is not legal, financial, tax, or investment advice. Descriptions of the conduct of any unidentified third party are preliminary characterizations of on-chain activity, not findings of fact or legal conclusions.