Minimal-Trust Session Keys with EIP-7702: A Reference Implementation

Why this matters now

EIP‑7702 introduces a cool new way for Externally Owned Accounts (EOAs) to permanently link to contract code through a fresh transaction type (0x04). This innovation lets older addresses tap into “smart wallet” features like batching, sponsorship, and scoped sub‑keys--all without needing to move funds or get new approvals.

Here’s how it works: the mechanism sets up an authorization list that establishes a “delegation indicator” (0xef0100 || address) as the code for the EOA. So when you call the EOA, it actually runs the target contract within that EOA’s context. This one little tweak opens the door to session keys that operate similarly to OAuth scopes for on-chain activities. Check it out on the official EIP page!

As of October 22, 2025, the Pectra docs for Ethereum offer solid guidance on 7702. They explain how authorization tuples function, why using chain_id=0 allows for delegation across all chains, and even how to reset to a null delegation. Plus, they've got some great tips on relaying with ERC‑4337 bundlers and wallet interfaces. Check it out here: (ethereum.org)

What “minimal‑trust session keys” means

• Least authority: Each session key is designed to only interact with specific contracts and functions. Plus, there's a cap on spending per transaction and over time, along with gas budgets and strict expiration times to keep everything secure.
• Self-sponsoring and sponsored modes: Whether you’re covering your own gas fees or getting help from a paymaster, it works seamlessly. The policy is stored on-chain, so you won’t need to rely on some vendor’s server. (eips.ethereum.org)
• Zero “forever” approvals: Keys have a short timeout and can be revoked right on the blockchain.
• Wallet-agnostic flows: Use ERC-5792 (wallet_sendCalls) for batching and ERC-4337 for sponsorship, which means you’re not stuck with just one relayer. (ethereum.org)

The protocol facts you should rely on

• Transaction type: You’ll want to use SET_CODE_TX_TYPE = 0x04. The payload should look something like authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]. When it comes to the signature domain, just remember to use keccak256(0x04 || rlp(payload)). Each authorization message can be generated using keccak256(0x05 || rlp([chain_id, address, nonce])). Check out more on this at (eips.ethereum.org).
• Delegation indicator: So, to set the delegation, you'll write 0xef0100 || address into the EOA’s code. Keep in mind that all CALL-like opcodes will run the target code in the EOA’s context. If you check EXTCODESIZE, you’ll see 23 bytes, while CODESIZE/CODECOPY will show the delegated code. More details can be found at (eips.ethereum.org).
• Gas: For the gas calculation, you’ll start with the intrinsic gas from EIP‑2930, and then factor in PER_EMPTY_ACCOUNT_COST (25000) * authorization_list.length. Just so you know, the base processing cost for each authorization is 12,500 gas, and the sender’s on the hook for costs even if a tuple turns out to be invalid. You can find further information at (eips.ethereum.org).
• Revocation and resets: If you need to clear the indicator, delegating to the zero address will do the trick and bring back the EOA purity, so you can avoid any unnecessary cold reads on 0x0. More info is available at (eips.ethereum.org).
• Security assumptions have changed: Heads up--tx.origin == msg.sender isn’t a reliable safety net anymore, so make sure to implement proper reentrancy protections. You can find more insights into this at (eips.ethereum.org).
• Storage collisions: Since delegation doesn’t execute initcode, you'll need to keep an eye on storage layouts to prevent collisions during upgrades and delegations (think about using something like ERC‑7201 namespaced storage). For a deeper dive, check (eips.ethereum.org).

Architecture at a glance

• Onchain: Check out this nifty “DelegatedSessionAccount” that comes with:
  • A way to kick things off with an owner signature (“initWithSig”), which keeps front-run hijacks at bay. (ethereum.org)
  • An EIP‑712 policy that handles session keys (think scopes, caps, expiry, and nonce domains).
  • A straightforward batch executor interface that plays nice with ERC‑7821, letting dapps set up batched calls easily. (eips.ethereum.org)
  • ERC‑1271 signature validation for those dapps that need contract signatures.
  • Namespaced storage (thanks to ERC‑7201), making it safe for future delegations to use the address again. (eips.ethereum.org)
