Avalanche Safe $7.45M Exploit: Empty-Address Approval

TL;DR

On October 26, 2026 at 12:56:14 UTC, a 2-of-7 Safe multisig on Avalanche C-Chain lost about $7.45M of trading inventory (3.09M USDC, 350.4K WAVAX, 182 WETH.e and 10.79 BTC.b) in one block, as first reported by Defimon. Nothing in the public record points to a stolen key or a phished signer, and the attack needed no Safe signature. On March 7 the Safe had signed unlimited approvals to 0x3725bd4d...155d, the address of the team's pool contract on Ethereum, Base and Arbitrum. On Avalanche that address held no code. It is the 13th contract that a CreateCall helper produces, so anyone who installed CreateCall on Avalanche and burned 12 deployments could put their own sweeper there. An attacker did that. An MEV bot copied the transaction, landed first in the same block, and the next day returned everything except about 42,541 WAVAX: an agreed 42,500 WAVAX bounty (about $371K) plus 41 WAVAX it never forwarded. The approvals had pointed at an empty address for 233 days.

What Happened to the Avalanche Safe?

The victim was a Safe at 0x631fca4a...b9b8 holding trading inventory for an operator that runs Safes on several chains. BlockintAI's reconstruction puts it at seven owners with a threshold of two. The operator has not been publicly named and has not published a postmortem as of October 28.

The setup is seven months old. At 16:10:25 UTC on March 7, 2026 the Safe executed one batch transaction that emitted four Approval events, each for the maximum uint256, on WAVAX, USDC, WETH.e and BTC.b. The spender in all four was 0x3725bd4d175283108156c3f15f86e1c51266155d.

On Ethereum, Base and Arbitrum that address is the operator's pool contract. We checked each chain with eth_getCode and found bytecode at the address on all three. On Avalanche it returned nothing. The approvals were never revoked.

On October 26, the address got code.

How Did an Empty Address Become a Weapon?

The CREATE opcode derives a new contract's address from two things only: the deployer's address and the deployer's nonce, as keccak256(rlp([deployer, nonce])). PandaSecurity's write-up lays out the formula. Nothing about the bytecode or the chain enters the hash. If the same deployer exists on two chains and reaches the same nonce, it produces the same address on both, whatever code it is told to put there.

The pool's deployer on the other chains was a CreateCall contract at 0xb22d635d552ec95142e2abe3ffb859ea7d7c0316. CreateCall is Safe's helper for deploying arbitrary bytecode, and it deploys whatever it is handed. It had been installed through the Safe singleton factory, a CREATE2 deployer that "will deploy the same code to the same address no matter when or where" it is used. That property is the point of the factory. It also means anyone can install the same CreateCall at the same address on any chain where it does not yet exist.

On Avalanche, it did not yet exist. We re-derived the arithmetic ourselves: nonce 13 of 0xb22d...0316 is 0x3725bd4d...155d. CreateCall's first deployment uses nonce 1, so the 13th contract it ever creates on any chain lands at the address the Safe had approved.

So the approved spender was open to anyone willing to pay gas for thirteen deployments.

Nobody has published how the attacker found it, and the operator has not said why the March batch ran on Avalanche at all. Our reading is that the shape fits a batch built for the chains where the pool exists and then executed on one where it does not. Finding the target needs no inside knowledge: Approval events are public, and a script that lists approved spenders with no code on a chain, then checks them against known CREATE deployers, would surface this one.

CryptoTimes frames it as a misconfiguration, and that is fair. Every contract involved behaved as written, and the defect sat in a signed transaction.

The Attack, Step by Step

#	Time (UTC)	Actor	Action	Evidence
1	Mar 7, 16:10:25	Victim Safe	Batch transaction approves unlimited WAVAX, USDC, WETH.e and BTC.b to `0x3725...155d`, which has no code on Avalanche	Approvals tx `0x6952f80b...42d3829e`
2	Mar 7 to Oct 26	Nobody	Approvals sit unrevoked for 233 days; CreateCall is never installed on Avalanche	BlockintAI
3	Oct 26, 12:29:39	Attacker	Fresh EOA `0x4c48...fa0a` receives 6.77 AVAX from an address BlockintAI labels "Relay: Solver"	BlockintAI
4	Oct 26, 12:56:14	Attacker	Sends one Multicall3 `aggregate3` call: install CreateCall via the singleton factory, run 12 throwaway deployments, deploy a sweeper as the 13th, call `transferFrom` on all four tokens	Attack tx, position 2
5	Same block	MEV bot `0x36b1...21b3`	Copies the payload, pays 1,815 gwei, lands at position 0; the sweeper at `0x3725...155d` is now the bot's	Bot tx `0xf88a7960...3c007ed5`
6	Same block	Attacker	Original transaction reverts with `Multicall3: call failed` because the address is already taken	Attack tx `0xf1f87d37...4a331289`
7	Oct 26, 13:00:23	Defimon	Alert fires, 4 minutes 9 seconds after the block	Defimon
8	Oct 26, 13:48 onward	Operator	Signers on HyperEVM, Base, Robinhood Chain, BSC and Ethereum evacuate those Safes to one fresh address, which Defimon puts at about $38.7M	Defimon
9	Oct 27, 07:22 to 09:46	Bot and owners	Test transfer, on-chain bounty agreement, then return of the funds minus 42,500 WAVAX	Bounty message tx, return txs

