EIP-7702 at the Exchange: When Deposit Addresses Run Code

For most of Ethereum’s history, an exchange could make one clean assumption about the addresses its users deposited from and paid out to: they were externally owned accounts, controlled by a private key and nothing more. An externally owned account (EOA) could hold tokens and sign transactions, but it could not run logic of its own. That single assumption shaped how deposit systems, sweeping engines, compliance screens, and withdrawal checks were built across the industry. In May 2025, a small Ethereum upgrade quietly retired it.

EIP-7702, shipped in the Pectra hard fork, lets an ordinary EOA point at a smart contract and temporarily behave like a smart account, without changing its address and without rotating its private key (eips.ethereum.org). For users, that unlocked transaction batching, gas sponsorship, session keys, and recovery features that previously meant migrating to a separate ERC-4337 wallet. For the exchanges and custodians on the other side of every deposit and payout, it created a subtler problem. Any address that arrives at the deposit edge can now carry code, and that code might be helpful, harmless, or hostile.

This piece is about that operational edge. Not the consumer pitch for smart accounts, which HOGE Wire has covered many times over, but the specific question a trading venue or custody desk now has to answer thousands of times a day: what happens when the address I am about to sweep, screen, or pay out is delegated to a contract, and how do I tell a legitimate upgrade from a drainer waiting for funds to land?

What EIP-7702 Actually Changed

Before Pectra, Ethereum had two kinds of accounts. EOAs were the wallets people actually used, controlled by a key, unable to run code. Contract accounts could run arbitrary logic but had no key of their own and could not initiate a transaction. Account abstraction spent years trying to give ordinary users the powers of the second kind without losing the simplicity of the first. ERC-4337 did it at the application layer, with a separate mempool of user operations, bundlers, and a singleton EntryPoint contract, but it required people to move their assets to a brand new smart-account address.

EIP-7702 took a different route. It added a new transaction type, 0x04, that lets an EOA attach a pointer to a contract’s code. After the transaction lands, the same address, with the same balance and the same private key, executes the logic of the contract it points at. Nothing moved. Nobody had to bridge, migrate, or re-fund a fresh account. That is why the upgrade spread so quickly: it met users exactly where their money already sat. It is also, as core developer Marius van der Wijden cautioned when the proposal was still fresh, a design that carries sharp corners. “It’s still a very early proposal, so we need to evaluate all the rough edges,” he told DL News.

Crucially, EIP-7702 does not replace ERC-4337; it complements it. Recent EntryPoint releases already understand 7702-delegated accounts, so a single EOA can carry a delegation and still be driven through the 4337 pipeline. For an exchange, the practical takeaway is blunt. The neat line between key-controlled wallets and code-controlled contracts, the line the entire back office was built around, no longer holds. A depositing address can be both at once.

The 23-Byte Flag: What a Delegation Looks Like On-Chain

The good news for anyone building screens is that a 7702 delegation is not hidden. When an address delegates, the network writes a compact marker into the account’s code field: the three-byte prefix 0xef0100 followed by the 20-byte address of the contract it points at, 23 bytes in total. Read the code at any address and, if those first bytes are 0xef0100, you are looking at a delegated EOA and you already know exactly which contract it borrows its behavior from.

That designator is only safe to rely on because of an older rule. EIP-3541 reserved the 0xef byte at the start of contract code, so no ordinary deployed contract can ever begin with it. A delegation marker therefore cannot be confused with real bytecode, which is what makes automated screening tractable at scale. The delegation itself is authorized by a signed tuple containing the chain id, the target contract, and a nonce, hashed with the magic byte 0x05. To undo a delegation, the owner signs a new authorization pointing at the zero address, which resets the account back to a plain EOA. One footgun matters for cross-chain venues: a delegation signed with a chain id of zero is valid on every chain, a convenience that doubles as a replay risk (OpenZeppelin).

