New EIP!
pERC20 - Privacy-Native Fungible Tokens
🔗 github.com/ethereum/EIPs/…
Highlights:
- Not ERC-20 compatible by design: pERC20 removes public balance/allowance concepts (no balanceOf/approve/allowance/transferFrom) and replaces transfers with a ZK note-based interface (transfer(PrivacyCall)), because public balances would defeat the privacy goal.
- Privacy-native from issuance: tokens are always represented as encrypted ZK-UTXO notes (Orchard-style actions with Groth16 proofs); there is no “public-to-private shielding” step—transfers are note→note and amounts/participants are private by default.
- Public, on-chain verifiable supply: totalSupply remains public and is updated only through controlled mint(amount, ...) and burn(amount, ...); transfers must conserve value (valueBalance == 0), enabling “no invisible inflation” while keeping balances private.
- Built-in compliance via frozen-root binding: every action commits to the contract’s cmxFrozenRoot, and the ZK circuit must prove the spent note commitment is NOT in the blacklist SMT. Admin can update the root (setFrozenRoot) to freeze/unfreeze specific notes without revealing normal users’ balances.
- Security-critical invariants and checks: implementations must prevent double-spends with nullifiers and must range-check each public field (< Fr) to avoid nf + Fr-style bypasses; the core bundle execution must not be publicly callable to prevent unaccounted supply changes; signature points must be curve/field validated and replay protection must bind chainId + contract + note data.
ELI5:
This EIP proposes a new kind of token standard for Ethereum where people’s token amounts and who they pay are hidden by default. Instead of keeping a public “balance” per account like ERC-20, the token exists as many encrypted “notes” (like digital cash bills) that can be spent with zero-knowledge proofs. Everyone can still see the total number of tokens that exist (totalSupply) so the issuer can’t secretly create extra tokens. It also adds an optional-but-built-in “freeze list” mechanism: the token contract keeps a public fingerprint (root) of a blacklist, and the zero-knowledge proof must show you are not spending a frozen note.
pERC20 - Privacy-Native Fungible Tokens
🔗 github.com/ethereum/EIPs/…
Highlights:
- Not ERC-20 compatible by design: pERC20 removes public balance/allowance concepts (no balanceOf/approve/allowance/transferFrom) and replaces transfers with a ZK note-based interface (transfer(PrivacyCall)), because public balances would defeat the privacy goal.
- Privacy-native from issuance: tokens are always represented as encrypted ZK-UTXO notes (Orchard-style actions with Groth16 proofs); there is no “public-to-private shielding” step—transfers are note→note and amounts/participants are private by default.
- Public, on-chain verifiable supply: totalSupply remains public and is updated only through controlled mint(amount, ...) and burn(amount, ...); transfers must conserve value (valueBalance == 0), enabling “no invisible inflation” while keeping balances private.
- Built-in compliance via frozen-root binding: every action commits to the contract’s cmxFrozenRoot, and the ZK circuit must prove the spent note commitment is NOT in the blacklist SMT. Admin can update the root (setFrozenRoot) to freeze/unfreeze specific notes without revealing normal users’ balances.
- Security-critical invariants and checks: implementations must prevent double-spends with nullifiers and must range-check each public field (< Fr) to avoid nf + Fr-style bypasses; the core bundle execution must not be publicly callable to prevent unaccounted supply changes; signature points must be curve/field validated and replay protection must bind chainId + contract + note data.
ELI5:
This EIP proposes a new kind of token standard for Ethereum where people’s token amounts and who they pay are hidden by default. Instead of keeping a public “balance” per account like ERC-20, the token exists as many encrypted “notes” (like digital cash bills) that can be spent with zero-knowledge proofs. Everyone can still see the total number of tokens that exist (totalSupply) so the issuer can’t secretly create extra tokens. It also adds an optional-but-built-in “freeze list” mechanism: the token contract keeps a public fingerprint (root) of a blacklist, and the zero-knowledge proof must show you are not spending a frozen note.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
