ERC-7984: A New Standard for Confidential Tokens

What is ERC-7984?

ERC-7984 is a token standard for confidential fungible tokens on EVM-compatible chains. Created in July 2025, the standard is currently in draft status with active discussion. OpenZeppelin provides a reference implementation that can be tested now.

ERC-20 stores balances as public uint256 values. Anyone can query balanceOf(address) and see exactly how many tokens an address holds. ERC-7984 changes this. Balances become encrypted values stored on-chain. When you hold 500 tokens, the contract stores encrypted(500) instead of 500. The same applies to transfer amounts, total supply, and any value that reveals how much. The contract performs arithmetic directly on encrypted data using Fully Homomorphic Encryption (FHE) through Zama's fhEVM, ensuring that neither the contract nor anyone observing the chain can read the actual values.

How FHE Makes This Possible

Traditional encryption requires decryption before computation. If you want to add two encrypted numbers, you must decrypt both, perform the addition, then re-encrypt the result. This exposes the values during computation.

encrypted(100) -> decrypt -> 100 + 50 = 150 -> encrypt -> encrypted(150)

Fully Homomorphic Encryption eliminates the decryption step. You perform operations directly on encrypted values. Add encrypted numbers, subtract them, compare them, all without revealing the underlying data.

encrypted(100) + encrypted(50) = encrypted(150)

For tokens, this means a smart contract can update balances without knowing what they are.

Initial state:

Alice's balance: encrypted(500)
Bob's balance: encrypted(200)

Transfer: Alice sends to Bob

Amount: encrypted(50)

Contract computes:

Alice new balance = encrypted(500) - encrypted(50) = encrypted(450)
Bob new balance = encrypted(200) + encrypted(50) = encrypted(250)

The contract executed the transfer. It updated both balances correctly. It never learned that Alice had 500 tokens or sent 50, and it never revealed these values to anyone observing the chain.

Zama's fhEVM brings FHE to the EVM. It provides encrypted types like euint64 for encrypted 64-bit unsigned integers (see all types). ERC-7984 uses euint64 for token amounts. When you deploy an ERC-7984 token, these encrypted types replace the standard uint256 types from ERC-20. The VM executes the same transfer logic, but operates on encrypted values throughout.

ERC-20 vs ERC-7984: What Changes

Note: The euint64 type is an encrypted 64-bit unsigned integer. Types prefixed with e (like euint64, ebool) are encrypted values provided by fhEVM.

The Operator Model:

The biggest change is how delegation works. ERC-20 uses allowances where you approve a specific amount:

approve(spender, 100); // Spender can use up to 100 tokens

The contract must compare allowance >= amount to enforce the limit. With FHE, this comparison produces an encrypted boolean that cannot control program flow. The EVM cannot branch on encrypted conditions. Amount-based allowances become impossible.

ERC-7984 replaces allowances with time-based operators:

setOperator(operator, timestamp); // Operator can spend any amount until timestamp

Operators do not receive a spending limit. They receive time-based control. An operator can transfer any amount from your balance as long as block.timestamp <= timestamp is true. The timestamp remains plaintext, not encrypted. If it were encrypted, we would face the same branching problem. You control when they can act, not how much they can spend.

This changes how protocols must be designed. Allowances are used throughout DeFi for vault deposits, DEX approvals... Protocols built on ERC-7984 must rethink delegation patterns. Instead of approving exact amounts for specific operations, users grant temporary full control and must revoke it when done.

Conclusion

This ERC can potentially be really interesting. With privacy protocols gaining momentum in blockchain, what stands out here is that Zama and FHE bring privacy directly to Ethereum. Not a separate chain, not a sidechain. Privacy on the execution layer itself. This blog does not go deep into implementation details. To fully understand how this works, you need to understand how Zama operates under the hood. But that is something for a later blog.