Reading the designator in practice is cheap, which is what makes screening viable at all. A single node call returns the code stored at an address, and the first bytes settle the question at once: empty means a plain EOA, 0xef0100 means a delegation, anything else means a full contract. The engineering challenge is not the check itself but running it across thousands of addresses without a separate call for each, which is exactly the problem the deposit systems discussed later in this piece had to solve. The point to hold onto is that nothing about a delegation is secret; it is legible to anyone who bothers to look.

Why a Smart-Account EOA Is an Exchange Problem

To see why this lands on the operations team and not just on wallet vendors, it helps to recall how most centralized venues actually move money. A user is assigned a unique deposit address. Funds sent there are later swept, in batches, into consolidated hot and cold wallets, because keeping thousands of live balances scattered across per-user addresses is both risky and expensive. Withdrawals run the other way, out of the hot wallet to whatever address the user provides. Every step assumes the addresses on both ends are inert: they receive, they hold, they get swept, and they do nothing on their own.

EIP-7702 breaks that assumption at three points. A user’s own wallet may now be a delegated smart account, so the address depositing to the exchange behaves differently depending on which wallet software controls it. A withdrawal target supplied by a user might be delegated to a contract that executes the instant funds arrive, which changes what a payout actually does. And, most awkwardly, a per-user deposit address the exchange itself controls can be delegated, either by the exchange as a feature or by an attacker who has compromised the key, turning the venue’s own sweeping logic into a live question rather than a settled routine.

None of this is theoretical. The same primitive that lets a wallet batch an approval and a swap into one signature lets a malicious contract drain tokens the moment they land. For a venue that trades user funds around the clock, the difference between those two outcomes is a screen that reads 23 bytes correctly. This is the sort of self-custody plumbing that quietly underpins the rest of the on-chain economy, including the on-chain perpetual futures venues where users trade directly from their own accounts.

The Deposit-Address Sweeper Problem

The clearest public illustration of how this reshapes back-office engineering comes not from a big-name exchange, which rarely open-sources its treasury code, but from the Internet Computer’s ckETH minter, a custodial-style bridge that issues a wrapped token against real ETH deposits and uses exactly the per-address deposit-and-sweep model described above. Over 2026, its engineers merged a series of pull requests that read as a field guide to living with EIP-7702 at the deposit edge.

The first problem was simply seeing the delegations. To sweep safely, the system needs to know, per deposit address, whether that address is delegated and to which contract. Checking one address at a time with a code lookup would cost a separate consensus call for every address, which does not scale. The fix was a batched reader that copies the first 32 bytes of code from hundreds of addresses in a single call and returns one word each, classifying every address as undelegated, delegated to a known contract, or holding other code. It works precisely because EIP-3541 guarantees the 0xef prefix cannot appear in ordinary bytecode (dfinity/ic PR 11549).

The second problem was sweeping once you know. A later change let the minter sweep an address that is already delegated to its own sweeper contract without attaching a fresh authorization tuple, saving roughly 25,000 gas per address, and another let it re-delegate deposit addresses to a newly configured sweeper as the design evolved (dfinity/ic PR 11550). That is the benign face of the technology: a deposit system deliberately using delegation to make consolidation cheaper. The hostile face is the same mechanism pointed the wrong way. As payments router Relay warns operators, a malicious delegation means “the malicious contract can auto-drain tokens as soon as they arrive,” so a compromised deposit address does not wait to be swept; it empties itself first (Relay support).

Screening the Designator: A New Duty at the Deposit Edge

Once a desk accepts that any address can carry code, screening the 0xef0100 designator stops being optional and becomes a standing control. The pattern that has emerged is an allow-list. A venue reads the delegation on each relevant address, and if it points at a known, audited implementation used by a mainstream wallet, the address is treated as an ordinary smart account. If it points at an unknown contract, or at one previously flagged as a drainer, the address is quarantined for review before funds move. Curvegrid’s open delegation checker encodes the same logic for individuals, showing green for recognized implementations, a question mark for unknowns, and an orange warning for addresses tied to compromise (eip7702.app).

