One of our users lost a 50 USDC payout the moment it landed. His wallet was carrying hostile EIP-7702 code, and every route we tried to clear it failed.
The funds arrived and were swept in the next transaction, in the same block. He still controlled the wallet and held its key, and the address otherwise appeared to behave normally. The code let anything arriving there be moved without another signature from him. This was not a typical token-approval drain.
Once we understood what had happened, we tried to help him recover the wallet. Rabby and MetaMask both refused to sign the reset transaction our agent prepared. We then tested the workaround people recommend, Rabby GasAccount, on a wallet of our own that was carrying the same kind of hostile code. The gas funding was swept in the same block, before the reset could land.
This post documents the incident from our perspective: what happened to the user, and why the recovery paths we tested failed. It is also why Ava now scans wallets for EIP-7702 code, in Telegram chat and through MCP, and tells you if it has already swept funds.
The wallet looked normal. It was not.
The user had been using the same address for months.
On 1 August 2026, he signed a type-4 transaction that appeared to send about half a cent of ETH. The real action was in its authorization list: it pointed the wallet at a contract built to forward its tokens and ETH to a collector.
Three weeks later, a community payout of 50 USDC arrived.
The sweeper took it immediately.
He still holds the key. The key is not enough.
With hostile code attached to the address, someone could move new deposits without asking him to sign again.
For readers who want the technical marker, an EIP-7702 designation looks like this:
eth_getCode(wallet) = 0xef0100 || <20-byte delegate>The last 20 bytes point to the contract the wallet follows. In this case, that contract was the sweeper.
Our agent could not complete the reset
There is a way to clear an EIP-7702 designation. The wallet signs a new authorization that points to the zero address, and another account can pay the gas.
That last part matters. A compromised wallet should not need to receive ETH before it can be repaired.
Our agent prepared the reset transaction and asked the connected wallet to sign it.
Rabby refused the type-4 transaction with: “EIP-7702 is not supported yet.”
MetaMask refused it with: “External EIP-7702 transactions are not supported.”
This is a wallet-provider limitation, not a limit of EIP-7702 itself. Rabby also detects EIP-7702 and has an in-wallet Cancel flow. But our agent cannot trigger that in-wallet action for the user.
So we tested the workaround people often recommend: Rabby GasAccount.
The rescue money was swept
We did not test this on the user's wallet.
We used a wallet that Ava controls, with unknown EIP-7702 code already attached on Base. That let us measure the full flow without putting a user's funds at risk.
Here is what happened:
- GasAccount sent 375.873368555 gwei to the occupied wallet.
- In the same block, the collector received exactly that amount.
- The occupied wallet started with zero and ended with zero.
- The transfer used 30,500 gas, showing that code ran when the ETH arrived.
- The Cancel transaction never landed.
The funding transaction is public on Base.
GasAccount worked as designed. The hostile wallet code did too.
The problem was the order of operations: the flow funded the occupied address before the reset was complete. The sweeper was waiting for exactly that.
There is no amount large enough to win this race. If the wallet forwards every deposit, a bigger deposit only gives it more to forward.
A safer recovery flow would let the occupied key sign the reset without broadcasting it. A different funded wallet could then publish the transaction. A provider method such as wallet_signAuthorization could make that possible without sending ETH to the compromised address first.
We shared the measurement and the failed recovery paths in RabbyHub/Rabby#3102.
Until injected wallets support a safe sponsored reset, our advice is simple: do not fund the address again, including through GasAccount. Move to a new wallet.
Affected wallets pointed to different contracts
We checked other affected wallets on Base.
Each pointed to a different unknown contract. That rules out one shared delegate. It does not prove who operated them or whether they came from the same attack kit.
One user address had also carried three different designations over time. That could mean the key was exposed. It could also mean the user signed more than one malicious authorization. We cannot tell from the chain alone.
Either way, clearing the current designation may not be enough. If the attacker can install another one, the wallet is still unsafe.
We are only identifying the Ava-owned test wallet in this post. The public funding transaction already reveals its full address; it is shortened here for readability:
eth_getCode(0x804e…81557) = 0xef0100 || 0xdf02e0aa8a707f2b190b355f320ce7d3bc698792We are not publishing the users' addresses, delegates, payout transactions, sweep transactions, or Discord handle. These are live drains, and public details can attract recovery scammers.
What you should do now
If a wallet has unknown EIP-7702 code attached:
- Stop sending funds to it. New deposits may be swept immediately.
- Do not assume approval revocation will fix it. Approvals and account code are different risks.
- Do not pre-fund it for gas. The ETH may be swept before a reset can run.
- Move to a new wallet. A reset is not a cure if the key or signing path is still compromised.
Rabby is not the villain here, and GasAccount is not broken. Our finding is narrower: the flow we measured funded an occupied address before recovery, and the attached code swept that funding in the same block.
What Ava is changing
Ava will now read account code whenever it scans a wallet in chat, Telegram, MCP, or the guardian.
Here is what that means in practice:
- Unknown code: show a critical warning and tell the user to stop deposits.
- Known code: explain what the wallet is using without creating unnecessary alarm.
- Ongoing alerts: tell guardian users when the code attached to an enrolled wallet changes.
Our agent cannot complete the reset today. The connected-wallet flows we tested do not support it safely.
We will not pretend otherwise.
What we are not claiming
We would not have stopped the malicious signature in August. That confirmation happened inside the wallet app, not inside Ava.
We are not claiming that every unknown EIP-7702 designation is malicious. Known smart-account systems use the same standard for legitimate features.
We are not claiming the affected wallets share one attacker. Different delegates rule out one shared contract, not one shared operator.
And we are not turning a 50 USDC loss into a 50 million dollar headline.
The amount was small. The mechanism was not.
The next deposit is the one that counts.
Our job is to name the thing that can take it before the user sends it.
Reading account code is how we do that.
Ava reads your positions, your approvals, and now your account code. Read-only to start: no signing, no deposit, no reset through the agent. Scan a wallet in Telegram
On-chain: the GasAccount measurement ran on a wallet we control, and its funding transaction is public. Researchers who want to verify the user incidents can ask us for the private references.
