An Ethereum address that belongs to you has been able to execute someone else's program code since the Pectra upgrade, without its address, its balance or its key changing at all. EIP-7702 is
An Ethereum address that belongs to you has been able to execute someone else's program code since the Pectra upgrade, without its address, its balance or its key changing at all. EIP-7702 is what makes this possible: one signature from you is enough, and from that moment on your address behaves like a contract. This is the basis for many convenient wallet features, and it is also the route by which attackers keep a drained account permanently under their control. This article shows you how to check in two minutes whether your own address carries such a delegation, and what to do if the contract sitting there is one you do not recognise.
The basis for this is our own measurement on the Ethereum chain, taken today. It shows how widespread these delegations have become and what they mostly point to. The answer is more uncomfortable than wallet marketing suggests, but also more nuanced than a bare percentage implies.
EIP-7702 is an extension to Ethereum that lets an ordinary key-controlled account run the program code of a contract without becoming a contract itself. The account keeps its private key, its address, its balance and its nonce. All it gains is a pointer to a contract whose code runs on the account's behalf on every call.
The technical term for this is delegation. The pointer is written into the account's code field, which until then was empty for a key-controlled account. From that moment on, anyone calling the account calls the stored contract, and that contract reaches the account's storage and balance.
The benefit is obvious. A wallet can bundle several steps instead of asking you to sign three times. A provider can cover the fee on your behalf. An app can set up a tightly bounded spending permission that expires after an hour. These are exactly the features wallet makers have been selling under the Smart Account label since 2025.
The price sits in the same sentence: the stored contract acts with your account's full authority. It can move funds, grant approvals and trigger further calls. A delegation is therefore not a setting but a power of attorney, and it stays in place until you replace it or revoke it.
A delegated account carries exactly 23 bytes in its code field: the fixed marker 0xef0100 followed by the 20 bytes of the target address. That marker is the only reliable evidence. Everything else an interface shows you is interpretation.
In practice you see it in two places. A block explorer suddenly lists your address as a contract, or displays a note about a delegated account, even though you have never deployed a contract. And the code lookup that every explorer offers returns, instead of an empty value, a short string beginning with ef0100.
The 20 bytes that follow are the address you have to check. They decide everything. If your wallet maker's contract address is sitting there, the delegation is probably intended. If something unfamiliar is sitting there, you have a problem that goes well beyond a misplaced click.
One point matters for context: an empty code field is the good news. If you find nothing there, you have no active delegation, regardless of whether one existed in the past.
The check takes a few minutes and needs neither a tool nor an installation.
The same check works on every chain where EIP-7702 is live. An authorisation signed for chain ID zero is even valid on all chains at once. Anyone using several networks is better off checking more than once.
An EIP-7702 authorisation works like a signed power of attorney: it costs the signer nothing and stays valid until they revoke it. This analysis was carried out by cryptoticker.io itself on September 13, 2026. Method: we pulled 200 consecutive blocks in full from a public Ethereum node, blocks 25,971,139 to 25,971,338, and evaluated every transaction of type 0x04 in them together with its authorisation list. The window runs from 21:14:35 to 21:54:23 UTC and covers 39.8 minutes of chain time.
The numbers from that window:
What we could not measure is how many accounts currently carry a delegation in total, because that would require a full state dump of the chain rather than a time window. Nor can these data show how much money was moved through the contracts we found. And a 40-minute window is a snapshot: another day may show a different distribution.
In this measurement the names say more than the shares do. Publicly verified source code is available for two of the three most frequent targets, and both describe themselves as tools used by criminals.
The most frequent target, with 2,007 authorisations, or 49.7 percent of the window, carries the name Poisoner in its verified source code. The comment in the source names the purpose outright: the contract is used for address poisoning, that is, to trick inattentive users into sending funds to a wrong address that looks visually similar. As the party behind the publication, the source names the trading firm Wintermute, which says it rebuilt and disclosed the contract. The program code itself is short: it executes a list of arbitrary calls, but only if the transaction was triggered by exactly the address that created the contract.
The third most frequent target, with 170 authorisations, carries the name CrimeEnjoyor. Here too the explanation sits in the source code, and it is set in capital letters: anyone who finds this contract in an authorisation list has a compromised account; no further funds may be sent there, because they will be swept immediately. The code is shorter still than that of the first contract. It does precisely one thing: every incoming amount is forwarded straight away to a target address fixed at setup.
For comparison, the legitimate side of the same list: in eighth place sits a verified contract from a well-known wallet maker with 110 authorisations, alongside several contract accounts from the account-abstraction world with 10 to 49 authorisations each. Those contracts run to several thousand bytes, while the two conspicuous targets get by on 772 and 1,042 bytes. A contract that only sweeps needs little code.
Care is needed here, because the percentage invites a false conclusion. So we looked at who actually sent these transactions.
The result: the 2,007 authorisations pointing at the top-ranked contract come from 186 transactions, and those 186 transactions came from a single sender. With 176 distinct senders across the whole window, almost half of all authorisations therefore trace back to one address that registers bundles of up to 110 powers of attorney at a time, minute after minute.
Our reading of this, and it is explicitly a reading rather than an established fact: the pattern does not fit 2,007 freshly harmed users, but rather an operator kitting out their own throwaway addresses. Besides the single sender, the design of the contract supports that view, since it only executes calls for its own creator. In address poisoning the attacker generates the deceptively similar addresses themselves and needs no one else's key to do so. What we are measuring in this case is infrastructure rather than loot.
The second conspicuous contract looks different. Its 170 authorisations are spread across 170 separate transactions from two senders, so one power of attorney per transaction. A collection contract that forwards incoming amounts immediately only makes sense for an account whose key is already in someone else's hands. For you as a reader the difference is decisive: the first case almost certainly does not concern you, the second concerns you directly if your account appears on that list.
The revocation is itself an authorisation: only a pointer to the zero target address clears the foreign code out of the account. A sweeper is a contract or program that forwards incoming amounts to an outside address automatically and within seconds. If you find a delegation to such a contract on your address, the delegation is not the cause but the consequence. Someone was able to sign in your name, and that requires your private key or your recovery words.
From this follows an order of operations that runs against the first reflex. The reflex says: revoke the power of attorney and move on. The correct view is this: the account is lost, and every amount you send there, including the fee for the revocation, will very likely go to the attacker. A revocation you pay for yourself funds the other side, in case of doubt.
So set up a new account first, ideally on a device whose key has never sat on a computer. Which designs come into question, and how the devices differ, is laid out in our software wallet comparison alongside the device selection. Only afterwards do you deal with whatever is left on the old account, and you do so with help.
For exactly this case there is a free point of contact, one that the sweeper contract's own source code names: the Flashbots whitehat hotline. It helps get remaining balances past a sweeper by settling the rescue and the fee in a single bundle that the sweeper cannot pick off separately. That is no guarantee, but it is the only serious route that requires no payment up front.
If the account is clean and the delegation is merely unwanted, because you no longer use a wallet feature for instance, then revoking it is simple and still easy to misunderstand.
A delegation does not end because you delete the app, change device or withdraw an approval. It ends solely through a new authorisation pointing at the zero target address, that is, an address made up entirely of zeros. Only then does your account's code field become empty again. Our measurement shows that this step does occur in practice: 140 of the 4,035 authorisations in the window were revocations of this kind.
Check the code field once more after revoking. An interface reporting success to you is not evidence. The evidence is an empty code field in the explorer.
A second point is easily overlooked: a new delegation replaces the old one entirely. Anyone switching from one wallet provider to another ends up with the new provider's power of attorney in the account, not both. That is reassuring, but it does not remove the need to check, because which contract ends up sitting there is decided by the most recently registered authorisation.
The most dangerous part of EIP-7702 is its price. An authorisation is a pure signature. It costs you nothing, it shows up in no fee summary, and you do not even have to submit it yourself: any third party may wrap it into a transaction of their own and cover the fee.
For honest providers that is an advantage, because a new account becomes usable straight away without holding funds. For a fraudulent site it is a gift. It needs no transfer from you, no approval and no balance on the account. A single signature in a window that looks like a login, a claim for free tokens or a security check is enough.
From this follows a rule for everyday use: treat every signature request whose content you cannot read as if it were a transfer. That applies in particular to requests asking you to update, migrate or secure an account. You already know this trick in its classic form from the world of manipulated payment recipients; how it plays out there was covered in our August analysis of address poisoning.
It would be wrong to conclude from all this that every delegation is an attack. Alongside the conspicuous targets, our measurement also shows a number of clearly attributable wallet contracts, among them the contract of a large browser wallet provider and several account templates from the account-abstraction world.
Three characteristics separate the two groups fairly reliably in practice:
Anyone working with several wallets regularly should note down their own provider's target address once. The check then becomes a comparison of twenty bytes next time, rather than a research task.
A common misconception holds that a hardware wallet makes this question moot. That is true for the key, but not for the power of attorney. An EIP-7702 authorisation is also signed with the private key, and in the worst case the device displays only a target address and a nonce, without being able to explain what follows from them.
What matters, then, is whether your device presents the content of a signature request in plain text and whether you have switched off the signing of unreadable data. What counts here was set out in our article on blind signing on hardware wallets. The recommendation from there applies unchanged: what the device cannot display, you do not sign.
The second protection is the separation of duties. One account for day-to-day dealings with applications, a second for holdings that stay put, and no signature from the second account on any website. A delegation on the everyday account is annoying; a delegation on the holdings account is expensive. If you need the technical wording of the specification, you can read it in the text of EIP-7702, in particular the rules for chain ID zero.
(As of September 13, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)
