From EOAs to “Code‑Enabled” Accounts: Safer Patterns for EIP‑7702

Executive briefing

If you're looking to improve onboarding, offer sponsored gas, or implement top-notch controls without making users switch addresses, then EIP-7702 is something you'll want to check out. This update introduces a new Type-4 transaction that allows an EOA to set a “delegation indicator” that links to trusted smart-wallet code. After that, the account works like a programmable wallet until you decide to change the pointer. This feature opens up possibilities for batching, policy enforcement, paymasters, and session keys--all with just one on-chain step. You can dive deeper into the details here: (eips.ethereum.org).

What actually shipped (and what didn’t)

Pectra officially went live on the mainnet on May 7, 2025 (epoch 364032), and it brought along EIP‑7702. You can read more about it here.
So, what does EIP‑7702 actually cover? Here’s a quick rundown:
- It introduces a new transaction type under EIP‑2718: SET_CODE_TX_TYPE = 0x04. Check out the details here.
- There’s now an authorization list of tuples formatted as [chain_id, address, nonce, y_parity, r, s], which are all signed by the EOA using keccak(0x05 || rlp([chain_id, address, nonce])). More info can be found here.
- For each valid tuple, clients get to write a delegation indicator into the EOA’s code: 0xef0100 || address. This means calls to the EOA will execute code located at “address” in the context of the EOA. Again, you can read more about this here.
- Once you set the delegation, it sticks around until you change it. If you delegate to the zero address, it clears the code and reverts to a plain EOA. Just so you know, the earlier “temporary” drafts didn’t make the cut. Details can be found here.
Now, let’s talk about some key gas and accounting stuff you’ll notice once you’re in production:
- PER_AUTH_BASE_COST is set at 12,500 gas, and PER_EMPTY_ACCOUNT_COST is 25,000 gas. You’ll face the worst-case cost upfront but may get some refunds in certain situations. For specifics, check out this link.
- The 7702 authorization uses the signer’s “authority” nonce, which needs to match and then gets incremented. Just a heads-up: the nonce is limited to < 2^64. More details can be found here.
- During delegated execution, CODESIZE/CODECOPY will show the target code, but EXTCODESIZE/EXTCODECOPY on the authority will only read the 23-byte indicator. This quirk might catch your tooling off guard! More info is available here.
Just a heads-up: EIP‑3074 (AUTH/AUTHCALL) has been withdrawn and is not part of Pectra anymore. If you see it floating around in your decks, it’s time to update that info. Check out the details here.

Why this is a big deal for product and platform leaders

Zero-migration UX: Users don’t have to worry about losing their addresses and balances; you simply “upgrade” your features by connecting to audited wallet code. This pretty much takes away the biggest barrier to adopting smart accounts. (eips.ethereum.org)
Immediate synergy with ERC-4337: An Externally Owned Account (EOA) can easily delegate tasks to a wallet that works with ERC-4337, allowing everything to be bundled up, complete with paymaster sponsorship, and all that jazz, using the current infrastructure. (eips.ethereum.org)
Multi-chain reality: Ethereum mainnet is on board, and Gnosis Chain has had EIP-7702 in action since May 7. Plus, BNB Chain threw in an equivalent with its Pascal fork (BEP-441). This means businesses can streamline their processes across EVM-compatible chains. (docs.gnosischain.com)

The new execution model in one picture (well, text)

Before the call:
- The user sends out a Type-4 transaction that includes an authorization_list.
- The client checks the signatures and authority nonces, then updates each authority’s code with “0xef0100 || target,” all while bumping the nonce up by one. (eips.ethereum.org)
During calls to the delegated EOA:
- When you use CALL/CALLCODE/DELEGATECALL/STATICCALL, it loads the target code and runs it within the EOA’s context; keep in mind that most code-reading opcodes don’t exactly follow the pointer. (eips.ethereum.org)
After:
- The delegation hangs around until you specifically reset it to 0x00…00 with another Type-4 transaction. From this point on, the tooling should recognize the EOA as “code-enabled.” (eips.ethereum.org)

Practical Implication: The rule “msg.sender == tx.origin only in the top frame” isn't a solid guarantee anymore, especially with self-sponsoring flows coming into play. If your contract depends on tx.origin for flash-loan protection, it’s time to refactor. (eips.ethereum.org)

