I’ve been watching Ethereum’s roadmap for years, and every now and then a proposal lands that makes me sit up a little straighter. This week it was the quiet suggestion that privacy pools could one day pay their own network fees without leaning on any third-party relayer. The idea sits inside the larger conversation about the 2027 Hegotá upgrade, and it feels like one of those rare moments when technical design and real-user experience actually line up.
Why Self-Funded Privacy Pools Matter Right Now
Privacy on Ethereum has always been a bit of a compromise. You can hide the amounts and the counterparties inside a pool, yet the act of submitting the transaction itself still needs someone to pay the gas. That someone is usually a relayer. And relayers, by definition, sit in the middle. They see timing patterns, they see which wallets interact with which contracts, and they introduce a potential point of failure or observation. Removing that middle layer is not just a nice-to-have. It changes the entire threat model.
Researchers inside the Protocol Architecture team have started pushing two specific changes that, together, could make this possible. One is Frame Transactions. The other is FOCIL. Neither is brand new, but the way they are being packaged for Hegotá feels deliberate. I’ve found that the most interesting upgrades are rarely the flashy ones. They are the quiet plumbing improvements that let other applications breathe.
Frame Transactions as a New Kind of Transaction Format
Frame Transactions, tracked as EIP-8141, reimagine what a transaction can look like. Instead of the rigid structure Ethereum has used for years, the proposal introduces programmable frames. Think of them as modular pieces of logic that a wallet or application can assemble. Validation, execution, and fee payment can each live in their own frame. That flexibility opens doors that used to stay locked.
Wallets could sponsor gas for users without complicated workarounds. Alternative signature schemes become practical. Key rotation stops feeling like a nightmare. And for privacy pools, the most immediate win is the ability for the pool itself to cover the fee. No external relayer needed. The transaction can carry its own payment instructions inside the frame.
I’ve always thought the current transaction format was a little too opinionated. It worked when Ethereum was smaller. It starts to show its age when you try to build sophisticated account-abstraction features on top of it. Frames feel like a reset button that still respects the underlying security model.
Together with Frames, these enable privacy pools where the pool itself can pay fees, removing the need for intermediaries.
That single sentence captures the practical upside. Once the pool can pay, the user no longer needs to reveal anything extra to an outside service just to get the transaction onto the network.
How Keyed Nonces and Recent Roots Fit In
Frame Transactions do not travel alone. They are designed to work alongside Keyed Nonces and Recent Roots, listed under EIP-8272. Keyed Nonces let an account keep several independent transaction sequences. That matters when you want parallel activity without the classic nonce bottleneck. Recent Roots allow a transaction to reference a recent state without locking itself to one specific block hash. Both features reduce the friction that currently forces privacy tools into awkward workarounds.
Add Transaction Assertions, or EIP-7906, and the package starts to feel complete. Assertions let a wallet declare conditions that must still be true when the transaction is finally processed. Users gain a way to limit what can happen after they sign. In a privacy context, that extra control is valuable. You can sign knowing the transaction will only execute under the exact circumstances you intended.
Some client teams are still comparing EIP-8141 with another account-abstraction proposal, EIP-8130. The debate is healthy. Better to argue now than to ship something half-baked later. A breakout meeting is already on the calendar for late August, with a final preference expected shortly after. Execution teams have until early September to submit their own lists for Hegotá.
FOCIL and the Fight Against Selective Exclusion
FOCIL, short for Fork-Choice Enforced Inclusion Lists and formally EIP-7805, is currently the only proposal locked in for Hegotá. That alone tells you something. The design lets a committee of validators publish lists of transactions that block builders are expected to include. If a builder leaves eligible transactions out, attesters can reject the block. It is a protocol-level check against censorship.
Privacy transactions stand to benefit more than most. Right now, a specialized builder can simply ignore a privacy-related transaction if it looks inconvenient or risky. FOCIL does not make the transaction private by itself. What it does is raise the cost of excluding it. Protocol rules start to protect inclusion the same way they already protect consensus.
In my experience, the most effective censorship resistance is the kind that does not rely on goodwill. FOCIL moves the decision from the builder’s private preference list into a public, enforceable process. Combine that with Frames that let the pool pay its own fees, and you suddenly have both independent payment and stronger inclusion guarantees. That combination is rare.
The Bigger Picture of Hegotá Planning
Hegotá is scheduled to follow Glamsterdam, the upgrade expected before the end of 2026. Glamsterdam focuses on enshrined proposer-builder separation and block-level access lists. Those changes already reshape how blocks are built and how data is prepared. Hegotá extends the work into privacy, account abstraction, state management, and further scaling.
Right now sixty-six proposals sit under discussion. That number is not a promise. Most will never reach a testnet. Developers keep repeating the same caution: a fork cannot become a wishlist. Choices have to be made about engineering capacity, testing time, and risk. Privacy and quantum resistance both appear in longer-term roadmaps, but they still compete for the same limited resources.
One researcher put it plainly: the community and core developers cannot keep jamming every possible improvement into the next fork. Prioritization is the real work. FOCIL already has its place. Frame Transactions are being argued as the natural partner that should share the spotlight.
What Changes for Everyday Users
If the package ships roughly as proposed, the experience of using a privacy pool becomes quieter. You interact with the pool. The pool handles the fee. The transaction still has to clear the inclusion rules, but those rules now lean in favor of eligible transactions rather than leaving everything to builder discretion. The surface area for observation shrinks.
None of this rewrites the legal landscape. Questions around sanctions screening, money-transmission rules, and compliance remain outside the protocol. The EIPs themselves stay silent on how any specific application should handle those obligations. They simply remove technical obstacles that currently force extra parties into the flow.
I’ve spoken with people who build privacy tools, and the consistent complaint is the same: every extra hop is another place where metadata leaks. Self-funding frames and protocol-enforced inclusion lists attack that problem from two different angles at once. That dual approach feels more robust than any single clever trick.
Technical Details Worth Understanding
Frames divide transaction logic into programmable sections. One frame can handle validation. Another can manage execution. A third can arrange payment. Because the pieces are modular, wallets and applications gain room to innovate without waiting for another hard fork. Account abstraction stops being a layer of clever hacks and starts looking like a native capability.
Keyed Nonces solve the sequential bottleneck. An account can maintain separate counters for different activities. Parallelism becomes practical. Recent Roots loosen the tight coupling to a single block. A transaction can still prove it is recent without becoming invalid the moment the chain advances one more block. Assertions add a final layer of user control: the conditions you set at signing time must still hold at execution time.
FOCIL works at the consensus layer. Validators publish inclusion lists. Builders are expected to honor them. Attesters enforce the expectation by rejecting non-compliant blocks. The mechanism does not guarantee every transaction will be included. It does guarantee that systematic exclusion becomes expensive and visible.
- Frame Transactions open programmable fee payment and validation logic
- Keyed Nonces allow independent transaction sequences per account
- Recent Roots reduce dependence on a single fixed block reference
- Transaction Assertions let users constrain post-signing behavior
- FOCIL creates protocol-level pressure against selective exclusion
Taken together, the pieces form a coherent package rather than a collection of unrelated ideas. That coherence is what makes the researcher’s preference list interesting. It is not a random assortment. It is an attempt to solve payment and inclusion in one coordinated step.
Risks and Open Questions
No upgrade is free of trade-offs. Programmable frames introduce new surface area for bugs. Client implementations will need careful review. FOCIL adds complexity to the fork-choice rule. Attesters must stay online and honest. The committee that produces inclusion lists must itself remain resistant to capture. These are real engineering challenges, not theoretical footnotes.
There is also the simple question of timing. Hegotá is still more than a year away. Preferences can shift. Competing proposals can gain support. Testing can reveal unexpected interactions with other planned changes. The September preference lists from client teams will give a clearer picture, yet even those lists are not final decisions.
Perhaps the most interesting open question is cultural. Ethereum has spent years arguing about the right balance between privacy and transparency. Protocol-level tools that make privacy pools more practical will re-open that conversation. Some will welcome the reduced reliance on intermediaries. Others will worry about the compliance implications. The technical design does not settle the social debate. It only changes the tools available to both sides.
How This Fits the Longer Roadmap
Looking further out, privacy and quantum resistance both appear in multi-year plans. New cryptography, proof-based verification, redesigned storage, and native protocol privacy are all on the table for the next three to four years. Hegotá is one step inside that larger arc. Self-funded pools and stronger inclusion guarantees are practical milestones rather than final destinations.
Glamsterdam will already change how blocks are constructed and how access lists work. Those foundations make later privacy features easier to reason about. Higher gas limits, separate access-list data, and optional zero-knowledge proofs for the main network are all under study. Each of them competes for the same scarce engineering attention. Prioritization remains the hardest part of the job.
I’ve found that the upgrades that age best are the ones that quietly expand the design space without forcing every application to rewrite itself overnight. Frame Transactions and FOCIL feel like that kind of change. They do not demand that every wallet or every pool immediately adopt the new model. They simply make a cleaner model available.
What Developers Should Watch Next
The next few weeks matter. Client teams will compare the competing account-abstraction designs. Preference lists for Hegotá will start to firm up. Testnet experiments will eventually reveal whether Frames and FOCIL interact cleanly with the rest of the planned changes. Anyone building privacy tools or account-abstraction wallets has a clear incentive to follow those discussions closely.
For ordinary users the impact will arrive more slowly. Once the features land and applications adopt them, the experience of using a privacy pool should feel less fragile. Fewer intermediaries. Stronger inclusion guarantees. Less need to trust external services with metadata that never needed to leave the protocol in the first place.
That is the real promise. Not a sudden revolution, but a quieter network that leaks less by default. I’ve seen enough roadmaps to know that promises can slip. Still, the combination of self-funded frames and protocol-enforced inclusion lists is one of the more coherent privacy packages Ethereum has seriously considered in a long time. If the developers keep their focus, 2027 could deliver something genuinely useful rather than just another incremental hard fork.
The conversation is still early. Preferences can change. New objections can surface. Yet the direction of travel feels clear: reduce the places where privacy tools must depend on outside parties, and raise the cost of excluding those tools from the chain. That is a goal worth watching, even if the final list of EIPs looks a little different when Hegotá finally arrives.
In the end, the most practical upgrades are the ones that remove friction without creating new points of control. Frame Transactions and FOCIL aim at exactly that balance. Whether they both ship in 2027 or one of them waits for a later fork, the discussion itself already improves the design space. Privacy pools that can pay their own way and still expect fair inclusion would be a meaningful step forward. The network would become a little more neutral, a little less dependent on specialized intermediaries, and a little closer to the original idea that anyone with a valid transaction should be able to use the chain without asking permission first.
