Ethereum's Hegota may provide new building blocks for privacy applications

Ethereum Hegotá upgrades or new building blocks for privacy apps

The August 6 core developer agenda set this date as the deadline for submission of proposals rather than a decision on Hegotá 's final feature set. Frame Transactions is one of the proposals currently under evaluation. Two related drafts-Keyed Nonces and Recent Roots-demonstrate how the transaction model, if adopted, will support wallets and privacy applications.

Frame Transactions splits transactions into programmable phases

EIP-8141, or Frame Transactions, proposes a new type of Ethereum transaction consisting of programmable frames. Different frames can verify actions, approve fuel payments, or perform user target calls. Selected frames can also be combined into atomic batches: if one frame fails, all state changes made by other frames in the batch will be rolled back. This structure provides wallets with more native options for batch processing, key rotation and complex transaction authorization. It can also allow one account or service to pay for fuel while another account authorizes operations.

Keyed Nonces Create independent anti-playback fields

Ethereum usually uses a single incremental nonce for each account. This number determines the order of transactions and prevents the same transaction from being executed twice. EIP-8250 will replace the single nonce in Frame Transactions with a set of nonce keys and serial numbers. Transactions that use non-overlapping non-zero key sets will be anti-reply-independent. This is about using a privacy protocol for shared senders so that each user does not expose a unique public sender address. Under a single nonce sequence, a delayed operation can interfere with other unrelated operations committed through the sender.

Keyed Nonces solves this anti-playback constraint, but does not provide privacy in itself. The nonce key is still visible in transaction data. The proposal also retains the rule of EIP-8141, which states that each sender can only have one pending Frame Transaction in the public mempool. Therefore, a separate nonce domain itself does not allow multiple Frame Transactions from the same sender to be pending in the common mempool at the same time.

Recent Roots avoids variable memory reads during verification

Privacy applications often use a commitment tree, with the closest root representing the commitments that users can use to justify spending. Frame Transaction verification cannot read any external storage controlled by other applications because the storage may change while the transaction is pending. EIP-8272, or Recent Roots, proposes a limited alternative. The root causes write the root to the system contract, and Frame Transactions can specify specific sources, slots, and roots in its signature data. The Ethereum client checks for this reference before the frame is executed. This allows applications to verify certificates against recent commitment roots without relying on external storage of changes during verification.

The proposal allows up to 16 root references in a transaction and limits the validity period of each root. It does not make ordinary ETH transfers private, but rather provides a layer of infrastructure that allows privacy applications to be used in conjunction with Frame Transactions.

The deadline has not yet finalized that the three EIPs of Hegotá

are still draft. EIP-8250 and EIP-8272 rely on EIP-8141, so neither can be activated independently. The August 6 deadline only closes the submission window for non-key proposals. Developers still need to decide whether Frame Transactions should be included in Hegotá, and if so, whether the design it relies on is ready to follow.

This combination of account flexibility, privacy and cryptographic resilience is also reflected in Ethereum's changing roadmap. But for now, these are still proposals under review and not features available to Ethereum users.

Disclaimer: This article is for reference 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 developer agenda of Hegotá and the draft specifications of EIP-8141, EIP-8250, and EIP-8272.