Session-Based Authentication on Ethereum: Delegation Patterns for EIP-7702

EIP-7702 made its debut with Ethereum’s Pectra mainnet upgrade on May 7, 2025. This feature allows any Externally Owned Account (EOA) to jump into smart-account capabilities by passing off its execution to contract code. In this post, we’ll explore practical delegation patterns that help create secure, wallet-managed “sessions.” These sessions cut down on annoying prompts, allow for sponsorship, and minimize risk--all while keeping user addresses right where they are. Check out the full details here.

Summary (1-2 sentences)

Pectra’s EIP-7702 transforms externally owned accounts (EOAs) into programmable wallets that follow specific policies by adding a delegation pointer to the account code. By using the right patterns, you can set up session keys that are time-limited and budget-specific, cover gas fees, and introduce passkey or multi-signature authentication--without changing the current addresses or infrastructure. Check it out here: (eips.ethereum.org)

---

Who should read this

• Product and engineering teams gearing up for wallet UX enhancements without moving users to new accounts.
• Platform crews diving into account abstraction (AA) roadmaps and compliance measures.
• Dapps on the lookout for fewer prompts, improved conversion rates, and more secure automation.

---

What EIP‑7702 actually changes (in practice)

EIP-7702 brings us a fresh transaction type, the 0x04 “set code” transaction. This one processes an authorization list of tuples and drops a delegation indicator--specifically, the bytes 0xef0100 followed by a 20-byte address--into the EOA’s code. After that, any external or internal calls made to that EOA will run the code located at the delegate address, but they'll do so in the context of the EOA’s storage and balance. Here are some key points about the spec: (eips.ethereum.org)

• Transaction type and constants:
  • SET_CODE_TX_TYPE = 0x04
  • PER_AUTH_BASE_COST = 12,500 gas
  • PER_EMPTY_ACCOUNT_COST = 25,000 gas (eips.ethereum.org)
• Auth tuple format: This is structured as [chain_id, address, nonce, y_parity, r, s] and is signed over keccak(MAGIC || rlp([chain_id, address, nonce])). Just a heads up, the chain_id can be 0 for cross‑chain authorization. If that’s not the case, it needs to match the current chain. (eips.ethereum.org)
• Nonce semantics: The nonce in the tuple has to match the authority's current nonce. After processing, the authority’s nonce gets bumped up by 1. If you have multiple tuples for the same authority, don’t worry--the last valid one takes precedence. (eips.ethereum.org)
• Gas: The intrinsic cost here follows EIP‑2930, plus you’ll incur PER_EMPTY_ACCOUNT_COST for each tuple. If the authority isn’t empty, you’ll get a refund of PER_EMPTY_ACCOUNT_COST minus PER_AUTH_BASE_COST, which means a regular existing EOA essentially ends up paying around 12.5k gas to (re)point delegation. (eips.ethereum.org)
• Execution: When it comes to CALL, CALLCODE, DELEGATECALL, and STATICCALL, they’ll all follow the delegation. Meanwhile, functions like EXTCODESIZE/EXTCODECOPY will read the 23‑byte indicator, while CODESIZE/CODECOPY will retrieve the delegate’s runtime code during delegated execution. This has an impact on code‑hash checks and certain anti‑MEV strategies. (eips.ethereum.org)
• Self‑sponsoring: Here’s a cool feature: tx.origin can set and use its own delegated code. This means users can take advantage of 7702 without needing any outside relayers. (eips.ethereum.org)

Pectra activation is set for mainnet epoch 364032 on May 7, 2025. Along with this, we’ll see 7,702 delivered, plus some other user experience and scaling EIPs. Check it out for more info: (blog.ethereum.org).

---

Why sessions now make sense for EOAs

Before Pectra came onto the scene, “session keys” were mainly found in ERC‑4337 smart wallets, which relied on plugins and modules. This setup meant you had to deploy a separate account. But with the introduction of 7702, it’s now possible for an EOA to easily link to established 4337 wallet code paths and tap into the same module ecosystems (like ERC‑7579) for handling permissions and passkeys--no need to shuffle assets or switch addresses around. Plus, wallets and bundlers are already rolling out 7702‑aware processes through EntryPoint v0.8 and a fresh eip7702Auth field. You can dive deeper into it here: (eips.ethereum.org).

