EIP-7702 in 2026: Can You Read What You Sign?

Almost every crypto loss eventually traces back to a signature. You approve something, the chain does exactly what you told it to, and there is no undo. EIP-7702 raised the stakes on that moment more than any wallet change in years, because the signature it introduced does not move a single token. It installs code. Approve the wrong one and you have not lost a transaction; you have handed an attacker a programmable copy of your account that can drain it on its own schedule.

That is the uncomfortable core of Ethereum’s smart-account era. HOGE Wire has already walked through what EIP-7702 is, how set-code transactions work, how wallets and exchanges adopted it, and the drainer economy that grew up around it. This piece is about the part users actually touch: the signing screen. Because a year and a half after the feature went live, the data is blunt about where the money goes. Not into a protocol hole. Into the gap between what a person approves and what they were able to read.

What EIP-7702 actually is

EIP-7702 shipped in Ethereum’s Pectra hard fork on May 7, 2025, authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett. The specification lets an externally owned account (EOA), the ordinary kind you control with a private key, point at a smart contract’s code and behave like a smart account for as long as that pointer is set. Batching several actions into one transaction, letting someone else pay your gas, granting a game a scoped session key: all of it becomes possible without abandoning your address or your key, as Ethereum’s own Pectra roadmap describes.

The important word is in-place. You do not migrate to a fresh smart-contract wallet the way ERC-4337 asked you to. Your address stays. Your key stays. A pointer gets written to your account, and the account suddenly runs someone else’s logic. That is the same shift that let trading venues start acting like wallets, a story covered in our look at account abstraction and the exchange as your wallet. The convenience is real, and adoption reflects it: on-chain trackers such as BundleBear count over 55 million live delegations and more than 100 million set-code transactions. The cumulative authorization figure, north of 239 million, is heavily inflated by automated sweeper contracts and should not be read as user demand, a caveat that turns out to matter a great deal below.

That combination, real utility with zero migration cost, is why 7702 won the near term over the cleaner but heavier alternatives. ERC-4337 already offered smart-account features through a separate contract wallet, but it asked users to move to a new address and developers to build around an alternate mempool. EIP-7702 met people where they were: same seed phrase, same address, one signature to switch it on. The trade-off, and this piece is really one long footnote to it, is that a change this frictionless is also frictionless for an attacker to trick you into.

The signature you are actually asked to approve

Under the hood, EIP-7702 adds transaction type 0x04. What you sign is an entry in an authorization list, a tuple of chain_id, address, nonce, and the signature parts y_parity, r, and s. The address is the contract whose code your account will borrow. Your wallet signs a message tagged with a MAGIC byte, 0x05, and once it lands on chain your account carries a delegation designator: the three-byte prefix 0xef0100 followed by the 20-byte address of the contract you pointed at, 23 bytes in total that anyone can read on a block explorer.

Two details decide how safe this is. If you set chain_id to 0, the authorization is valid on every EIP-7702 chain at once, which is convenient and also a cross-chain replay risk. And you undo a delegation by signing a new one that points at the zero address, which resets your account to a plain EOA. Nothing here is exotic. The problem is that almost none of it is legible on a hardware-wallet screen at the moment you approve it, which is where the whole security question lives.

Why the signing moment is the attack surface

A normal token transfer is easy to reason about: value leaves your account, and you can see how much and to whom. A 7702 authorization is the opposite. It moves nothing. It looks, to a human and often to the wallet itself, like a no-op. That is exactly why it is dangerous: the payload that grants total control of your account is the one that appears to do nothing at all.

Once the designator is written, the borrowed contract can move any asset in the account, bundle approvals and transfers together, and keep doing so until you reset it. A 2026 academic study of the pattern, EIP-7702 Phishing Attack by Minfeng Qi and colleagues, analyzed more than 150,000 authorization and execution events and described the failure mode precisely: a single signed tuple can hand an attacker persistent, unconditional control, and because the delegation persists it can be re-triggered later rather than only at the instant of signing. There are no chargebacks and no support line. The signature is the whole security model, which means the ability to understand a signature is the whole defense.

