EIP-8141 Frame Transaction
DraftCorecreated 2026-01-297 later proposals build on itrequires EIP-1559, EIP-2718, EIP-2780, EIP-3529, EIP-3607, EIP-4844, EIP-7594, EIP-7623, EIP-7702, EIP-7708, EIP-7778, EIP-7825, EIP-8037
Add frame abstraction for transaction validation, execution, and gas payment
Authors: Vitalik Buterin (@vbuterin), lightclient (@lightclient), Felix Lange (@fjl), Yoav Weiss (@yoavw), Alex Forshtat (@forshtat), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Derek Chiang (@derekchiang), Toni Wahrstätter (@nerolation), Stavros Vlachakis (@svlachakis)
Depends on (13)
Proposals this one names in its requires field.
EIP-1559Fee market change for ETH 1.0 chainEIP-2718Typed Transaction EnvelopeEIP-2780Resource-based intrinsic transaction gasEIP-3529Reduction in refundsEIP-3607Reject transactions from senders with deployed codeEIP-4844Shard Blob TransactionsEIP-7594PeerDAS - Peer Data Availability SamplingEIP-7623Increase calldata costEIP-7702Set Code for EOAsEIP-7708ETH transfers emit a logEIP-7778Block Gas Accounting without RefundsEIP-7825Transaction Gas Limit CapEIP-8037State Creation Gas Cost IncreaseBuilt on by (7)
Later proposals that name this one in their requires field.
EIP-7906Transaction Assertions via State Diff OpcodeEIP-8209Commit-Reveal Transaction FramesEIP-8250Keyed Nonces for Frame TransactionsEIP-8266Expiring Nonces for Frame TransactionsEIP-8272Recent Roots for Frame TransactionsERC-8286Modular Accounts for Frame TransactionsEIP-8369VOPS Profiles for FOCIL EligibilityWhat the specification covers
AbstractMotivationSpecificationConstantsFrame TransactionPayload EncodingField DefinitionsOuter transaction payloadFrame objectFlagsSignature objectConstraintsTransaction SignaturesReceipt EncodingSignature HashSignature ValidationExpiry Verifier FrameBehaviorCross-frame interactionsGas AccountingFrame gas poolsState-gas attribution and refillsTransaction settlementBlock-level gas accountingBlob handlingDefault codeAPPROVE Instruction (0xaa)StackScope OperandBehaviorGasIntrospectionTXPARAM Instruction (0xb0)FRAMEDATALOAD Instruction 0xb1FRAMEDATACOPY Instruction (0xb2)FRAMEPARAM Instruction (0xb3)SIGPARAM Instruction (0xb4)SIGDATACOPY Instruction (0xb5)MempoolConstantsValidation PrefixPolicy SummaryMode SubclassificationsPublic Mempool-recognized Validation PrefixesSelf RelayBasic TransactionDeploy New AccountCanonical PaymasterBasic TransactionDeploy New AccountStructural RulesExpiry Verifier FrameCanonical Paymaster ExceptionDirect Evaluation of Protocol-Defined FramesValidation Trace RulesBanned OpcodesPaymastersCanonical paymasterNon-canonical paymasterAcceptance AlgorithmReplacement and EvictionRevalidationTransaction originationNetworkingRationaleCanonical signature hashAPPROVE calling conventionPayer in receiptNo authorization listNo access listAtomic batchingPer-frame costFrame entry access chargePer-frame valueTwo-dimensional gas budgetsCalldata floor and paymentCross-frame state-gas refillsIntrinsic cost decompositionTransaction execution gas capPublic Key AliasesExternally Owned Account (EOA) supportNon-canonical paymasters in the mempoolExamplesExample 1: Simple TransactionExample 1a: Simple ETH transferExample 1b: Simple account deploymentExample 2: Atomic Approve + SwapExample 3: Sponsored Transaction (Fee Payment in ERC-20)Data EfficiencyBlob supportBackwards CompatibilitySecurity ConsiderationsTransaction PropagationExample AttackDeploy Frame Front-RunningExplicit Sender State-Read AmplificationCross-frame Data Visibility During ValidationArbitrary Signature MalleabilityMitigationsState Gas Isolation Between FramesExecution Approval Authorizes All Subsequent Sender FramesCopyright
This proposal declares no Solidity interface, so there is nothing to compute. It may be a core protocol change, a meta proposal, or written in prose only.
Compare with
Parsed from the canonical specification · discussion