Burn Notice #3
Gnosis Pay's Delay-Module Signature, StakeDAO's setPeer Mint, and a Bridge Down to Its Signing Key
Three of this week’s losses share a shape worth sitting with. The smart contracts behaved exactly as written and the money still left, because the authorisation wrapped around those contracts is where the real control lived. A signature checker in a Safe module, a deployer key that still held cross-chain config rights, and a bridge signing key carried this week’s drains between them.
In today’s issue.
Gnosis Pay’s Zodiac Delay module accepted a queued transfer with no real signature behind it.
A stolen StakeDAO deployer key repointed a LayerZero peer and forged a 5.4 trillion token mint.
Gravity Bridge lost millions through its signing layer rather than its contract code.
Need to Know
The week’s headline failures did not touch a single line of vulnerable contract logic. They landed one layer up, in the modules, keys, and peer configurations that decide who is allowed to move funds. That layer rarely gets the review attention the core contracts do, even though it now carries most of the loss. If your last audit stopped at the contract boundary, what reviewed the authorisation wrapped around it? —Adrian
The Big One. Gnosis Pay’s Delay Module Approved a Signature It Should Have Rejected
The news. On 1 June an attacker drained funds from Gnosis Pay accounts without ever touching a private key. Each Gnosis Pay account is a Safe smart account wrapped in two Zodiac modules, a Roles module that authorises card spending and a Delay module that holds outgoing transfers for a roughly three minute cooldown. The break sat in how that Delay module checked the signature authorising a queued transfer.
What broke and how. The Delay module’s signature checker reads the signing bytes from the tail end of the calldata, after the normal module-call arguments. You can append arbitrary trailing bytes to ABI calldata for free, so a normal call ignores them while the module reads them as a signature. An attacker crafted those bytes as an EIP-1271 contract signature, set the vouching address to the Safe’s trusted signer, and pointed at a blob they controlled. The contract-signature path then handed validation to that signer and accepted a response carrying the magic value 0x1626ba7e while ignoring the staticcall success flag, so a contract that reverts but returns the right four bytes passed as a valid signer. The malicious transfer enqueued, the cooldown ran, and because executeNextTx can be called by anyone the Safe paid out. Zodiac’s own notice scoped the flaw to Roles Modifier v2 and Delay Modifier v1.1.0 where a Safe with a vulnerable fallback handler sits as a member, and confirmed Safe’s core contracts are unaffected.
Why it kept happening. This is the second Safe-module drain in eight days. Last week roughly $3.2M left 86 Safe wallets across Ethereum and Base through a third-party module called SquidRouterModule, where weak identity validation let an attacker run arbitrary calldata with no wallet signature, flagged by Blockaid and unrelated to Gnosis Pay’s code. Modules are how Safe gets extended, and they run with the Safe’s full authority while rarely getting the review the assets they guard receive. A team adds a module to ship a feature like card payments or routing, and that module becomes a second front door with full spending power behind it.
What to check now.
Inventory every module enabled on every Safe that holds value, including ones added for one feature and never removed.
For any module that verifies signatures, confirm the EIP-1271 path checks the staticcall success flag, not only the returned selector.
Confirm signature material is read from a fixed, declared location and never from trailing calldata an attacker can append.
Treat
executeNextTx-style “anyone can finalise” functions as fully public, and make sure the only real gate is the enqueue authorisation.Review third-party modules with the same rigour as your core contracts, because they inherit the same authority.
A Safe with five modules has five contracts that can move its money, and most reviews still budget time for one. The module list is the first thing worth pulling on any account that matters, ahead of the balances and ahead of the signers.
— Adrian
Chain Reaction. StakeDAO’s Deployer Key Repointed a Bridge and Minted 5.4 Trillion Tokens
The news. On 27 May someone holding StakeDAO’s deployer key on Arbitrum used it to call setPeer on the project’s LayerZero v2 OFT contract, repointing the token’s trusted cross-chain peer to a contract they controlled on Ethereum. About 25 seconds later that contract sent a forged LayerZero message back to Arbitrum and the legitimate vsdCRV token minted 5,446,744,073,709 units to the attacker. Nothing in the contract was bugged, and the token minted what an authorised peer instructed it to.
What broke and how. The OFT standard trusts a configured peer on each chain to authorise cross-chain mints, and setPeeris an owner-level function. Whoever holds that key can name a new trusted source and then have it order mints with no ceiling. Blockaid and BlockSec’s Phalcon team both traced the incident to a compromised deployer private key rather than a logic flaw. The only thing that bounded the loss was liquidity. vsdCRV pools were tens of thousands of dollars deep, so the attacker converted part of the supply to about 43.78 ETH, roughly $91,000, before the price collapsed, against a paper value of hundreds of billions. StakeDAO closed the vsdCRV bridge, secured the Ethereum side, and said no mainnet funds were lost.
Why it kept happening. This is the same shape as a run of 2026 incidents where a single key with peer-config or admin rights on an OFT or bridge quietly equals total mint authority. The realised loss looked small only because the token was illiquid, and the same key on a liquid token is an open mint with no brake. A deployer key that retains setPeer after launch is a production signing key, and it almost never gets handled like one.
What to check now.
List every address that can call
setPeer,setTrustedRemote, or equivalent peer-config functions on your OFT and bridge contracts.Move those rights behind a multisig with a timelock, or renounce them once configuration is stable.
Hold any deployer key that retains post-launch authority in an HSM or KMS, never a hot wallet.
Alert on peer and trusted-remote changes the moment they land on chain, not after the mint clears.
For low-liquidity tokens, remember the mint ceiling is set by the market and not by your contract.
The thing you keep noticing in this space is that a loss only looks contained because the market was too thin to cash out, which is luck wearing the costume of a control.
— Adrian
Around the Forums
Radiant Capital’s DAO has voted to begin a gradual wind-down after failing to recover from its October 2024 exploit, secure new financing, or rebuild usage. The roughly $50M loss put the protocol into a tail it could not climb out of, and the council is now choosing an orderly close over a slow bleed. The precedent worth noting is that an exploit’s real cost gets paid in the quarters of lost trust that follow, not the dollars that left on the day.
THORChain’s third incident update left the root cause of its recent vault exploit openly contested, with the team saying the future of the cryptographic systems securing the vaults is still under discussion. Watching a protocol debate its signing scheme in public is rare and the candour is useful. The open question for any threshold-signature operator reading along is whether they would even know which of their validators to distrust. Formal council votes were otherwise light this week.
What Else Happened
Bridge signing-key compromise at Gravity Bridge. The Ethereum-to-Cosmos bridge lost about $5.4M on 30 May through its authorisation layer rather than a contract bug and halted its validators to investigate, a design that leans on a full validator set instead of a small multisig and still failed at the signing layer. Candidate for a dedicated treatment next issue.
Unprotected admin key on DxSale. The 2021 BNB Chain liquidity locker was drained of roughly $7.3M across about 1,400 LP positions through an admin key a security firm had flagged as risky back in 2023.
Mint-and-dump via a compromised key at Tessera DAO. An attacker minted 99 million TSR on BNB Chainroughly 19 hours before the public alert, swapped it for about $2.5M, collapsed the token by 99 percent, and routed the proceeds through a mixer, the same compromised-key-then-mint shape as the StakeDAO drain above.
Laundering closes the door on KelpDAO recovery. The attacker behind April’s roughly $293M KelpDAO exploit has now moved nearly all of the stolen funds, leaving little realistic path to recovery.
Open-source supply chain stayed under pressure. A compromised maintainer account pushed malicious code into AntV npm packages including a charting library with over a million weekly downloads, while CrowdStrike, Google, and the Shadowserver Foundation dismantled the Glassworm botnet that had poisoned more than 300 GitHub repositories aimed at open-source developers. Any crypto front-end or tooling team pulls from these registries.
On the Clock
Two items carry real urgency this week. If you run any Safe with a Zodiac Roles or Delay module enabled, check it against Zodiac’s security notice and complete the remediation before assuming you are clear, since most identifiable accounts are already resolved and the stragglers are now the targets. And any build that pulls the affected AntV packages should pin and audit those dependencies now rather than after the next install.
Long Reads
THORChain’s own exploit report alongside TRM Labs on the multi-chain drain lays out what is known and what is still contested, including the live question of whether the threshold-signature stack itself was the weak point.
rekt.news on the DxSale drain is worth it for the detail that the fatal admin key was flagged for a $500 fee years before it cost millions.
BlockSec’s weekly Web3 security roundup breaks down the DxSale and SquidRouter incidents with root-cause notes, and its companion May monthly brief frames where the month’s losses actually landed.
Elliptic on crypto governance argues for a governance model the author thinks already works, useful framing for any DAO operator rethinking council design after a week like this.
The Operator’s Read
The Audit Stops Where the Money Starts
The thing you keep noticing, watching how these systems get built and broken, is how much review effort still stops at the contract boundary. The Solidity gets read line by line. The module added later to ship a feature, the key that was meant to be temporary, the peer configuration that points trust at another chain, those get a glance and a shrug. They get treated as plumbing, when in practice they are the locks on the doors.
From where I sit the uncomfortable pattern of 2026 is that the contract layer has quietly got good. Audits are sharper, the obvious reentrancy and overflow classes mostly get caught, and the money has responded by moving up a level. Modules, deployer keys, bridge signers, peer configs. The authorisation surface. It is less glamorous to review and it carries almost none of the formal scrutiny, which is exactly why the value sits there now.
There is a tell in how thin the StakeDAO loss looked. Five point four trillion tokens minted, ninety one thousand dollars out, and a lot of relieved commentary about a contained incident. What contained that loss was thin liquidity and nothing the protocol actually controlled. The same key on a liquid token mints a nine figure hole. Calling it a near miss reads the lesson backwards.
So the question worth carrying into your own stack is the one the audit never asked. Has anyone reviewed the full list of things that can move your funds without ever touching the contracts you paid to have checked? How long is that list, who holds each entry, and when did you last make it shorter?
— Adrian
Adrian Hetman Burn Notice Operational intelligence for Web3, every week.