Four ways to make a token private, and what separates them

pERC20, EIP-8182, and STRK20 arrived inside three months, alongside ERC-7984, the incumbent. They are four answers to different questions and the people building them are arguing.

Within a single quarter, the EVM world produced four separate ways to hold and move a token without publishing the balance. In March, Tom Lehman, a co-founder of the Layer 2 network Facet, published EIP-8182, a protocol-level shielded pool for private ETH and ERC-20 transfers, and in May pitched it for inclusion in Ethereum's Hegota hard fork. That same month Starknet announced STRK20, a privacy layer for every token on the network, and shipped it in June. Then in June a developer working as Cyimon, under the banner PERC20Labs, posted pERC20, a token standard that is private from the moment it is minted, an open draft still in flux, renumbered twice in two weeks (7605, then 8287, now 8289) across successive pull requests to the ERCs repository. All of it sits alongside ERC-7984, the confidential-token standard OpenZeppelin and Zama have had live on mainnet since the winter.

A reader watching this go by could be forgiven for filing it under noise: another quarter, another batch of privacy tokens. But the four are not redundant, and they are actually not really competing on the same ground. They separate as to where privacy attaches and what it covers, and also how the anonymity that privacy depends on gets pooled.

Issuance versus shielding

The cleanest split is between privatizing assets that already exist and issuing assets that are private from the start.

EIP-8182 is the first kind. It is a Standards Track core proposal, so, a change to the protocol, activated by a hard fork, that installs a single shielded pool as a system contract at a fixed address, with no admin key, proxy, or pause function. A holder deposits public ETH or an ERC-20 into the pool, moves value privately inside it, and withdraws back to a public address when finished. The design takes a Zcash-style shielded-pool model of note commitments, nullifiers, a Poseidon-hashed Merkle tree, a Groth16 proof over BN254 and re-expresses it as Ethereum protocol stuff. It privatizes the assets the network already has.

pERC20 defines an application-layer token interface, IPERC20, in which a token exists as encrypted Orchard-style notes from issuance onward, with a public totalSupply but private balances and transfers. There is no public-to-private conversion step because there is no public phase to convert from. This is meant to complement protocol-level work because the two privatize different things, one shielding existing public assets and the other defining how a natively private asset is issued in the first place.

ERC-7984 describes a confidential token, but it ships an ERC-20 wrapper extension that converts a public ERC-20 into a confidential balance and back at a fixed rate, shielding existing assets, while also supporting native confidential issuance. STRK20 takes the shielding route at the level of an entire ecosystem: one Starknet Privacy Pool that any ERC-20 on the network can enter, transact inside, and exit.

Notes versus encrypted balances

Three of the four (EIP-8182, pERC20, and STRK20) are built on shielded-pool zero-knowledge designs, the Zcash lineage in which value lives in encrypted commitments rather than public balances. ERC-7984 is built on account-based encrypted balances, where every balance and transfer amount is stored on-chain as a fully homomorphic encryption ciphertext handle, manipulated through Zama's fhEVM co-processor.

EIP-8182's rationale section argues against the model ERC-7984 is built on, that account-based encrypted balances leak access patterns, (which accounts transact and how often) even when the amounts themselves stay hidden, and UTXO notes avoid that because spending a note simply produces fresh commitments that reveal nothing about who holds what.

pERC20's rationale makes the same case in nearly the same terms. The question is about whether the FHE balance model leaks too much metadata to be the right substrate, and the FHE camp would counter that the access-pattern objection is the price to pay for composability.

The composability wall

If it's just about private transfers, the actual private transfer is the easy part. The hard part is doing anything else with the token.

The original pERC20 draft removed balanceOf, approve, and allowance outright, so there is no public balance to read or to approve against, because account state is held locally by the user and only private state lives on-chain. But stripping balanceOf breaks compatibility with most of the DeFi protocols in existence, and if the sender-recipient link is already hidden, why also hide the balance at the cost of so many use cases? Cyimon's answer was that letting users selectively disclose a balance would be a useful feature to add later. The revision that followed restored approved spending — approve, allowance, and transferFrom — implemented through one-time subaccounts so that on-chain every movement still looks like the same private transfer. A standing approve(contract) allowance, the pattern that lets a DEX router or lending pool pull tokens autonomously, has no equivalent, because spending a note requires a private key and a contract cannot hold one. Approved spending works for externally owned accounts but it does not reach the contract-driven composability that DeFi runs on.

