blockintAI · Research blog

An Avalanche Safe Approved an Empty Address. Seven Months Later, Someone Tried to Use It to Take $7.45M

BlockintAI · 2026-10-27T17:17:20.495Z

Most token-approval losses start with a bad contract. This one started with no contract at all.

On October 26, 2026, an attacker tried to empty a 2-of-7 Safe multisig on Avalanche holding about $7.45M in trading inventory, according to the security monitor Defimon. The attack did not break the Safe, steal a key or trick a signer. It used token approvals the Safe had signed seven months earlier, to an address that was empty on Avalanche. Anyone who could place code at that address could spend the Safe's tokens.

The attacker found a way to do that, and an MEV bot copied the transaction and ran it first, in the same block. The bot, which calls itself a whitehat, sent the funds back on October 27, keeping a 42,500 WAVAX bounty that one of the Safe's owner addresses agreed to on-chain, plus 41 WAVAX it did not return. We checked each step on Avalanche's public chain data.

Times are in US Central Time (CT), with UTC in brackets where it matters.

Key facts
Target Safe 0x631fca…b9b8 on Avalanche C-Chain: 7 owners, 2 signatures needed (read from the contract, Oct 27)
The mistake On Mar 7, 2026 a Safe batch approved unlimited WAVAX, USDC, WETH.e and BTC.b to 0x3725bd…155d, which had no code on Avalanche
Why that address It is the address Safe's public CreateCall contract (0xb22d63…0316) produces on its 13th deployment. On Ethereum, Base and Arbitrum the operator's contract sits there; on Avalanche, CreateCall itself did not exist until Oct 26
Attack Oct 26, 7:56 AM CT (12:56:14 UTC), block 98,605,391. Sender 0x4c48b79b97516719444056d2bf0dc9564138fa0a failed
Front-run MEV bot 0x36b112…21b3 ran a copy first in the same block: 3,090,123.58 USDC, 350,375.86 WAVAX, 181.98 WETH.e, 10.79 BTC.b
Returned Oct 27, 4:37 to 4:46 AM CT, to 0x35c6aa…807c, the address named in the bot's on-chain message: all of the USDC, WETH.e and BTC.b, and 307,834.86 WAVAX
Bounty 42,500 WAVAX (about $371K, per Defimon), accepted in an on-chain message at 4:30 AM CT Oct 27
BlockintAI report Attempted $7.45M drain of an Avalanche Safe multisig via a stale token approval

The approval that pointed at nothing

On March 7, 2026 at 10:10 AM CT (16:10:25 UTC), the Safe executed a batch transaction. Its logs on Avalanche show four Approval events, each granting the maximum possible allowance from the Safe to 0x3725bd…155d:

  • WAVAX (wrapped AVAX)
  • USDC
  • WETH.e (bridged ether)
  • BTC.b (bridged bitcoin)

Approving a contract you use is routine. The problem, as Defimon describes it, is that 0x3725bd…155d is the address of the operator's pool contract on other chains. We checked: on Ethereum, Base and Arbitrum there is contract code at that address, created in each case through the same factory, 0xb22d63…0316. On Avalanche there was none.

An approval to an empty address looks harmless, because nothing there can call transferFrom. It stops being harmless the moment someone can deploy code to that exact address.

Why anyone could claim the address

Ethereum-style chains compute a new contract's address from the deployer's address and a counter, its nonce. Nothing else goes in. So if the same deployer exists on two chains and has made the same number of deployments, its next contract lands at the same address on both.

0xb22d63…0316 is Safe's CreateCall helper. Its verified source on Etherscan is named CreateCall, and it deploys whatever bytecode a caller hands it. It can be installed at the same address on any chain through the Safe singleton factory, a deterministic deployer. We computed the address it produces on its 13th deployment: 0x3725bd…155d.

Before October 26, CreateCall had not been deployed on Avalanche at all. SnowScan's contract-creation record for it on Avalanche points to the October 26 block, installed through the Safe singleton factory 0x914d7f…43d7. So for seven months the Safe's allowances waited for whoever first installed CreateCall on Avalanche, made twelve throwaway contracts, and put a sweeper in thirteenth place. Defimon describes the attacker's transaction doing exactly that.

October 26: one block, two transactions

The attacker's wallet, 0x4c48b79b97516719444056d2bf0dc9564138fa0a, received 6.77 AVAX at 7:29 AM CT (12:29:39 UTC), in a transaction sent by an address that SnowScan, Etherscan's Avalanche explorer, labels Relay: Solver. It was the only AVAX the wallet ever received.