Here’s today’s infra snapshot you can count on:

• The EntryPoint v0.8 deployments are now up and running at a stable address: 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108. Check it out on GitHub.
• Bundlers like Etherspot Skandha and Candide Voltaire are on board with 7702, meaning they handle authorizations as part of UserOperations through eip7702Auth. More details can be found at Etherspot.
• Modular session stacks (ERC‑7579) are powering Smart Sessions from Rhinestone/Biconomy, which come with handy reusable policies and validators. Dive deeper into the specs on Ethereum EIPs.

---

Delegation patterns for session-based authentication

Here are some patterns we're rolling out with our clients. Each pattern uses 7702 to "activate" smart logic for an EOA, and then we layer on modules and policies to grant time-limited, scope-restricted permissions.

Pattern A -- Wallet‑managed permanent delegation to a modular smart account

• What you do: You start by pointing your EOA to a solid, battle-tested 4337 account setup that plays nicely with ERC‑7579 modules (think validators, executors, and hooks). Next, you’ll want to install a “session manager” module that can issue and check scoped session keys. (eips.ethereum.org)
• When to use: This setup is perfect for high-trust wallets and comes with a wide range of features (like batched calls, sponsorship, and passkeys) that work seamlessly across a ton of dapps.
• Pros:
  • You get a one-time 7702 pointer, which costs around 12.5k gas on existing EOAs. (eips.ethereum.org)
  • It makes good use of EntryPoint v0.8 mempool and tools, meaning you won’t have to worry about any opcode changes. (eips.ethereum.org)
• Gotchas:
  • Be careful not to depend on EXTCODEHASH for figuring out wallet behavior--it only gives you the indicator hash, not the hash of the delegate code. So, when you’re designing feature detection, stick to interfaces or off-chain allowlists. (eips.ethereum.org)

Pattern B -- Time‑boxed session delegation to a “policy proxy” delegate

• What you do: You set up a lightweight PolicyDelegate contract that taps into the session state from the EOA’s storage (that’s your delegated execution context) and makes sure to enforce:
  • expiry (validUntil),
  • allowlists for specific functions or contracts,
  • caps on spending values and tokens,
  • and if you want, some optional rate limits.
    This delegate checks the session key signature (think EIP‑1271 style) and passes on the allowed calls.
• When to use: Perfect for app-specific sessions--like a trading interface for a day or a gaming session.
• Pros: It keeps things contained with a tight blast radius; audits are straightforward; and if you need to revoke permissions, just reset 7702 to the zero address. (eips.ethereum.org)
• Gotchas:
  • Keep in mind that chain_id: 0 authorizations can be replayed across chains; so for those app-specific sessions, make sure to bind it to the current chain. (eips.ethereum.org)

Pattern C -- Sponsored sessions via 4337 paymasters

• What you do: Keep the 7702 pointing to an account that's compatible with 4337. You'll need to issue session keys and route transactions using a bundler and a paymaster to cover gas fees in ERC-20 or by the app itself. Plus, make sure that bundlers are enforcing those ERC-7562 validation rules to steer clear of any DoS issues. Check it out here: (eips.ethereum.org).
• When to use: This is perfect for onboarding new users, running promotions, or enhancing that high-frequency user experience--especially when your users don't have any ETH on hand.
• Pros: You’ll be working with a mature infrastructure that provides you with detailed control over sponsorship.
• Gotchas:
  • Keep in mind that the bundler policy now limits how 7702 authorizations show up in UserOps. That means you can only have a single 7702 authorization per UserOp, the sender has to match, and the delegate must be consistent. So, make sure you’re on the same page with bundler expectations. More info here: (ercs.ethereum.org).

Pattern D -- Passkey‑first sessions (WebAuthn)

• What you do: You’ll want to use a passkey (P‑256) to sign UserOps or session tokens. The 7702-delegated account takes care of verifying that P‑256 in validateUserOp/1271. This setup lets you combine it with short-lived sessions for that “sign once, act many” vibe. If you’re curious about how it works, check out some example repos that show P‑256 and session key rotation in action. You can find them here.
• When to use: This is perfect for consumer apps where a smooth biometric experience and frequent credential rotation are key.
• Gotchas:
  • Just a heads up: Passkeys can’t be exported, so make sure you have a plan for multi-device enrollment and recovery. You can read more about it here.

