Chapters

Protocol

Block building & execution

Once a transaction is selected, execution follows a fixed order. Understanding it clarifies receipt fields, phase semantics, and why sponsor reimbursement can survive a failed user call.

Execution order

  1. If account_changes include config or delegation: read lock; reject if locked. Delegation requires admin EOA-actor authority (native secp256k1 self).
  2. Deduct ETH gas from payer (sponsor or self). Invalid if insufficient balance.
  3. If not nonce-free: increment Nonce Manager for (sender, nonce_key). Nonce-free: skip.
  4. If no code, no create, no delegation: auto-delegate to default account implementation (0xef0100 || DEFAULT), persistent.
  5. Process account_changes in order (create / config / delegation).
  6. Set Transaction Context precompile (sender, payer, actorId, calls).
  7. Execute call phases.

Unused execution gas refunds to the payer. Intrinsic gas (including auth) is not refundable, protocol SHOULD inject config-related logs into the receipt (EIP-7708-style).

Call phases (builder-relevant)

Each phase is an atomic executeBatch: Completed phases are not rolled back if a later phase reverts. That is the sponsor guarantee: phase 0 can pay the payer; phase 1 can fail without undoing payment.

  • On phase revert: that phase’s state rolls back; later phases skip.
  • Receipts expose phaseStatuses[] so indexers distinguish pay-OK / action-fail.
  • Top-level status is success only if all phases succeeded (or calls empty), which keeps naive tools roughly correct.

Receipt extensions

  • payer: who paid gas.
  • status: all-phases aggregate.
  • phaseStatuses: per-phase 0x01 / 0x00.

RPC extensions builders/wallets need

  • eth_getTransactionCount with optional nonceKey.
  • Receipt fields above on eth_getTransactionReceipt.
  • EIP-8130-aware eth_estimateGas (auth priced by blob shape, not a real signature).

Tie-back to revalidation

With mempool hardening, dead txs should already be gone before selection (executor state-diff / BAL → WatchSet index). Between admission and inclusion, only hot invalidators matter, and they are exact-match slots, balance reservations, or expiry buckets, not full wallet re-simulation.

Why Transaction Context is a precompile

Context is immutable tx metadata, so a precompile at TX_CONTEXT_ADDRESS reads the client's in-memory struct directly: protocol writes cost nothing (no journaling or rollback tracking), authenticators pull the fields they need, and new context fields are added as new precompile methods without changing IAuthenticator. It is populated only while the transaction's calls are dispatched.