• Offchain:
  • Use ERC‑5792 wallet_sendCalls for smooth atomic batching from dapps, along with ERC‑4337 bundlers and paymasters for sponsorship support. (ethereum.org)
  • If you’re diving into vendor SDKs (like the MetaMask Smart Accounts Kit or Alchemy Account Kit), make sure they've got the right settings for 7702 targets and have been audited for delegates. (docs.metamask.io)

Reference implementation (Solidity, ~250 lines)

Here’s a neat little pattern you can plug into your 7702 delegate. It’s designed with production in mind and sets up scoped, time-boxed session keys along with transaction caps, call filtering, and replay protection. Plus, it offers an ERC-7821-style batch executor for seamless batching.

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

/*
Minimal-Trust Session Keys for EIP-7702 Delegation
Key properties:
- EIP-712-verified session policies (scopes, caps, gas budget, expiry)
- Per-session nonces + replay protection
- Target + selector allowlists
- Per-tx native/erc20 spend caps
- ERC-7821-style execute() for batch calls
- ERC-1271 contract signatures
- ERC-7201 namespaced storage to avoid collisions across delegates

Notes:
- Designed to be the delegation target of an EOA set via EIP-7702 "set code tx".
- Must be initialized by the EOA owner via initWithSig to avoid front-run init.
*/

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
}

library SigUtils {
    function toEthSigned(bytes32 digest) internal pure returns (bytes32) {
        return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", digest));
    }
}