Pattern E -- Delegation Manager workflows (emerging)

• What you do: You take session permissions and bundle them into neat little “delegations” that can be redeemed through an ERC‑7710 DelegationManager. This helps sync up wallet-managed permission requests (ERC‑7715) with on-chain redemption processes. Check it out here: (eips.ethereum.org).
• When to use: This is perfect for multi-app ecosystems that need a unified permission language across different wallets and services.

---

How to implement: from signature to session

1) Point an EOA to a 4337‑compatible account

• First up, you'll need to get the user to sign a 7702 authorization tuple. Make sure to set the address to your preferred smart account code. Once that's done, the client will write 0xef0100||address into the EOA’s code and bump up the EOA’s nonce. Just a heads up--the delegation will stick around until you clear it. (eips.ethereum.org)
• If you’re rolling with EntryPoint v0.8, your bundler can totally handle the 7702 tuple within UserOps.

Example: UserOperation with eip7702Auth (EntryPoint v0.8 bundlers)

In this example, we’re looking at how to use UserOperation with eip7702Auth in the context of EntryPoint v0.8 bundlers. Let’s break it down step by step.

What is UserOperation?

UserOperation is a structure designed to facilitate user actions in a decentralized environment. It's all about allowing users to perform operations securely and efficiently.

Setting Up eip7702Auth

To start using eip7702Auth, you'll need to set up your EntryPoint with the corresponding configuration. Here’s a sample of how you might structure your code:

UserOperation memory op = UserOperation({
    sender: senderAddress,
    nonce: nonce,
    initCode: initCode,
    callData: callData,
    callGasLimit: callGasLimit,
    verificationGasLimit: verificationGasLimit,
    preVerificationGas: preVerificationGas,
    maxFeePerGas: maxFeePerGas,
    maxPriorityFeePerGas: maxPriorityFeePerGas,
    paymasterAndData: paymasterAndData,
    signature: signature
});

Key Components of the UserOperation

Here’s a quick rundown of the main components you’ll find in UserOperation:

• sender: The address of the user initiating the operation.
• nonce: Ensures that each operation is unique.
• initCode: Any initialization code necessary for the operation.
• callData: The actual data for the function call.
• callGasLimit: The maximum gas limit for the call.
• verificationGasLimit: Gas limit for verification operations.
• preVerificationGas: Gas limit needed before the actual operation.
• maxFeePerGas: The highest gas fee the user is willing to pay.
• maxPriorityFeePerGas: The tip for miners to prioritize this operation.
• paymasterAndData: Information for the paymaster handling fees.
• signature: A cryptographic signature to verify the operation.

Conclusion

By using UserOperation with eip7702Auth, you can streamline user interactions and enhance security in your decentralized application. It’s all about making things smoother and safer for your users!

{
  "sender": "0xEoaAddress",
  "callData": "0x...",
  "maxFeePerGas": "0x...",
  "maxPriorityFeePerGas": "0x...",
  "signature": "0x...", 
  "eip7702Auth": {
    "chainId": "0x01",
    "address": "0xDelegateContract",
    "nonce": "0x000000000000000A",
    "yParity": "0x01",
    "r": "0x...",
    "s": "0x..."
  }
}

Bundlers like Voltaire (Candide) and Skandha (Etherspot) now support the eip7702Auth field with EntryPoint v0.8. You can check out more details here.

EntryPoint v0.8 address you’ll want to keep in mind: 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108 (works on mainnet and other supported networks). You can check it out on GitHub.

2) Install a session module (ERC‑7579)

• If you're working with a modular smart account as your delegate, it's a good idea to include a session manager (like Rhinestone or Biconomy's “SmartSession”) and set up your policies such as:
  • target contract/function selectors,
  • value and token budgets,
  • expirations and rate limits. Check it out on (github.com)!

3) Register a session key

• Generate a temporary key (like P‑256) and then register its public key along with the constraints in the module. The module will make sure these constraints are followed in the validateUserOp function or a similar dispatcher. (docs-devx.biconomy.io)

