A trading team’s Safe multisignature wallet on Avalanche lost control of approximately $7.45 million in digital assets after an attacker exploited an unlimited token approval that had remained active since March. The funds were captured by a competing automated trading bot before the original attacker’s transaction could succeed, and approximately $7.08 million was subsequently returned under a negotiated recovery agreement.
An investigation published on October 29 reconstructed how the incident unfolded across October 26 and 27. The affected wallet contained approximately $3.09 million in USDC, 350,000 Avalanche tokens, 182 ETH and 10.8 BTC in wrapped form. The bot retained 42,500 AVAX, worth approximately $371,000, as an agreed reward for returning most of the assets.
The incident did not establish a vulnerability in Safe’s wallet contracts or the Avalanche blockchain. Instead, it exposed the danger of leaving unrestricted token-spending permissions active on a network where the approved destination address did not contain the contract the wallet’s owners expected.
An unlimited approval left the wallet exposed for 233 days
The affected wallet was a Safe multisignature account associated with an unidentified trading team. Its configuration required two signatures from seven authorized signers for ordinary wallet transactions. The owners had granted unlimited token-spending permissions to a specific address on March 7, 2026, approximately 233 days before the October incident.
The approvals covered four assets: USDC, WAVAX, WETH.e and BTC.b. They were intended for an address associated with the team’s trading infrastructure on Ethereum, Base and Arbitrum. On Avalanche, however, the same address did not contain a deployed contract.
That distinction created the opportunity for the attack. Token allowances authorize a designated address to transfer tokens from a wallet without requiring the wallet’s signers to approve every subsequent transfer. Once the owners granted unlimited allowances, the permissions remained available until they were consumed, changed or revoked.
The attacker exploited the empty destination address by using Safe’s publicly available CreateCall helper. The address corresponded to a predictable deployment position: the helper’s thirteenth contract creation. By deploying the helper on Avalanche and executing 12 preliminary deployments, an attacker could place custom code at the address that already possessed the wallet’s spending permissions.
The attacker then used that code to initiate transfers of the approved tokens from the Safe. The weakness was not that the wallet’s multisignature threshold had been bypassed through a flaw in its normal transaction approval process. Rather, the previously granted token allowances provided a separate route for transferring assets without fresh signatures from the wallet’s owners.
A competing bot captured the funds before the attacker
The decisive transactions occurred on October 26. The attacker assembled a transaction designed to deploy the required contracts and sweep the wallet’s token balances. An automated bot monitoring pending blockchain transactions identified the opportunity, copied the transaction’s essential operations and submitted its own version with a higher transaction fee.
The bot’s transaction was executed first in the same block, allowing it to transfer approximately 3.09 million USDC, 350,375 WAVAX, 181.976 WETH.e and 10.786 BTC.b from the Safe. The original attacker’s transaction subsequently failed because the relevant contract address had already been occupied by the bot’s deployment.
This was an example of maximal extractable value, or MEV, in which a transaction’s ordering determines who captures an available financial opportunity. In this case, the bot effectively outcompeted the original attacker for the assets rather than allowing the intended theft to proceed.
The distinction matters when describing the incident’s financial consequences. Approximately $7.45 million was transferred out of the wallet, but the original attacker did not successfully collect the funds through the attempted transaction. The bot became the temporary holder of the assets and subsequently negotiated with the wallet’s representatives.
The episode also differs from the Bloom trading bot incident, where investigators identified transfers authorized through the affected wallets’ normal signing authority rather than a token-approval exploit. Both cases demonstrate the importance of identifying the precise mechanism behind an asset loss instead of treating every wallet drain as the same type of security failure.
The bot returned approximately $7.08 million
After capturing the assets, the bot moved them to a holding wallet and communicated with representatives of the affected Safe. It reportedly requested a reward of between 5% and 10% of the recovered value in exchange for returning the funds.
On October 27, one of the Safe’s owner addresses agreed that the bot could retain 42,500 WAVAX as a reward. The agreed amount was valued at approximately $371,000 at the time of the investigation.
Between approximately 09:37 and 09:47 UTC, the bot returned roughly 3.09 million USDC, 307,835 WAVAX, 182 WETH.e and 10.8 BTC.b to the designated receiving address. The returned assets were valued at approximately $7.08 million, leaving the agreed AVAX reward with the bot.
On-chain checks reported in the October 29 investigation showed that the original token allowances on Avalanche subsequently read zero. The returned funds substantially reduced the financial impact on the wallet’s owners, although the reward remained a real cost of recovering the assets.
The approximately $371,000 should be understood as the reported negotiated bot reward, not as evidence that the original attacker independently extracted an additional $371,000. The attacker’s transaction failed after the competing bot executed first.
The recovery also does not establish that the bot’s intervention was risk-free or that similar incidents will produce the same result. The owners had to negotiate with an independent party that controlled their assets, and the recovery depended on that party agreeing to return most of the funds.
Why the incident matters for multisignature wallet security
The most important lesson is that multisignature protection does not automatically eliminate the risks created by token allowances. A Safe can require multiple signers for normal transactions while still having previously authorized an external address to transfer tokens without another round of signatures.
The cross-chain dimension made the incident particularly revealing. The owners apparently intended to authorize a trading contract that existed on several networks, but the same address was empty on Avalanche. Because blockchain addresses can have different deployment histories across networks, an address that is trusted on one chain is not necessarily controlled by the same code on another.
That means reviewing a token approval requires more than recognizing an address or remembering that it was previously used by a trusted application. Wallet operators must verify the spender’s identity, confirm that the expected contract exists on the relevant network and assess whether the permission is limited to the amount and duration actually required.
A practical guide to identifying crypto scams and dangerous wallet permissions explains why the authority granted by a transaction matters more than the appearance of the website or application requesting it. An approval can create a persistent financial risk even when the original interaction was legitimate.
Safe’s own guidance on DeFi deposits explicitly advises against setting unlimited token allowances for security reasons. The incident illustrates the practical value of that advice: narrowly scoped approvals reduce the amount an authorized spender can access if an address is later misused or becomes controlled by an unexpected party.
What investors and wallet operators should watch next
The public reconstruction does not point to a vulnerability in Safe’s core contracts or the Avalanche network. The principal failure was an operational configuration decision: unlimited approvals were granted to an address that was empty on one of the networks where the wallet operated.
That distinction should not make the incident seem less serious. Security failures can arise from the interaction of correctly functioning components, particularly when a permission remains active longer than necessary or is deployed across networks without checking the destination contract.
For trading firms, treasuries and protocol teams, the immediate priority is to audit existing token allowances across every network on which their wallets hold assets. Permissions to unused or unfamiliar addresses should be reviewed and revoked where they are no longer required. Where approvals remain necessary, the permitted amounts should be restricted to operational needs rather than left unlimited by default.
The team should also establish a recurring review process. A permission that was appropriate when a contract was deployed may become dangerous after infrastructure changes, a network migration or the abandonment of an application. The investigation into an eight-year-old wallet drained after a move to a new Ledger illustrates a broader security principle: changes in wallet configuration and operating practices can introduce risks that were not present in the previous setup.
There is also a limit to what the recovery outcome proves. The bot’s decision to return most of the assets was beneficial to the wallet’s owners, but it does not provide a reliable recovery mechanism for future victims. Another bot might keep the entire balance, and an attacker who controls an approved address may not negotiate at all.
The lasting significance of the Avalanche incident is therefore not that a bot rescued a trading team’s money. It is that an unlimited permission remained exploitable for months because its destination was not what the owners believed it to be on that network. The approximately $7.08 million recovery softened the outcome, but preventing similar incidents depends on eliminating stale allowances, verifying contracts independently on each chain and treating every persistent spending permission as an ongoing security responsibility.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574