FacebookTwitterLinkedInTelegramCopy LinkEmail
Blockchain

Ethereum’s Hegota Could Give Privacy Apps New Building Blocks

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.

Author
Kosta Gushterov, journalist in Coindoo.com

Reporter at Coindoo

Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work at Coindoo has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.

Learn more about crypto and blockchain technology.

Glossary