4) Execute batched flows with sponsorship (optional)

• Make sure to use paymasters and 4337 bundlers; also, ensure that you comply with ERC‑7562 validation. Don’t forget to stake for entities that keep state, like factories, paymasters, and aggregators, to steer clear of any mempool throttling or bans. (eips.ethereum.org)

---

Minimal PolicyDelegate example for “wallet‑local” sessions

Here's a simple delegate contract designed to hit that 7702 target. It covers a few important points:

• A single session key
• An expiry timestamp
• Allowlists for per-call targets and function selectors
• Limits on ETH and ERC-20 transactions

Notes:

• Storage refers to the EOA’s memory while it’s doing some delegated execution--so any reads or writes here will stick “in” the EOA. (eips.ethereum.org)
• When you’re in a production environment, it’s better to go with an ERC‑7579 module instead of a custom policy; also, make sure to include EIP‑712 typed session tokens and a full set of events.

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

interface IERC20 { function transferFrom(address a, address b, uint256 v) external returns (bool); }
interface IERC1271 { function isValidSignature(bytes32, bytes calldata) external view returns (bytes4); }

// Deployed once. 7702 points EOAs here. Storage is the EOA's storage under delegation.
contract SessionPolicyDelegate {
    // Session state in the EOA's storage
    address public sessionKey;        // EOA-scoped
    uint64  public validUntil;        // unix time
    uint96  public ethBudget;         // remaining wei
    mapping(address => uint256) public erc20Budget;   // token -> remaining
    mapping(address => mapping(bytes4 => bool)) public allowed; // target -> selector -> ok
    address public admin;             // EOA owner sets during init

    event SessionStarted(address key, uint64 until);
    event SessionCleared();
    event CallExecuted(address to, uint256 value, bytes4 sel);
    event BudgetUsed(address asset, uint256 amount);

    modifier onlyAdmin() {
        require(msg.sender == admin, "not admin");
        _;
    }

    function init(address _admin) external {
        require(admin == address(0), "inited");
        admin = _admin;
    }

    // Register/refresh a session
    function startSession(
        address key,
        uint64  until,
        uint96  maxEth,
        address[] calldata tokens,
        uint256[] calldata maxToken,
        address[] calldata targets,
        bytes4[] calldata selectors
    ) external onlyAdmin {
        require(until > block.timestamp, "expiry");
        sessionKey = key;
        validUntil = until;
        ethBudget = maxEth;
        for (uint256 i; i < tokens.length; i++) erc20Budget[tokens[i]] = maxToken[i];
        for (uint256 j; j < targets.length; j++) allowed[targets[j]][selectors[j]] = true;
        emit SessionStarted(key, until);
    }

    function clearSession() external onlyAdmin {
        sessionKey = address(0);
        validUntil = 0;
        ethBudget  = 0;
        emit SessionCleared();
    }

    // Forward a permitted call using a session signature (off-chain signed intent)
    function forward(
        address to,
        uint256 value,
        bytes calldata data,
        bytes calldata sessionSig,
        bytes32 intentHash // EIP-712 domain recommended in production
    ) external payable returns (bytes memory) {
        require(block.timestamp <= validUntil, "expired");
        require(sessionKey != address(0), "no session");

        // Verify the session key via 1271-style contract or EOA ecrecover
        if (isContract(sessionKey)) {
            bytes4 magic = IERC1271(sessionKey).isValidSignature(intentHash, sessionSig);
            require(magic == 0x1626ba7e, "bad 1271");
        } else {
            // For brevity: assume data encodes r,s,v and recover equals sessionKey
            (bytes32 r, bytes32 s, uint8 v) = abi.decode(sessionSig, (bytes32,bytes32,uint8));
            address rec = ecrecover(intentHash, v, r, s);
            require(rec == sessionKey, "bad EOA sig");
        }

        // Scope checks
        bytes4 sel = data.length >= 4 ? bytes4(data[0:4]) : bytes4(0);
        require(allowed[to][sel], "not allowed");

        // Budget checks (ETH)
        if (value > 0) {
            require(value <= ethBudget, "eth budget");
            ethBudget -= uint96(value);
            emit BudgetUsed(address(0), value);
        }

        // Optional ERC-20 budget check if call is transferFrom or transfer
        if (sel == 0x23b872dd /* transferFrom */ || sel == 0xa9059cbb /* transfer */) {
            address token = to;
            (address a, , uint256 amt) = sel == 0x23b872dd
                ? abi.decode(data[4:], (address,address,uint256))
                : (address(0), address(0), abi.decode(data[4:], (address,uint256))._2);
            require(erc20Budget[token] >= amt, "token budget");
            erc20Budget[token] -= amt;
            emit BudgetUsed(token, amt);
        }

        // Execute
        (bool ok, bytes memory ret) = to.call{value: value}(data);
        require(ok, "call fail");
        emit CallExecuted(to, value, sel);
        return ret;
    }

    function isContract(address a) internal view returns (bool) {
        uint256 size; assembly { size := extcodesize(a) }
        return size > 0;
    }
}

