Every few years, someone announces they have solved privacy on public blockchains. And every few years, financial institutions look at the solution and decide it is not what they actually need.
In late 2024, Circle took a different approach. It did not claim to have solved privacy. It argued that regulated finance had been asking the wrong question. That distinction is the reason the idea has since moved from a research paper into an Ethereum draft standard, a live mainnet, and Circle’s own institutional Layer 1.
If your team is building tokenized assets, payroll rails, or institutional settlement on public chains, this is the direction the privacy stack is moving — and the architectural decisions it implies are worth understanding before your design is locked in.
The problem: public chains expose too much
Public EVM chains expose everything. Not just who is sending and who is receiving, but how much. Balances, transfer amounts, position sizes — all of it readable on-chain by anyone.
For a retail user sending twenty dollars, that transparency is harmless. For a corporate treasury running payroll, it is a real operational exposure. For an asset manager holding tokenized fund positions, it is competitive risk they cannot accept. For a bank running institutional settlement, it is a confidentiality requirement they cannot waive.
This is the main reason serious tokenized finance has largely stayed on permissioned chains. Not because institutions distrust public infrastructure, but because public infrastructure shows too much.
“Most teams assume the choice is binary — go public and accept full transparency, or go permissioned and lose the network. The interesting work right now is in refusing that trade-off.” — Przemysław Koper, CEO, Espeo Software
The reframe: confidentiality is not anonymity
In October 2024, Circle Research, together with a team from Inco Network, published a paper introducing the Confidential ERC-20 framework, shortened to cERC20. It opens with a distinction that sounds simple but is unusually sharp.
There are two different things a financial transaction can hide. One is who is involved — the sender and the receiver. Hiding that is anonymity. The other is the amount. Hiding that is confidentiality. They are not the same thing, and they do not require the same tools.
Circle’s argument is that regulated finance does not need anonymity. It never did. What it needs is confidentiality — the ability to keep transaction amounts and balances private from the public, while remaining fully visible to authorized parties on demand.
Think about how a peer-to-peer payment app works. You can see that someone paid someone else; you cannot see the amount. That is not full anonymity. It is selective confidentiality, and it is how most professional financial systems already operate.
How cERC20 works
The design stays close to a standard ERC-20, with one decisive change: balances and transfer amounts are stored as encrypted integers rather than plain numbers.
The encryption model is Fully Homomorphic Encryption (FHE). In practice, FHE lets a smart contract perform operations on encrypted values without ever decrypting them. The contract can add to a balance without knowing the balance. It can check whether a transfer limit has been exceeded without seeing the amount.
The visibility boundary is precise:
- Visible publicly: the sender address, the receiver address, and the fact that a transfer occurred.
- Hidden: the transfer amount and the running balance.
For many regulated use cases, that is exactly the right line. Not more visible, not less. Exactly that.
Delegated viewing: compliance without a global backdoor
The second layer matters specifically for financial and compliance teams. The framework supports delegated viewing — different parties can be granted the ability to decrypt specific values, without access to private keys and without touching anything else.
An issuer can grant a regulator view access. A treasurer can let an auditor see transaction history for a defined period. A compliance team can see the transfers that need review. Nobody gets access to everything. Each permission is defined in the contract and can be changed when circumstances require it.
This is where FHE has a meaningful advantage over the zero-knowledge approach that most people in this space know better. ZK commitments are powerful, but once you commit to a value, the viewing permissions are largely fixed at that moment. FHE-based systems let you adjust access dynamically through contract state. For institutions that need to onboard new auditors, respond to regulatory requests, or change their access structure over time, that flexibility has real operational value.
“Compliance access shouldn’t be a one-time decision baked in at commitment. Real institutions reorganize, change auditors, and answer new regulatory requests constantly. Access that can evolve through contract state is the part engineers should be paying attention to.” — Przemysław Koper, CEO, Espeo Software
From research paper to capital structure
To be direct: cERC20 itself is research. Circle says so explicitly. The reference implementation is a proof of concept, it has not been audited, and it cannot run on Ethereum mainnet today because it requires a chain with FHE-capable execution.
But the work did not stop there.
- In April 2025, Inco, OpenZeppelin, and Zama co-founded the Confidential Token Association. Its output was ERC-7984, a draft Ethereum standard for confidential fungible tokens. OpenZeppelin has since published audited reference contracts built on Zama’s fhEVM coprocessor, where amounts are stored on-chain as encrypted
euint64ciphertext handles decryptable only by authorized parties. - Zama launched its own confidential-token mainnet infrastructure on Ethereum, with the decryption coprocessor and threshold key management now live.
- JP Morgan’s blockchain arm, Kinexys, published a proof of concept using this infrastructure for institutional tokenized-finance privacy. That is not a startup experiment — it is one of the largest banks in the world validating the same cryptographic approach.
- Circle’s own Layer 1, Arc, shipped with opt-in confidential transfers as a day-one feature: amounts hidden, addresses visible, authorized parties able to view via view keys. In May 2026, Circle closed a $222 million Arc token presale at a $3 billion fully diluted valuation, led by a16z crypto with BlackRock, Apollo, and Intercontinental Exchange (NYSE’s parent) all in the round.
That is no longer a research paper. That is a capital structure forming around a specific architectural thesis.
The honest critique
The cypherpunk critique of cERC20 is straightforward: the issuer has a backdoor. Authorized parties can see everything. If you believe financial privacy should be absolute and user-controlled, this framework is not that.
Circle and Inco would agree — and say that is exactly the design. The institutions they are building for do not want absolute privacy. They want protection from public exposure and competitive visibility, with full auditability toward regulators when required. That is a different requirement, and it needs a different solution.
Whether that satisfies you depends on what problem you think needs solving. For individual privacy, it is not enough. For institutional finance operating on public infrastructure, it may be exactly right.
“We’re engineers, not privacy maximalists or hype merchants. The right question for a client is never ‘is this maximally private’ — it’s ‘does this hide exactly the values that need hiding, and expose exactly what your regulator and auditors need to see.'” — Przemysław Koper, CEO, Espeo Software
The bigger shift
The deeper point is not about one framework. It is about a change in what the regulated-finance conversation is actually asking.
For years the question was: can public chains be made private enough for institutional use? The usual answer was only if you build a new chain or move to a permissioned network.
What cERC20, ERC-7984, and the broader FHE ecosystem propose is a third path. Keep the public chain. Keep settlement transparency. Encrypt only the financial values that need protecting. And give authorized parties the keys they need, when they need them.
That is a narrower claim than earlier privacy systems made. It is also, arguably, a more honest one — not hiding everything, but hiding exactly the right things, with exactly the right visibility controls in place.
What this means if you’re building on-chain
If your roadmap includes tokenized assets, payroll infrastructure, or institutional settlement on public chains, the practical questions are engineering questions, and they are best answered early — before the architecture is locked in:
- How do compliance rules get encoded into contract logic and access roles?
- How does delegated viewing map onto your audit and regulatory structure — who can decrypt what, and how does that change over time?
- How do wrapping mechanics affect your token model when converting between a standard ERC-20 and a confidential ERC-7984 representation?
- What execution environment do you target, given that FHE-based confidentiality requires an FHE-capable chain rather than Ethereum mainnet as-is?
These are exactly the decisions that are cheap to get right at the design stage and expensive to retrofit later.
How Espeo can help
Espeo Software has built production systems in regulated fintech across multiple markets. If you want to think through what confidential tokenization looks like in practice for your product — the architecture, the compliance encoding, and the trade-offs specific to your regulatory environment — get in touch with our team.
