Anandi Sheladiya
Contact
  • About Anandi
  • SKILLS & EXPERIENCE
    • Frontend
      • ReactJS
      • Next.js – The React Framework for Production
      • ChartJS / D3.JS / Fabric JS
      • Three.JS: The JavaScript Library for 3D Graphics
      • HTML/CSS/JS/Tailwind CSS/Bootstrap
      • Material UI – The Ultimate React UI Framework
      • ShadCN/UI – The Modern UI Library for React
    • Backend
      • NodeJS & ExpressJS
      • Web3.JS
      • Python & Django
      • GoLang
      • TypeScript
    • Database
      • PostgreSQL
      • MongoDB - NOSQL Database
      • MySQL
    • API
      • REST API
      • GraphQL API
      • RPC (Remote Procedure Call)
      • WebSocket
    • Solidity
    • Layer 1 Blockchain
      • Ethereum
      • Solana
      • Bitcoin
      • Hyperledger
      • Binance
      • Avalanche
      • Cardano
      • Polkadot
      • Near Protocol
      • Algorand
      • TON (Telegram Open Network)
    • Optimistic Rollups (L2 on Ethereum)
      • Arbitrum
      • Base
      • Mantle
    • ZK-Rollups (L2 on Ethereum)
      • zkSync Era
      • Polygon zkEVM
    • Wallet Integration
      • Reown Appkit
      • Rainbow Walletkit
      • Web3 Modal
      • WalletConnect
      • Wagmi
      • Metamask & Safewallet SDKs
    • Web3 SDKs & API Providers
      • Alchemy
      • Moralis
      • QuickNode
      • BitQuery API & Stream
      • ThirdWeb
      • Infura
      • Li.Fi
      • 1Inch API
      • Uniswap API
      • OpenZeppelin
    • Web3 Middleware/ UX Infrastructure Platform
      • Biconomy
      • Pimlico
      • Alchemy AA
      • Safe (formerly Gnosis Safe)
      • ZeroDev
    • On Chain Trading Platform & Telegram Bot
      • Bullx
      • Wave Bot
      • GMGN
      • Shuriken
      • Magnum Trade
      • Trojan
  • PROTOCOLS
    • ERCs & EIPs
      • ERC-20: The Standard for Fungible Tokens
      • ERC-721: The Standard for Non-Fungible Tokens (NFTs)
      • ERC 4337
      • ERC 6551: Token Bound Accounts (TBA)
      • ERC 7702
      • EIP 4844 (Proto-Danksharding)
      • Ethereum Pectra
  • ARTICLES
    • Medium
Powered by GitBook
On this page
  • How It Works
  • Use Cases
  • Architecture Diagram
  • Coding Example
  • Security Considerations

Was this helpful?

  1. PROTOCOLS
  2. ERCs & EIPs

ERC 7702

EIP-7702 is a proposal aimed at enhancing Ethereum's account abstraction by allowing Externally Owned Accounts (EOAs) to temporarily function as smart contract accounts. This capability enables EOAs to have both code and storage, unlocking features such as transaction batching, gas sponsorship, and delegated actions.

How It Works

EIP-7702 introduces a new transaction type called the "set code transaction," which allows an EOA to temporarily adopt the code of an existing smart contract. The EOA owner signs an authorization that specifies the desired contract code, and this authorization can be submitted by anyone as part of the new transaction type. The code remains valid until replaced by another authorization, and the authorization can be chain-specific or applicable across multiple chains.

A sample transaction payload in EIP-7702 is structured as follows:

rlp([
  chain_id,
  nonce,
  max_priority_fee_per_gas,
  max_fee_per_gas,
  gas_limit,
  destination,
  data,
  access_list,
  [
    [contract_code, y_parity, r, s],
    ...
  ],
  signature_y_parity,
  signature_r,
  signature_s
])

In this structure, the contract_code is added to the signing address before the transaction begins and removed after it ends. This allows the EOA to temporarily adopt the functionality of the specified contract code during the transaction's execution.

Use Cases

  • Transaction Batching: EOAs can bundle multiple operations into a single transaction, reducing costs and improving efficiency.

  • Gas Sponsorship: Third parties can sponsor gas fees for EOAs, enabling users to interact with the blockchain without holding Ether.

  • Delegated Actions: EOAs can grant limited permissions to other addresses to act on their behalf, facilitating more flexible account management.

Architecture Diagram

While a specific architecture diagram is not provided in the sources, the following conceptual diagram illustrates the process:

+------------------+        +------------------+
|                  |        |                  |
|   EOA Owner      |        |   Smart Contract |
|                  |        |                  |
+--------+---------+        +---------+--------+
         |                            |
         | 1. Sign Authorization      |
         |    (Specifies Contract     |
         |     Code)                  |
         |                            |
         v                            |
+--------+---------+                  |
|                  |                  |
|   Authorization  |                  |
|                  |                  |
+--------+---------+                  |
         |                            |
         | 2. Submit Authorization    |
         |    as Part of Set Code     |
         |    Transaction             |
         |                            |
         v                            |
+--------+---------+                  |
|                  |                  |
|   Ethereum       |                  |
|   Network        |                  |
|                  |                  |
+--------+---------+                  |
         |                            |
         | 3. Temporarily Assign      |
         |    Contract Code to EOA    |
         |                            |
         v                            |
+--------+---------+                  |
|                  |                  |
|   EOA (Now       |                  |
|   Functions as   |                  |
|   Smart Contract)|                  |
|                  |                  |
+------------------+                  |
                                      |
                                      |
4. Execute Transaction Utilizing      |
   Smart Contract Functionality       |
                                      |
                                      v
+------------------+
|                  |
|   Transaction    |
|   Execution      |
|                  |
+------------------+

Coding Example

Below is a simplified example demonstrating how an EOA can temporarily adopt smart contract functionality using EIP-7702. In this scenario, the EOA sets its code to a simple contract that allows it to execute a specific function during the transaction.

  1. Define the Smart Contract Code

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

contract TemporaryContract {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    function executeAction() external {
        require(msg.sender == owner, "Not authorized");
        // Perform desired action
    }
}
  1. Sign the Authorization

The EOA owner signs an authorization that specifies the contract code (TemporaryContract) to be adopted during the transaction.

  1. Submit the Set Code Transaction

The signed authorization is submitted as part of the set code transaction, temporarily assigning the TemporaryContract code to the EOA.

  1. Execute the Desired Action

With the TemporaryContract code assigned, the EOA can now call the executeAction function within the same transaction.

This process allows the EOA to temporarily function as a smart contract, enabling more complex interactions within a single transaction.

Security Considerations

Implementing EIP-7702 requires careful attention to security, particularly in the following areas:

  • Secure Delegation: Delegated contracts should implement replay protection mechanisms, such as nonces, to prevent unauthorized reuse of signatures.

  • Transaction Propagation: Allowing EOAs to behave as smart contracts introduces challenges in transaction propagation. Clients should be designed to handle scenarios where multiple transactions from the same EOA may become invalidated due to changes in delegation.

  • Storage Management: Changing an account's delegation is a security-critical operation. Developers must ensure that storage layouts are managed carefully to avoid accidental collisions during migrations from one delegate contract to another.

For a comprehensive overview of security considerations, refer to the EIP-7702 proposal.

EIP-7702 represents a significant advancement in Ethereum's account abstraction efforts, providing EOAs with enhanced capabilities to interact with the blockchain more flexibly and efficiently.

PreviousERC 6551: Token Bound Accounts (TBA)NextEIP 4844 (Proto-Danksharding)

Last updated 3 months ago

Was this helpful?