How it fits 7702:

• The EOA kicks things off by setting the code to the 0xef0100||address for this PolicyDelegate.
• The admin is the EOA owner, and sessions are stored in the EOA’s storage. If you clear the 7702 pointer to zero, it instantly disables delegation. (eips.ethereum.org)

Production Guidance:

• It's better to stick with the audited 4337+7579 modules (Rhinestone/Biconomy SmartSession) instead of going for custom delegates when it comes to rich policy composition. Check it out here: (github.com)

---

Security and compliance checklist (what we enforce in reviews)

• Wallet-controlled authorizations: Just a heads-up, the EIP itself mentions that apps shouldn't be able to ask for random 7702 authorizations. Wallet interfaces need to check out and whitelist the delegate code. Treat those 7702 pointers as if they're upgrades. (eips.ethereum.org)
• Panic revoke: You can set up a quick “revert to EOA” button that sets the delegate address to zero, which will clear the code hash to empty as per the specs. (eips.ethereum.org)
• Cross-chain risk: Be cautious with chain_id = 0 unless you're totally okay with using it across chains. It's better to tie sessions to specific chain IDs. (eips.ethereum.org)
• tx.origin invariants: With 7702, delegated accounts can kick off transactions, which messes with assumptions like require(msg.sender == tx.origin. So, it’s a good idea to review any legacy controls that depend on tx.origin. (eips.ethereum.org)
• Code-hash checks: When using EXTCODE*, it returns a 23-byte indicator. Don't just lean on codehash equality to control behavior; you should go for interface detection or check an explicit registry instead. (eips.ethereum.org)
• Front-running and initialization: Make sure to stick to the spec guidance when setting up delegates and dodging any races (like using deploy code templates; never inline per-user initialization code). (eips.ethereum.org)
• Bundler policy: If you’re working with 4337, double-check that you're adhering to ERC-7562 validation rules and managing reputations correctly. Also, it’s wise to stake entities that maintain state to steer clear of mass invalidation. (eips.ethereum.org)
• Passkeys: It's smart to set up multiple credentials. Encourage users to register an extra device or hardware key to keep those annoying lockouts at bay. (developers.flow.com)

---

Gas and performance notes

• Setting up or refreshing delegation on an existing Externally Owned Account (EOA) costs about 12,500 gas per authorization. The protocol charges 25k for this, but if your account isn’t empty, you get a refund on the extra gas. For empty accounts, it’s a straight 25k. That’s a huge bargain compared to launching a new smart account, which can run you around 400k to 600k in many cases. (eips.ethereum.org)
• The way 7702 is designed encourages everyone to reuse common code templates (here’s a pointer to the code) instead of creating unique deployments for each user. This helps to keep the state size and auditing processes streamlined. (eips.ethereum.org)

---

Deployment and rollout plan (6-8 weeks)

1. Discovery and Threat Model

• Create a session matrix that outlines target flows, including allowed contracts/selectors, budgets, expiries, and rate limits.
• Figure out if it's better to stick with a modular smart account (ERC‑7579) or go for a minimal PolicyDelegate tailored for your app-specific sessions. Check out the details here.

2) Prototype on Sepolia/Holesky with EntryPoint v0.8