Security model changes you should plan for

The private key is still the boss. Even if you've delegated it, the EOA key can switch things up anytime it wants. So, your risk strategy needs to cover both the key and the delegated code. Check out the details here: (docs.safe.global).
Let’s talk about mempool behavior: once an EOA is delegated, any call made can either move ETH or bump nonces. Client teams suggest keeping a close eye on pending transactions per delegated EOA to minimize invalidation issues. And hey, wallets and relayers should steer clear of the old mempool assumptions from the EOA age. More info can be found here: (eips.ethereum.org).
The phishing game has changed: ever since the Pectra update, we’ve seen “upgrade to 7702” scams and mass-delegation sweepers popping up. Treat any authorization prompt off your wallet regarding 7702 with suspicion, and always double-check those target code hashes. Be cautious! Here’s a deeper dive: (cryptopolitan.com).

1) Delegate only to audited, registry‑pinned implementations

Establish a “code registry” (an on-chain allowlist linking code hashes to implementation details) and make it a rule to not sign 7702 tuples that aren’t listed in this registry. You'll need to ensure:
- The bytecode is source-verified, the initializer is immutable, and there are no sneaky upgrade paths hiding away.
- A well-defined signature domain with built-in replay protection should be included right in the wallet's code.
Here are some good places to kick things off:
- Check out eth‑infinitism’s Simple7702Account (it’s compatible with 4337 and has been audited in the AA v0.8 line). You can find it here.
- Don’t miss Base’s EIP‑7702 Proxy (this one uses the ERC‑1967 pattern with explicit nonce tracking and state validation). More details are available here.
- Lastly, take a look at Safe’s experimental 7702 integrations (like SafeLite and the modified singleton). Just a heads up: treat these as experimental until all the audits wrap up. For more info, check out the documentation here.

What to Include in Your Policy:

Make sure to sign only the code hashes on the registry, not just the addresses.
As part of your incident response plan, rotate the delegation to 0x0 (which clears the code). You can check out more details on this here.

2) Enforce spending policy in the wallet code, not in the dApp

Defining a Minimum Policy Surface for Delegated Code

Before running any calls, it's crucial that the delegated code sticks to a minimal policy surface. This means there are certain rules and guidelines that need to be enforced. Here’s how we can outline this:

Access Control:
- Ensure that only authorized users or contracts can initiate calls.
- Utilize roles and permissions to restrict access where necessary.
Input Validation:
- Check all incoming data for correctness and consistency.
- Reject any inputs that don’t meet predefined criteria to avoid unexpected behavior.
Gas Limit Enforcement:
- Set a maximum gas limit for each transaction to prevent abuse and excessive resource consumption.
Error Handling:
- Implement comprehensive error handling to manage unexpected failures gracefully.
- Logs should be created for any errors encountered to facilitate debugging.
Audit and Logging:
- Maintain a detailed log of all transactions for auditing purposes.
- Ensure that logs are immutable and accessible for review.
State Integrity:
- Confirm that any state changes align with the contract’s logic and do not disrupt the system’s integrity.
Rate Limiting:
- Introduce rate limiting to prevent too many calls in a short period, which could lead to network congestion.

By having these policies in place, you can keep the delegated code in check and ensure a smoother, more secure execution of calls. This structured approach minimizes risks while optimizing performance.

Replay protection: Use monotonic nonces or check out EIP‑712 domain‑separated counters. (eips.ethereum.org)
Quotas: Set up daily spending caps for each token, limit per transaction values, and create cumulative budget windows.
Scoping: Allowlist certain target contracts and function selectors; you can also choose to restrict the ERC‑20 approve() to avoid those pesky non-zero unlimited approvals.
Time‑boxing: Implement validUntil/validAfter windows for sub-keys or sessions.
Gas pinning: Make sure the signed intent ties gas limits to prevent griefing through forced out-of-gas (OOG) situations. (eips.ethereum.org)

A Minimal Solidity Sketch for a 7702-Safe Executor:

Alright, let's dive into a neat little Solidity sketch that creates a 7702-safe executor. This should give you a solid foundation to work with!

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SafeExecutor {
    address public owner;

    modifier onlyOwner() {
        require(msg.sender == owner, "Not the contract owner!");
        _;
    }

    constructor() {
        owner = msg.sender;
    }

    function execute(address target, bytes calldata data) external onlyOwner {
        (bool success, ) = target.call(data);
        require(success, "Execution failed!");
    }
}

