4 hours ago
22
64. That is the MAX_FRAMES parameter proposed in EIP‑8141, a number that turns a monolithic Ethereum transaction into a sequence the protocol can step through. It signals a post‑EOA model: validation, gas approval and execution no longer fused into a single blob, but orchestrated frame by frame. The design opens space for native account abstraction, unconventional signature schemes and flexible gas payment, and it is the substrate on which next‑generation wallet UX and on‑chain privacy would ride. Yet while the mechanism exists on paper, the Hegotá upgrade is currently led by a different bet: enforced inclusion.
Frame Transactions refactor a transaction into up to 64 frames
EIP‑8141 defines a new FRAME_TX type that decomposes a user action into discrete frames, each with a specific role: a validation frame to check intent and authorization, a gas‑approval frame to resolve who pays and under what rules, and an execution frame to apply state changes. The proposal sets MAX_FRAMES = 64 and attaches explicit per‑frame costs, so complex workflows can be broken into bounded, metered steps rather than bespoke contract workarounds.
The functional payoff is native account abstraction. Instead of hard‑wiring the externally owned account model and ECDSA, frames let wallets and contracts specify custom signature schemes, rotate keys or migrate to post‑quantum‑resistant signatures without relying on an L2 or a third‑party relayer. Gas‑payment abstractions become first‑class as well: a user can define in‑protocol policies for who pays and how, from sponsor models to multi‑asset rules, encoded as a frame rather than an off‑chain agreement.
For privacy tooling, frames matter because they separate proving and authorization logic from state‑changing writes. A wallet could validate a zero‑knowledge proof under a scheme of its choosing in one frame, approve gas in another, then commit the private transfer in the execution frame. The protocol gets a standard, verifiable choreography; application teams are not forced to replicate envelope contracts for every new use case.
All of that remains contingent on inclusion in a network upgrade. And here, Hegotá’s priorities put inclusion before refactoring.
Hegotá’s headliner is enforced inclusion, not privacy
In its April 10, 2026 developer update, the Ethereum Foundation confirmed that FOCIL (EIP‑7805) is the Hegotá headliner. Fork‑Choice Enforced Inclusion Lists are a consensus and execution mechanism intended to guarantee timely transaction inclusion, mitigating builder‑level censorship that can quietly strand transactions outside the canonical chain.
In the same update, the Foundation noted that Frame Transactions (EIP‑8141) moved to “Considered for Inclusion” as a non‑headliner. That label commits protocol teams to work on the feature but with no elevation to centerpiece status. Timing is uncertain, and with it the schedule for native account abstraction and the wallet‑level gains that frames would unlock.
The ordering speaks to first principles. Inclusion guarantees are a prerequisite for any serious privacy layer. If builders or block producers can suppress or indefinitely delay transactions, a private write is only private until it fails to land at all. By locking in FOCIL, Hegotá aims to harden the guarantee that private submissions, whether shielded transfers or proof‑heavy updates, actually reach the chain.
Canonical shielded transfers on L1 aim to fix fragmented anonymity
The other privacy plank now on Ethereum’s roadmap is a single, protocol‑managed shielded pool deployed via fork. EIP‑8182 proposes a system contract capable of private ETH and compatible ERC‑20 transfers using a split‑proof architecture: a pool proof to show that a transfer is consistent with the shielded state, and a separate auth proof to demonstrate spending authority. The objective is to build one canonical pool into L1 rather than rely on a patchwork of application‑level mixers with small, fragmented anonymity sets. The Ethereum privacy roadmap lists EIP‑8182 as being considered for Hegotá alongside Frame Transactions, and notes that protocol changes alone are insufficient to deliver end‑to‑end privacy.
Privacy depends on a chain beyond protocol changes
The roadmap updated on July 27, 2026 breaks the problem into three outcomes — private reads, private writes and private proving — and states plainly that shipping a new transaction type or a system‑level pool will not complete the picture. Several complementary layers must arrive together:
- Private Information Retrieval for private reads, so wallets can discover and fetch relevant data without revealing interests to servers.
- Frame Transactions plus FOCIL for censorship‑resistant submission, so private writes are structured and cannot be indefinitely excluded.
- Client‑side proving and zkVMs for confidential semantics, so users can generate proofs locally without leaking sensitive details to third parties.
Only with these components composing cleanly does a user journey become genuinely private: discover a balance without signaling it, prepare a transfer without outsourcing secrets, and submit it under a protocol that can neither second‑guess nor stall the transaction. Hegotá can lay the rails for parts of this sequence, but the access layer and proving stack have to keep pace.
That dependency chain also shapes wallet UX. Frames promise to normalize how authorization and gas policy are expressed, but developers still need battle‑tested libraries for local proof creation and efficient circuits, and users need client software that can handle proof generation within acceptable latency and power budgets. Without those, a canonical pool risks existing as a powerful primitive that few mainstream users can exercise.
Regulatory precedent looms over a protocol‑native shielded pool
Compliance is a second constraint. On August 8, 2022, the U.S. Treasury’s Office of Foreign Assets Control sanctioned the Tornado Cash mixer, setting a reference point for how privacy and mixing infrastructure can be treated by regulators. The press release and subsequent prosecutions underscored that tools enabling anonymized transfers can attract enforcement action.
A fork‑managed L1 pool is not equivalent to a third‑party service, but the precedent still matters. Exchanges, wallet providers and infrastructure operators that must interpret sanctions risk could moderate or restrict interactions with a native pool even if it is canonical and audited. That affects not just optics but also the practical reach of private transfers, and it introduces operational decisions for entities that intermediate user access to Ethereum.
Hegotá’s sequencing is clear: enforced inclusion is locked in, while the frame‑based transaction refactor sits at “Considered for Inclusion.” Ethereum can likely guarantee that private writes are not censored before it can natively decompose and authorize them under a new transaction type. Whether a fork‑managed shielded pool delivers practical privacy depends on that ordering — and on non‑protocol components like PIR and client‑side proving arriving in time.
Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.
English (US) ·