{"id":602753,"date":"2026-05-27T10:42:45","date_gmt":"2026-05-27T14:42:45","guid":{"rendered":"https:\/\/ambcrypto.com\/?p=602753"},"modified":"2026-05-27T10:42:45","modified_gmt":"2026-05-27T14:42:45","slug":"compromised-stakedao-deployer-key-allegedly-enabled-forged-layerzero-mint-on-arbitrum","status":"publish","type":"post","link":"https:\/\/ambcrypto.com\/compromised-stakedao-deployer-key-allegedly-enabled-forged-layerzero-mint-on-arbitrum\/","title":{"rendered":"Compromised StakeDAO deployer key allegedly enabled forged LayerZero mint on Arbitrum"},"content":{"rendered":"

Blockchain security firm Blockaid said it detected an exploit targeting StakeDAO on Arbitrum. An attacker allegedly compromised the protocol’s deployer private key and minted more than <\/span>5.4 trillion vsdCRV<\/b> tokens through manipulated cross-chain messaging.<\/span><\/p>\n

According to Blockaid, the attacker reconfigured the trusted LayerZero peer tied to <\/span>StakeDAO’s vsdCRV OFT contract<\/b>. They then sent a forged cross-chain mint message that created <\/span>5,446,744,073,709 vsdCRV tokens on Arbitrum<\/b>.<\/span><\/p>\n

The security firm said the exploit stemmed from a compromised deployer wallet rather than a flaw in the token contract itself.<\/span><\/p>\n

Unauthorized peer change preceded massive mint<\/b><\/h2>\n

Blockaid said the attacker used the compromised deployer key to modify the setPeer() configuration on the LayerZero v2 OFT contract.<\/span><\/p>\n

The change allegedly redirected trust away from the legitimate Ethereum-side adapter toward an attacker-controlled contract.<\/span><\/p>\n

After the peer relationship changed, the attacker reportedly sent a forged cross-chain message that minted trillions of vsdCRV tokens from a null address.<\/span><\/p>\n

Independent on-chain investigators later reconstructed the exploit timeline. They traced the attacker’s preparation wallets, bridge activity, and token dumping transactions across Arbitrum and Ethereum.<\/span><\/p>\n

According to the investigation thread, the attacker first funded wallets through Tornado Cash before using Relay and Stargate to move assets between chains.<\/span><\/p>\n

Attacker rapidly dumped minted tokens<\/b><\/h2>\n

Investigators said the attacker swapped the newly minted tokens for ETH across multiple decentralized exchanges, including Curve, KyberSwap, MetaMask Router, and Enso.<\/span><\/p>\n

Despite the massive token mint, the actual extracted value appeared relatively limited.<\/span><\/p>\n

The investigation estimated the attacker ultimately removed roughly <\/span>43.9 ETH<\/b>, worth about <\/span>$91,000<\/b> at the time of the exploit.<\/span><\/p>\n

The funds were later bridged from Arbitrum back to Ethereum, where the ETH reportedly remained untouched at the time of writing.<\/span><\/p>\n

Exploit renews concerns around admin-key security<\/b><\/h2>\n

The exploit has renewed scrutiny around operational security risks across cross-chain DeFi infrastructure.<\/span><\/p>\n

Rather than exploiting token math or contract logic directly, the attacker allegedly manipulated privileged trust configuration tied to LayerZero peer verification.<\/span><\/p>\n

The incident highlights how many cross-chain systems remain heavily dependent on admin-key security and trusted infrastructure relationships.<\/span><\/p>\n

Compromising those permissions can effectively grant attackers mint authority even when underlying smart contracts function as intended.<\/span><\/p>\n

Industry figures warn DeFi security risks are expanding<\/b><\/h2>\n

The exploit also fueled broader debate around the state of DeFi security.<\/span><\/p>\n

Manuel Ar\u00e1oz, founder of OpenZeppelin, said on X that he now considers “all of DeFi unsafe,” arguing AI-powered coding agents are becoming increasingly effective at identifying vulnerabilities across operational infrastructure, protocol design, and security configuration.<\/span><\/p>\n

Marc Zeller pushed back on the claim, arguing that most recent DeFi failures stem from poor operational security and risk management rather than flaws in smart contract codebases themselves.<\/span><\/p>\n

The discussion followed several recent exploits involving:<\/span><\/p>\n