The check has to run in both directions. On deposits, it protects the exchange from crediting funds that a hostile delegation siphons back out. On withdrawals, it protects the user, because paying out to a freshly delegated address can hand tokens straight to an attacker’s contract. Curvegrid’s own operations guidance frames the mental model well: authorizing a delegation is “closer to installing software than approving a payment,” which is exactly why a payout screen that only checks balances and blocklists is no longer enough (Curvegrid).

The Custodian’s Answer: MPC Plus 7702

Institutional custodians reached the same conclusion from the other side of the desk. Fireblocks, which secures a large share of institutional transaction flow, published guidance early treating delegation as a first-class custody risk. “A single malicious delegation is all that is needed,” wrote Arik Galansky, its VP of Technology, arguing that firms should delegate only to fully audited contracts, prefer battle-tested implementations with a small footprint over feature-rich ones, and confine 7702 to accounts that hold limited value while keeping larger balances in wallets with no smart-contract risk at all (Fireblocks). That last point is the institutional version of hot, warm, and cold segregation: put the new powers where the money is smallest.

The deeper argument Fireblocks makes is that multi-party computation and EIP-7702 are complementary rather than competing. In a follow-up, Galansky described the relationship as mutualism: MPC removes the single point of failure by splitting a key across multiple parties and adds signing-quorum and transaction-policy privacy that on-chain contracts cannot offer, while 7702 gives those MPC accounts the on-chain conveniences of batching, gas sponsorship, and session keys. “MPC solves 7702 gaps and vice versa,” he wrote (Fireblocks). For a custody desk, that means the delegation is only ever installed behind a policy engine, and only ever points at code the desk has reviewed itself.

The obvious caveat is that audited is not the same as safe. An audit is a snapshot of a codebase at a moment in time, and 2026 offered blunt reminders that even reviewed contracts fail, as HOGE Wire documented in its account of how a hack drained a protocol that had been through the process (Zero Bugs Found). Delegating to an audited contract lowers the odds; it does not zero them.

Gasless Deposits: Paying Fees in USDC

Not every consequence of the upgrade is defensive. The same capability that worries security teams is also the most powerful onboarding lever exchanges have been handed in years. Because a 7702-delegated EOA can be driven through the account-abstraction pipeline, a paymaster can cover its gas, which means a user can transact without first buying the native token to pay fees.

Circle built its paymaster around exactly this. With Pectra live, an EOA can “temporarily assume the behavior of Smart Contract Accounts,” and Circle Paymaster can evaluate the resulting operations, confirm the sender holds enough USDC, and pay the gas on the user’s behalf, enabling what Circle calls USDC-first onboarding, where someone funds a new wallet with a stablecoin and transacts immediately (Circle). For an exchange, that closes one of the oldest gaps in the funnel: the new user who withdraws to self-custody, then cannot move their tokens because they have no ETH for gas. The economics still have to be paid by someone, and sponsored gas is a cost center, not magic, but it turns a dead end into a smooth first transaction.

The economics deserve a second look, because sponsored gas is a budget line, not a gift. A paymaster operator fronts the network fee and recovers it either from the user in a stablecoin, often with a small surcharge, or from the app that wants the frictionless onboarding. That creates operational questions of its own: a poorly metered sponsorship can be bled dry by bots submitting junk transactions, so desks that offer it wrap the paymaster in spend caps and rate limits. Handled well, gas sponsorship is the closest thing self-custody has to the invisible fees of a traditional brokerage, where the plumbing cost is absorbed and the customer simply sees the transaction go through.

How Much of This Is Real: Adoption in 2026

Adoption numbers for EIP-7702 need a health warning before they are useful. Dashboards report a headline count of cumulative authorizations, which as of mid-September 2026 sat just under 249 million per BundleBear, but that figure is badly inflated by automated sweeper bots that re-authorize the same throwaway addresses over and over (BundleBear). The honest gauge is the number of addresses currently delegated, which stood closer to 58.7 million, alongside more than 104 million set-code transactions. Those are still large numbers for a feature that did not exist eighteen months earlier, but they are an order of magnitude below the headline.

