Ethereum’s Hegota Could Give Privacy Apps New Building Blocks

Ethereum developers have closed the submission window for non-headlining EIPs for Hegotá, the planned upgrade after Glamsterdam.
The August 6 core-developer agenda described the date as a cut-off for putting forward proposals, not a decision on Hegotá’s final feature set.
Frame Transactions is among the proposals now being assessed. Two dependent drafts, Keyed Nonces and Recent Roots, show how that transaction model could support wallets and privacy applications if it is adopted.
Frame Transactions split a transaction into programmable stages
EIP-8141, known as Frame Transactions, proposes a new Ethereum transaction type made up of programmable frames.
Different frames could validate an action, approve payment for gas or execute the user’s intended call. Selected frames could also be grouped into an atomic batch: if one fails, the state changes made by the other frames in that batch are reverted.
The structure could give wallets more native options for batching, key rotation and complex transaction authorization. It could also allow one account or service to pay gas while another account authorizes the action.
Keyed Nonces create separate replay-protection domains
Ethereum normally uses a single sequential nonce for each account. That number determines transaction order and prevents the same transaction from being executed twice.
EIP-8250 would replace that single nonce for Frame Transactions with a set of nonce keys and a sequence number. Transactions using non-overlapping non-zero key sets would be replay-independent.
This matters for privacy protocols that use a shared sender, so that each user does not expose a distinct public sender address. With a single nonce sequence, one delayed action can interfere with unrelated actions submitted through that sender.
Keyed Nonces address that replay-protection constraint, but they do not provide privacy on their own. The nonce keys remain visible in the transaction data.
The proposal also preserves EIP-8141’s rule allowing only one pending Frame Transaction per sender in the public mempool. Separate nonce domains would therefore not, by themselves, allow multiple Frame Transactions from the same sender to remain pending publicly at once.
Recent Roots avoid mutable storage reads during validation
Privacy applications often use a commitment tree, with a recent root representing the commitments against which a user can prove a spend.
Frame Transaction validation cannot read arbitrary external storage controlled by another application. That storage could change while a transaction is pending.
EIP-8272, known as Recent Roots, proposes a limited alternative. A root source would write roots to a system contract, while a Frame Transaction could name a specific source, slot and root in its signed data.
Ethereum clients would check that reference before frame execution. The application could then validate a proof against a recent commitment root without relying on changing external storage during validation.
The proposal permits up to 16 root references in one transaction and limits how long each remains valid.
It would not make ordinary ETH transfers private. It would provide an infrastructure layer that privacy applications could use alongside Frame Transactions.
The deadline did not finalize Hegotá
All three EIPs are still drafts. EIP-8250 and EIP-8272 also require EIP-8141, so neither could be activated independently.
The August 6 deadline merely closed the window for new non-headlining proposals. Developers must still decide whether Frame Transactions belong in Hegotá and, if so, whether the dependent designs are ready to follow.
That combination of account flexibility, privacy and cryptographic resilience is also visible in Ethereum’s changing roadmap. But for now, these are proposals under review—not features available to Ethereum users.
Disclaimer: The article is for informational purposes only. EIP-8141, EIP-8250 and EIP-8272 are draft proposals that may change, be excluded from Hegotá or never be activated.
Methodology: This article is based on the official Hegotá developer agenda and the draft specifications for EIP-8141, EIP-8250 and EIP-8272.