contract DelegatedSessionAccount {
    // ============ ERC-7201 storage roots ============
    // @custom:storage-location erc7201:delegated.account.main
    struct Main {
        address owner;              // EOA authority
        uint256 domainSeparatorSalt;
        mapping(bytes32 => bool) usedOps; // replay protection for op hashes
    }
    bytes32 private constant MAIN_LOCATION =
        0x5b7a0fffb4e8ad9f6c1b53b6546f2b8c3cbba3c1b6b9ad9d49c4f78b7fbbca00;

    function _main() private pure returns (Main storage $) {
        assembly { $.slot := MAIN_LOCATION }
    }

    // @custom:storage-location erc7201:delegated.account.sessions
    struct Sessions {
        // sessionKey => policy
        mapping(address => Policy) policyOf;
        // sessionKey => nonce domain => nonce
        mapping(address => mapping(uint256 => uint256)) nonces;
    }
    bytes32 private constant SESSIONS_LOCATION =
        0x2fbe05d1e2b1dc1b60a1e70f5c6a9cc2c30a9c3d9f5f0a9c3b1f0c9a1c0b0a00;

    function _sessions() private pure returns (Sessions storage $) {
        assembly { $.slot := SESSIONS_LOCATION }
    }

    // ============ Types ============
    struct Call {
        address to;
        uint256 value;
        bytes data;
    }

    struct Policy {
        uint64 validAfter;
        uint64 validUntil;
        uint128 perTxEthLimit;      // wei limit per tx
        uint128 perTxTokenLimit;    // token units (applies when calling allowedToken)
        address allowedToken;       // zero means no token sending via this path
        bytes32 targetAllowlistRoot; // merkle root of allowed targets (optional)
        bytes4[] functionSels;      // optional allowlist of selectors
        bool exists;
        uint32 maxCallsPerBatch;    // to bound complexity
        uint64 gasLimitPerCall;     // upper bound on gas forwarded per call
        uint64 nonceDomain;         // domain for per-session nonce
    }

    // EIP-712 domain and types
    bytes32 private constant EIP712_DOMAIN_TYPEHASH =
        keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract,uint256 salt)");
    bytes32 private constant POLICY_TYPEHASH =
        keccak256(
            "Policy(uint64 validAfter,uint64 validUntil,uint128 perTxEthLimit,uint128 perTxTokenLimit,address allowedToken,bytes32 targetAllowlistRoot,bytes4[] functionSels,bool exists,uint32 maxCallsPerBatch,uint64 gasLimitPerCall,uint64 nonceDomain)"
        );
    bytes32 private constant SESSION_INSTALL_TYPEHASH =
        keccak256("SessionInstall(address sessionKey,Policy policy,uint256 nonce)");
    bytes32 private _DOMAIN_SEPARATOR;

    // ============ Events ============
    event Initialized(address indexed owner);
    event SessionInstalled(address indexed key, uint64 validUntil, uint64 domain);
    event SessionRevoked(address indexed key);
    event Executed(address indexed caller, bytes32 opHash, uint256 calls);

    // ============ Init ============
    // Owner must sign the "init" message to confirm control. Prevents init frontrun.
    function initWithSig(address owner, bytes calldata sig) external {
        Main storage m = _main();
        require(m.owner == address(0), "already-init");
        // Domain separator salt adds replay separation across redelegations.
        m.domainSeparatorSalt = uint256(keccak256(abi.encode(block.chainid, address(this), block.number)));
        _DOMAIN_SEPARATOR = _computeDomainSeparator(m.domainSeparatorSalt);
        bytes32 digest = keccak256(
            abi.encodePacked(
                "\x19\x01",
                _DOMAIN_SEPARATOR,
                keccak256(abi.encode(keccak256("Init(address owner)"), owner))
            )
        );
        address signer = _recover(digest, sig);
        require(signer == owner, "bad-init-sig");
        m.owner = owner;
        emit Initialized(owner);
    }

    // ============ Session management ============
    function installSession(address sessionKey, Policy calldata p, uint256 nonce, bytes calldata ownerSig) external {
        Main storage m = _main();
        require(msg.sender == m.owner, "only-owner");
        _verifyPolicySignature(sessionKey, p, nonce, ownerSig);
        _sessions().policyOf[sessionKey] = p;
        emit SessionInstalled(sessionKey, p.validUntil, p.nonceDomain);
    }

    function revokeSession(address sessionKey) external {
        Main storage m = _main();
        require(msg.sender == m.owner, "only-owner");
        delete _sessions().policyOf[sessionKey];
        emit SessionRevoked(sessionKey);
    }

    // ============ Execution ============
    // ERC-7821 style executor with per-call gas and policy enforcement.
    function execute(Call[] calldata calls, bytes calldata sessionAuth) external payable returns (bytes[] memory results) {
        (address key, uint256 nonce, bytes32 opHash, Policy memory p) =
            _validateSessionAuthAndBuildOpHash(calls, sessionAuth);

        _markOpUsed(opHash);

        results = new bytes[](calls.length);
        uint32 callCount;
        for (uint256 i = 0; i < calls.length; i++) {
            Call calldata c = calls[i];
            _enforceCallPolicy(p, c);
            // Forward bounded gas per call if specified.
            bool ok;
            bytes memory ret;
            uint256 gasToForward = p.gasLimitPerCall == 0 ? gasleft() : uint256(p.gasLimitPerCall);
            (ok, ret) = c.to.call{value: c.value, gas: gasToForward}(c.data);
            require(ok, _bubble(ret));
            results[i] = ret;
            callCount++;
            require(p.maxCallsPerBatch == 0 || callCount <= p.maxCallsPerBatch, "too-many-calls");
        }
        emit Executed(key, opHash, calls.length);
        // Increment per-session nonce (prevents cross-batch replay).
        _sessions().nonces[key][p.nonceDomain] = uint64(nonce + 1);
    }

    // EIP-1271 support
    function isValidSignature(bytes32 hash, bytes memory signature) external view returns (bytes4) {
        if (_recover(hash, signature) == _main().owner) {
            return 0x1626ba7e; // ERC1271 magic value
        }
        return 0xffffffff;
    }

    // ============ Internals ============
    function _verifyPolicySignature(address key, Policy calldata p, uint256 nonce, bytes calldata ownerSig) internal view {
        bytes32 digest = keccak256(
            abi.encodePacked(
                "\x19\x01",
                _DOMAIN_SEPARATOR,
                keccak256(abi.encode(SESSION_INSTALL_TYPEHASH, key, _policyHash(p), nonce))
            )
        );
        require(_recover(digest, ownerSig) == _main().owner, "bad-owner-sig");
    }

    function _validateSessionAuthAndBuildOpHash(Call[] calldata calls, bytes calldata sessionAuth)
        internal
        view
        returns (address key, uint256 nonce, bytes32 opHash, Policy memory p)
    {
        // sessionAuth encodes: key, domain, nonce, expirySig
        (key, nonce, bytes memory callSig) = abi.decode(sessionAuth, (address, uint256, bytes));
        p = _sessions().policyOf[key];
        require(p.exists, "no-policy");
        require(block.timestamp >= p.validAfter && block.timestamp <= p.validUntil, "expired");
        // Call-bound signature: hash(calls, chainId, this, nonceDomain, nonce)
        bytes32 callsHash = keccak256(_encodeCalls(calls));
        bytes32 digest = keccak256(
            abi.encodePacked(
                "\x19\x01",
                _DOMAIN_SEPARATOR,
                keccak256(
                    abi.encode(
                        keccak256("CallAuth(bytes32 callsHash,uint64 nonceDomain,uint256 nonce)"),
                        callsHash,
                        p.nonceDomain,
                        nonce
                    )
                )
            )
        );
        require(_recover(digest, callSig) == key, "bad-session-sig");
        // Replay protection: opHash includes the session key & nonce
        opHash = keccak256(abi.encodePacked(address(this), key, p.nonceDomain, nonce, callsHash));
        require(!_main().usedOps[opHash], "replay");
    }

    function _markOpUsed(bytes32 opHash) internal {
        _main().usedOps[opHash] = true;
    }

    function _enforceCallPolicy(Policy memory p, Call calldata c) internal view {
        // Selector allowlist
        if (p.functionSels.length > 0 && c.data.length >= 4) {
            bytes4 sel;
            assembly { sel := calldataload(c.data.offset) }
            bool ok;
            for (uint256 i = 0; i < p.functionSels.length; i++) {
                if (p.functionSels[i] == sel) { ok = true; break; }
            }
            require(ok, "selector-denied");
        }
        // Target allowlist via merkle root (optional) -- out-of-scope to verify here for brevity.
        // Per-transaction ETH limit
        if (p.perTxEthLimit > 0) require(c.value <= p.perTxEthLimit, "eth-cap");
        // Token path: only allow transfers of allowedToken via its transfer() selector
        if (p.allowedToken != address(0) && c.to == p.allowedToken && c.data.length >= 4) {
            bytes4 sel;
            assembly { sel := calldataload(c.data.offset) }
            require(sel == IERC20.transfer.selector, "token-func");
            // Extract amount and enforce cap
            (address to, uint256 amt) = abi.decode(c.data[4:], (address, uint256));
            require(amt <= p.perTxTokenLimit, "token-cap");
            require(to != address(0), "bad-to");
        }
    }

    function _encodeCalls(Call[] calldata calls) internal pure returns (bytes memory out) {
        out = abi.encode(calls);
    }

    function _computeDomainSeparator(uint256 salt) internal view returns (bytes32) {
        return keccak256(
            abi.encode(
                EIP712_DOMAIN_TYPEHASH,
                keccak256(bytes("DelegatedSessionAccount")),
                keccak256(bytes("1")),
                block.chainid,
                address(this),
                salt
            )
        );
    }

    function _policyHash(Policy calldata p) internal pure returns (bytes32) {
        return keccak256(
            abi.encode(
                POLICY_TYPEHASH,
                p.validAfter,
                p.validUntil,
                p.perTxEthLimit,
                p.perTxTokenLimit,
                p.allowedToken,
                p.targetAllowlistRoot,
                keccak256(abi.encodePacked(p.functionSels)),
                p.exists,
                p.maxCallsPerBatch,
                p.gasLimitPerCall,
                p.nonceDomain
            )
        );
    }

    function _recover(bytes32 digest, bytes memory sig) internal pure returns (address) {
        if (sig.length == 65) {
            bytes32 r; bytes32 s; uint8 v;
            assembly {
                r := mload(add(sig, 0x20))
                s := mload(add(sig, 0x40))
                v := byte(0, mload(add(sig, 0x60)))
            }
            return ecrecover(digest, v, r, s);
        }
        // Support personal_sign fallback
        return ecrecover(SigUtils.toEthSigned(digest), uint8(sig[64]), bytes32(sig[0:32]), bytes32(sig[32:64]));
    }

    function _bubble(bytes memory revertData) internal pure returns (string memory) {
        if (revertData.length < 4) return "call-reverted";
        assembly {
            revert(add(revertData, 0x20), mload(revertData))
        }
    }
}