This is the missing piece Eli Ben-Sasson, the StarkWare co-founder, pointed at when CoinDesk covered the proposals: pERC20 is largely about private transfers, and doing more than that is the harder problem. STRK20 is built as Starknet's answer to it, with anonymous swaps on the Ekubo exchange and anonymous staking, all of it written in Cairo so that the client-side proof and the on-chain contract share one codebase and existing Starknet accounts work unchanged. The trade is platform lock-in, so it is not something an Ethereum-L1 or general-EVM team can adopt. Composability and portability are, for now, pulling in opposite directions.

The anonymity-set problem

Privacy depends on a crowd to hide in, and a crowd is hard to assemble.

Lehman's entire argument for putting EIP-8182 in the protocol rests on it. Application-level privacy pools, he argues, cannot offer meaningful anonymity without a critical mass of users, and cannot attract users without anonymity already in place, and competition between pools only fragments the crowd further. A single shared pool at the base layer that every wallet and application draws on is his way out. It is, by construction, an argument against the application-layer approach the other designs take. EIP-8182 does not arrive alone, either: it is one of three privacy proposals aimed at Hegota, alongside EIP-8141, which lets pools pay withdrawal fees from withdrawn funds, and EIP-8250, which adds keyed nonces for shared-sender designs.

What the regulator gets

EIP-8182 builds in nothing: its rationale explicitly rejects in-protocol compliance primitives — no allowlists, no freeze, no risk scores — on the grounds that encoding one compliance model into the protocol is less expressive than building it off-chain and commits the base layer to a single regime by hard fork.

pERC20 builds in a freeze at the note level: an admin maintains an off-chain blacklist whose root is posted on-chain, and the circuit proves that a spent note is not on it.

ERC-7984 offers a freezer role that can lock a holder's tokens and a per-account observer who can be granted visibility into balances and transfers.

STRK20 takes a fourth path: every user registers an encrypted viewing key on entry, and a designated auditor can decrypt one user's key on a legal request and trace their history without touching anyone else's.

To these four can be added the live precedent that concerns Circle's address-level freeze of the contract behind Zama's confidential USDC, which froze the pooled collateral of everyone wrapped into it.

Or you privatize the environment

Why not just make the chain private, and let the token inherit it?

Aztec tried the token-standard route first. Its note-based zkERC20, proposed in 2019, is the direct ancestor of the design pERC20 now revives, and it did not take. What Aztec's team built over the years since is Aztec, a privacy-preserving Layer 2 whose Ignition mainnet chain went live in November 2025. On Aztec, contracts are written in the Noir language and carry dual private and public state; a developer marks each function private or public and composes between them, users execute the private logic locally and submit a zero-knowledge proof, and permissionless sequencers validate it without seeing the data before settling to Ethereum. Privacy is a property of the execution environment and it spans data, identity, and compute. Aztec frames the problem it set out to solve — wrapping and unwrapping tokens leaks privacy and breaks composability, and smart contracts cannot easily work with encrypted balances — in terms that double as a critique of the wrapper and FHE-balance approaches.

Miden, a Polygon spin-off that raised $25 million in a round led by a16z crypto, takes the same altitude with a different posture. Its accounts hide balances and transactions by default, transactions execute locally on the user's own device, privacy is selectable per transaction, and the cryptography is post-quantum. Miden also names, more squarely than anyone else in this set, the cost of privatizing the environment: private-by-default accounts break the coordination tools finance depends on, like backup, recovery, multi-device sync, policy enforcement, which is why it built a private state-management layer it calls Guardian to restore those functions without a custodian holding keys.

OpenZeppelin, the same security library author behind ERC-7984's FHE confidential token on the EVM, has begun an early, explicitly experimental confidential contracts library for Miden, written in Miden Assembly and Rust and built on that private state-management layer. It is one of several privacy substrates the firm is now porting its patterns to at once, alongside Zama's fhEVM and a Compact library for the Midnight chain. The standards layer, in other words, is not betting on a single privacy architecture.

What comes next

Which of these bets will matter most? Consider whether the externally-owned-account limit on approved spending permanently walls a native-private token like pERC20 off from contract-driven DeFi, or whether the predicate-authorized and MPC-custody approaches its author defers as future work can bridge it.

Consider also whether a per-asset token standard can ever assemble an anonymity set deep enough to be worth using, or whether the shielding camp is right that privacy has to be pooled at the protocol or network level to work at all.

But also, does privacy belong on the token at all? Maybe Aztec and Miden are right to privatize the chain, inherit privacy everywhere, and pay for it in ecosystem bootstrapping.

The builders, at least, agree on the questions.