Ethereum developers have begun filtering candidates for Hegotá, the network upgrade meant to follow Glamsterdam. Ethereum Foundation researcher and proposal co-author Toni Wahrstätter said 66 changes were still “on the table” on August 16. That number describes a candidate pool, not the contents of a release ready for activation.

One cluster built around “Frame Transactions” could make wallets more flexible and reduce some of the outside infrastructure that private-payment applications need. The specifications are still drafts, however, and they would not make ordinary ether transfers confidential.

What actually changed

The new event is not an Ethereum activation. It is the move from collecting ideas to selecting them. The agenda for the August 13 All Core Devs Execution meeting says the proposed-for-inclusion, or PFI, list should be finalised roughly two weeks later. A proposal without a clearly identified champion is supposed to be dropped automatically.

Teams maintaining the main Ethereum clients must then publish their preferences by September 10. That stage matters. An idea can be technically attractive without having several implementations, a realistic testing schedule or enough support to enter a network upgrade.

The count of 66 comes from an August 16 public post by Toni Wahrstätter. It combines proposals with very different scope and maturity. Some address computation or memory pricing; others cover validators, quantum resistance, block construction or account behaviour.

“Hegotá” therefore does not yet mean a frozen package. CoinDesk independently reported that the next developer meetings will narrow the list before implementations, devnets and testnets. Treating all 66 proposals as an adopted roadmap would be misleading.

Frame Transactions would change the transaction structure

EIP-8141, still labelled “Draft”, proposes a new transaction type split into frames. Some frames verify authorisation, others approve gas payment or execute the requested actions. The protocol could therefore accept validation rules other than the conventional signature imposed on ordinary accounts today.

The possible user effects are tangible: rotate a key without moving the account, bundle several actions, let another party cover the fee, or eventually adopt a different cryptographic system. For wallets, that flexibility moves capabilities now assembled through contracts and relayers closer to a format understood directly by the protocol.

The August 13 agenda says Frames are “considered for inclusion”, or CFI, for Hegotá. That is more advanced than a basic candidacy, but it is not a final specification or a deployment promise. The same agenda records an EVM-compatibility objection and mentions a competing direction for account abstraction.

GatherHub’s Blockchain course explains why a change to shared rules requires agreement and upgrades across several independent software clients. A published EIP is not active code: it still has to be implemented, tested and selected for the fork specifications.

How the package could help private applications

Two companion drafts explain the current privacy interest. EIP-8250 proposes independent transaction counters called keyed nonces. A privacy application may route many users through a shared address so each action is not automatically tied to a personal address. With one linear counter, a delayed transaction can block everything behind it. Separate domains would reduce that bottleneck.

EIP-8272 would let a transaction refer to a recent cryptographic root already checked by the protocol. An application could prove that a spend belongs to a recent commitment set without reading external state that may change during validation. The draft explicitly targets the commitment trees used by privacy systems.

Both mechanisms depend on EIP-8141 and are themselves drafts. They improve plumbing that a private application can use; they hide no data by themselves. The cryptographic proof, commitment management and disclosure rules remain application responsibilities.

A conventional ETH transfer between two addresses would still be public. Amounts, addresses and history would remain readable. Even inside a specialised application, network metadata, regulated on- and off-ramps, or careless address reuse can reconnect a user with their activity.

Privacy and censorship resistance solve different problems

Hegotá also includes work that is not designed to hide transactions. EIP-7805, known as FOCIL, proposes that a validator committee produce inclusion lists. Attesters would withhold support from a block that omitted a still-valid transaction found in those lists.

The goal is censorship resistance: reducing a dominant block builder’s ability to exclude a transaction. It does not encrypt the address, amount or content. A transaction can be difficult to censor while remaining fully public; it can also be cryptographically private while depending on a small group of relayers able to block it.

This distinction keeps the conclusion narrow. Hegotá gathers several projects affecting how transactions are sent and included, but they do not solve the same problem or move at the same speed.

The risks of a more programmable transaction

Moving more logic into the protocol can remove intermediaries, but it also expands the surface that every client must implement in exactly the same way. A disagreement over validation, fee accounting or execution order could make clients reject transactions differently or, in the worst case, disagree about the chain state.

Frame Transactions introduce several modes, multiple signatures, a separate fee payer and as many as 64 frames in the current draft. Keyed nonces and recent roots add state and validity rules. Developers must weigh these features against denial-of-service risks, gas costs, mempool complexity and a wallet’s ability to show users what they are authorising.

Privacy also creates an operational and regulatory trade-off. A company may want to protect payroll or treasury activity without making flows impossible to audit. Protocol engineering alone cannot decide which information should be visible, to whom and under what conditions.

What to watch next

The next All Core Devs Consensus call on August 20 again lists Hegotá. The PFI list is expected near the end of August, followed by client preferences on September 10. These are selection milestones, not activation dates.

The next evidence will be implementations in multiple clients, devnets, test results and whether the EIP-8141/8250/8272 package survives the process. Until then, GatherHub’s conclusion is limited: Ethereum is evaluating a more native foundation for programmable transactions and some private applications; it is not launching a confidential network.

Sources reviewed