11 - Security Audit Assignment and Account Abstraction

Grading Methodology

Workflow

As Developer (initial setup):

As Auditor:

Important: All audit work stays in your private fork. Do not push anything to Developer’s original repository.

As Developer (triage and fixes):

Important: Apply fixes separately in each Auditor’s private fork. Do not share fixes between auditors' forks or push to your original repository during audit period.

Privacy: Each Auditor works in their own private fork. Multiple Auditors cannot see each other’s findings.

All materials (PR, report PDF, issues, triage responses) remain in private fork for instructor evaluation.

Introduction

This section explores Account Abstraction – a fundamental improvement to Ethereum’s account model that addresses limitations of Externally Owned Accounts (EOAs) introduced in Tutorials 3 and 4.

Tutorial Prerequisites

Tutorial Objectives

After completing this section, students should be able to:

Problem Statement: EOA Limitations

EOAs are public-private key pairs with a binary access model:

Account Abstraction: The Solution

Account abstraction decouples authentication logic from the protocol layer, enabling smart contracts to define custom:

Implementation: EIP-4337

EIP-4337 introduces account abstraction without modifying Ethereum’s core protocol. Deployed to Mainnet on March 1, 2023, it has seen significant adoption, particularly on Layer 2 networks, with millions of smart accounts deployed across Ethereum, Arbitrum, Optimism, Polygon, and Base.

{
  "sender": "0x...",           // Smart wallet address
  "nonce": "0x1",
  "initCode": "0x...",         // Wallet deployment code (if needed)
  "callData": "0x...",         // Operation to execute
  "callGasLimit": "0x...",
  "verificationGasLimit": "0x...",
  "preVerificationGas": "0x...",
  "maxFeePerGas": "0x...",
  "maxPriorityFeePerGas": "0x...",
  "paymasterAndData": "0x...", // Gas sponsorship data
  "signature": "0x..."         // Wallet-specific signature
}

Transaction Flow

The following diagram illustrates the complete EIP-4337 architecture and transaction flow:

Flow explanation:

1. User creates UserOperation – The Smart Contract Wallet generates a UserOperation containing transaction details: sender, callData, signature, nonce, and gas parameters (callGasLimit, verificationGasLimit, maxFeePerGas)
2. Alternative Mempool – UserOperations are sent to a separate mempool (not Ethereum’s standard mempool) where bundlers can access them
3. Bundler collects operations – The Bundler (off-chain actor) selects multiple UserOperations and bundles them together
4. Bundler simulates – The Bundler calls the EntryPoint Contract’s simulateValidation() to verify operations will succeed before submitting
5. Bundler executes – The Bundler submits the bundle to the EntryPoint Contract’s handleOps() function via a regular Ethereum transaction
6. Validation phase – The EntryPoint Contract calls each wallet’s validateUserOp() function:
   • If an Aggregator is specified, it validates aggregated signatures
   • If a Paymaster is specified (paymasterAndData), it validates and commits to sponsor gas fees
   • The Smart Contract Wallet verifies the operation is authorized
7. Execution phase – If validation passes, the EntryPoint Contract executes the operation (callData) in the wallet’s context
8. Result – The Smart Contract Wallet executes the intended operation (e.g., token transfer, contract interaction)

This separation of validation and execution enables arbitrary authentication logic while maintaining protocol security guarantees.

Implementation: EIP-7702

EIP-7702 enables native account abstraction by allowing EOAs to delegate to smart contract code. Deployed as part of Ethereum’s Pectra upgrade on May 7, 2025.

Key Features Enabled

contract SocialRecoveryWallet {
    address[] public guardians;
    uint256 public threshold;
    mapping(address => mapping(address => bool)) public recoveryApprovals;

    function initiateRecovery(address newOwner) external {
        require(isGuardian(msg.sender), "Not a guardian");
        recoveryApprovals[newOwner][msg.sender] = true;

        if (countApprovals(newOwner) >= threshold) {
            owner = newOwner;
        }
    }
}

struct SessionKey {
    address key;
    uint256 validUntil;
    uint256 spendingLimit;
    address[] allowedContracts;
}

// Single transaction replacing approve + swap
wallet.executeBatch([
    Call(token, abi.encodeCall(IERC20.approve, (dex, amount))),
    Call(dex, abi.encodeCall(IDex.swap, (tokenIn, tokenOut, amount)))
]);

Security Considerations

// Malicious contract
contract Malicious {
    // Storage slot 0 matches wallet's owner variable
    address public owner;

    function attack() external {
        // Changes the wallet's owner to attacker
        owner = msg.sender;
    }
}

// If wallet executes: delegatecall(malicious.attack())
// The attacker becomes the new owner

function checkTransaction(
    address to,
    uint256 value,
    bytes memory data,
    Enum.Operation operation,
    ...
) external view override {
    // Prevent delegatecalls to untrusted addresses
    require(
        operation != Enum.Operation.DelegateCall ||
        allowedTargets[to].delegateCallAllowed,
        "Delegate call not allowed to this address"
    );

    // Whitelist target addresses
    require(allowedTargets[to].allowed, "Target address is not allowed");

    // Restrict ETH transfers
    if (value > 0) {
        require(allowedTargets[to].valueAllowed, "Cannot send ETH to this target");
    }

    // Whitelist function selectors
    if (data.length >= 4) {
        require(
            !allowedTargets[to].scoped ||
            allowedTargets[to].allowedFunctions[bytes4(data)],
            "Target function is not allowed"
        );
    }
}

# Verify a Safe transaction on Arbitrum
./safe_hashes.sh --network arbitrum \
  --address 0x111CEEee040739fD91D29C34C33E6B3E112F2177 \
  --nonce 234

Resources