Ethereum Developers Revisit Privacy With pERC-20 Token Proposal

pERC-20 would replace public balances with encrypted notes

pERC-20 is not designed as a wrapper around existing ERC-20 tokens. It is described as a replacement interface that is privacy-native from mint to transfer. The proposal would remove familiar ERC-20 functions such as balanceOf, approve, allowance and transferFrom, replacing them with a new IPERC20 interface built around mint, burn and transfer operations.

Each pERC-20 mint, burn or transfer operation would require a valid zero-knowledge proof. The system is designed so encrypted balances never appear in public state during a token’s lifecycle. Instead of public account balances, tokens would exist as encrypted cryptographic notes, similar to digital cash. Each note would represent a discrete amount, be owned by a key pair and be spendable exactly once.

The design draws heavily from ZK-UTXO architecture pioneered by Zcash. Specific Zcash-linked influences include the Groth16 proof system and Orchard-style note commitments, adapted for Ethereum Virtual Machine deployment. The proposal also uses Poseidon hash commitments for note construction because Poseidon is optimized for zero-knowledge circuit efficiency.

Transaction validity would be verified through Groth16 zero-knowledge proofs, the same proof system used by Zcash at scale. The proof would let the network confirm that inputs equal outputs and that the spender owns the notes being consumed, without revealing the actual values involved.

Ownership would be proven through standard ECDSA signatures, which is why the system is described as EVM-native and wallet-compatible. The proposal is also described as MetaMask-compatible and requiring no new precompile, meaning it could launch at the application-standard level without requiring a protocol-level Ethereum mainnet change.

Spent-note tracking would happen in O(1) time with configurable epoch cleanup. That structure is presented as a way to prevent the unbounded state growth that affected earlier on-chain privacy experiments.

pERC-20 does not hide every part of a transaction system. Total token supply would remain publicly visible, allowing observers to verify that new tokens are not being secretly created. The proposal also includes a compliance mechanism that would allow issuers to freeze specific notes through a cryptographic blacklist without exposing ordinary users’ balances or transaction histories.

The blacklist mechanism positions pERC-20 as regulation-aware infrastructure rather than a privacy-maximalist tool. That design reflects a broader shift from a binary debate over privacy versus compliance toward systems that attempt to support both in the same architecture.

A June 4, 2026 post from ethresearchbot described the proposal as “pERC20 – Privacy-Native Fungible Tokens.” The same post said pERC20 is “Not ERC-20 compatible by design,” because it removes public balance and allowance concepts and replaces transfers with a ZK note-based interface.

One major limitation remains in the VOSA design. Amounts are hidden, but the public transfer graph is preserved, meaning observers can still see which addresses interacted with which addresses. That leaves relationship metadata visible even when balances and transaction amounts are concealed.

pERC-20 remains a draft. The standard would still need to move through the ERC review process before broad deployment. Its first practical milestone is whether it advances from forum discussion into a stable interface with a reference implementation.

We’ve launched the all-new COIN360 Perp DEX, built for traders who move fast!

Trade 130+ assets with up to 100× leverage, enjoy instant order placement and low-slippage swaps, and earn USDC passive yield while climbing the leaderboard. Your trades deserve more than speed — they deserve mastery.

STRK20 expands the privacy discussion beyond token transfers

Starknet has launched STRK20, a privacy-focused token framework aimed at extending confidentiality beyond simple token transfers. STRK20 is designed for DeFi use cases such as lending, staking and token swaps.

Eli Ben-Sasson, the co-founder of StarkWare, the main developer firm behind Starknet, said the biggest obstacle facing privacy technologies today is not cryptography. “The big problem of dealing with privacy is UX,” Ben-Sasson said.

Ben-Sasson said privacy systems need large anonymity sets, because if only a small number of users participate, it becomes easier to identify individual participants. “If the UX is bad, very few users are going to be using it,” he said. “If very few users are going to be using it, and only for a very small number of things, they don’t really get a lot of anonymity.”

Ben-Sasson said pERC-20 appears mostly focused on private token transfers and draws on ideas pioneered by privacy-focused projects such as Zcash. He described private transfers as important, but said the next stage of privacy infrastructure must support a wider range of financial activity. “Today we can do more,” Ben-Sasson said.

STRK20 was built around that broader goal. Rather than shielding a single token, it allows users to manage multiple assets under one unified privacy layer. According to Ben-Sasson, STRK20 users can access services such as swapping, borrowing and staking without sacrificing privacy.

STRK20 also uses post-quantum secure cryptography. Ben-Sasson said post-quantum security will become increasingly important as blockchain developers prepare for future advances in quantum computing.

The contrast between pERC-20 and STRK20 shows two emerging approaches to crypto privacy design. One approach focuses on making payments private while leaving more of the broader ecosystem transparent. The other approach treats privacy as a foundational layer across financial applications.

pERC-20 fits the first approach more clearly, with private token transfers, visible total supply, compliance hooks and some public metadata. STRK20 fits the second approach more clearly, with a broader privacy environment for DeFi actions, multiple assets and application-level confidentiality.