ERC-4337.md

ERC4337 Audit Checklist

Checklist

General

• How are the audited contracts different from Infinitism's sample contracts?
• Can the project be deployed on targeted EVM-compatible chains, e.g. through the correct version of the Solidity compiler?
  • Code4rena/Ambire/M-04: Project may fail to be deployed to chains not compatible with Shanghai hardfork
  • Non-issue in Infinitism sample
• Do the components support the latest EntryPoint contract?

Wallet Account Factory

• Does it use CREATE2 to create the wallet?
  • ERC-4337: The factory is expected to use CREATE2 (not CREATE) to create the wallet
  • Non-issue in Infinitism sample
• Does it return the wallet account address even if it has already been created?
  • ERC-4337: If the factory does use CREATE2 or some other deterministic method to create the wallet, it’s expected to return the wallet address even if the wallet has already been created.
  • Non-issue in Infinitism sample
• Can an attacker gain control of the wallet account by deploying it on behalf of its owner?
  • ERC-4337: For security reasons, it is important that the generated contract address will depend on the initial signature. This way, even if someone can create a wallet at that address, he can’t set different credentials to control it.
  • Code4rena/Biconomy/H-03: Attacker can gain control of counterfactual wallet
  • Code4rena/Ambire/L-01: AmbireAccountFactory.deploySafe() does not guarantee that no call hasn’t already been made on the deployed contract
  • Non-issue in Infinitism sample
• Does the factory allow anyone to add stake to the entrypoint? In that case, the unstakeDelay may not be changed, otherwise it could be set to high value, preventing unstaking

Wallet Account

• Can the wallet account implementation contract be initialized by an attacker, e.g. through frontrunning?
  • Code4rena/Biconomy/H-01: Destruction of the SmartAccount implementation
  • Code4rena/Ambire/M-05: AmbireAccount implementation can be destroyed by privileges
  • Non-issue in Infinitism sample
• Can the wallet account execute transactions without going through the EntryPoint, and if so, are access controls and signature validations properly implemented?
  • Code4rena/Biconomy/H-04: Arbitrary transactions possible due to insufficient signature validation
  • Code4rena/Ambire/M-03: Recovery transaction can be replayed after a cancellation
  • Code4rena/Ambire/L-02: Fallback handler should not be allowed to be this
  • Code4rena/Ambire/L-16: Transactions bundles signed for a future nonce cannot be cancelled
  • ZeroDev/Kernel/ZeroDev-wallet-02: Signature Replay Attack can be done on validateUserOp of Kernel
  • ZeroDev/Kernel/ZeroDev-wallet-05: Incomplete Validation of Operation Types in Session Verification
  • Non-issue in Infinitism sample
• Does the wallet account use different signature validation schemes, and are they correctly implemented?
  • ERC-4337: If the account does not support signature aggregation, it MUST validate the signature is a valid signature of the userOpHash, and SHOULD return SIG_VALIDATION_FAILED (and not revert) on signature mismatch. Any other error should revert.
  • Code4rena/Ambire/L-03: Schnorr signature validation may be incompatible with the intended signers
  • Code4rena/Ambire/L-04: Schnorr signature length is not checked
  • Code4rena/Ambire/L-15: require(sp != 0); fails to protect Schnorr signature validation
  • Non-issue in Infinitism sample
• Does the wallet account implement ERC-1271, and if so, can "owners" be shared between accounts?
  • In most naive implementations of isValidSignature() (e.g. one that checks that some owner has signed the bytes32 hash), signatures can be replayed across accounts with shared owners. The hash needs to be altered by the account (e.g. using EIP-712) so that a signature is only valid for a specific wallet.
  • Correct implementation in Safe contracts
• Does the wallet only access storage fields that are associated with the sender? Otherwise, standard bundlers won't support it
• Is the wallet proxy based? If so, which proxy is used? If its an ERC1967Proxy, does it comply to the standard?
  • Non-issue in Infinitism sample
• Can the smart contract account be converted to another type of smart contract account (via the proxy pattern)? Could the initalizable storage slot be reused?
• Does the wallet account support modules? If so what type? Does it comply to the specs (e.g. if delegatecall is used, no storage slots overlaps)? What is the process the review modules? What is the process to register modules?
  • delegatecall based
    • ZeroDev
    • Diamond Pattern EIP-2535
    • Safe
  • call based
    • EIP-6900
    • Universal Profile (slightly different)
• Does the wallet support session keys?
  • Biconomy
  • ZeroDev, ref
  • MatchboxDAO

Paymaster

• Can VerifyingPaymaster signatures be replayed?
  • Code4rena/Biconomy/H-05: Paymaster’s signature can be replayed to drain their deposits
  • Code4rena/Biconomy/M-03: Cross-Chain Signature Replay Attack
  • Non-issue in Infinitism sample
• Can arbitrary error messages happen in the postOp() function?
  • There is a bug in the v0.6 entrypoint that results in the mishandling of short revert messages. This means a revert in the initial postOp() call can revert the entire bundle, even though it's expected that a second postOp() call would be made.

Bundler

• Does it implement eth_sendRawTransactionConditional for supporting L2s? (References: Ethereum Foundation, Optimism, Arbitrum, Polygon)

Signature Validator

• Does it correctly validate user signatures for the correct amount of gas from the User Operation? ref

Other chains

• Does the chain (plan to) support RIP-7560

Applications

• Do applications use ERC-6492: Signature Validation for Predeploy Contracts? If so, do they comply to the standard?
• Do applications not rely on tx.origin for signature checking?
• Do applications always use gas estimations, instead of relying on assumptions for specific costs (e.g 21000 fixed cost of transfer)
• Do applications support batching (not required, but can greatly improve UX)
• Do appplications support paymasters (e.g. paying gas with the token that is being converted)

Resources

ERC

• ERC-4337: Account Abstraction Using Alt Mempool

Audits

• EIP-4337 – Ethereum Account Abstraction Audit
• EIP-4337 – Ethereum Account Abstraction Incremental Audit
• Biconomy - Smart Contract Wallet contest Findings & Analysis Report
• Ambire Wallet - Invitational Findings & Analysis Report
• ZeroDev Wallet Kernel Security Assessment

Publications

• The road to account abstraction
• ERC 4337: Account Abstraction via Entry Point Contract specification
• ERC 4337: account abstraction without Ethereum protocol changes
• ERC-4337 & Account Abstraction: A Comprehensive Overview
• A deep dive into the main components of ERC-4337: Account Abstraction Using Alt Mempool — Part 1
• A deep dive into the main components of ERC-4337: Account Abstraction Using Alt Mempool — Part 2
• A deep dive into the main components of ERC-4337: Account Abstraction Using Alt Mempool — Part 3
• A deep dive into the main components of ERC-4337: Account Abstraction Using Alt Mempool — Part 4
• Smart Account Security: Auditing Account Abstraction
• ChainLight Patch Thursday - Account Abstraction Security Guide