On the wallet side, adoption is broad. Ambire was first to ship 7702, and MetaMask made it the primary upgrade path for its smart-account features, with Rabby, Trust Wallet, and others following. On the venue side, wallet products from exchanges such as OKX and the trading platform WhiteBIT were among the early movers to recognize and support delegated accounts. The point for an operations team is that this is no longer a niche a desk can ignore until it matures. A meaningful and growing share of the addresses interacting with any large venue already carry, or can trivially install, a delegation. The macro backdrop has not hurt: ETH traded around 2,600 dollars in mid-September 2026, up from the low-2,000s earlier in the year, which tends to pull more retail activity, and more delegated wallets, onto the chain (CoinDesk).

There is also a quieter form of adoption that matters more to a desk than raw counts: default behavior. As mainstream wallets make delegation the standard way to unlock batching and gas features, a growing share of ordinary users become smart-account users without ever choosing to, simply by updating their app. That is good for user experience and awkward for any system that assumed a fixed account model. It means the population of delegated addresses is not a niche of power users a venue can gate or ignore; it is drifting toward the median customer, which is precisely why the screening and sweeping changes described here are becoming table stakes rather than optional hardening.

The Dark Side the Desk Has to Screen For

The reason screening is not paranoia is that the majority of early delegation activity was outright malicious. When researchers at trading firm Wintermute looked at the first wave of 7702 delegations, they found that more than 97 percent pointed at copies of the same reused sweeper bytecode, nicknamed CrimeEnjoyor, deployed to automatically empty any address whose key had leaked. Wintermute counted roughly 2.88 ETH spread across about 79,000 addresses, with a single contract handling over 52,000 of them, and noted that the campaign was not even profitable, because it was chasing wallets that were already drained or empty (CoinDesk). The important nuance is that this was never a flaw in EIP-7702; it was old-fashioned key theft wearing a new coat.

The costlier cases came from phishing that weaponized the batching feature. In one widely reported incident, a single victim lost 1.54 million dollars in one 7702 transaction after signing what looked like a routine interaction (Cryptopolitan). A peer-reviewed empirical study presented at the USENIX Security Symposium analyzed more than 3.6 million authorizations across seven chains, tied over 63 percent of them to malicious contracts, manually confirmed 924 distinct malicious implementations, and tallied around 2.36 million dollars in realized losses plus roughly 10.14 million dollars of ongoing exposure from legacy contracts (USENIX Security). The one piece of good news is directional: overall wallet-drainer losses fell about 83 percent to 83.85 million dollars in 2025 as the ecosystem hardened (Cointelegraph).

The Signing Screen Is Still the Weakest Link

Every EIP-7702 attack shares a root cause: someone signed something they did not understand. A delegation installs code and moves nothing at the instant of signing, so it can look harmless on a hardware wallet that only displays a hash. That is the same weakness behind the largest exchange hack on record, when signers approved what looked like a routine transfer while the payload quietly swapped a contract. Odysseus, founder of the security firm Phylax, drew the lesson bluntly afterward: “a hardware wallet is pointless if the transaction is signed on an internet-connected laptop or phone” (The Block). For a custody desk, blind signing is not a training problem; it is an architectural one.

The industry’s answer is clear signing, an effort to make wallets show, in plain language, what a transaction will actually do before it is approved. ERC-7730, a standard that began at Ledger and moved to Ethereum Foundation stewardship in 2026, defines machine-readable descriptors so a signing screen can translate an opaque payload, including a 7702 authorization, into a readable summary (eips.ethereum.org). Transaction simulation adds another layer by previewing the state changes a signature would cause. Neither is a guarantee, because a descriptor has to exist for the specific contract and simulations can be fooled by state-dependent code, but together they turn the signing moment from a leap of faith into something closer to an informed decision. For desks that move eight-figure sums, the signing environment, offline, verified, and clear-signed, is now as important as the vault behind it.