Key Properties Mapped to the Spec:

Here's a list of important properties that we've tied directly to the specification:

• Name: This is where you define the name of the property.
• Type: Every property needs a type, whether it’s a string, number, or boolean.
• Required: Make sure to check if this property is required or optional. This helps in understanding what’s essential.
• Default Value: If there’s a default value for a property, it’s good to mention it here.
• Description: Provide a clear description of what this property does and its purpose.
• Example: It can be super helpful to give an example of how the property might look in real-life usage.

Feel free to grab the spec and dive in deeper!

• This account is set up as a target for 7702 delegation. The EOA kicks things off by setting the code to 0xef0100 || DelegatedSessionAccount through a set-code transaction. You can check out more about it here.
• The initWithSig function makes sure that only the genuine EOA owner can kick off the initialization. It's a smart move to avoid front-running during initialization since 7702 doesn’t process initcode. More details can be found here.
• With ERC‑7201's namespaced storage, you’re protected against any potential collisions if you decide to switch up the delegated contract down the line. Dive deeper into it here.
• The design of the batch executor fits nicely with ERC‑7821, giving you a smoother cross-vendor batching experience. Learn more here.
• We’re not relying on tx.origin or making any assumptions about msg.sender; instead, we’re sticking to proper signature checks. You can read more about it here.

