Ethereum's Pectra upgrade activated on 7 May 2025. It included EIP-7702, which lets an ordinary account delegate its behaviour to contract code. F103-04's capabilities, without migrating to a new address.
Within four weeks, Wintermute's researchers reported that more than 97 percent of delegations on mainnet pointed at copy-pasted automated sweeper contracts.
Be careful with that number, because it gets misread. Most of those sweepers were attached to addresses whose keys were already compromised, and were racing each other to drain incoming funds. Wintermute reported they were largely unprofitable. It is a striking statistic about who showed up first, not a measure of damage.
The damage came from a separate pattern. Phishing campaigns impersonating familiar interfaces persuaded people to sign batch transactions and delegation approvals: around $12M from more than 15,000 wallets, including a single loss of about $1.54M in one batch-transaction phishing attack in late August.
Here is what makes this different from every other phishing autopsy in the Academy.
These people were not signing something they misread. They were signing something their wallet could not yet explain, in a category that had not existed the month before. The capability shipped, the attacks were operational in weeks, and the tooling that would have rendered "this installs code that controls your entire account" in plain language was not there yet.
F103-04 described what smart accounts make possible. This lesson is about the interval between a capability arriving and anybody being able to read it, because that interval is where the losses are.
It is marked low confidence deliberately. The specific mechanism here was months old when this was written and may already be superseded. The pattern is the part worth learning.
Scope is the whole difference
You already know token approvals from F105-05. Put the two side by side, because the jump is larger than it looks.
A token approval grants a specific contract the right to spend a specific token, up to an amount. Bad ones are bad: an unlimited approval on a stablecoin is your whole stablecoin balance. But it is bounded on three axes, and assets you never approved are untouched.
A delegation installs code that acts as your account. Not one token. Not one contract. Every asset the account holds and every action it can take, for as long as the delegation stands.
| Token approval | Delegation | |
|---|---|---|
| Scope | One token | The whole account |
| Limit | An amount you set | None |
| Counterparty | One named contract | Whatever code you pointed at |
| Duration | Until revoked | Until revoked |
| If you hold ten assets | One is exposed | Ten are |
| What it looks like to sign | Increasingly well rendered | Frequently a hash |
The last row is the autopsy. Wallets have spent years learning to display approvals well, with warnings on unlimited amounts and named contracts. Delegations arrived without any of that accumulated tooling.
Take an account holding a realistic mix.
- $3,000 in a stablecoin
- $6,000 in ETH
- $1,000 across four other tokens
Total: $10,000.
Worst case from one unlimited token approval, on the stablecoin:
Exposure = $3,000, or 30 percent
The ETH is untouched, because an ERC-20 approval cannot move the native asset. The other tokens are untouched, because the approval named one contract.
Worst case from one malicious delegation:
Exposure = $10,000, or 100 percent
Everything, including the ETH, in one atomic batch before you can react.
The ratio for this account is 3.3 times, and it gets worse the more diversified you are, which inverts the usual intuition about spreading holdings. Under approvals, holding ten assets means an approval mistake costs you a tenth of your exposure. Under delegation, holding ten assets means a delegation mistake costs you all ten.
Now add the second axis, which is time. An approval sits until revoked and an attacker must return to use it, which leaves a window. A malicious delegation typically batches the drain into the same transaction, so the gap between signing and losing the funds is zero.
Both of those point at the same conclusion, and it is the reason F104 has three tiers: the account you experiment with should not be the account that holds anything.
The three properties, which recur
This will happen again with something that does not exist yet, so learn the shape rather than the instance.
A new authorisation primitive becomes an attack surface when three things are true at once, and they all peak at launch.
It is powerful. Attackers go where the authority is, and a new primitive is usually introduced precisely because it grants more than the old one.
It is unfamiliar. Users have no stored pattern. F111-01's whole argument is that people classify by resemblance to things they have seen, and a request in a brand-new category resembles nothing.
The tooling has not caught up. Wallets, explorers, simulators and revocation tools have to be taught what each new thing means, and they are taught after it ships, by which point the attacks are running.
Those three peak together, in the weeks after launch, which is exactly when the ecosystem is loudest about how much better everything now is.
If your wallet cannot render, in one sentence, what a request does, do not sign it.
Not "read it more carefully". Not "look it up". Do not sign it.
This is a stricter rule than F105-02's verification discipline and it is stricter on purpose, because verification assumes there is something legible to verify. When a primitive is new, there frequently is not, and the honest response to an unreadable request is refusal rather than effort.
The cost of the rule is that you are late to new capabilities by a few months. That is the entire cost. The benefit is that you skip the window in which the losses happen, and you arrive when your wallet can tell you what you are approving.
Check your own account
Do this today, and repeat it on the schedule from F105-05.
Look at what your account currently delegates to. A block explorer will show whether an address has code attached to it, which for an account you believe is a plain one is a finding rather than a curiosity. Several wallets now surface this directly.
Revoke what you do not recognise, using a revocation tool you reach through your own bookmark, per F111-04. Not a link, and not a search result, because "revoke your compromised delegation here" is the obvious follow-up attack on anyone who just read this lesson.
Add delegations to your existing revocation review. You already have one for approvals. This is a second column in the same habit, not a new habit.
And if you find something: F106-06's triage applies. A live malicious delegation on an account with funds is class 2, revoke then move, unless you have reason to think the key itself is exposed, in which case it is class 1 and you move first.
This is why the new account types are a bad idea and I should stay on a plain EOA.
Understandable, and it draws the wrong line, in a way that would have you making the same error in the other direction for the next decade.
The losses here are not evidence that the capability is bad. They are evidence about timing. The identical pattern preceded this one: token approvals were a novel primitive once, drained people at scale, and are now routinely rendered with warnings, simulated before signing, and revocable through mature tooling. The capability did not become safe. The ecosystem learned to describe it.
Staying on a plain EOA forever also has a cost, and F103-04 quantified it: the single largest cause of loss in this field is people losing access, and recovery is the thing smart accounts genuinely fix.
The defensible position is neither refusal nor enthusiasm. It is a lag. Let a new primitive mature until your wallet can explain it, your revocation tooling supports it, and the first wave of losses has produced the warnings. Then adopt it on a tier where a mistake is survivable, per F104, before it holds anything you cannot replace.
That is a rule you can apply to something that has not been invented yet, which is the only kind of rule worth learning in a lesson marked low confidence.
Closing F103
You now have the chain from entropy to address, what the words in a seed phrase actually are, the question that determines whether you are in custody or in a claim, what programmable accounts buy and cost, and how a new capability becomes an attack surface before anyone can read it.
F103-L, the lab, makes the derivation path concrete: import a throwaway seed into two wallets, derive the same address in both, then change the path, watch a different empty address appear, and explain what happened. Do it with nothing at stake, so that the day it happens by accident you recognise it instead of panicking.
Then F104, which takes all of this and turns it into an architecture you actually run.
A token approval is bounded by token, amount and counterparty; a delegation installs code that acts as your entire account, so the same single mistake costs 30 percent of a mixed portfolio in one case and 100 percent in the other, with no window in between. New authorisation primitives become attack surfaces because three properties peak together at launch: they are powerful, they are unfamiliar, and the tooling that would explain them has not caught up. So the standing rule is not to read harder, it is to refuse: if your wallet cannot say in one sentence what a request does, do not sign it. Then check what your account delegates to, revoke through your own bookmark, and adopt new capabilities on a lag.