When a Delegation Goes Bad: Revocation Is Not a Cure

Support desks have learned a counterintuitive lesson that operations teams need to internalize: if a user discovers an unknown delegation on their wallet, revoking it is close to useless. Relay states the reasoning plainly. An unexpected delegation almost always means the key or seed phrase has already been compromised, so resetting the delegation to the zero address treats the symptom while the attacker still holds the key and can simply re-delegate. Relay’s guidance is to stop using the wallet entirely, move any recoverable assets to a fresh wallet with uncompromised keys, and abandon the old one, because “every case investigated has shown the wallet was already compromised before using Relay” (Relay support).

This matters for how a venue talks to affected customers. The instinctive support script, telling a user to revoke and continue, can send them straight back into the trap. The correct script routes them to a clean wallet. It also complicates automated recovery, because revocation support is inconsistent from wallet to wallet, and some interfaces can display a delegation without being able to clear it. Tools such as Curvegrid’s checker can show where an address is delegated across chains, but no checker can recover funds after a key compromise or guarantee that a given delegate is safe. Since the attack ultimately lives at the moment of signing rather than in the protocol, the same discipline that protects any key applies here, a theme HOGE Wire explored in its look at mobile crypto security. And because drained funds are often laundered across networks, the cross-chain angle connects directly to bridge security, where a chain-id-zero replay can turn one stolen signature into losses on several chains at once.

What the SEC Says About Self-Custody and Brokers

Delegation blurs a line US venues care about a great deal: the boundary between offering software and acting as a broker or custodian. A smart-account feature that batches, sponsors gas, or automates actions can look, to a nervous compliance officer, like the platform is doing more than passing along instructions. The current staff position at the Securities and Exchange Commission offers useful cover. In 2026, SEC staff indicated that software enabling transactions from a self-hosted wallet is not, by itself, treated as broker activity, a stance that helps wallet builders ship 7702 features without automatically inheriting broker-dealer obligations (CoinDesk).

That distinction cuts to the heart of self-custody. When a user controls their own key and their own delegation, the exchange that provided the interface is generally not the custodian of those assets, and there are no chargebacks: a payout to a hostile delegate is final. When the exchange holds the key, the opposite is true, and the delegation risk becomes the venue’s own liability to manage under its custody controls. Outside the United States, venues operating as licensed crypto-asset service providers face parallel screening and record-keeping duties under regimes such as the European Union’s MiCA framework, but for a US audience the practical rule is the SEC-shaped one: the further a feature moves toward controlling user assets, the heavier the regulatory weight it carries.

Compliance duties do not vanish with self-custody; they shift. A venue still has to apply sanctions screening and, where it qualifies, travel-rule recordkeeping to the counterparties it transacts with, and a delegated address muddies the picture of who or what actually controls the funds on the other side. If the delegate is a contract that forwards assets elsewhere the moment they arrive, the exchange’s record of paying out to a customer may not match where the value ends up. That gap is exactly why the designator check belongs in the compliance stack and not only the security one: knowing that an address runs code, and whose code, is now part of knowing your counterparty.

The Bridge That Stayed

EIP-7702 was pitched as a bridge, a stopgap until Ethereum built account abstraction directly into the protocol. Alex Jupiter, a senior product manager at MetaMask, described it as part of “one unified Account Abstraction roadmap” that would eventually converge (DL News). In 2026 that convergence stalled. The two leading native-abstraction efforts, one from the Ethereum side and one from Base, could not be reconciled and are now shipping as separate designs, a split HOGE Wire covered in Native AA Splits, the Bridge Stays. The upshot is that the temporary fix is becoming permanent infrastructure by default.