The bot's transaction shows the full haul: 3,090,123.580226 USDC, 350,375.855 WAVAX, 181.976 WETH.e and 10.786059 BTC.b, moved from the Safe to the bot's EOA. It also shows the sweeper's construction in its creation list: CreateCall, then twelve throwaway contracts, then 0x3725bd4d...155d. It cost the bot 1.70767905 AVAX in gas, about $15 at Snowscan's price.

How Did Three Bidders End Up in One Block?

The race was decided entirely by gas price.

rendering diagram…

The attacker's transaction went out at 2.5 gwei from a wallet funded 27 minutes earlier. A same-block copy means it was visible before inclusion, most likely in the public mempool, though no source has confirmed the route. A generic front-running bot only needs to simulate a pending transaction, see that it pays out, and replay it with its own address substituted. The payload here was fully self-contained: install a public contract, burn twelve nonces, deploy, sweep.

Snowscan shows a third transaction in the same block that nobody has written up. It came from 0x2061b663...27d4, called aggregate3 on the same Multicall3 at 12.1 gwei, sat at position 1, and failed. Its calldata is the same length as the attacker's but not identical. Our reading is a second copier that substituted its own address and underbid. That is an inference from the block, not a published finding.

The economics were lopsided. The winning bot spent about $15 in gas and walked away with a bounty Defimon values at $371K. The attacker's whole budget was the 6.77 AVAX that funded the wallet, about $60 at Snowscan's AVAX price, against a $7.45M target. The attacker spent a few cents in failed gas and lost everything to a bid 726 times larger than their own. If the transaction was broadcast publicly, as the copy suggests, any searcher simulating pending transactions could take the payout.

How Did the Funds Come Back?

Nineteen minutes after the block, at 13:15:17 UTC, the bot sent an on-chain message to the Safe itself. By our decoding of the transaction input, it read: "it appears that we intercepted an attack targeting your wallet. We will return your funds, but we need some time to figure out what happened." That call reverted as a Safe transaction, but the message is on-chain. The bot then moved the assets to a holding wallet, 0x11eb9b67...9bc5, between 14:05 and 14:22 UTC.

The negotiation that followed was careful on both sides. By our decoding of the messages exchanged on-chain, an owner address replied with a fresh receiving wallet, 0x35c6aa24...807c. The bot asked for a second confirmation from the address it called the wallet deployer, 0xffCc4933...9a57, which had executed earlier Safe transactions, rather than trusting the first address that wrote to it. It then asked for a 5% to 10% bounty, which Defimon reports, and offered to deduct it in place.

At 09:30:43 UTC on October 27 the owners confirmed on-chain: "we confirm your test and that we are happy for you to keep 42,500 WAVAX as a bounty." Within sixteen minutes the holding wallet sent back all of the USDC, WETH.e and BTC.b, plus 307,834.855 WAVAX, the last leg landing at 09:46:42 UTC. BlockintAI puts the returned value at about $7.08M.

The bounty arithmetic is slightly off. The bot took 350,375.855 WAVAX and returned 307,834.855, so it kept 42,541, not 42,500. The extra 41 never reached the holding wallet; BlockintAI reports the bot kept it at its own address.

Address poisoners also showed up. BlockintAI found fake "USDC" and "BTC.b" tokens emitting transfers from the holding wallet to 0x35c660...807c, a lookalike of the real return wallet. By the holding wallet's token-transfer log, the fake USDC amount, 0.580326, mirrors the real test transfer sent fourteen minutes earlier. Anyone copying the "last address that received funds" from an explorer would have picked the wrong one.

How Much Was Actually at Risk?

Defimon's $7.45M is the headline we use. Snowscan's day-of-transfer prices put the four legs at about $3.09M USDC, $3.13M WAVAX, $0.43M WETH.e and $0.87M BTC.b, which sums to roughly $7.52M.

The net loss to the operator is the bounty, about $371K at Defimon's price, plus the 41 WAVAX the bot kept on top of it. The gross exposure was the full balance, and it was decided by a bot's choice to return it.

Has This Happened Before?

A team handing out an address it only controlled on a different chain has happened before, and the best-known case is Wintermute's.