How It Works:

Ownership: The contract sets up a simple ownership model where only the contract owner can execute functions.
Execute Function: The execute function takes in the target address and the call data, then attempts to execute it. If that call fails for any reason, it reverts.

Important Notes:

This sketch is very basic. In a real-world scenario, you'd want to implement more security features and checks.
Be careful with the call method since it can introduce security risks if not handled properly.

Feel free to tweak this sketch to fit your needs! Happy coding!

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

// Minimal executor meant to be the EIP-7702 delegation target.
// Enforces: nonces, budgets, target/function allowlist, time windows.
contract PolicyExecutor {
    struct Intent {
        address target;
        uint256 value;
        bytes data;
        uint256 nonce;
        uint256 maxGas;
        uint48 validAfter;
        uint48 validUntil;
        uint256 dailyLimit; // per-token or ETH, simplified here
    }

    mapping(address => uint256) public nonces;              // per-authority
    mapping(address => uint256) public spentToday;          // reset logic omitted
    mapping(address => mapping(bytes4 => bool)) public ok;  // target+selector allowlist

    error NotAuthorized();
    error Expired();
    error LimitExceeded();
    error BadNonce();

    // EIP-1271-style validation for sub-keys or guardians can be added here.

    function execute(Intent calldata i) external {
        address authority = msg.sender; // executing in EOA context under 7702
        if (i.validAfter > block.timestamp || i.validUntil < block.timestamp) revert Expired();
        if (i.nonce != ++nonces[authority]) revert BadNonce();
        if (!ok[i.target][bytes4(i.data)]) revert NotAuthorized();
        if (i.value + spentToday[authority] > i.dailyLimit) revert LimitExceeded();

        (bool s, bytes memory r) = i.target.call{value: i.value, gas: i.maxGas}(i.data);
        if (!s) assembly { revert(add(r, 32), mload(r)) }
        spentToday[authority] += i.value;
    }
}

This moves the responsibility to the delegated code, which is where it truly belongs, instead of relying on those ad-hoc dApp prompts.

3) Ship with “session keys” for teams and devices

For Operations Teams (Treasury Payouts, Vendor Settlements)

When it comes to operations teams, like those handling treasury payouts and vendor settlements, it's a good idea to add some extra security with secondary signing keys that have limited permissions--let's call them “session keys.” Each session should be tied to:

User-specific identification: Make sure each session key is linked to a specific user to keep things personal and secure.
Activity type: Specify what kind of actions each session key can perform. This keeps things neat and organized.
Time-limited access: Set an expiration on these session keys. After a certain period, they should no longer work, adding an extra layer of protection.
Geolocation restrictions: If possible, restrict where the keys can be used. This adds another hurdle for any potential unauthorized access.
Revocation process: Have a clear method for revoking keys if something seems off. This way, you can quickly cut off access if needed.

By implementing these session keys, you’ll give your operations team the balance of flexibility and security they need to do their job effectively!

Certain contracts like USDC or those for payroll,
Value limits for specific time frames,
Expiration times,
Optional limits on rates.

Most 4337 wallets already have session keys or plugins in place. By linking your EOA to that code through 7702, you can enjoy the same user experience without the hassle of migrating addresses. Check out more details here!

4) Integrate paymasters deliberately

With 7702 -> 4337, you’ve got the option to sponsor gas or accept ERC‑20 fees. Here’s a quick guide to the best practices:

We've got split paymaster policies: there's the free tier that has allowlist flows and smaller quotas, and then there's the enterprise tier for KYC'd accounts with much higher limits.
Let users' intentions really stick by binding the token, max fee, and paymaster address together. This helps prevent any sneaky fee-bait-and-switch tactics.
When it comes to L2s and sidechains, double-check that we're on par with EIP-7702 and that the paymaster API is supported--lots of EVMs are now showing off their EIP-7702 support. (docs.gnosischain.com)

5) Wallet UX guardrails (must‑haves)

