ERC: Encrypted Token Standard — FHE-encrypted balances with ZK transfer verification

ERCs
1

Summary

I’m proposing a new ERC that defines a standard interface for fungible tokens with Fully Homomorphic Encrypted (FHE) balances and zero-knowledge transfer verification.

In short: an ERC-20 where nobody can see your balance or transfer amounts — but anyone can verify that every transfer is valid.

PR: Add ERC: Encrypted Token Interface by Valisthea · Pull Request #1680 · ethereum/ERCs · GitHub
Repository: GitHub - Valisthea/styx-erc-encrypted-token: ERC-XXXX: Encrypted Token Standard — FHE-encrypted balances with ZK transfer verification. By Kairos Lab. · GitHub

Author: Valisthea

The Problem

ERC-20 exposes everything. Balances, transfer amounts, approval values — all public. This creates five concrete issues:

  1. Portfolio exposure — anyone can query your holdings, enabling targeted social engineering and front-running.

  2. Transfer surveillance — on-chain graph analysis de-anonymizes users even across mixers.

  3. MEV extraction — visible pending amounts enable sandwich attacks. Privacy is the only structural MEV fix at the token layer.

  4. Governance coercion — token-weighted DAO voting with visible balances enables vote buying and political retaliation.

  5. Regulatory tension — GDPR Article 17 (right to erasure), MiCA, and HIPAA conflict with permanent public balance storage.

Why Existing Solutions Don’t Work

Mixers / Privacy layers (Tornado Cash, Aztec Connect) are external wrappers. A shielded token cannot be used in Uniswap, Aave, or Compound without unshielding first — defeating the privacy guarantee. They break DeFi composability.

Commitment-based approaches (Pedersen, Poseidon hashes) hide values but don’t support computation. You can’t add two commitments without the sender’s cooperation. A lending protocol can’t compute a liquidation threshold on committed collateral.

FHE-native chains (Fhenix, Zama’s fhEVM) exist but have proposed no standard interface. Each implementation invents its own API. Wallets and protocols can’t integrate generically.

No ERC currently standardizes encrypted token balances. This proposal fills that gap.

What This Standard Defines

An interface that extends ERC-20 metadata (name, symbol, decimals, totalSupply) with encrypted counterparts for all privacy-sensitive operations:

Encrypted Queries

  • encryptedBalanceOf(address) → returns FHE ciphertext (only owner can decrypt)

  • encryptionScheme() → identifies which FHE scheme is used (TFHE, OpenFHE, etc.)

  • publicKey() → contract’s FHE public key (users encrypt inputs with this)

Blind Transfers

  • blindTransfer(to, encryptedAmount, proof) → transfer with ZK-verified validity

  • blindTransferFrom(from, to, encryptedAmount, proof) → delegated blind transfer

  • Event: BlindTransfer(from, to, proofHash) — no amount leaked

Encrypted Approvals

  • blindApprove(spender, encryptedAmount, proof) → encrypted allowance

  • encryptedAllowance(owner, spender) → ciphertext of remaining allowance

Selective Disclosure (optional)

  • verifyBalancePredicate(account, predicate, proof) → proves “balance ≥ X” without revealing balance

Shield / Unshield Bridge (optional extension)

  • shield(amount) → move from public ERC-20 pool to encrypted pool

  • unshield(amount, proof) → move from encrypted pool to public pool

The standard is FHE-scheme-agnostic and ZK-proof-system-agnostic. Implementations can use TFHE, BFV, Groth16, Halo2, or any system that meets the specified requirements.

Key Design Decisions

FHE over commitments — FHE ciphertexts support homomorphic addition/comparison natively. The contract updates balances without decryption. A lending protocol can verify balance ≥ collateralThreshold homomorphically.

Predicate proofs over balance queries — DeFi rarely needs exact balances. It needs “is this enough?” — a boolean. verifyBalancePredicate gives protocols exactly what they need and nothing more.

Events without amounts — BlindTransfer(from, to, proofHash) preserves indexability (who sent to whom) without leaking how much. The proofHash enables authorized off-chain auditors to verify.

Backwards-compatible with ERC-20 — the public metadata functions are identical. A token can implement both standards with shield/unshield as the bridge between pools.

Security Considerations

The draft includes detailed analysis of: ciphertext malleability (mitigated by proof binding), proof replay (nonce + chainId + contractAddress in public inputs), side-channel leakage (timing, gas — mitigated by constant-size circuits), quantum threats (lattice-based FHE is believed quantum-resistant), and key management (threshold Shamir SSS with ≥ 5 custodians).

The full specification, including Solidity interface, proof format, predicate encoding, and security analysis is in the repository.

Questions for the Community

  1. Scheme registry — should the standard define a bytes4 registry for FHE scheme identifiers, or is a free-form string sufficient?

  2. Proof size — what’s a reasonable SHOULD limit for proof size? 1KB? 4KB?

  3. totalSupply visibility — should totalSupply be mandatory public, or should confidential supply be part of the core interface (vs. an extension)?

  4. Fee interface — should the standard include an optional fee extension for FHE computation costs (pGas model), or leave this entirely to implementations?

  5. Key rotation — the draft includes keyVersion() and isKeyActive() for key lifecycle management. Is this overengineering at the standard level, or is it essential?

Looking forward to feedback from the community. This is the first ERC proposing native FHE-encrypted token balances — if something similar has been discussed before, I’d love to see the prior art.

— Valisthea