The persistence is what makes it worse than a one-off scam. The same study grouped the exploitation into three paths: a user tricked into signing the delegation directly, an attacker who already holds a leaked key using 7702 to automate the sweep, and delegations that get re-triggered by later on-chain events rather than a fresh signature. In each case the crucial approval happened once, quietly, and kept paying out. A stolen private key has always been catastrophic; 7702 turns it into a reusable, programmable pipe, which is precisely why the moment of signing deserves more scrutiny than any transfer you will ever send.

Session keys and the delegation you grant on purpose

Not every delegation is an ambush, and it would be a mistake to read this as an argument against ever signing one. The same set-code power a drainer abuses is what lets a game grant you a session key so you stop approving every single move, or lets a subscription pull a fixed amount on a schedule without a pop-up each time. The difference between a useful delegation and a dangerous one is comprehension and scope. A well-built session key says spend up to this much, on this contract, until this date, and nothing else; a malicious 7702 delegation says install this code and trust it with everything, then hides that behind a hash.

Standards are catching up to that distinction. ERC-7715 defines a way for an app to request scoped, time-bounded permissions from a wallet, and MetaMask has shipped a version of it as Advanced Permissions, where the user grants a bounded allowance once instead of signing every action. Games on networks such as Ronin and Aptos already lean on this pattern to cut the friction of on-chain play. The security question is not delegation yes or no; it is what am I delegating, to whom, and for how much, and whether the wallet is honest enough to show me the answer before I approve.

Blind signing: the Bybit lesson

If you want to see what happens when signers cannot read what they approve, look at the biggest theft in the industry’s history. On February 21, 2025, Bybit lost roughly $1.5 billion. The exchange’s cold wallet was a Safe smart account, and the attackers, later attributed by the FBI to the North Korea-linked Lazarus group, did not break the contract. As The Block’s technical breakdown laid out, they compromised the interface so that signers saw a routine transfer while the payload they actually approved swapped the wallet’s implementation to attacker code. The signers were using hardware wallets. Those devices showed a hash, not the action.

Odysseus, founder of the security firm Phylax, put the lesson bluntly to The Block: “a hardware wallet is pointless if the transaction is signed on an internet-connected laptop or phone.” The point generalizes far beyond one exchange. A hardware wallet protects your key; it does not, on its own, tell you what you are authorizing. When the thing you authorize is a 7702 delegation, blind signing is not a theoretical risk, it is the mechanism. That the attackers turned out to be a state-linked crew rather than opportunists only sharpens the warning, a pattern we traced in our post-mortem on North Korea’s crypto operations. Understanding what a signature really commits you to is a discipline that stretches across chains, from Ethereum delegations to the invisible multisig of Taproot on Bitcoin.

Clear signing and the ERC-7730 fix

The direct answer to blind signing is clear signing: rendering a raw transaction as something a person can actually read before they approve it. The emerging standard is ERC-7730, which Ledger first proposed in 2024 and whose stewardship it handed to the Ethereum Foundation on May 12, 2026 as part of the foundation’s Trillion Dollar Security Initiative, according to The Defiant.

A wallet that supports ERC-7730 reads a contract’s descriptor file alongside the raw calldata and reconstructs the intent: a Uniswap swap renders as send 1,000 USDC, receive at least 0.42 WETH, instead of a function selector and a wall of hex. The descriptor registry now lives under the Ethereum Foundation, open for anyone to mirror, with contributors including Trezor, MetaMask, Fireblocks, WalletConnect, and others; Ledger has documented the move in its own account of the standard’s evolution. For 7702 specifically, the goal is that the screen tells you which contract you are delegating to and what it can do, in words, rather than 23 bytes you have to decode by hand.

Clear signing has a real limit worth stating plainly: it only works when a descriptor exists for the contract in question. A brand-new attacker contract has no descriptor, so the wallet falls back to raw data or a generic warning, which is exactly the situation a phisher wants. That is why the community-submitted registry matters, and why clear signing is necessary but not sufficient on its own. It also builds on an older, partial step, EIP-712 typed-data signing, which made structured messages readable but never covered the full range of what a smart account can be asked to do. The honest framing is that clear signing raises the floor for known contracts and pairs with simulation to cover the rest.

Simulation: a preview before you sign

