[GH-ISSUE #3733] [Feature] ERC-4337 / EIP-7702 account-abstraction reverse engineering: UserOperations, EntryPoint, paymasters, factories and delegated-code graphs #1441

Open
opened 2026-10-16 21:05:28 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @matbrgz on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3733

Type: Feature Domain: Reverse Engineering Status: Proposed Ecosystem: REA

Problem Statement & Context

Account Abstraction is fundamentally reshaping how Ethereum and EVM-compatible chains handle identity, transaction sponsorship, and smart contract wallets:

  1. ERC-4337 (Off-Chain Alternative Mempool): User transactions packaged as UserOperation structs instead of raw Ethereum transactions, processed through an authoritative EntryPoint contract (0x0000000071727De22E5E9d8BAf0edAc6f37da032 or v0.7 0x0000000071727De22E5E9d8BAf0edAc6f37da032).
  2. UserOperation Structure: Sender account, nonce, initCode (account creation code), callData (target action), execution gas limits, paymaster verification limits, pre-verification gas, max fee, and signature.
  3. Paymasters & Gas Sponsorship: Specialized smart contracts validating and sponsoring gas payments (validatePaymasterUserOp, postOp), often utilizing off-chain sponsor signatures.
  4. Smart Account Factories & Bundlers: Deterministic account deployment via initCode using factories (e.g. SimpleAccountFactory, Safe4337Factory) and batched bundling via handleOps.
  5. EIP-7702 (EOA Code Delegation): Ephemeral delegation allowing standard Externally Owned Accounts (EOAs) to set a contract code pointer (0xef0100 || contract_address) for the duration of a transaction, temporarily granting smart account capabilities to regular wallets.

Currently, reverse engineering an EVM transaction involving account abstraction produces confusing, deeply nested call trees where the origin sender appears as the bundler instead of the user. REA needs an account-abstraction semantic engine capable of decoding UserOperations, identifying paymasters, modeling account creation, and unraveling EIP-7702 delegation graphs.

Proposed Architecture

flowchart TD
    A["Raw Transaction / Trace (handleOps / EIP-7702 auth)"] --> B["Account Abstraction Semantic Engine"]
    B --> C["EntryPoint & UserOperation Dissector"]
    B --> D["Paymaster & Sponsorship Inspector"]
    B --> E["Account Factory & initCode Reconstructor"]
    B --> F["EIP-7702 Delegation Resolver"]
    
    C --> C1["handleOps Payload Parsing (Array of UserOperations)"]
    C --> C2["Inner Execution CallData Decoding (Sender, Target, Value, Calldata)"]
    
    D --> D1["Paymaster Address & validatePaymasterUserOp Decoding"]
    D --> D2["Sponsor Identity & Payment Policy (Token vs Native Gas)"]
    
    E --> E1["Factory Address & Deployment Parameters"]
    E --> E2["CREATE2 Derived Smart Wallet Address"]
    
    F --> F1["Authorization Tuple (chain_id, address, nonce, y_parity, r, s)"]
    F --> F2["Delegated Code Graph (EOA -> Target Implementation)"]
    
    C & D & E & F --> G["Synthesized UserOperation Architecture Diagram & Asset Flow"]

Technical Capabilities & Modules

  1. UserOperation Slicing & Deserialization:

    • Detect calls to EntryPoint.handleOps (versions v0.6 and v0.7).
    • Unpack packed UserOperation structs: sender, nonce, initCode, callData, accountGasLimits, preVerificationGas, gasFees, paymasterAndData, signature.
    • Decode inner target transactions from callData (e.g. execute, executeBatch).
  2. Paymaster & Sponsorship Policy Reconstruction:

    • Extract paymaster contract addresses from paymasterAndData.
    • Identify sponsorship models: free sponsorship, ERC-20 token payment, subscription-based allowance.
    • Decode paymaster verification signatures and post-operation accounting logic.
  3. Smart Account Factory & Creation Modeling:

    • Parse initCode: separate factory address (first 20 bytes) from factory calldata (remaining bytes).
    • Calculate deterministic derived counterfactual contract addresses (CREATE2).
    • Map initialization ownership parameters (owners, signers, recovery guardians).
  4. EIP-7702 Code Delegation Analysis:

    • Parse EIP-7702 transaction envelopes: authorization lists, delegated contract implementation addresses, and nonces.
    • Map execution boundaries: trace how an EOA's temporary code pointer behaves during multi-step contract calls.
  5. Semantic Identity & Flow Reconstruction:

    • Reconstruct true user attribution: re-anchor transaction causality from the bundler relayer to the actual UserOp.sender.
    • Build an asset flow diagram showing token movements, gas reimbursements, and state changes.

Acceptance Criteria

  • Automated decoding of ERC-4337 v0.6 and v0.7 UserOperation arrays from transaction traces.
  • Accurate extraction and separation of inner execution calldata and target contracts.
  • Attribution of paymaster sponsors and gas payment mechanisms.
  • Parsing of initCode to identify account factory parameters and derived wallet addresses.
  • Decoding of EIP-7702 authorization lists and delegated implementation contracts.
  • Complements #972 (Solidity/EVM reverse engineering)
  • Complements #2391 (EVM calldata and execution trace analysis)
  • Complements #2394 (EVM transaction simulation and state diffs)
Originally created by @matbrgz on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3733 [![Type: Feature](https://img.shields.io/badge/type-feature-blue.svg?style=flat-square)](https://github.com/morluto/rea) [![Domain: Reverse Engineering](https://img.shields.io/badge/domain-reverse_engineering-blueviolet.svg?style=flat-square)](https://github.com/morluto/rea) [![Status: Proposed](https://img.shields.io/badge/status-proposed-blue.svg?style=flat-square)](https://github.com/morluto/rea) [![Ecosystem: REA](https://img.shields.io/badge/ecosystem-morluto%2Frea-8A2BE2.svg?style=flat-square)](https://github.com/morluto/rea) ### Problem Statement & Context Account Abstraction is fundamentally reshaping how Ethereum and EVM-compatible chains handle identity, transaction sponsorship, and smart contract wallets: 1. **ERC-4337 (Off-Chain Alternative Mempool)**: User transactions packaged as `UserOperation` structs instead of raw Ethereum transactions, processed through an authoritative `EntryPoint` contract (`0x0000000071727De22E5E9d8BAf0edAc6f37da032` or v0.7 `0x0000000071727De22E5E9d8BAf0edAc6f37da032`). 2. **UserOperation Structure**: Sender account, nonce, `initCode` (account creation code), `callData` (target action), execution gas limits, paymaster verification limits, pre-verification gas, max fee, and signature. 3. **Paymasters & Gas Sponsorship**: Specialized smart contracts validating and sponsoring gas payments (`validatePaymasterUserOp`, `postOp`), often utilizing off-chain sponsor signatures. 4. **Smart Account Factories & Bundlers**: Deterministic account deployment via `initCode` using factories (e.g. SimpleAccountFactory, Safe4337Factory) and batched bundling via `handleOps`. 5. **EIP-7702 (EOA Code Delegation)**: Ephemeral delegation allowing standard Externally Owned Accounts (EOAs) to set a contract code pointer (`0xef0100 || contract_address`) for the duration of a transaction, temporarily granting smart account capabilities to regular wallets. Currently, reverse engineering an EVM transaction involving account abstraction produces confusing, deeply nested call trees where the origin sender appears as the bundler instead of the user. REA needs an account-abstraction semantic engine capable of decoding UserOperations, identifying paymasters, modeling account creation, and unraveling EIP-7702 delegation graphs. ### Proposed Architecture ```mermaid flowchart TD A["Raw Transaction / Trace (handleOps / EIP-7702 auth)"] --> B["Account Abstraction Semantic Engine"] B --> C["EntryPoint & UserOperation Dissector"] B --> D["Paymaster & Sponsorship Inspector"] B --> E["Account Factory & initCode Reconstructor"] B --> F["EIP-7702 Delegation Resolver"] C --> C1["handleOps Payload Parsing (Array of UserOperations)"] C --> C2["Inner Execution CallData Decoding (Sender, Target, Value, Calldata)"] D --> D1["Paymaster Address & validatePaymasterUserOp Decoding"] D --> D2["Sponsor Identity & Payment Policy (Token vs Native Gas)"] E --> E1["Factory Address & Deployment Parameters"] E --> E2["CREATE2 Derived Smart Wallet Address"] F --> F1["Authorization Tuple (chain_id, address, nonce, y_parity, r, s)"] F --> F2["Delegated Code Graph (EOA -> Target Implementation)"] C & D & E & F --> G["Synthesized UserOperation Architecture Diagram & Asset Flow"] ``` ### Technical Capabilities & Modules 1. **UserOperation Slicing & Deserialization:** - Detect calls to `EntryPoint.handleOps` (versions v0.6 and v0.7). - Unpack packed `UserOperation` structs: `sender`, `nonce`, `initCode`, `callData`, `accountGasLimits`, `preVerificationGas`, `gasFees`, `paymasterAndData`, `signature`. - Decode inner target transactions from `callData` (e.g. `execute`, `executeBatch`). 2. **Paymaster & Sponsorship Policy Reconstruction:** - Extract paymaster contract addresses from `paymasterAndData`. - Identify sponsorship models: free sponsorship, ERC-20 token payment, subscription-based allowance. - Decode paymaster verification signatures and post-operation accounting logic. 3. **Smart Account Factory & Creation Modeling:** - Parse `initCode`: separate factory address (first 20 bytes) from factory calldata (remaining bytes). - Calculate deterministic derived counterfactual contract addresses (`CREATE2`). - Map initialization ownership parameters (owners, signers, recovery guardians). 4. **EIP-7702 Code Delegation Analysis:** - Parse EIP-7702 transaction envelopes: authorization lists, delegated contract implementation addresses, and nonces. - Map execution boundaries: trace how an EOA's temporary code pointer behaves during multi-step contract calls. 5. **Semantic Identity & Flow Reconstruction:** - Reconstruct true user attribution: re-anchor transaction causality from the bundler relayer to the actual `UserOp.sender`. - Build an asset flow diagram showing token movements, gas reimbursements, and state changes. ### Acceptance Criteria - [ ] Automated decoding of ERC-4337 v0.6 and v0.7 `UserOperation` arrays from transaction traces. - [ ] Accurate extraction and separation of inner execution calldata and target contracts. - [ ] Attribution of paymaster sponsors and gas payment mechanisms. - [ ] Parsing of `initCode` to identify account factory parameters and derived wallet addresses. - [ ] Decoding of EIP-7702 authorization lists and delegated implementation contracts. ### Related Issues & Dependencies - Complements #972 (Solidity/EVM reverse engineering) - Complements #2391 (EVM calldata and execution trace analysis) - Complements #2394 (EVM transaction simulation and state diffs)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#1441
No description provided.