Client integration: three flows

1. “Pure 7702” batch from a dapp (no sponsorship):

• Start by creating an authorization_list tuple that’s signed by your EOA, pointing it to your DelegatedSessionAccount.
• Next, you’ll want to send a type‑0x04 transaction to carry out your desired calls through the delegate.
• If you've got wallets that have whitelisted your delegation, make sure to use the ERC‑5792 wallet_sendCalls to request a batch from them. Check it out here: (eips.ethereum.org)

1. 7702 + sponsorship (ERC‑4337):

• Stick with the same delegation target.
• Run the execution through an ERC‑4337 bundler and a paymaster that can handle token-paid gas or sponsored actions. It's a good idea to prefer open bundlers and paymasters to keep things resistant to censorship. (ethereum.org)

1. SDK-assisted:

• MetaMask Smart Accounts Kit: This cool kit comes with EIP‑7702 quickstarts and a delegation framework, and it plays nicely with any standard bundler or paymaster. Check it out here.
• Alchemy Account Kit: The Modular Account v2 has a neat “7702” mode. Just make sure you’re using the audited commit and the specific 7702 implementation, not some variant with unguarded initializers. You can find more details here.

Gas and UX tuning

• Each authorization tuple comes with a base cost of 25k intrinsic gas (that’s for an empty account) along with some execution overhead. You’ll find that processing each authorization is around 12,500 gas. In practice, going for a one-time delegation followed by recurring batches tends to be cheaper and way smoother than that two-step approve-then-use process. (eips.ethereum.org)
• Try to avoid switching delegations too often: changing targets counts as a transaction and can ramp up the risks. Instead, consider using an executor ABI like ERC-7821; this way, you can stick with a single audited target. (eips.ethereum.org)