Just a heads up, only the wallet UI will show the 7702 authorization signing. The folks who put together the EIP strongly advise against letting dApps kick off these processes. (eips.ethereum.org)
You’ll see some eye-catching codehash and publisher badges, plus links to audits and source verification so you can dive deeper.
There's a handy “one-click emergency restore” feature that lets you wipe your delegation (setting it to 0x0) with a quick confirmation from your hardware wallet. (eips.ethereum.org)
You can also simulate what happens after delegation (just keep an eye on the differences between EXTCODESIZE and CODESIZE) and check out the exact downstream calls and balances. (eips.ethereum.org)

Emerging risks, with data

Mass-delegation “sweepers”: Market-maker Wintermute spotted a concerning trend they've labeled “CrimeEnjoyors.” This involves tens of thousands of delegations sent to the same sweeper bytecode, all aiming to drain future ETH deposits from compromised EOAs. While the losses were kept in check and many of these attempts didn’t bring any profit, it's definitely something to watch. Make sure your SOC is on its toes and keeping an eye out for known sweeper code hashes. (coindesk.com)
Phishing “upgrade” campaigns: Security firms are warning about new tactics where scammers entice users to authorize delegations to shady addresses. The rule of thumb here? Never sign those 7702 authorizations that come from suspicious links or pop-ups; always stick to your wallet’s native 7702 flow. It’s also a good idea to get your support teams up to speed on this! (cryptopolitan.com)

Concrete implementation paths (with real stacks)

Path A: “4337 Inside” for zero‑migration smart accounts

First off, point your EOA to a wallet that’s compatible with 4337 (like the Simple7702Account).
Right from the get-go, you’ll unlock some awesome features: batching, ERC‑20 gas, paymasters, and session keys, across all networks with 4337 infrastructure. Check it out here: (github.com).
So, who’s on board with this? A bunch of wallets rolled out support right on mainnet launch day; some even took it a step further by restricting hardware signing to audited delegates at first. You can read more about it here: (blog.ambire.com).

KPIs to Keep an Eye On:

Decline in failed “approve then swap” flows: We’re aiming for this to be almost non-existent thanks to atomic batching.
Percentage of first-session users without native ETH who successfully complete a transaction: This is through sponsorship, and we want to see those numbers rising!

Path B: Proxy façade for enterprise policy sprawl

Use a slim ERC‑1967 proxy that:
- Checks authority signatures for upgrades,
- Keeps track of nonces separately to avoid replay issues with delegates,
- Ensures that implementation state remains consistent (like making sure the guardian set is right). (github.com)
Switch up implementations behind a stable proxy address as your program changes (think new limits, new modules).

Path C: Safe‑style custody with a 7702‑compatible core

Check out the lighter version of Safe called SafeLite, perfect for teams who want multisig and policy features without the full-blown Safe storage setup. Just a heads up--consider this experimental until the audits are wrapped up. For more details, swing by the docs.safe.global.

Example: CFO‑friendly batched payouts with guardrails

Goal: Grant Your Finance Ops the Power to Handle Monthly Vendor Payouts Securely

You want your finance team to be able to process monthly vendor payouts straight from the corporate EOA, but you don’t want to leave the door wide open for unlimited risk. Here’s how to strike that balance and keep everything in check.

Delegate to the audited 4337 wallet code using a Type-4 transaction that's signed by your EOA’s hardware key. You can check it out here: (eips.ethereum.org).
Set up a session key with the following:
- Targets: Just the USDC token and your payouts contract.
- Caps: Limit of $100k per day and $1M per month; max for each recipient.
- Expiry: 30 days, but any executive key can revoke it if needed.
Use a paymaster to manage fees in USDC on L2.
Keep an eye on things:
- Get alerts if the delegation changes (like a codehash mismatch).
- Get notified if you're close to spending limits or if there are any target violations.

Outcomes to Expect

One-click batched payouts: Get your funds out with just a click!
No open token approvals: Say goodbye to those pesky open approvals.
Clear blast-radius if a session key leaks: You’ll know exactly what’s at risk if a session key gets compromised.

Operational gotchas to address before go‑live

