Loading market data...

Stake DAO Loses Millions as Attacker Exploits Deployer Key on Arbitrum

Stake DAO Loses Millions as Attacker Exploits Deployer Key on Arbitrum

An attacker compromised a privileged deployer key on Stake DAO’s Arbitrum deployment on May 27, minting roughly 5.4 trillion fake Vote-Boosted sdCRV (vsdCRV) tokens and swapping them for ether via MetaMask’s public router. The exploit did not touch any smart-contract code; instead it abused a key with special permissions.

How the attack worked

Blockaid, a security platform, detected the breach and issued an on-chain alert. Investigators found the attacker used the compromised key to reset the LayerZero v2 bridge peer for vsdCRV. That allowed them to forge a cross-chain message and mint the massive supply of fake tokens. The minted tokens were then swapped for ETH through MetaMask’s public router, draining value from the protocol.

Stake DAO’s team has not yet published a full post-mortem. The exploit shows a vulnerability in DeFi that’s separate from code bugs: operational key security.

Pattern of key compromises

Stake DAO’s incident is not isolated. Similar key-related exploits hit Wasabi Protocol ($4.5 million), Drift Protocol ($285 million), KelpDAO ($292 million), and Resolv ($80 million). All those projects had passed third-party audits, but audits don’t cover the safety of deployer keys or privileged-access management.

In particular, a recent LayerZero exploit on KelpDAO worked through the same kind of peer-configuration abuse that appeared in the Stake DAO attack. The attacker reset the bridge peer settings after gaining access to a key, then sent a forged message across chains.

Audits aren’t enough

Shalev Keren, co-founder of security firm Sodot, pointed to the broader lesson. “DeFi must focus on operational key security rather than just audits,” Keren said. His comment echoes a growing concern among developers: even flawless smart contracts can be undone by a single leaked private key.

The exploit raises questions about how Stake DAO managed its deployer key and whether multi-signature safeguards or key rotation could have stopped the attack. For now, the protocol has not announced a recovery plan or any changes to its key-management procedures.