Ethereum developers recently disclosed new progress in the design of EIP-8141. The proposal aims to implement certain transaction functionalities as programmable contract calls, known as "frames," rather than modifying the Ethereum transaction format each time a new feature is added.
The trading functionality has been changed to programmable invocation.
This approach covers functionalities such as transaction expiration, aggregated signatures, Merkle roots related to privacy pools, and assertion checks after transaction execution. Developers believe that if this interface is sufficiently generic, when Ethereum introduces new verification methods in the future, wallets, browsers, signing devices, and Layer 2 solutions will not need to adapt to new transaction wrappers each time.
The EIP-8141 draft defines a Frame Transaction as a sequence of contract calls. Different frames can be responsible for verifying transaction conditions, approving gas payments, or executing user actions.
The current draft outlines three modes: DEFAULT, VERIFY, and SENDER. The VERIFY frame is used to check whether a condition is satisfied, while the SENDER frame represents performing an action as the transaction sender. Multiple frames can also be grouped into an atomic batch, which either succeeds entirely or rolls back as a whole.
Reduce wallet and infrastructure coordination costs
Developer Derek Chiang’s core insight is that future new features don’t necessarily require designing an entirely new trading wrapper; by expressing them through new frame targets and invocation patterns, functionality can be expanded while maintaining a stable underlying structure.
Each modification to Ethereum's transaction format affects not only execution clients—wallets, Layer 2 solutions, block explorers, hardware and software signing libraries, and various infrastructure providers must all understand and support the new format.
Chiang stated that Ethereum upgrades occur approximately every nine months, and frequently changing transaction packaging would incur high coordination costs. In contrast, if the frame format could become a more stable interface, new validation methods could be more readily handled by contracts or designated protocol components.
However, this does not mean that all future features can bypass network upgrades. EIP-8141 itself still modifies Ethereum’s consensus rules and requires client implementations. If it involves new opcodes, precompiled contracts, or gas rules, a hard fork may still be necessary.
EIP-8130 and the Direction of Parallel Verification
Developers also acknowledge that increasing transaction abstraction makes it more difficult for wallets and sequencers to analyze transactions before execution. To address this, the team is researching how EIP-8141 can work in conjunction with another account abstraction proposal, EIP-8130.
EIP-8130 proposes an on-chain keystore structure that allows accounts to pre-register participants and authentication contracts, and explicitly specify the authentication method in transactions. This enables nodes to determine the required verification process before executing any wallet code. For Layer 2, this helps limit authentication methods to a set of more predictable costs.
Vitalik Buterin also explained the direction in another post, breaking transactions into two parts: "actions" and "dependency conditions." The former is responsible for changing the Ethereum state, while the latter includes prerequisite conditions such as signatures, Merkle proofs, or zero-knowledge proofs. If these dependencies are independent of each other, they could potentially be checked in parallel in the future, reducing the processing cost of certain transactions.
Listed on Hegotá, but activation time is yet to be determined.
The official Hegotá Meta EIP has listed Frame Transactions as one of the planned upgrades, indicating that its status has progressed further than before. However, EIP-8141 remains a core draft, and technical details have not yet been finalized.
Remaining tasks include updating the specifications, completing the execution client implementation, setting up a development network, and conducting interoperability testing with wallets and Layer 2 systems. Developers also need to assess mempool denial-of-service risks, as programmable validation may increase the computational cost of filtering out invalid transactions.
Currently, the activation times for Hegotá on Sepolia, Hoodi, and mainnet are still pending. EIP-8141 has been included in the upgrade roadmap, but there remains a period of implementation and testing before final deployment.