Turn a Regular Wallet into a Smart Account with EIP 7702

Web3 has made huge strides in recent years, but UX and mainstream adoption remain major hurdles. According to surveys, key management is the biggest blocker: 46.8% of users cite “security concerns” as their top deterrent, and 80% say they need stronger confidence in account protection before transacting. According to surveys Unfortunately, that fear is valid. Billions in crypto have been lost due to misplaced keys, seed phrase mishandling, and private key theft. For teams building web3 products, this creates a painful trade-off: intuitive, seamless UX often means compromising on security or self-custody. Billions in crypto As the saying goes — pick only two: UX, security, or sovereignty. The community has been working to break this triangle. Among the most promising directions: EIP-7702 — lets EOAs temporarily delegate execution to a smart contract without changing the user’s address or history. EIP-4337 — standardizes smart contract accounts and brings the necessary infrastructure (like bundlers and paymasters) to make them work like web2 logins. MPC accounts — use secure key sharing to enable social login, recovery flows, and higher resilience, without giving up control. EIP-7702 — lets EOAs temporarily delegate execution to a smart contract without changing the user’s address or history. EIP-7702 — EIP-4337 — standardizes smart contract accounts and brings the necessary infrastructure (like bundlers and paymasters) to make them work like web2 logins. EIP-4337 — MPC accounts — use secure key sharing to enable social login, recovery flows, and higher resilience, without giving up control. MPC accounts I’m a mentor at international web3 hackathons and regularly publish guides and open-source tools to help teams adopt modern UX architectures faster. These approaches are battle-tested in real products and adapted across blockchain stacks. Currently building at Unique Network — an infrastructure project on Polkadot focused on NFTs and developer tooling. In this article, I break down how to apply EIP-7702 in practice — using a minimal smart wallet as an example, with step-by-step delegation, initialization, and safe migration without state loss. EIP-7702 What is EIP-7702 What is EIP-7702 Today's users won't tolerate poor UX. They expect smooth experiences that can be achieved through abstraction, including: Transaction batching Gas sponsorship Enhanced security (social recovery, spending limits, limited delegation) Transaction batching Gas sponsorship Enhanced security (social recovery, spending limits, limited delegation) Significant progress was made with smart contract wallets. However, the ecosystem carried the legacy burden of EOA accounts, preventing applications from leveraging the benefits of the Account Abstraction initiative, as there's a fundamental difference between what can be done with smart contract wallets and EOAs. Then, the Pectra hard fork introduced EIP-7702. EIP-7702 is a key step in Ethereum’s account abstraction roadmap. It gives existing Externally Owned Accounts (EOAs) access to smart contract capabilities — without requiring users to switch to a new address or give up their account history. With EIP-7702, an EOA can temporarily delegate execution to smart contract code while preserving its original structure. In simple terms, it lets you upgrade your regular wallet with smart account features like transaction batching, custom validation, and gas sponsorship — all while keeping your existing address. What this guide covers What this guide covers In this developer guide, I walk through how to apply EIP-7702 by progressively building a delegation-based smart wallet — starting from a minimal example and gradually adding ownership checks, batch execution, and safer storage patterns. We’ll cover: How Type 4 transactions and authorization_list work How to handle initialization, storage safety, and ownership How to batch transactions and improve UX Where the edges are — and what EIP-7702 doesn’t solve How Type 4 transactions and authorization_list work authorization_list How to handle initialization, storage safety, and ownership How to batch transactions and improve UX Where the edges are — and what EIP-7702 doesn’t solve All code is written in Solidity and tested with Foundry. You’ll also find runnable examples and full tests on GitHub. Solidity Foundry. GitHub Let’s get started. How EIP-7702 Works Technically How EIP-7702 Works Technically EIP-7702 introduces a delegation mechanism that allows an EOA to temporarily point to smart contract code while keeping its original structure and history. This is enabled by a new transaction type (0x04) that includes an authorization_list. 0x04 authorization_list. chain_id nonce max_priority_fee_per_gas max_fee_per_gas gas_limit destination value data access_list authorization_list signature_y_parity signature_r signature_s chain_id nonce max_priority_fee_per_gas max_fee_per_gas gas_limit destination value data access_list authorization_list signature_y_parity signature_r signature_s The authorization_list property is the most essential part of the new transaction type. authorization_list Authorization list The authorization_list contains signatures from EOA owners authorizing their accounts to delegate execution to specific smart contracts. It's a list of tuples that store the contract address to which the signer wants to delegate execution in the context of their EOA. authorization_list authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...] // ^^^^^^^ // This is the contract address that the EOA (the signer of this tuple) will delegate to authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...] // ^^^^^^^ // This is the contract address that the EOA (the signer of this tuple) will delegate to The authorization_list is specifically designed to contain signature components (y_parity, r, s), enabling sponsored transactions where the delegator doesn't need to pay gas fees. Set code transactions can be executed by wallets or applications on behalf of users. authorization_list y_parity r s The authorization list is designed as an array to allow applications to migrate multiple accounts in a single transaction. However, this doesn't mean you can set various delegators for one EOA — only one delegation target is allowed per account The set code transaction goes through a specific validation process, and if successful, it sets the code for the EOA. The code set on an EOA account is called a delegation designator and has a specific format: // EIP-7702 delegation designator structure bytes memory delegationCode = abi.encodePacked( hex"ef0100", address(targetContract) ); // Total: 23 bytes // EIP-7702 delegation designator structure bytes memory delegationCode = abi.encodePacked( hex"ef0100", address(targetContract) ); // Total: 23 bytes Where: 0xef — EIP-3541 reserved byte indicating special protocol code (not executable bytecode) 01 — EIP-7702 feature identifier within the EIP-3541 reserved space 00 — version of the EIP-7702 delegation format (currently version 0) address (targetContract) — the final 20 bytes contain the full Ethereum address of the smart contract that will execute all function calls made to this EOA 0xef — EIP-3541 reserved byte indicating special protocol code (not executable bytecode) 0xef 01 — EIP-7702 feature identifier within the EIP-3541 reserved space 01 00 — version of the EIP-7702 delegation format (currently version 0) 00 address (targetContract) — the final 20 bytes contain the full Ethereum address of the smart contract that will execute all function calls made to this EOA address (targetContract) Now your account points to a smart contract and can execute its logic. Initialization challenges Initialization challenges This brings up an important implementation detail. When we delegate our EOA to, say, an ownable wallet, how does this wallet know which address is authorized to execute a transaction? When a traditional wallet is deployed, its constructor runs and sets up the initial state, configuring owners, signature requirements, and other essential parameters. But when you delegate to an existing contract, your EOA's storage starts completely blank. This is because EIP-7702 delegates code execution, not storage. Your EOA maintains its own storage space, separate from the implementation contract. This means the contract you delegate to must provide an initialization mechanism to set up the required state in your EOA's storage space. Delegating to a Smart Contract Wallet Delegating to a Smart Contract Wallet Full code examples are available on GitHub: github.com/Maksandre/try-eip-7702 github.com/Maksandre/try-eip-7702 Let's start by implementing a simplified smart wallet to understand the basic mechanics, then improve it step by step. For this guide, we'll use Foundry to build and test the implementation. Our first version has a single method to execute a transaction: execute // SmartWallet.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract NotReallySmartWallet { function execute(address to, uint256 value, bytes calldata data) external payable { (bool success,) = to.call{value: value}(data); require(success, "Transaction reverted"); } fallback() external payable {} receive() external payable {} } // SmartWallet.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract NotReallySmartWallet { function execute(address to, uint256 value, bytes calldata data) external payable { (bool success,) = to.call{value: value}(data); require(success, "Transaction reverted"); } fallback() external payable {} receive() external payable {} } Next, we’ll write a test to understand how delegation works using Forge cheatcodes. We’ll use vm.signAndAttachDelegation, which mocks a SET_CODE_TX_TYPE for an EOA and a smart contract. cheatcodes vm.signAndAttachDelegation SET_CODE_TX_TYPE Setup steps: Create two addresses: Alice (prefunded) and Bob (empty) Deploy our test wallet contract Make sure Alice’s EOA initially has no code Create two addresses: Alice (prefunded) and Bob (empty) Deploy our test wallet contract Make sure Alice’s EOA initially has no code contract NotReallySmartWalletTest is Test { address public ALICE_ADDRESS; uint256 public ALICE_PRIVATE_KEY; address public BOB_ADDRESS; // Test parameters uint256 constant INITIAL_ALICE_BALANCE = 10 ether; uint256 constant TRANSFER_AMOUNT = 1 ether; // The contract that Alice will delegate execution to NotReallySmartWallet public delegationTarget; function setUp() public { // Generate addresses and keys dynamically (ALICE_ADDRESS, ALICE_PRIVATE_KEY) = makeAddrAndKey("alice"); BOB_ADDRESS = makeAddr("bob"); // Fund Alice's account vm.deal(ALICE_ADDRESS, INITIAL_ALICE_BALANCE); // Deploy the delegation contract delegationTarget = new NotReallySmartWallet(); } } contract NotReallySmartWalletTest is Test { address public ALICE_ADDRESS; uint256 public ALICE_PRIVATE_KEY; address public BOB_ADDRESS; // Test parameters uint256 constant INITIAL_ALICE_BALANCE = 10 ether; uint256 constant TRANSFER_AMOUNT = 1 ether; // The contract that Alice will delegate execution to NotReallySmartWallet public delegationTarget; function setUp() public { // Generate addresses and keys dynamically (ALICE_ADDRESS, ALICE_PRIVATE_KEY) = makeAddrAndKey("alice"); BOB_ADDRESS = makeAddr("bob"); // Fund Alice's account vm.deal(ALICE_ADDRESS, INITIAL_ALICE_BALANCE); // Deploy the delegation contract delegationTarget = new NotReallySmartWallet(); } } In our test, we start by delegating Alice's account to the predeployed `SmartWallet` contract. `SmartWallet` Then we check that Alice's account now has a delegation designator code. Remember, it has a special format starting with `ef0100`: `ef0100` assertEq( ALICE_ADDRESS.code, abi.encodePacked(hex"ef0100", address(delegationTarget)) ); assertEq( ALICE_ADDRESS.code, abi.encodePacked(hex"ef0100", address(delegationTarget)) ); This is important: EOAs can no longer be identified by empty code. Instead, check if the code starts with 0xef0100 — that's a delegated EOA under EIP-7702. 0xef0100 Now we can call Alice’s EOA like any contract: NotReallySmartWallet(ALICE_ADDRESS).execute( BOB_ADDRESS, TRANSFER_AMOUNT, "" ); NotReallySmartWallet(ALICE_ADDRESS).execute( BOB_ADDRESS, TRANSFER_AMOUNT, "" ); Verify account balances after the transaction to ensure it succeeded: // Verify final balances assertEq(BOB_ADDRESS.balance, TRANSFER_AMOUNT); assertEq( ALICE_ADDRESS.balance, INITIAL_ALICE_BALANCE - TRANSFER_AMOUNT ); // Verify final balances assertEq(BOB_ADDRESS.balance, TRANSFER_AMOUNT); assertEq( ALICE_ADDRESS.balance, INITIAL_ALICE_BALANCE - TRANSFER_AMOUNT ); Building UX, Security, and Control Building UX, Security, and Control At this point, our contract is working — but with no access control or real safety. Let's fix that. 1. The Lack of Access Control 1. The Lack of Access Control We don’t have any authorization mechanism — anyone can call execute on the account. To demonstrate this, you can simply change the transaction origin from Alice to Bob, and the test will still pass: vm.prank(/* ALICE_ADDRESS -> */ BOB_ADDRESS); NotReallySmartWallet(ALICE_ADDRESS).execute( BOB_ADDRESS, TRANSFER_AMOUNT, "" ); vm.prank(/* ALICE_ADDRESS -> */ BOB_ADDRESS); NotReallySmartWallet(ALICE_ADDRESS).execute( BOB_ADDRESS, TRANSFER_AMOUNT, "" ); Let’s make sure that the signer of a transaction is actually the delegating EOA account. If you want to restrict access to just that key, you can check that msg.sender == address(this). msg.sender == address(this) But what if you want more flexible access control — like multisig or passkeys? The SET_CODE_TX_TYPE doesn’t allow you to deploy a new contract with init code. You can only point to an existing one. That means the contract must already be initialized before it’s delegated to. SET_CODE_TX_TYPE before The most straightforward — but incorrect — approach is to set the storage in the implementation contract. The problem is that EIP-7702 delegates code execution, not storage. Like delegatecall, execution happens in the context of the EOA, not the contract you're delegating to. code execution, not storage Take the OpenZeppelin Ownable contract as an example. If you initialize it before delegation, the onlyOwner check will look for the owner in the EOA's storage — not in the contract’s own storage — and it won’t find it. The value you set in the contract itself will be ignored. Ownable before onlyOwner To solve this, you need to move the owner initialization into a separate function and call it after the delegation: owner after // Remove constructor initialization // constructor() { // owner = msg.sender; // } function initialize() external { require(owner == address(0), "Already initialized"); owner = msg.sender; } // Remove constructor initialization // constructor() { // owner = msg.sender; // } function initialize() external { require(owner == address(0), "Already initialized"); owner = msg.sender; } Now, after invoking the initialize function, the owner will be stored in the EOA storage and, as a result, recognized correctly. However, we've introduced another vulnerability. initialize 2. Front-running 2. Front-running If delegation and initialization are two separate transactions, someone could initialize the wallet faster and gain access to the account's assets. There are two ways to prevent this: Delegate and initialize in the same transaction — by including the initialization call in the same transaction that performs the delegation. Use the ecrecover precompile to ensure that the initialization is performed by the EOA's key. Delegate and initialize in the same transaction — by including the initialization call in the same transaction that performs the delegation. Use the ecrecover precompile to ensure that the initialization is performed by the EOA's key. ecrecover Let’s start with the first option. You can use the to and data fields of the EIP-7702 transaction to include an initialization call. Suppose our implementation contract has the following function: to data function initialize(address _owner) external { require(owner == address(0), "Already initialized"); owner = _owner; } function initialize(address _owner) external { require(owner == address(0), "Already initialized"); owner = _owner; } Then you can call this function in the same transaction, immediately after setting the delegation. Here's how you can do it using viem: ... const authorization = await walletClient.signAuthorization({ contractAddress: implementationAddress, account: delegator, // <---- 1. the `delegator` account signs the authorization to `implementationAddress` executor: executor, }); const eip7702tx = await walletClient.sendTransaction({ account: executor, // 2. During the execution of the eip7702 transaction, the `executor` calls `delegator.address` // this transaction will be executed at the end of the transaction. At this point the EOA already // has code set to: delegator.address, data: encodeFunctionData({ abi: artifact.abi, functionName: "initialize", // <---- the `executor` calls the `initialize` function args: [delegator.address], }), type: "eip7702", authorizationList: [authorization], }); ... const authorization = await walletClient.signAuthorization({ contractAddress: implementationAddress, account: delegator, // <---- 1. the `delegator` account signs the authorization to `implementationAddress` executor: executor, }); const eip7702tx = await walletClient.sendTransaction({ account: executor, // 2. During the execution of the eip7702 transaction, the `executor` calls `delegator.address` // this transaction will be executed at the end of the transaction. At this point the EOA already // has code set to: delegator.address, data: encodeFunctionData({ abi: artifact.abi, functionName: "initialize", // <---- the `executor` calls the `initialize` function args: [delegator.address], }), type: "eip7702", authorizationList: [authorization], }); This approach is safe, but it comes with a limitation: it only works for a single account. You can’t reuse the same trick when migrating multiple EOAs in one EIP-7702 transaction. In that case, you may need to use the ecrecover precompile for initialization. ecrecover It’s a big improvement — but there’s still one more issue to tackle. 3. Storage collisions When an account redelegates from one contract to another that uses the same storage slots differently, it can cause unpredictable behavior or even security vulnerabilities. To illustrate the problem, let’s create two simple contracts that both use slot 0 — but for different data types: contract A { address public owner; // slot 0 // ... } contract B { uint256 public balance; // slot 0 // ... } contract A { address public owner; // slot 0 // ... } contract B { uint256 public balance; // slot 0 // ... } After redelegation from contract A to contract B, the previous owner value will be interpreted as a huge balance. Alice’s address (20 bytes) will be read as a uint256, resulting in an absurdly large number. owner uint256 To avoid such collisions, we can use EIP-7201, which introduces namespaced storage layouts. This standard defines a method for assigning pseudo-random storage slots, significantly reducing the risk of overlap. EIP-7201 To apply it, we first wrap our data in a struct and compute a unique slot using EIP-7201’s formula. This ensures our contract uses a dedicated storage location that won’t conflict with others. contract ContractA_7201 { // @custom:storage-location erc7201:example.contractA struct ContractAStorage { address owner; uint256 nonce; } // keccak256(abi.encode(uint256(keccak256("example.contractA")) - 1)) & ~bytes32(uint256(0xff)) bytes32 private constant ContractAStorageLocation = 0xd01525294f88a57baa3c94c84cf5cf8d70d334377609d6aabd7ec7c9ce460d00; contract ContractA_7201 { // @custom:storage-location erc7201:example.contractA struct ContractAStorage { address owner; uint256 nonce; } // keccak256(abi.encode(uint256(keccak256("example.contractA")) - 1)) & ~bytes32(uint256(0xff)) bytes32 private constant ContractAStorageLocation = 0xd01525294f88a57baa3c94c84cf5cf8d70d334377609d6aabd7ec7c9ce460d00; The access function returns a reference to our namespaced storage. It uses assembly to point directly to our calculated slot location. function _getContractAStorage() private pure returns (ContractAStorage storage $) { assembly { $.slot := ContractAStorageLocation } } function _getContractAStorage() private pure returns (ContractAStorage storage $) { assembly { $.slot := ContractAStorageLocation } } Both functions first obtain a reference to the namespaced storage, then perform read/write operations. The initialize function sets the owner once, and the ownerfunction retrieves it. All storage interactions go through our collision-safe location. initialize owner function initialize() external { ContractAStorage storage $ = _getContractAStorage(); require($.owner == address(0), "Already initialized"); $.owner = msg.sender; } function owner() public view returns (address) { ContractAStorage storage $ = _getContractAStorage(); return $.owner; } function initialize() external { ContractAStorage storage $ = _getContractAStorage(); require($.owner == address(0), "Already initialized"); $.owner = msg.sender; } function owner() public view returns (address) { ContractAStorage storage $ = _getContractAStorage(); return $.owner; } Great! We've set up the first version of access control that actually works. Now let’s focus on improving usability. 4. Better UX: batch transactions 4. Better UX: batch transactions Ethereum's design often requires multiple separate transactions for related actions, creating friction and increasing gas costs. For instance, swapping tokens usually involves approving the spend first and then executing the swap — two signatures, two gas payments. One of the key benefits of smart contract wallets is the ability to batch multiple operations into a single transaction. Let’s add that capability: struct Call { address to; uint256 value; bytes data; } function executeBatch(Call[] calldata calls) external payable onlyOwner { for (uint256 i = 0; i < calls.length; i++) { (bool success,) = calls[i].to.call{value: calls[i].value}(calls[i].data); require(success, "Batch transaction reverted"); } } struct Call { address to; uint256 value; bytes data; } function executeBatch(Call[] calldata calls) external payable onlyOwner { for (uint256 i = 0; i < calls.length; i++) { (bool success,) = calls[i].to.call{value: calls[i].value}(calls[i].data); require(success, "Batch transaction reverted"); } } This allows users to perform multiple operations atomically — for example, approving a token and then swapping it in a single transaction, reducing gas costs and improving the user experience. No more endless transaction signing! You can also imagine additional UX improvements, like session keys with limited access to wallet funds or spending limits. Now, let’s turn our focus to security. 5. Security Improvements 5. Security Improvements A vast amount of funds is permanently lost due to lost private keys. The inability to restore them is a major problem. Fortunately, with programmability, we can address this issue. Using smart contracts, you can set up social recovery, giving trusted friends the ability to transfer ownership of your account to a new EOA. To prevent abuse, you can add timelocks that give you time to cancel a malicious recovery attempt. Other possible security improvements include setting transfer limits. So even if you accidentally sign a malicious transaction, the attacker can only drain a small amount. You have a lot of power with programmability. But unfortunately, EIP-7702 doesn't solve one crucial problem. Private Key Remains a Security Risk Private Key Remains a Security Risk If someone gets access to your EOA's private key, you're in trouble. No recovery method will help you get your funds back or limit your losses. That private key is like having the master key to everything. It doesn't matter what smart account features you've set up; the private key can override all of them. The only way to truly protect yourself from this scenario is to use pure smart contract accounts that don't rely on a single private key. Delegation Clearing Delegation Clearing Users can remove their attached code by authorizing a delegation to the zero address. After this, the code behind the EOA becomes empty — it’s no longer 0xef01000000.... However, note that this does not reset or wipe the storage associated with the EOA. 0xef01000000 not Here's how to do it using viem: const cleanupAuthorization = await walletClient.signAuthorization({ contractAddress: zeroAddress, account: delegator, executor: "self", }); const cleanupTx = await walletClient.sendTransaction({ account: delegator, type: "eip7702", authorizationList: [cleanupAuthorization], }); const cleanupAuthorization = await walletClient.signAuthorization({ contractAddress: zeroAddress, account: delegator, executor: "self", }); const cleanupTx = await walletClient.sendTransaction({ account: delegator, type: "eip7702", authorizationList: [cleanupAuthorization], }); Drawbacks Drawbacks While EIP-7702 brings meaningful improvements, several key limitations remain. Gas sponsorship requires EIP-4337 Gas sponsorship requires EIP-4337 EIP-7702 enables smart contract functionality, but truly gasless transactions still depend on EIP-4337 infrastructure. The authorization list supports sponsored transactions, but you'll still need bundlers and paymasters for a full gasless experience. Complexity and attack vectors Complexity and attack vectors Delegation introduces added complexity that can lead to unexpected behavior or new attack surfaces. Developers must carefully manage storage layout, initialization logic, and possible contract conflicts when working with EIP-7702. Developer experience Developer experience The separation of code execution (delegated) and storage (local to the EOA) introduces a new mental model. Misunderstanding this model can easily lead to bugs or unintended side effects. Despite these challenges, EIP-7702 marks a major step toward making Ethereum more intuitive and flexible, while preserving the security and decentralization that define the platform. It helps bridge the gap between EOAs and full account abstraction, providing a gradual path that retains user control and account history. This is a foundational step toward native account abstraction. Future EIPs will likely build on it to offer more comprehensive solutions, potentially unifying EOAs and smart contracts into a single, seamless account model.