Ethereum core developers have moved EIP-8141, known as Frame Transactions, to Scheduled for Inclusion for the Hegotá network upgrade. The decision came during All Core Devs Execution call #244, where client teams agreed to prioritize native account abstraction while continuing work on the proposal’s final architecture. The scheduling gives EIP-8141 a formal place in Hegotá’s development path, but it does not freeze the specification in its current form.
The official EIP-8141 specification introduces a new transaction type composed of programmable “frames” that can handle validation, gas payment and execution. Instead of requiring every account to rely on Ethereum’s conventional ECDSA authentication model, accounts could define validation logic through the EVM. That would make key rotation, alternative signature schemes, batched actions and flexible fee payment native capabilities at the protocol level.
Frame Transactions Open a Post-Quantum Migration Path
One of EIP-8141’s longer-term objectives is preparing Ethereum accounts for post-quantum cryptography. Because authentication becomes programmable, wallets could eventually switch from ECDSA to quantum-resistant signature systems without requiring Ethereum to migrate every account simultaneously. Frames provide an account-level escape path from elliptic-curve signatures rather than making Ethereum fully quantum-resistant by themselves.
That distinction is significant because Ethereum’s cryptographic exposure extends well beyond user accounts. Ethereum’s security roadmap identifies validator BLS signatures, KZG commitments, account ECDSA signatures and some zero-knowledge proof systems as separate areas requiring post-quantum work. The U.S. National Institute of Standards and Technology has similarly urged organizations to begin migrating toward post-quantum cryptography well before cryptographically relevant quantum computers exist. EIP-8141 addresses one component of a much larger cryptographic transition.
The proposal remains a Draft EIP even after being scheduled for Hegotá. “Scheduled for Inclusion” is a fork-planning designation rather than final technical approval, and developers explicitly said during ACDE #244 that Frames should continue evolving as implementation and interoperability questions are resolved. Client testing, specification changes and devnets can still materially reshape what ultimately ships.
Ethereum and L2 Teams Still Need to Converge
A major unresolved issue involves compatibility with Layer 2 networks. Base has been developing EIP-8130, an alternative native account-abstraction design centered on account configurations and predictable authentication costs. Base plans to introduce that architecture through its own upgrade path, creating pressure to avoid incompatible account systems between Ethereum L1 and its rollups. The current objective is to preserve a common user experience even if L1 and L2 implementation requirements differ.
During ACDE #244, developers discussed modifying EIP-8141 so that L2 requirements around static analysis, denial-of-service resistance and high-throughput validation can be accommodated. Participants agreed to increase account-abstraction breakout meetings to a weekly cadence while the two approaches converge. Scheduling Frames therefore establishes direction without ending the technical debate between EIP-8141 and EIP-8130.
Hegotá itself is expected in 2027, following Glamsterdam, and its scope is still being finalized. EIP-8141 now joins FOCIL among the upgrade’s highest-priority features, giving Hegotá significant changes across both execution and consensus. For Ethereum, the immediate milestone is not mainnet activation but turning native account abstraction from a selected architecture into client implementations that can survive devnet and public-testnet testing.