Clear signing tells you what a transaction says it will do. Simulation tries to show what it will actually do, by running it against current chain state in a sandbox and reporting the balance changes before you sign. Blockaid’s pre-sign checks now ship by default in MetaMask; Rabby has shown a pre-sign preview on its signing screen for years; and Ledger added Transaction Check in 2025 to bring simulation onto its devices.

Charles Guillemet, Ledger’s chief technology officer, framed the shift in the company’s Transaction Check announcement as moving crypto security “from reactive verification to proactive protection”: not just reading what you sign, but anticipating the consequences before you sign it. Combined, clear signing and simulation are the strongest defense a normal user has at the signing screen, and they embody the same adversarial mindset that professional security teams bring when they break into systems before attackers do. The table below sorts the layers by what each one actually protects against.

When the preview lies: simulation phishing

Here is the 2026 twist, and it is the reason this piece exists. The simulation that is supposed to protect you can itself be phished. A study published to arXiv, Blockchain Transaction Simulation Phishing, showed that attackers can craft contracts whose behavior depends on chain state, so the wallet’s sandbox previews a benign or even profitable outcome while the real on-chain execution redirects funds to the attacker.

The researchers tested 11 leading wallets that offer simulation, including MetaMask, Rabby, and Phantom, and found that most presented misleading or inaccurate previews under this attack. Their detector, SIMGUARD, flagged more than 4,000 phishing contracts deployed between August 2024 and June 2025 across Ethereum, BNB Chain, Avalanche, and Polygon, tied to over 5,700 victims and roughly $3.48 million in losses, with 91.5% of the damage on Ethereum. The lesson is not that simulation is useless. It is that simulation is a layer, not a guarantee, and a 7702 delegation approved on the strength of a clean-looking preview can still be the one that empties the account. The defense is depth: clear signing, simulation, and hardware confirmation together, with no single one treated as the final word.

CrimeEnjoyor and the drainer economy

None of this would matter if attackers had not industrialized it. Within weeks of Pectra, the trading firm Wintermute reported that more than 97% of EIP-7702 delegations on mainnet pointed to the same copy-pasted sweeper bytecode, a script the firm nicknamed CrimeEnjoyor. The economics were almost comic: as CoinDesk reported, the operators spent around 2.88 ETH to authorize roughly 79,000 addresses, with one contract handling more than 52,000 of them, and the campaign was not even profitable, because the wallets being swept were already compromised and empty. Wintermute was careful to add that EIP-7702 is not flawed and is safe to use; the sweepers were a symptom of leaked keys, not a hole in the standard.

The reason the technique spread so fast is that phishing is a service business now. Off-the-shelf drainer kits, the best known being Inferno Drainer, hand attackers a ready-made front end and take a cut of whatever they steal, and they folded 7702 batch signatures into their playbook within weeks of Pectra. The upgrade let a single signature approve and sweep in one motion, collapsing what used to be two or three separate prompts into one clean-looking confirmation. That is a usability win for legitimate apps and a conversion-rate win for criminals, from the same feature, which is the recurring shape of this whole story.

Targeted phishing is where the real money moves. On August 24, 2025, a single victim lost about $1.54 million in wstETH, cbBTC, and NFTs after signing a batch transaction on a fake DeFi interface, with part of the proceeds bridged out via Relay, as Cryptopolitan documented. Scam Sniffer put August 2025 phishing losses at $12.17 million across 15,230 victims, a 72% jump the firm tied specifically to EIP-7702 batch-signature scams. The bigger picture is genuinely improving, with Scam Sniffer’s full-year data showing drainer losses down about 83% to roughly $83.85 million in 2025, but the batch-signature technique that 7702 enables bucked the trend.

A protocol that works, keys that do not

It is tempting to read all this and conclude the standard is broken. The researchers who have studied it hardest say the opposite. Taylor Monahan, a security researcher at MetaMask, argued in the company’s June 2025 security report that the core issue is not EIP-7702 itself but the persistent challenge of users securing their private keys; the feature simply gives attackers a more efficient way to exploit keys that were already compromised.

