Key Highlights
- Ethereum researchers are debating native UTXOs as a way to reduce permanent state growth for one-time payments.
- The latest discussion has shifted toward privacy, data retention, wallet discovery, and whether UTXOs need a protocol-level data field.
- Researchers warned that users may rely on wallets, RPC providers, or specialized UTXO providers to retain opening data after history pruning.
Ethereum’s proposed native UTXO model has entered a new phase of debate, as researchers are now questioning whether the design can support private wallet discovery and reliable data retention before becoming a serious protocol-level scaling proposal.
The discussion began with a July 6 EthResearch post by Nero_eth, which argued that Ethereum could support Bitcoin-style one-time payment objects without abandoning its account model. The post said native UTXOs could reduce permanent state usage for payment workloads by roughly 99.8%, because Ethereum would store only a spent marker instead of keeping full payment-related account or storage state forever.
However, the latest comments on July 9 show the debate moving beyond state reduction. Researchers are now focused on whether the proposal creates new problems around privacy, wallet sync, old data availability, and the incentives for keeping UTXO opening data available.
Privacy Becomes a Key Issue
The latest development came after Nero_eth suggested that wallets could use light clients and peer-to-peer requests to discover UTXOs filtered by recipient. He said this could work in a way similar to wallets on UTXO-based or privacy-focused chains such as Bitcoin, Zcash, and Monero.
WGlynn pushed back, arguing that this creates a deeper privacy tradeoff. According to the comment, filtering UTXOs by recipient may work for transparent payments, but it breaks down for stealth-address payments because the query can reveal which outputs belong to a user. The alternative is scanning all outputs, which makes wallet sync heavier.
This turns wallet discovery into one of the biggest open questions in the proposal. If wallets ask a provider for only their UTXOs, they may leak ownership information. If they scan everything privately, the user experience becomes heavier.
Researchers Push for a UTXO data Field
Another major update in the discussion is the push to add a protocol-opaque data field to the UTXO object.
Georgeh argued that native UTXOs could support shielded pools, escrow payments, and other privacy-focused use cases if each UTXO carried optional extra data. He said putting this information directly inside the UTXO object could be simpler and cheaper than relying on separate smart contract commitments or additional event logs.
WGlynn supported the idea, saying the same field could also help wallet discovery. He pointed to view-tag-style scanning, where a small hint attached to each output could make scanning much faster while leaking little information. He argued that adding this field later would require an encoding change, so the format may need to reserve room before the design hardens.
This is now one of the most important design questions: whether Ethereum UTXOs should remain minimal or include a flexible data slot for privacy, scanning, and future applications.
Data Retention Remains Unresolved
The second major challenge is data retention.
The proposal does not store full UTXO openings directly in Ethereum state. Instead, users must prove that a UTXO was created by using opening data and a proof against an openings root. That keeps state small, but it raises a practical question: who keeps the opening data available years later?
Nero_eth said openings may not need to follow normal history-pruning rules. He argued that even if nodes prune old historical blocks under models such as EIP-4444, they could still extract and retain UTXO openings during sync. He also said RPC providers, local nodes, wallets, or specialized UTXO providers could serve this data.
WGlynn said this is not enough because the proposal does not yet explain the incentive model for UTXO providers. He asked what happens if no provider retains a user’s opening data, adding that making retention easy is different from making it someone’s responsibility.
He proposed a possible solution: a small retention bounty could be escrowed when a UTXO is created and later claimed by whoever provides the opening when the UTXO is spent. This would make data availability an economic service rather than an assumption.
One-Block Delay Confirmed
The discussion also confirmed an important timing limitation. Nero_eth said there would be a one-block delay between creating and spending a UTXO because the UTXO must be proven against the block’s post-state.
WGlynn noted that this differs from Bitcoin, where child transactions can reference parent transactions in the mempool and both can be confirmed in the same block. Under the Ethereum proposal, newly created UTXOs cannot be spent immediately in the same block because the relevant root only exists after the block ends.
That detail matters for payment systems, exchanges, arbitrage flows, and any service that depends on fast chained transactions.
EIP-8141 Remains the Base Layer
The native UTXO proposal depends on EIP-8141, a draft Ethereum Improvement Proposal for frame transactions. EIP-8141 introduces a transaction structure where validation, execution, gas payment, and signatures can be handled through frames.
In the UTXO proposal, this frame model is important because it could allow a UTXO to pay for its own transaction fee. That would let a fresh recipient spend a UTXO even if their Ethereum account has no ETH balance.
The debate now is not only whether UTXOs can work technically, but whether the design can avoid creating new wallet, privacy, and data-availability burdens.
What Comes Next?
The proposal is still at the research-discussion stage and has not become a formal Ethereum upgrade. The latest EthResearch comments show that the idea has drawn serious technical interest, but also that core design questions remain unresolved.
The next major issues to watch are whether the UTXO format adds a data field, whether Ethereum defines a standard way to discover and prove UTXOs, and whether the proposal includes incentives for providers to retain opening data after history pruning.
For now, Ethereum’s native UTXO debate has moved from a simple state-saving idea to a broader discussion about how Ethereum wallets, privacy systems, and data providers would actually support one-time payment objects at scale.
Also Read: Vitalik Proposes an ‘Extremely Lean’ Ethereum That Re-Anonymizes Validators Daily
