T27 · Account Abstraction

A Real-World Problem

You built a lightweight onchain app. The feature itself takes three clicks on first use.

For a new user, the real flow is:

1. Install a wallet extension
2. Copy twelve English words, then select them again in order
3. Buy a little native token somewhere or the first action cannot be sent
4. Click "Start," then confirm a signature popup
5. Click Next and sign again
6. Click Next again and sign a third time

Your funnel shows one hundred visitors, thirty who install a wallet, fifteen who finish the recovery phrase, five who acquire gas, and two who complete their first action.

Nothing is wrong with the product itself. All the drop-off occurs in the act of becoming an onchain account.

Three months later, one of those two users asks for help. They changed phones, lost the wallet, and cannot find the paper note holding the recovery phrase. Can you restore it?

You cannot.

These are two sides of one property: for an externally owned account (EOA), the private key is the entire account. Possess it and you have every permission; lose it and you have none.

There is no “only play this game” permission, no “at most ten dollars per trade” rule, and no recovery procedure after key loss.

Can this all-or-nothing model be split apart?

Thought Experiment

Compare two kinds of account.

First: a safe with one key.

Whoever holds the key controls the safe. The key cannot open only its left half. It cannot be canceled or replaced: the safe recognizes the key, not a person. Lose it and you are locked out forever; have it stolen and your contents are gone.

Here, “who can move the money” is a physical fact.

Second: a company's bank account.

There is no single master key, but a set of rules:

- A cashier may pay up to 5,000
- A finance director may pay up to 50,000
- Above 500,000, two people must sign
- Monthly rent and utilities are recurring payments without individual approvals
- If the chair's seal is lost, publish notice, wait for objections, and issue a new one

These rules do four things the safe cannot: tier by amount, grant permissions by purpose, require several decision-makers, and recover from a lost key.

One difference makes it possible:

In the safe, who can move funds is a physical fact. In the company account, it is a readable, changeable, auditable rule.

Account abstraction puts that rule onchain as code. The account becomes a contract rather than an address derived from a public key. One function answers “Do I authorize this operation?”

So far that sounds ideal. But code creates another question:

Who may change the rule?

A safe has one way to fail: a lost key. A programmable rule adds another: the rule can be changed.

You moved risk from a physical problem into governance. The rest of this chapter handles that new problem.

Your Decision

Return to the funnel. You can improve one thing first.

What Happens

Compare the routes:

Reading the key-loss and single-point columns together gives the first conclusion:

Account abstraction does not remove keys. It divides one key's unlimited power among several keys with different scopes and adds a path to recover after loss.

That is a real improvement: account-level “permissions” gain meaning.

It also demands a second conclusion:

Once permissions can be divided, the boundaries between them become attack surfaces.

An EOA exposes one key. A smart account exposes at least five things: its contract code, session-scope definition, sponsor policy, recovery mechanism, and who can modify all four.

The risk has moved to a new place. That place has one major advantage: it can be audited, tested, and expressed as assertions. You cannot write a test for a lost paper phrase; you can test a session key's scope.

This mirrors T32: structured proposals, deterministic validation, configurable policy, and traceable logs. Account abstraction puts a policy engine in the contract.

Build a Model

The central split: validation versus execution

The design starts by separating two steps:

validate(op)  →  Do the account's rules authorize this operation? (Do not act yet.)
execute(op)   →  Perform it, only after validation passes

For an EOA, a valid signature effectively combines both, with no intermediate rules. In a smart account, authorization becomes code you can write.

The complete path of one operation

The user signs an operation intent rather than sending a transaction. Another party places it onchain.

Three roles here do not exist in the EOA flow:

As in the last chapter, a bundler is transport; it affects delivery, not authenticity. “Many bundlers make us secure” confuses those layers.

Smart-account core

Here is the essential part; the rest is surrounding infrastructure:

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

contract SmartAccount {
    address public owner;                 // Primary key
    uint256 public nonce;                 // Replay protection
    address public immutable entryPoint;  // Only accepted entry

    struct SessionKey {
        uint48  validUntil;    // Expiry
        uint128 spendLimit;    // Cumulative limit in smallest units
        uint128 spent;         // Amount used so far
        bool    enabled;
    }

    // Session key → scope
    mapping(address => SessionKey) public sessions;
    // Session key → target contract → function selector → allowed?
    mapping(address => mapping(address => mapping(bytes4 => bool))) public allowed;

    constructor(address ep, address o) {
        entryPoint = ep;
        owner = o;
    }

    modifier onlyEntryPoint() {
        require(msg.sender == entryPoint, "not entry point");
        _;
    }

    /// Validation: decide authorization without external calls
    function validate(
        bytes32 opHash,
        bytes calldata signature,
        address target,
        bytes4  selector,
        uint256 value
    ) external onlyEntryPoint returns (bool) {
        address signer = recover(opHash, signature);

        // Primary key: unrestricted
        if (signer == owner) return true;

        // Session key: check each scope dimension
        SessionKey storage s = sessions[signer];
        if (!s.enabled) return false;
        if (block.timestamp > s.validUntil) return false;
        if (!allowed[signer][target][selector]) return false;
        if (value + s.spent > s.spendLimit) return false;

        // Charge cumulative allowance during validation to prevent repeated uses in a block
        s.spent = uint128(s.spent + value);
        return true;
    }

    /// Execution: called only after EntryPoint accepts validation
    function execute(address target, uint256 value, bytes calldata data)
        external
        onlyEntryPoint
    {
        (bool ok, bytes memory ret) = target.call{value: value}(data);
        if (!ok) {
            assembly { revert(add(ret, 32), mload(ret)) }
        }
    }

    function recover(bytes32, bytes calldata) internal pure returns (address) {
        return address(0); // Replace with signature recovery from your framework
    }
}