The largest empirical study to date agrees on the mechanism while sharpening the alarm. In Revealing the Dark Side of Smart Accounts, presented at the 35th USENIX Security Symposium in 2026, Mingyuan Huang and colleagues analyzed EIP-7702 activity across seven chains and found that more than 63% of authorization transactions were tied to malicious, EOA-targeted attacks, with 924 confirmed malicious contract accounts, several of them previously unreported zero-days, responsible for more than $2.3 million in realized losses and over $10 million in exposure. Read the number carefully, as CryptoSlate stressed: 63% counts transactions, not users or dollars, because attacker contracts get reused far more than legitimate ones. The standard is not the vulnerability. The signing habits around it are.

The gap between $2.3 million realized and more than $10 million exposed is the part that should worry defenders, because it measures how much was sitting one careless signature away from being taken. That the researchers turned up previously unreported zero-days says the attackers were, at least for a while, ahead of the tools meant to catch them. None of it points to a patch for the protocol. It points to better signing surfaces, better key hygiene, and users who treat an account upgrade with the same caution they would give a stranger asking to hold their wallet.

How to read and reset your own delegation

You are not helpless at the signing screen. A safe 7702 delegation has a few tells:

• It points at a contract your own wallet vendor controls; MetaMask, for example, delegates only to its own audited contract.
• The designator on chain resolves to that known address, not to a contract you have never heard of.
• The authorization is scoped to the chain you are actually using, rather than chain_id 0.
• Your wallet renders it as an account upgrade or delegation, in words, not as an unlabeled hash.

Reading and, if needed, clearing your current delegation takes a minute:

1. Open your address on a block explorer such as Etherscan and check whether the code field shows a 0xef0100 delegation designator; the 20 bytes after it are the contract you are delegated to.
2. Cross-check that address against your wallet’s own settings and a delegation viewer such as eip7702.app to confirm it is the contract you expect.
3. Use a tool like revoke.cash to see your delegations, but know its limit: it can show a 7702 delegation, it cannot revoke one for you.
4. To actually reset, sign a new authorization pointing at the zero address from your wallet, which returns the account to a plain EOA.
5. If you suspect the delegation is malicious, assume the key is compromised: revoking is false comfort, so move your assets to a fresh wallet with a new key.

One caveat deserves emphasis, because it trips up even careful users: if your private key is already compromised, resetting the delegation to the zero address does not save you. The attacker holds the key, so they can simply sign a fresh delegation right back. Revocation only helps when the key is still yours and you delegated to the wrong contract by mistake. The moment you suspect the key itself has leaked, stop trying to clean the account and move everything to a new wallet with a new key; anything less is rearranging furniture in a house someone else has a spare key to.

Exchanges, custody, and the 23-byte screen

For exchanges and custodians, EIP-7702 turned a routine operation into a screening problem. Many venues assign each customer a unique deposit address and periodically sweep balances into cold storage. If a deposit address has a malicious delegation set, an incoming deposit can be redirected by the borrowed code before the exchange’s own sweep runs. The defensive move is to read the 23-byte designator on every relevant address and refuse to treat a delegated EOA as a plain one, screening the contract it points at against an allow-list. That kind of operational discipline is exactly what regulators have been demanding of large venues since the compliance reckoning we covered in the Binance teardown.

The deposit flow is where this gets operationally messy. A venue that assigns each user a unique address, then periodically consolidates balances into cold storage, has to decide what to do when one of those addresses carries a delegation. Credit the deposit and sweep as usual, and the borrowed code may have first claim on the funds; freeze it, and a legitimate customer is stuck. The pragmatic answer most desks have converged on is to screen the designator on both the deposit and withdrawal side, treat any delegated address as higher risk, and refuse to auto-sweep from one until the delegated contract clears an allow-list. It is more work than the old model, and it is not optional anymore.

Institutional custody leans on multi-party computation (MPC) and policy engines rather than a single signer, which removes the single-signature blast radius that makes 7702 phishing so effective against retail. Providers such as Fireblocks have published guidance treating 7702 as appropriate mainly for hot, limited-value accounts and insisting that delegations only ever point at fully audited contracts. The through-line is the same as everywhere else in this story: the risk is not the feature, it is an unverified signature, and the institutions that handle it well are the ones that made reading the payload a hard requirement rather than a user’s good intention.