For exchanges and custodians, permanence is the operative word. The Fusaka upgrade that went live in December 2025 focused on data availability and layer-2 costs rather than accounts, and the next fork on the horizon is expected to reprice the gas that smart-account transactions consume rather than replace the 7702 model outright (CoinDesk). In other words, the 23-byte designator, the deposit-address screening, and the MPC-plus-delegation custody pattern are not stopgaps a desk can defer maintaining. They are the shape of the plumbing for the foreseeable future, and the sensible move is to treat them as standing systems rather than temporary patches.

For an operations team, the split has a mundane but real consequence: there will be more than one native-abstraction model to support, not a single standard that finally retires 7702. An address arriving from an Ethereum-aligned chain and one from a Base-aligned chain may express account logic differently, which pushes still more classification work onto the screening layer. In that world the humble 0xef0100 delegation is the common denominator, the one account upgrade that already works across chains and that every wallet and venue already understands. The pragmatic bet is that 7702 stays the interoperable baseline long after the native designs ship, because it is the thing they all have to remain compatible with.

The Bottom Line for Users and Desks

EIP-7702 did not so much add a feature as change what an Ethereum address is. The convenience is real, and so is the new attack surface, and both now sit at the exact point where users and exchanges meet. For anyone running that edge, or depositing across it, a short checklist captures the essentials.

1. Read the delegation. Check the code at any address you deposit from or pay out to; a 0xef0100 prefix means it is a delegated smart account, and you should know which contract it points at.
2. Delegate only to code you trust. Use audited, widely used implementations with a small footprint, and remember that audited still is not the same as safe.
3. Keep large balances plain. Confine delegations to accounts holding limited value and keep the bulk of assets in wallets with no smart-contract risk.
4. Screen at both edges. Run designator checks on deposits and on withdrawals, and quarantine unknown or flagged delegates before funds move.
5. Treat an unknown delegation as full compromise. Do not just revoke; move recoverable assets to a fresh wallet with new keys and abandon the old one.
6. Watch the chain id. Flag delegations authorized with a chain id of zero, which are replayable across chains.

The line between a key-controlled wallet and a code-controlled account is gone for good. The venues and users that thrive with EIP-7702 will be the ones that stop treating an address as an inert container and start treating every delegation as a piece of software they chose to install.

Frequently Asked Questions

How do I know if my Ethereum address has an EIP-7702 delegation?

Read the code stored at your address. If the first bytes are 0xef0100 followed by a 20-byte address, your account is delegated to that contract and behaves like a smart account. Free checkers such as eip7702.app let you look this up across multiple chains without any technical setup, and they flag whether the delegate is a recognized implementation or an unknown contract.

Can an exchange reject a deposit from a smart-account address?

Yes. A venue can read the delegation designator on any address and apply its own policy, which usually means quarantining deposits or withdrawals tied to unknown or previously flagged delegate contracts until a review clears them. Reputable delegations from mainstream wallets are typically treated as ordinary smart accounts, so most users will never notice the screen running.

Is it safe to deposit to an exchange from a smart-account wallet?

Depositing from a legitimate, audited smart-account wallet is generally fine, because the risk lives in which contract an address is delegated to, not in the fact of delegation itself. The danger is a hostile delegation installed after a key compromise, which can drain funds automatically. Keep large balances in wallets without smart-contract risk and verify your delegate before moving significant sums.

If my wallet has a malicious delegation, does revoking it fix the problem?

No. An unexpected delegation almost always means your private key or seed phrase is already compromised, so resetting the delegation does not stop an attacker who can simply install it again. The correct response is to move any recoverable assets to a new wallet with fresh keys and stop using the old one entirely, rather than relying on revocation as a fix.

Does supporting EIP-7702 make an exchange a broker or a custodian?

Not by itself. SEC staff indicated in 2026 that software enabling transactions from a self-hosted wallet is not treated as broker activity on its own, so offering smart-account features does not automatically create broker-dealer obligations. The regulatory weight rises as a platform moves toward actually controlling user keys and assets, which is where custody rules and liability begin to apply.

By Marcus Okafor, senior wallets and exchanges correspondent at HOGE Wire.