Tooling: Make sure to update your explorers and indexers to figure out the difference between “contract vs EOA” using EXTCODESIZE. Just a heads up, delegated EOAs have a 23-byte indicator, and code-following is going to need some special care. (eips.ethereum.org)
Mempool policies: When it comes to relayers and wallet backends, it's smart to assume there's only one pending transaction per delegated EOA. This helps cut down on those annoying invalidations. (eips.ethereum.org)
Signing: The authorization digest for 7702 has a 0x05 “magic” prefix and isn’t set up for EIP‑712/191, so just double-check that your signers and HSMs can handle this. (eips.ethereum.org)
Cross‑chain: Make sure to confirm that 7702 is in sync across target EVMs (like Gnosis and BNB Chain BEP‑441). Keep in mind, differences in fee markets and calldata costs could really impact your batching economics. (docs.gnosischain.com)
Wallet posture: At first, it’s a good idea to limit delegation to a carefully curated list. Taking a page from Ledger’s book on whitelisting targets is a great model when rolling this out to hardware signers. (ledger.com)

FAQ for decision‑makers

Is this “temporary smart code per tx”? Nope! The EIP that's been shipped actually creates a permanent delegation pointer. You can reset it to zero whenever you feel like it. Those early drafts that suggested temporary code got tossed out. (eips.ethereum.org)
Can we still use 4337? Absolutely--and that’s the whole idea! EIP 7702 acts as a bridge, allowing EOAs to set up 4337 wallets with just one transaction. After that, you can work with the current bundlers and paymasters. (eips.ethereum.org)
Is this safe for retail? Yes, as long as you have the right wallet user experience and well-chosen delegates. Just make sure not to let sites ask for 7702 signatures. Keep an eye out for sweeper code hashes and make sure your support teams are trained on how to handle revocations. (cryptopolitan.com)

A 30‑day rollout plan (7Block Labs template)

Week 1

Choose the delegate implementation(s) you want to use and jot down the code hashes in an internal registry, complete with audit links. Set up a simulation that tracks the 7702 indicators. Check out the release details here: github.com.
Start drafting the wallet UX copy for 7702 signing, code hash badges, and the emergency reset feature.

Week 2

Launch a small pilot on an L2 using paymaster-backed flows. Make sure gate hardware signing is restricted to whitelisted code only. (ledger.com)
Set up alerts for: delegation changes, policy breach attempts, and code hash drift.

Week 3

Launch on mainnet using limited session keys for operations. Transition the “approve+swap” processes into atomic batches.

Week 4

Get the support team trained up; release the revocation runbook (“set delegation to 0x0”), and conduct a red-team exercise to simulate a phishing attempt. (eips.ethereum.org)

Closing thought

EIP‑7702 isn't here to replace smart accounts; it's all about speeding them up. It takes every Externally Owned Account (EOA) and makes it upgradeable to audited, policy-aware code with just a single transaction. For teams that combine 7702 with solid code registries, session-key policies, and user-friendly wallet experiences, the benefits are real--better conversion rates and fewer incidents--without making users switch their addresses. This is the sensible route to having safer, smarter accounts by 2026.

Sources and further reading

Check out the EIP‑7702 spec and rationale, which covers transaction type 0x04, a neat delegation indicator, plus some gas and security considerations. You can find it here: (eips.ethereum.org).
Exciting news from the Ethereum Foundation: they've announced that the Pectra mainnet will go live with activation set for May 7, 2025. More details are available on their blog: (blog.ethereum.org).
For a quick overview of EIP-7702 and the authorization tuple, head over to Ethereum.org: (ethereum.org).
There are some interesting updates regarding ERC‑4337 and 7702; check out the changes around the Simple7702Account and the API updates here: (github.com).
If you're looking into 7702 integrations and caveats, the Safe docs have you covered, although they're still in the experimental phase. Take a look: (docs.safe.global).
Base’s got a cool 7702 proxy pattern out, aimed at making secure upgrades easier. Check it out here: (github.com).
Curious about the Gnosis Chain status for 7702? You can also find out about BNB Chain BEP‑441 for 7702 parity over at their docs: (docs.gnosischain.com).
Lastly, there's some risk intel regarding the so-called “CrimeEnjoyors” mass-delegation sweepers and warnings about 7702 phishing schemes that you should definitely check out: (coindesk.com).

7Block Labs

At 7Block Labs, we specialize in helping businesses create, audit, and implement 7702-ready programmable accounts. If you're on the lookout for a custom code registry, an awesome wallet UX, and a paymaster strategy that fits your specific needs, we've got your back! We’d love to share our reference implementations with you and even set up a pilot to get things rolling.