Twenty-seven minutes later, at 7:56:14 AM CT, it sent its only transaction: a Multicall3 batch whose calldata contains the Safe, the Safe singleton factory, CreateCall, and the WAVAX and USDC token contracts. It sits at position 2 in block 98,605,391, and it failed.

Position 0 in the same block belongs to the MEV bot 0x36b112…21b3. Its transaction succeeded. In it, CreateCall was installed on Avalanche, a contract was created at 0x3725bd…155d, and the Safe's tokens moved to the bot:

Token Amount taken from the Safe
USDC 3,090,123.580226
WAVAX 350,375.855
WETH.e 181.976
BTC.b 10.786059

The contract the bot left at 0x3725bd…155d now holds code that reverts on every call. As of 7:44 AM CT on October 27, the Safe's four approvals to that address were still in place (WAVAX at the maximum, the other three at the maximum less the amounts taken), but the Safe held none of those tokens, and nothing at that address can spend them.

Funds back, minus a bounty

From 9:05 to 9:22 AM CT on October 26, the bot moved all of the USDC, WETH.e and BTC.b, and 350,334.86 WAVAX, to a holding wallet, 0x11eb9b…9bc5. The other 41 WAVAX stayed with the bot and were not returned.

The bot then talked to the Safe's side on-chain. In a message Defimon reposted, it pointed to the original attack transaction, promised to return the funds to 0x35c6aa…807c "within the next few hours," and asked for a 5 to 10% bounty. At 4:30 AM CT on October 27 (09:30:43 UTC) a message sent to the bot from one of the Safe's seven owner addresses read:

"Ok that works, we confirm your test and that we are happy for you to keep 42,500 WAVAX as a bounty for your help if can proceed with remaining transfers"

The "test" was a 0.58 USDC transfer at 2:22 AM CT. From 4:37 to 4:46 AM CT, the holding wallet sent the rest:

Token Returned to 0x35c6aa…807c
USDC 3,090,123.580326 in three transfers, including the test
WETH.e 181.976
BTC.b 10.786059
WAVAX 307,834.855

When we checked at 7:44 AM CT on October 27, the return address held exactly those amounts and the holding wallet held 42,500 WAVAX, the bounty. In US dollars, using Defimon's October 27 figures ($7.45M at stake, a 42,500 WAVAX bounty worth $371K), about $7.08M went back: $7.45M minus $371K.

Address poisoning, right on cue

Within hours, fake tokens started arriving. The holding wallet's history shows transfers of "USDC" and "BTC.b" from token contracts that are not the real ones (0x7ae672…af97 and 0x4549e9…fe75), apparently sent from the holding wallet to 0x35c660…807c. That address shares its first and last characters with the real return address 0x35c6aa…807c. Fake tokens can emit transfer events that seem to come from any address. The goal is to plant a lookalike in the wallet's history and hope someone copies it for the next transfer. None of the real tokens went there.

Other chains, according to Defimon

Defimon reports that the same operator runs Safes on other chains, each with its own signers, and that from 8:48 AM CT (13:48 UTC) on October 26 those signers moved funds out of their Safes on HyperEVM, Base, Robinhood Chain, BNB Chain and Ethereum into one fresh address, 0x70d54b…2099. Defimon puts that address's holdings at about $38.7M. Those transfers and that figure are Defimon's.

What this means

  • An approval is a promise to an address, not to a contract. If nothing is deployed at the approved address on that chain, the approval belongs to whoever deploys there first. Before approving, check that the spender has the expected code on that chain.
  • Same address on every chain is not a guarantee. Contracts created through a shared factory land at the same address only if that factory has done the same number of deployments on each chain. If the factory does not exist on a chain yet, anyone can install it and count up to the right number.
  • Review old approvals. These allowances sat for 233 days. Revoking unused approvals, especially unlimited ones from treasuries and multisigs, closes the door before someone finds it.
  • The mempool watches too. This time a bot that copies profitable transactions happened to run first and chose to give the money back. That was luck, not a defense.

If you lost money in a hack or any crypto theft, report it to ic3.gov and the FTC, and file a report at blockint.ai so others can see the addresses involved.

Addresses

  • Attacker wallet (Avalanche C-Chain), sent the failed drain transaction: 0x4c48b79b97516719444056d2bf0dc9564138fa0a

For reference, not attacker addresses: the Safe 0x631fca…b9b8, the MEV bot 0x36b112…21b3 and its holding wallet 0x11eb9b…9bc5, the return address 0x35c6aa…807c, and 0x3725bd…155d.

Sources