Four choices in that code match real failure classes.

First, onlyEntryPoint. Restrict the account's entry, or anyone can call execute and withdraw funds. This directly applies T7's rule to assume any public function will be called by strangers.

Second, deduct the cumulative allowance during validation. If deducted after execution, the same session key can be used repeatedly in one block while spent still shows the old value. It foreshadows reentrancy: state updates after use can be exploited repeatedly.

Third, avoid external calls during validation. Bundlers simulate validation offchain before paying to include an operation. If validation depends on external state, simulation can pass and chain execution fail, leaving the bundler to pay gas. Repeated failures drive bundlers away, so allowed validation behavior is tightly constrained.

Fourth, bubble the original failure from execution. T14 left a receipt-mapping question: a bundle has one transaction status but several inner operations. The account must preserve inner revert data so the interface can show which step failed.

Session keys: scope is everything

A session key is not “a weaker key”; it is a key with a defined scope. That scope decides whether it is useful or dangerous.

A usable scope needs at least six dimensions:

The selector row deserves special attention. Restricting only target contracts lets a game session key call an approval-like function on the game contract and grant an attacker-controlled address an allowance. The attacker then withdraws later.

This repeats T32's approval-versus-transfer issue:

Policy must cover every action that changes control of funds, not only transfers.

Paymasters: whoever pays gas needs their own policy

A paymaster pays on others' behalf. An unbounded subsidy is a pool anyone can drain repeatedly.

Three common models:

At minimum, set per-account count and amount limits, a daily global budget, allowed target contracts, and an immediate off switch.

The transfer-hook risk links to T9: a nonstandard token's transfer can hand control away. If payment collection includes that call, the paymaster introduces external execution into a critical path. The next chapter demonstrates what that can do.

Recovery: the most dangerous section of this chapter

A standard social-recovery flow:

1. Owner designates N guardians and a threshold M
2. On loss, M guardians sign a proposal to replace the primary key
3. A timelock begins for T days
4. During T days, the current primary key can cancel unconditionally
5. If not canceled, recovery takes effect after T days

Steps three and four supply the mechanism's security. Without them, M guardians are M keys that can take the account directly.

Even with them, misuse remains possible. Recovery designs often consider only a user losing their key; list other cases:

The fourth row matters. A timelock assumes the user can receive notice and cancel within its window. But events that lead to lost keys may also prevent the user from being online.

Three recovery rules matter more than the exact guardian count:

1. Proposals must emit an onchain event and trigger an offchain notification path. An unseen proposal makes the timelock useless.
2. The current primary key must cancel unconditionally and without delay. Cancellation should have no extra gate.
3. Verify guardian independence rather than assume it. Record how and when each guardian was confirmed.

One product decision remains: timelock length is a tradeoff, not merely a technical parameter. Short windows weaken protection against collusion; long ones punish legitimate recovery. Use different windows for different account values, akin to T17's confirmation tiers by business risk.

What It Is Called

Hands-on

Check 1: Primary key can execute any authorized operation
Check 2: Session key executes only inside scope; outside scope reverts
Check 3: An account with zero native-token balance still completes an operation
Check 4: Session key cannot bypass amount limits through an approval-like call

- Who is the onchain transaction's from address? (Not the user.)
- Which account paid gas?
- How many times did validate run?

- Enough guardians propose; primary key cancels in window: recovery must fail
- Enough guardians propose; nobody cancels: recovery must take effect
- Proposal emits an onchain event with initiator, new primary key, and effective time

AI Lab

Step one:
Design social recovery for a smart account. Specify the full state machine:
states, transition events, and exact actions each role may take in each state.
Describe contract functions, not only abstract behavior.

Step two:
List all trust assumptions as “if ___ cheats or fails, the account will be ___.”
Name concrete roles and numbers.

Step three:
Now act as an attacker. Your goal is to take an account using this recovery flow.
Give at least six attack paths. For each, include:
- The prerequisites you need
- The exact sequence of actions
- Which step of this recovery flow fails to stop you
- Whether the account owner has a chance to notice
Consider social engineering and timing, not only technical methods.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check