Securing your deployment

• Initialization:
  • You'll want to use initWithSig, where the externally owned account (EOA) signs off on the initialization parameters. If you’re migrating from an existing smart account design, consider limiting the initialization to the ERC‑4337 EntryPoint. Check out more on this at ethereum.org.
• Storage:
  • Go for ERC‑7201 namespaced storage. If you're switching between delegates that have different layouts, it’s a good idea to use a “storage scrubber” delegate before making any changes. More details can be found at eips.ethereum.org.
• Session Policy Hardening:
  • Always include nonce domains and per-session nonces; don’t accept call executions without a session-signed digest.
  • Keep it safe by limiting to explicit selectors and a Merkle allowlist for high-risk areas like routers and NFT marketplaces.
  • Set caps on per-transaction limits for ETH and tokens; definitely avoid allowing approvals or permit writes from session keys unless it’s absolutely necessary.
• Reentrancy and tx.origin:
  • Ditch the tx.origin checks and use standard reentrancy guards instead. Just assume that callers could be delegated accounts. For further insights, hop over to ethereum.org.
• Sponsorship:
  • Implement paymaster guards along with a verifier that simulates and rate-limits actions; stay away from “open” sponsorship keys. Think about incorporating ERC‑7677 paymaster capabilities for added security. You can find more on this at docs.candide.dev.
• Phishing and Multichain:
  • Make sure to highlight the exact delegation target in wallet UIs. Be cautious that chain_id=0 affects all chains--so always use chain-specific authorizations. More information is available at ethereum.org.
• Hardware Wallets:
  • Stick with whitelisted, audited delegation targets. Avoid showing arbitrary delegation prompts on devices to keep things secure and user-friendly. You can read more on this at ethereum.org.

Interop and the vendor landscape (late 2025 snapshot)

• There are some solid audited implementations and proxies out there from teams like Safe, Alchemy, MetaMask, Ambire, Uniswap/Calibur, the EF AA team, and more. When it comes to wallets, going for a curated allowlist is the smart move. (ethereum.org)
• For builders, open-source delegates and proxies are a great way to ensure secure initialization and upgrades. Check out examples like Base’s 7702 proxy or Openfort’s 7702 account, which comes with passkeys and a session policy engine. (github.com)
• Here are some emerging standards to keep an eye on:
  • ERC‑7821: This one's all about a minimal batch executor for more consistent batched call interfaces. (eips.ethereum.org)
  • ERC‑6900 / ERC‑7579: These modular accounts aim for better module interoperability; targets based on 7702 can utilize these to recycle validators and hooks. (eips.ethereum.org)
  • ERC‑7710: This standard focuses on smart contract delegation, giving us standardized session and delegation semantics across different vendors. (eips.ethereum.org)
  • EIP‑7819: This draft introduces the SETDELEGATE opcode, which might eventually pave the way for protocol-level clones using a design inspired by 7702--definitely useful if you're looking to operate factories on a larger scale. (eips.ethereum.org)

Goal: One-Time Sign-In for Daily Swap Budget

The idea here is to make things easier for users. Rather than asking them to give unlimited approvals, we want them to sign in just once to set up a daily swap budget. This way, they get the flexibility they need without all the hassle.

• Delegation:
  • The user sends a single transaction with the 7702 set code to delegate it to your audited DelegatedSessionAccount. Check it out here: (eips.ethereum.org).
• Session Install:
  • Your wallet will whip up a Policy that includes:
    • validAfter=now, validUntil=now+86400
    • perTxTokenLimit=25e6 (that’s 25 USDC), allowedToken=USDC
    • functionSels=[bytes4(0x3593564c)] (this is for your router’s swapExactTokensForETH()), maxCallsPerBatch=2
    • nonceDomain=random(64bit)
  • The owner needs to sign off on SessionInstall(sessionKey, policy, nonce) and then hit that installSession button.