In 2022 Wintermute gave Optimism an address for 20M OP that was its Gnosis Safe on Ethereum but did not exist on Optimism. Rekt's account explains that the mainnet Safe was created by an older ProxyFactory using CREATE, so the address depended only on the factory and its nonce. The exploiter deployed Safes on Optimism in batches, as owner, until the nonce matched, and took the tokens. The Block reported that the attacker sold 1M OP and the Optimism Foundation issued a second 20M OP grant.

The Avalanche case uses the same primitive in reverse, with allowances granted to the unclaimed address instead of funds sent to it. In both, the team's mental model was "this is our address," and on Avalanche that assumption failed.

A code audit certifies the contracts you hand it. No review of the pool's Solidity would have looked at a Safe batch signed on a chain where the pool was never deployed. The failure lived in operations: a batch replayed onto a new chain, approvals that outlived their purpose, and a deployment that never happened.

Our posts on rsETH and SquidRouterModule covered Safes drained through permissions granted to modules. The failure type differs, but the exposure is related: a standing permission that nobody re-checked after it was granted.

What Would Have Caught It?

Nothing could have stopped the sweep once it was broadcast. It was one transaction, and neither the Safe nor the four tokens had a pause the operator could use. The stoppable moment was March 7, when the approvals were signed.

The condition that made it possible was observable for 233 days. Two facts were checkable from public chain state at any block between March 7 and October 26, and a third sized the exposure:

The Safe held unlimited allowances on four tokens to a spender whose code size on Avalanche was zero.
The deployer that produces that address, CreateCall, had no code on Avalanche either, so the address was claimable by anyone.
By the attack block, the balances behind those allowances were about $7.45M. We have not reconstructed the earlier balance history.

A check of the form "every spender this Safe approves has code on this chain" fails at 16:10:25 UTC on March 7, the moment the batch lands. A Safe transaction guard written to decode MultiSend batches into their inner calls could run that check and refuse the batch; a team would have to build or adopt that control. A second check, "code appears at an address this Safe has approved," fires in the attack block itself, too late for this Safe. Whether the operator's Safes on other chains carry approvals to addresses with no code there is not public. Their signers started moving funds out 52 minutes after the block.

An audit scoped to the pool contract would never have looked at any of this, because the gap sat in how the Safe was operated across chains. A penetration test simulates real-world attack campaigns against the whole Web3 setup, operational security included. Scoped to your Safes, that campaign is the one this attacker needed: pull every Approval event on every chain you run, flag spenders with no code, and check whether anyone can install their deployer. The approval to 0x3725bd4d...155d fails both checks on the day it was signed.

What Should Operators Do Now?

Check spender code on the target chain before signing any approval. extcodesize(spender) > 0 and a code-hash match against the contract you expect. A Safe transaction guard can enforce this for every approve the Safe signs.
Deploy first, approve second.
Do not build cross-chain address identity on CREATE from a public deployer. CREATE binds the address to a counter. CREATE2 binds it to the bytecode, so a squatter can only deploy your code there. If you use a public factory, bind the salt to your own deployer.
Replace unlimited allowances with exact, expiring ones. Give each one an owner and a revocation date.
Inventory allowances per Safe, per chain. For every Safe on every chain, list spenders, their code hashes and the balances behind them. Alert on zero-code spenders and on code appearing at an approved address.
Treat a batch replayed onto a new chain as a new transaction. Simulate it on the target chain and diff the result before the second signature.
When a bot offers to return funds, verify the channel. Copy addresses from the signed message, never from an explorer's recent-transfers list, because poisoners will be spoofing them within minutes.

Frequently Asked Questions

Was a Safe signer key compromised in the Avalanche incident?

No, as far as the public record shows. Neither Defimon nor BlockintAI reports a stolen key or a phished signer, and the attacker needed no Safe signature at all. The Safe had already signed unlimited approvals on March 7 to an address with no code on Avalanche, and the attacker deployed a sweeper at that address and called transferFrom.

Did the operator get the $7.45M back?

Yes, most of it. The MEV bot that front-ran the attacker returned all of the USDC, WETH.e and BTC.b plus 307,834.855 WAVAX on October 27. It kept a 42,500 WAVAX bounty that the owners agreed to on-chain, about $371K at Defimon's price, plus roughly 41 WAVAX it never forwarded.

Would an audit have caught this?

No, not a code audit of the pool contract. The pool was never deployed on Avalanche and its code played no part. The defect was a signed multisig transaction on the wrong chain, which is an operational control: pre-signing spender checks, a transaction guard, and a recurring check for spenders with no code and for code appearing at an approved address.

Can someone else claim the approved address now?

No. A contract now sits at 0x3725bd4d...155d, deployed by the MEV bot's transaction, and an address with code cannot be deployed to again. BlockintAI reports that its code reverts on every call, so as long as that holds nobody can use the allowances through it, the bot included. The Safe's unlimited approvals to it were still live as of October 27 and should be revoked anyway.

Avalanche Safe $7.45M: The Approval That Waited 233 Days for Code to Appear