The SEC, self-custody, and who reverses a signed drain

Regulation does not save you here, and in the United States it is not really trying to. The Securities and Exchange Commission signaled in April 2026 that software letting users transact from self-hosted wallets is not itself acting as a broker, which keeps self-custody wallets outside the registration regime that governs exchanges. That is mostly good news for builders, but it carries a blunt corollary for users: when you sign a 7702 delegation from a self-custodied wallet and it drains you, there is no broker to complain to and no regulator that can reverse the transaction.

The IRS still expects its cut of any gains along the way, and US brokers began reporting digital-asset proceeds on Form 1099-DA for the 2025 tax year, but none of that unwinds a bad signature. In self-custody, the signing screen is the compliance department, the fraud desk, and the last line of defense at once. That is the trade every smart-account user makes, and EIP-7702 made the trade invisible enough that a lot of people made it without noticing.

There is a quieter policy point here too. Every consumer-protection regime that works, from card networks to bank transfers, relies on an intermediary who can claw a payment back. Self-custody deliberately removes that intermediary, which is the entire point and also the entire risk. Regulators can chase the phishing crews, pressure the exchanges that cash out stolen funds, and push disclosure standards, but they cannot reach into a settled Ethereum block. For now the responsibility that a bank would carry sits with whoever is holding the seed phrase, and EIP-7702 quietly widened what a single approval from that person can authorize.

Native account abstraction will not fix the human

The long-promised fix, native account abstraction baked into the protocol, keeps slipping. Base’s Cobalt upgrade and its EIP-8130 account-configuration model, once expected on mainnet around September 2026, now show mainnet activation as to-be-determined and remain confined to a devnet, as Bitcoinist reported. A competing proposal, EIP-8141, sits in the queue for a later fork Vitalik Buterin refers to as Hegota, with no committed date.

Even when native AA lands, it changes the plumbing, not the psychology. It can remove the bundler and relay dependencies that make today’s stack fragile, and it can make gas sponsorship and passkey signing first-class. What it cannot do is make a human understand a payload they never read. Native or not, the account will still do exactly what the last valid signature told it to. The durable fix is the unglamorous one that ERC-7730, simulation, and hardware verification are all circling: make the signing screen legible, and treat every request to install code with the suspicion it deserves. In a market where ETH trades around $2,506, per CoinDesk, the value sitting behind a single 7702 delegation is rarely trivial, and the one defense that scales is a user who reads before signing.

Frequently Asked Questions

Is EIP-7702 safe to use in 2026?

The standard itself is considered safe. Researchers at Wintermute and MetaMask attribute almost all EIP-7702 losses to compromised private keys and phishing rather than a flaw in the feature. The risk lives in what you sign, so use a wallet that clear-signs and simulates 7702 authorizations, and only delegate to contracts your wallet vendor controls.

What is blind signing and why is it dangerous with EIP-7702?

Blind signing means approving a transaction your wallet cannot show in human-readable form, so you see a hash instead of the action. It is dangerous with EIP-7702 because a delegation installs code rather than moving funds, so a malicious authorization can look harmless on screen while handing an attacker full control of the account.

How do I check and revoke an EIP-7702 delegation?

Look up your address on a block explorer such as Etherscan and check for a 0xef0100 delegation designator, which is followed by the address you are delegated to. Tools like revoke.cash and eip7702.app can display delegations, but to reset you must sign a new authorization to the zero address from your wallet. If you think the delegation is malicious, move your assets to a fresh wallet.

What is ERC-7730 clear signing?

ERC-7730 is a standard first proposed by Ledger and now stewarded by the Ethereum Foundation that lets wallets render raw transactions as readable descriptions using published contract descriptor files. For EIP-7702 it is meant to show which contract you are delegating to and what it can do, in plain language rather than raw hex.

Can transaction simulation be trusted to catch EIP-7702 scams?

Simulation helps but is not foolproof. A 2026 arXiv study showed that attackers can build state-dependent contracts that make a wallet preview look benign while the real execution steals funds, and that most simulating wallets were fooled. Treat simulation as one layer alongside clear signing and hardware verification, not as a guarantee.

By Marcus Okafor, HOGE Wire wallets and security desk.