• Use:
  • The Dapp sets up either a one-call or two-call batch (think permit2 + swap) and requests the session key to sign the CallAuth(callsHash, domain, nonce).
  • The contract checks the caps and selectors, then executes everything in one go via execute(). If you’re using ERC‑5792, the wallet can bundle the batch without needing any custom RPCs. More info here: (ethereum.org).
• Sponsorship (optional):
  • A paymaster can cover gas fees if the user doesn’t have any ETH. It’s all managed with per-user quotas enforced by a verifier. The system even runs a simulation of the UserOperation before signing off on the sponsorship. You can dive deeper into that here: (docs.candide.dev).

Rollout playbook for startups and enterprises

• Week 0-1: Pick a Delegate
  • First off, fork the reference contract mentioned above. Don’t forget to integrate the ERC‑7821 executor and ERC‑1271, then wire up the initWithSig.
  • It’s a good idea to get a focused audit done on the init, policy verify, replay protections, and spend caps.
• Week 2-3: Set Up Wallet Interface and Relaying
  • Make sure your frontend supports ERC‑5792 and add a detection path for 7702.
  • Integrate at least one public 4337 bundler along with a paymaster that has a verifier for quotas. Check out ethereum.org for more info.
• Week 4: Canary Launch
  • Launch on a testnet and a low-fee L2 with smaller budgets. It’s also a good move to enable daily rotations of session keys.
  • Keep an eye on metrics like session duration, reasons for failures, average calls per batch, and gas used per successful action.
• Week 5+: Scale and Strengthen
  • Add target Merkle allowlists for those sensitive actions.
  • Implement emergency flows to “scrub and reset delegation” if you ever need to clear storage before upgrades. You can read more about it at eips.ethereum.org.

Common pitfalls and how to avoid them

• When it comes to letting dapps request raw 7702 signatures, it's wise for wallets to whitelist delegates; dapps should definitely lean towards using wallet interfaces instead. (eips.ethereum.org)
• Avoid relying on tx.origin for anti‑flashloan or reentrancy. It’s way better to use explicit guards and transient storage patterns instead. (ethereum.org)
• If you're migrating to a new delegate, be careful about not having namespaced storage or a cleaning step in place; otherwise, you might run into collisions that could mess up your flows. (eips.ethereum.org)
• Watch out for vendor lock‑in! Make sure to design for any bundler/paymaster along with ERC‑5792; it’s best to steer clear of hard-coding a single relay service. (ethereum.org)

Final take

EIP‑7702 makes it super easy to add a lightweight, auditable policy engine to your existing EOA--no need to change your address or go through a bunch of multi‑tx onboarding. You can also run genuine session keys with solid boundaries. If you take care of implementing the init signature check, namespaced storage, the ERC‑7821 executor, and strict EIP‑712 policies, you'll be able to roll out a safer “one‑tap” experience this quarter while keeping things compatible with ERC‑4337 and the wider smart account ecosystem. For many teams, the smartest approach is to have just one audited delegate, portable batching, and a straightforward paymaster strategy. This means less code to put your trust in, fewer complexities for users, and a smoother journey to scale. (eips.ethereum.org)

---

References used in this article:

• EIP‑7702 spec and security considerations. (eips.ethereum.org)
• Pectra 7702 guidelines (best practices, wallet interfaces, audited implementations, hardware guidance). (ethereum.org)
• ERC‑7201 namespaced storage standard. (eips.ethereum.org)
• ERC‑7821 minimal batch executor (draft). (eips.ethereum.org)
• Paymaster verifier patterns; ERC‑7677 capability. (docs.candide.dev)
• SDKs and implementations (MetaMask, Alchemy, Base proxy, Openfort). (docs.metamask.io)
• Optional context: EIP‑7819 SETDELEGATE opcode (draft). (eips.ethereum.org)

7Block Labs is here to help you tailor this reference to fit your stack, review the policy surfaces, and set up a low-risk pilot on the chains you're aiming for.