Draft EIP-8287 outlines privacy-native fungible token standard for the EVM

What the draft proposes

The draft introduces a standard interface called IPERC20 for tokens built around privacy from issuance onward. Instead of exposing balances through a public account model, the proposal uses encrypted UTXO-style notes and Groth16 zero-knowledge proofs in what it describes as an Orchard-style model.

Under the draft, fungible assets would not be binary-compatible with ERC-20. Public functions such as balanceOf, approve and transferFrom are not part of the interface. In their place, the standard defines private transfer, mint and burn flows using a PrivacyCall-based action bundle.

How balances and transfers would work

The proposal centers on encrypted notes that carry value and recipient information. Key elements include note commitments, called cmx, nullifiers, or nf, and an anchor that refers to a historical root. Receiving addresses are represented through a privacy address format identified as perc1.

The specification highlights several goals: privacy by default, no public account balances, and publicly auditable totalSupply. It also defines fixed note-encryption formats and on-chain data structures such as PrivacyCall and BundleAction to standardize how wallets, indexers and related services interact with these assets.

Transfers, burns and mints would all require Groth16 proofs. According to the draft, valueBalance encoding is used to preserve conservation of value, while supply invariants are intended to ensure that changes in supply can only happen through controlled mint, burn and transfer actions.

Compliance and blacklist controls

A central feature of the proposal is a compliance mechanism tied to each asset. Every pERC20 token must bind to a compliance blacklist root, named cmxFrozenRoot, that is maintained by the asset contract. Notes on that blacklist cannot be spent.

The blacklist itself would remain off-chain, with only its root stored on-chain. The proof system is designed to enforce that spent notes are not members of the blacklist rooted at the current cmxFrozenRoot. The draft also states that an administrator can update that root, and that minting is restricted to the token issuer.

The interface includes methods such as name, symbol, decimals, totalSupply, issuer, cmxFrozenRoot, setFrozenRoot, transfer, mint and burn. Instead of public Transfer events, the draft uses NoteAdded and NoteConfirmed events to provide per-note observability.

Compatibility limits and possible use cases

Because EIP-8287 does not preserve ERC-20’s public balance and allowance model, the draft explicitly says it is not binary-compatible with the existing token standard. That limits direct interoperability with public DeFi systems built around ERC-20 assumptions.

The document suggests that integration with those systems could happen through an optional bridge to a public ERC-20 representation, though it presents that as a possibility rather than a built-in requirement.

If adopted, EIP-8287 would give Ethereum developers a common interface for fungible assets whose privacy is native rather than added later through wrappers or application-specific designs. At the same time, the draft keeps one core transparency feature: a publicly verifiable totalSupply intended to prevent hidden inflation, even as balances and transfer amounts remain private by default.