
ethereum
EIP-8182 Explained: Native Private Transfers Coming to Ethereum
EIP-8182 is a draft Ethereum proposal from Tom Lehman that adds a shared shielded pool and ZK verification precompile to the base layer. The design has no admin key or governance token, upgrades only through hard forks, and currently sits in Draft status as of April 202
MAY 04, 2026
Last updated MAY 04, 2026 · V1
TL;DR
EIP-8182 is a draft proposal to make private transfers a native feature of the Ethereum protocol.
Key facts:
- Authored by Tom Lehman and published in April 2026.
- Adds a single shared shielded pool as a system contract at a fixed address.
- Introduces a ZK proof-verification precompile.
- Has no admin key, no governance token, and no on-chain upgrade path.
- Upgrades only through Ethereum hard forks.
- Currently sits in Draft status.
- Targets the gap where fewer than 1 in 10,000 Ethereum transactions were private in 2025.
What Is EIP-8182?
EIP-8182 is a draft Ethereum Improvement Proposal that builds private ETH and ERC-20 transfers directly into the base layer. The proposal was published by developer Tom Lehman in April 2026 under the title “Private ETH and ERC-20 Transfers.”
The design embeds a single shielded pool into Ethereum itself rather than leaving privacy to separate apps. Anyone with a wallet that integrates the standard could send privately to any Ethereum address or ENS name.
Is There Privacy on Ethereum?
Almost every Ethereum transaction is fully public, exposing balances, amounts, and counterparties. In April 2025, Vitalik Buterin called for privacy tools to be built directly into wallets and privacy is also a part of the Strawmap Roadmap.
A year later, fewer than 1 in 10,000 Ethereum transactions were private, still below the 2020 peak. Two structural problems explain this phenomenon:
- The anonymity-set chicken-and-egg problem. A new privacy app cannot offer real privacy to early users, and without privacy nobody joins.
When you send a private transaction, anyone can still see that a private transaction happened on chain. What’s hidden is which user did it, out of the pool of users who could have done it.
So if 10,000 people use the same privacy pool, and one of them sends a private payment, an observer knows the sender is one of those 10,000 but can’t tell which. That group of “people who could have been the sender” is called the anonymity set.
The larger the anonymity set, the harder it is to guess the person behind the transaction.
- The trust model problem. App-level privacy systems require an upgrade mechanism owned by multisig signers, token holders, or a DAO.
Public transfers on Ethereum carry no such trust assumption. A private-transfer default cannot either.
How EIP-8182 Works
EIP-8182 places a shared ‘shielded pool’ inside Ethereum as a system contract at a fixed address, modeled on EIP-4788. The contract holds
- the note-commitment tree,
- nullifier set,
- key registries,
- authorization policy registry.
Alongside it, the proposal adds a zero-knowledge proof-verification precompile. The pool has no proxy, no admin function, and no on-chain upgrade hook, so changes occur only through Ethereum hard forks.
What You Can Build With EIP-8182
The proposal turns private transfers into a primitive that any wallet or app can call. Developers no longer need to bootstrap their own custom privacy tech.
Sends to Standard Ethereum Addresses
Recipients keep using normal Ethereum addresses and ENS names. A recipient registers once, and from then on anyone can send to that address privately.
Outsourced Proof Generation
Most wallets cannot generate zero-knowledge proofs on-device. EIP-8182 separates spend authorization from proving, so the user signs intent in the wallet and a remote prover handles the math.
The prover can compute but cannot decide. If it alters the transaction parameters, the proof fails verification.
Customizable Authorization
Authorization is fully extensible through account abstraction, with options including:
- passkeys,
- multisig,
- social recovery,
- single-private-key signing.
All authorization methods share the same anonymity set. The method itself stays private, so on-chain observers cannot tell which one a sender used.
Atomic Swap and Reshield
Private funds can leave the smart contract, hit a public smart contract, and return inside one transaction. A common flow unshields token A to a helper contract, swaps it for token B on a DEX, then redeposits token B back into the smart contract.
The swap remains visible like any DEX trade. The sender’s identity and the reshielded destination stay private.
What Stays Public and What Stays Private
| Action | Public on chain | Private on chain |
| Deposit | Depositor, token, amount | Recipient note |
| Shielded transfer | Nothing | Token, amount, sender, recipient |
| Withdrawal | Token, amount, recipient address | Origin inside smart contract |
The design hides the core transfer while leaving the fact that value entered or exited the pool visible.
EIP-8182 vs Existing Privacy Protocols
| Protocol | Type | Governance | In-Pool Transfers |
| Tornado Cash Classic | Mixer with fixed denominations | Immutable contracts | No |
| Privacy Pools | Mixer with dissociation proofs | App-level | No |
| Railgun | Multi-asset shielded pool | Token vote | Yes |
| Aztec | L2 for generic private compute | Multisig / Rollup DAO | Depends on app |
| EIP-8182 | Protocol-level shielded pool | Ethereum hard fork | Yes |
The closest comparison is Railgun, which also supports private in-pool transfers and atomic unshield flows. The main split is governance: Railgun upgrades through token holders, while EIP-8182 upgrades through Ethereum itself.
Risks and Open Questions
EIP-8182 faces three structural risks that the proposal’s optimistic framing tries to soften. Regulatory exposure, hard-fork inclusion uncertainty, and verifier soundness concentration each carry the potential to derail or compromise the design before it reaches mainnet.
Regulatory exposure
A protocol-enshrined ‘shielded pool’ with unconditional privacy and no compliance hooks might be materially harder for regulators to accept than app-level designs.
EIP-8182 offers no native dissociation tooling, opt-in allowlists, or proof-of-innocence mechanism inside the mechanism itself. That design choice protects user sovereignty but raises the ‘political’ cost of inclusion in a hard fork.
Hard-fork inclusion is a high bar
Draft status on an Ethereum Improvement Proposal is the start of a multi-year process. Most Draft EIPs never reach Final, and protocol-level privacy has been debated inside Ethereum core development circles since at least 2018 without reaching consensus on a single shared design.
EIP-8182 would need to clear:
- community review on Ethereum Magicians and All Core Devs calls,
- independent cryptographic audits of the proof system,
- client-team implementation across Geth, Nethermind, Besu, Erigon, and Reth,
- testnet deployment and shadow forks,
- inclusion in a future hard fork’s scope.
No timeline has been announced for any of these milestones.
Verifier soundness concentration
A single shared contract concentrates cryptographic risk across the entire shielded supply rather than fragmenting it across competing apps.
The system-contract model contains the blast radius to assets inside the pool, the bug cannot mint ETH or corrupt state outside it. That containment might be a real upside, but the absence of an on-chain upgrade hook means emergency patching may require a coordinated hard fork, which historically takes weeks to months rather than hours.
Scope of the Proposal
EIP-8182 is explicit about what it does not solve. End-to-end privacy still requires mempool encryption, network-layer anonymity, and wallet-side UX changes, all of which sit outside the scope of the proposal.
Status and What Comes Next
EIP-8182 sits in Draft status as of April 2026. The full specification, reference implementation, and FAQ are hosted at eip8182.com.
The proposal aligns with Ethereum’s 2026 roadmap, which Ethereum Foundation leaders have framed around faster finality and compliant privacy. A dedicated Privacy Cluster of 47 experts inside the Ethereum Foundation is pushing related work forward.
FAQ
Does EIP-8182 charge a protocol fee?
No. EIP-8182 does not charge a fee on deposits, transfers, or withdrawals. Users still pay normal Ethereum gas, plus any third-party proving or relaying costs.
When will EIP-8182 ship?
There is no confirmed timeline. EIP-8182 is in Draft status and would need to clear community review, audits, and inclusion in a future hard fork before activation.
Does EIP-8182 hide the amount I send?
Yes, shielded transfers inside the pool hide the token, amount, sender, and recipient from public view. Only deposits into the pool and withdrawals out of it expose the token and amount on chain, while the actual transfer between 2 users inside the pool reveals nothing.
Can I still use my existing Ethereum wallet with EIP-8182?
Yes, recipients keep using standard Ethereum addresses and ENS names with no separate privacy address format required. Wallets that integrate the standard let users send privately to any address after a one-time recipient registration step.
Is EIP-8182 live on Ethereum today?
No, EIP-8182 sits in Draft status as of April 2026 and is not deployed on Ethereum mainnet. The proposal would need to clear community review, independent audits, client implementation, and inclusion in a future hard fork before activation, with no timeline announced for any of those steps.
Disclaimer:
This article is for informational purposes only and does not constitute an endorsement of EIP-8182, Ethereum, Tom Lehman, or any protocol, project, or person mentioned. Nothing in this article is financial, legal, tax, or technical advice, and readers should conduct their own research and consult qualified professionals before acting on any information presented here.
The content reflects publicly available information as of April 30, 2026 and may become outdated as EIP-8182 evolves through community review. References to third-party protocols, including Tornado Cash, Privacy Pools, Railgun, and Aztec, are descriptive comparisons only and do not imply endorsement, partnership, or recommendation of any kind.
Share with your network