• Get yourself a 7702‑aware bundler and check that the eip7702Auth integration is working smoothly. Make sure to validate the sponsor flows from start to finish with your paymaster. You can find more details here: docs.candide.dev

3) Wallet UI and Policy Registry

• Make sure to whitelist delegate code templates in the wallet, following the “wallet-controlled authorization” guidelines from the EIP. Check it out here: (eips.ethereum.org).

4) Observability

• Capture: Keep track of session issuance and revocation events, validation failures (according to the ERC‑7562 rules), budget burn-downs, and sponsor expenditures. Check it out here: (eips.ethereum.org)

5) Security Review

• Take a good look at those session policies and upgrade paths. It’s also a good idea to simulate revocations while under load and to test out any tx.origin-sensitive contracts in your estate. Check it out here: (eips.ethereum.org)

1. Gradual exposure

• Begin with self-sponsored (tx.origin) transactions aimed at power users; after that, roll out sponsored 4337 routes for new users. (eips.ethereum.org)

---

KPIs we recommend

• Prompt Reduction: Check out the average number of confirmations needed per task before and after sessions.
• Conversion: Look at the success rate for our multi-step processes (like approve+swap and list+sell).
• Safety: This is all about the percentage of actions that get blocked by our policy, along with the average loss we've managed to avoid through budgets.
• Cost: We’re comparing gas usage per user against the 4337 migration baselines, looking specifically at set-code versus new deployments.

---

Reference snippets and spec hooks (for implementers)

• Detecting a 7702‑delegated account off‑chain: To get started, you’ll want to look for a code that’s 23 bytes long and kicks off with the prefix 0xef0100. After that, just decode the 20-byte delegate address. Oh, and keep in mind that the EXTCODE* function reads the indicator, while CODESIZE can change when you’re in the middle of delegated execution. For more details, check out the EIP-7702.
• Clearing delegation: If you need to clear the delegation, you just have to set the delegate address to 0x0 in your next 7702 authorization. And don’t forget, clients MUST reset the code hash to the empty code. Check this out for more info: EIP-7702.
• 4337 bundlers and v0.8 EntryPoint address: The EntryPoint address here is 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108. Make sure to use eip7702Auth in your UserOps. You can find more on this over at GitHub.
• Session key modules: For a more seamless experience, consider adopting the ERC‑7579 “SmartSession”. This will help you create interoperable policies across platforms like Safe, Kernel, and others. Dive into the details here.

---

The bottom line

7702 offers a straightforward solution to transition from EOAs to smart-account user experiences--no need to worry about address migrations or constant opcode changes. When you combine it with modular session policies and 4337 infrastructure, you can streamline your processes. This means fewer prompts, improved conversion rates, and automated tasks that are well-guarded.

The specification lays out clear boundaries (like the auth tuple, nonce, chain_id, and the 0xef0100 pointer), which means you just need to focus on ensuring that your authorization flows remain wallet-controlled and that your policies are easy to audit. If you're looking for a seasoned partner to help you design, audit, and implement this across wallets and dapps, check out 7Block Labs.

---

Sources and further reading

• EIP‑7702: Setting Code for EOAs (details on the spec, gas constants, behavior, and some security tips). Check it out here: (eips.ethereum.org)
• Big news! The Pectra mainnet is officially announced, and you can find out when it’s going live (thanks to the Ethereum Foundation and coverage from The Block). More info here: (blog.ethereum.org)
• Need the EntryPoint v0.8 address? You can find it in the eth‑infinitism repo and the Pimlico chain table. Here’s the link: (github.com)
• If you're looking for Bundlers that support 7702, check out these options: Candide Voltaire and Etherspot Skandha. Get the details here: (docs.candide.dev)
• Don’t miss out on ERC‑7579 for modular smart accounts and Smart Sessions--definitely something to look into from Rhinestone/Biconomy. Here’s the link: (eips.ethereum.org)
• Want to know about the ERC‑7562 validation rules? They’re all about keeping the mempool safe for Account Abstraction. Read up here: (eips.ethereum.org)
• Lastly, we’ve got some exciting stuff with ERC‑7710 for Smart Contract Delegation, ERC‑7715 for Wallet-granted permissions, and ERC‑7739 for readable typed signatures. Check it out: (eips.ethereum.org)