ERC-7984 enables confidential token transfers with encrypted balances while preserving compliance, selective disclosure, and policy control.
ERC-7984 is an Ethereum standard for confidential fungible tokens, where balances and transfer amounts are stored on chain as ciphertext handles instead of readable numbers. Addresses stay public, which means the standard provides confidentiality and not anonymity.
Token issuers are faced with a different engineering problem. Instead of trying to hide nothing at all, they have to answer questions like: What information has to remain visible? Who is able to decrypt which information? And what kind of integration problems are they willing to accept? ERC-7984 is not ERC-20 compliant and therefore has to be treated as an architecture choice instead of a token upgrade that can be implemented easily.
ERC-7984 replaces plain integer balances with encrypted state references. A transfer is no longer a simple subtraction and addition of amounts visible on chain. Instead, the contract accepts encrypted inputs, runs whatever proof or verification the implementation requires, and updates the encrypted balance.
This has implications for the behavior of tokens on the network. Since balances are now encrypted, the typical way a wallet reads a balance, by calling a public function that returns the balance for an address, no longer works. Indexers can no longer reconstruct historical balances from emitted events. Compliance logic that relies on comparing amounts stops working unless that logic can operate over the ciphertext, or some subset of values is disclosed to a trusted subsystem for validation.
A production deployment usually needs custom client libraries, a privacy aware registry for keys and permissions, and a decision about where the encrypted computation happens.
ERC-7984 does not hide sender, recipient, contract, timing, calldata, etc. In other words, it does not provide anonymity. However, it does hide balances and transfer amounts.
So if the purpose of the regulated issuer of a use case is to obscure counterparties then ERC-7984 alone will not be sufficient. A regulated issuer may however be satisfied that holdings and transfer amounts are hidden from the public while remaining visible to authorized parties, and this is a different aim from the anonymization of transactions in order to reduce address level traceability.
ERC-7984 outlines the interface of the token as well as the encrypted state model, but it does not fix a single cryptographic backend for all issues. The choice of a single cryptographic backend affects many more things (like latency, trust assumptions, throughput, operability and audit scope) than the simple token interface itself.
| Foundation | Where computation happens | Main trust assumption | Operational profile | Common failure concern |
|---|---|---|---|---|
| FHE | On encrypted data, often with heavy off chain assistance and on chain verification | Soundness of scheme and parameter selection, plus the threshold key management system that controls decryption | Strong confidentiality model, slower and harder to integrate | Incorrect parameters, proof bugs, impractical performance |
| MPC | Across a committee of nodes holding shares | Honest majority or threshold honesty plus liveness | Better performance than pure FHE in many designs, more moving parts | Collusion, stalled committee, complex key management |
| TEE | Inside secure hardware enclaves | Hardware vendor security and attestation validity | Fastest path for many products, closer to conventional app design | Side channels, enclave compromise, attestation misuse |
FHE (Fully Homomorphic Encryption) is really attractive if you want a simple, clean way to compute on hidden values. The tradeoff, however, is that implementation is a lot of work. And in practice, trust models are rarely pure FHE. Most FHE reference implementations rely on a threshold key management system to authorize decryption, so an operator set is implemented underneath the cryptography. State transitions, proof generation and developer tooling are all a lot less forgiving than plain Solidity.
MPC works well if you have a governance model in place to manage an operator set, and you are already using off chain services in your product. TEE based systems are the fastest way to get to production, but then you have to deal with trust that is not in the cryptography itself, i.e., hardware and operational controls. Ultimately, most issuers will be focused on figuring out which of these models they can get their auditors, regulators, and counterparties to trust.
Selective disclosure becomes murky when building confidential token designs. “Auditor access” is not a feature. The issuer has to define whether an authorized party can view a single transfer, an address balance at a point in time, the complete transaction history of a single wallet, or the total supply movements in the system as a whole.
Separating public settlement from privileged disclosure is key to many confidential token designs. A design specifies disclosure keys held by whom, unilateral access or threshold gated, permanent vs. time bounded disclosures, and a public trail of disclosure actions or not.
Useful patterns tend to fall into a few buckets:
Threshold approval and event specific reveals extend both patterns to isolate a single disputed transaction without disclosing other accounts.
ERC-7984 is useful when policy has to be enforced before a confidential transfer settles. This can include: transfer caps, holding thresholds, allowlists, sanctions checks, lockups, investor class restrictions, geography based rules etc. A contract or tightly coupled policy engine can enforce rules against the encrypted transfer without disclosing the amount to the outside world.
Public metadata rules are simple to create and enforce such as an allowlist registry for approved recipients, account classification or even a flag indicating the sender's or recipient's jurisdiction. However, amount based rules are inherently harder to enforce. Either a limit comparison has to be made on the concealed transfer amount or such a comparison must be externally proven and then later verified on chain.
The main design choices usually look like this:
To create a functioning confidential issuance system, all the pieces (registry contracts, signing services, off chain proof infrastructure and admin controls) need to be built as one system, and therefore typically get built as custom protocol code and not as a standard token issue.
ERC-7984 will fit into a number of existing use cases where there are known participants, required compliance, and a business risk to public disclosure of balances and transfer sizes. Security tokens will be the obvious use case here to allow for cap table privacy, negotiated deal sizes and transfer restrictions on a per investor basis.
This also applies to real world asset tokenization, where the issuers require on chain settlement but do not want the public to see the allocation sizes, the treasury movements and the secondary transfer amounts.
Corporate payments and treasury operations fit in this category. Counterparties would be fine with publicly visible addresses, but then require amount privacy on the public chain. Open consumer tokens and other liquidity first DeFi assets will lose a lot of value when balances are no longer machine readable across the whole stack.
Tokens with confidential information are not plug and play solutions for DeFi. Assets listed on AMMs, lending markets, vaults, and other financial applications are typically listed with publicly readable reserves, collateral positions, and liquidation information. This information is also used by accounting systems, and by applications such as DeFi bridges and contract routers.
Analytics and explorers also fail at the data model level. ERC-20s are indexable in a pure functional manner: replaying the logs re-creates all of the balance information for a given block. ERC-7984 removes this property on purpose, therefore holder tables, portfolio tracking information, and risk scoring information will require privileged decryption or delegated read rights to be read by external tools.
Just because ERC-7984 exists doesn't mean you can just compose on top of it for your product. Integrations will require custom work: adapters, wrappers, custom interfaces for the frontend, APIs for the backend, and indexing. The reference implementation covers the token contract itself, so the work sits in the layers around it. Typically this will also involve smart contract development services to build the application layer around the Solidity code. If composability with existing DeFi is the core product requirement, ERC-7984 is usually the wrong starting point.
Encrypted token systems extend the audit surface far beyond the simple balance arithmetic, access control, and upgradeability of typical state storage systems. Proof verification logic, ciphertext handling rules, key lifecycle design, disclosure rules, replay protection, and off chain systems that generate and process attestations or encrypted inputs are all part of the scope.
A serious review would highlight the biggest risks to the system, which would be dependent on the chosen backend. The biggest risks to an FHE based system would be incorrect parameter choices for the encryption or proof verification mistakes. MPC systems could be at risk of committee collusion, poor resharing procedures or even liveness collapse. TEE systems are at most risk from enclave side channels, weak attestation checks or over trusted operators. In all cases the code for selective disclosure is especially fragile as privacy tends to fail at the exception path as opposed to the transfer path.
You should review the contract logic, the cryptographic assumptions, the operational controls and the interfaces between these components. In practice, this means a protocol review followed by a focused smart contract audit of the encrypted state model and the surrounding services. This review should then be extended to a full Web3 development process for the entire product flow, prior to mainnet launch.
Is ERC-7984 a good fit for a regulated token? This can work if the requirement is for confidential balances and transfer amounts while still showing addresses and allowing for a transfer policy to be enforced. Address level anonymity or allowing for a very wide range of DeFi compatible use cases would not work well with ERC-7984.
Can KYC and sanctions controls still work with confidential transfers? Yes. In such design, identity and eligibility checks are kept in registry/attestation layer, while amounts of tokens are encrypted. Such design allows for strong policy decisions to be enforced, even when amounts of transferred tokens are not publicly visible.
Can an ERC-7984 token be wrapped for use in DeFi? Yes, but probably with lower levels of privacy than in the original architecture. A wrapper for confidential tokens usually introduces visibility somewhere in the stack, even if only for a single operation. Improved composability is the major advantage of using a wrapper for confidential tokens, but it may reduce the privacy guarantees that justified ERC-7984 in the first place.
Do auditors or regulators need a master key to see everything? No, as stronger designs do not include a single universal key to reveal all information and rather include features such as scoped view permissions, threshold approval and event specific disclosure. Such designs reduce concentration risk and make access control easier to justify.
Is migration from ERC-20 straightforward? No. All of the interfaces (e.g. for contract interaction), wallet support, indexing, reporting, and user operations change. From a technical standpoint, this is closer to launching a completely new token architecture than to upgrading an existing token.
