ERC-7984 is an Ethereum standard proposal for confidential fungible tokens. It aims to reduce the exposure of account balances and transaction amounts on public blockchains while preserving the ability to transfer tokens and interact with smart contracts. Unlike ERC-20, which is primarily designed around public balances and publicly visible transfer amounts, ERC-7984 attempts to establish a standard interface capable of handling confidential values, providing more flexible privacy protection for on-chain financial activities.
As stablecoin payments, tokenized assets, and institutional DeFi continue to develop, blockchain transparency is facing new application requirements. Public ledgers facilitate transaction verification and asset-flow tracking, but corporate payments, institutional fund allocation, and commercial settlements often involve sensitive amounts. If every payment and account balance can be queried directly by external observers, some traditional financial activities may be difficult to migrate fully to public blockchains.
The focus of ERC-7984 is not to make all on-chain transactions untraceable. Instead, it seeks to establish a new balance between programmable finance and commercial privacy through confidential data-processing mechanisms. This article examines the standard's design, FHE technology, differences from ERC-20, and practical use cases to explain how ERC-7984 enables confidential token transfers and the potential impact this standard could have on the stablecoin, RWA, and DeFi ecosystems.
ERC-7984 is an Ethereum standard proposal for Confidential Fungible Tokens. It aims to protect token balances and transfer amounts.
Unlike traditional ERC-20 tokens, ERC-7984 uses references or handles for confidential values to represent token amounts, allowing smart contracts to perform related operations without exposing plaintext amounts.
Fully Homomorphic Encryption (FHE) is one important implementation path for ERC-7984. It supports computation on encrypted data, but the standard itself does not mandate any specific encryption technology.
ERC-7984 primarily protects amounts and balances. It does not automatically hide the addresses of transaction parties and therefore should not be equated with fully anonymous transactions.
The OpenZeppelin and Zama technology ecosystems provide an implementation foundation for ERC-7984, helping move confidential tokens from a technical concept toward composable smart contract applications.
Confidential stablecoins, institutional payments, RWA asset management, and privacy-preserving DeFi are potential application areas. However, practical adoption still faces challenges related to performance, permission management, interoperability, and compliance.
ERC-7984 is a proposal for a confidential fungible token interface standard jointly introduced by developers from ecosystems including OpenZeppelin and Zama. It was created on July 3, 2025. It retains the basic concepts of fungible tokens, including account balances, token transfers, and third-party authorization, while changing how traditional tokens handle amount data.
In the ERC-20 model, balances and transfer amounts are generally recorded as public values in smart contract state and transaction events. Anyone can view this information through blockchain explorers or on-chain analytics tools. This design supports transparent auditing, transaction verification, and composability, but it also means that on-chain fund activity may be continuously observed.
ERC-7984 instead uses a design based on confidential value references. The standard uses pointers such as bytes32 to represent balances and transfer amounts. The underlying implementation determines how the specific values are stored, computed, and accessed. Smart contracts can initiate transfers through standardized interfaces without exposing the amount as an ordinary plaintext integer.
As of October 2026, ERC-7984 remains an evolving standard proposal and should not be viewed as a mature, general-purpose standard that has fully replaced ERC-20. Its main significance lies in establishing reusable interfaces for confidential tokens, allowing wallets, payment applications, and DeFi protocols to develop functionality around relatively consistent mechanisms.
ERC-20 is one of Ethereum's most widely used fungible token standards. It defines basic interfaces for balance queries, transfers, allowances, and events. USDT, USDC, and many DeFi tokens use ERC-20 or compatible implementations.
ERC-7984 treats the confidentiality of balances and amounts as a core requirement from the design stage. It is not simply an option added to ERC-20 to hide transaction records. Instead, it uses different data representations and transfer interfaces.
| Comparison Dimension | ERC-20 | ERC-7984 |
|---|---|---|
| Balance Data | Generally public | Uses confidential value references |
| Transfer Amounts | Generally public | Processed confidentially |
| Addresses of Transaction Parties | Public | May still be exposed by the base interface |
| Transfer Interfaces | transfer, transferFrom | confidentialTransfer and others |
| Third-Party Authorization | Allowance-based amount authorization | Time-limited Operator authorization |
| Smart Contract Integration | Mature ecosystem with broad compatibility | Requires adaptation for confidential data processing |
| Typical Applications | General-purpose tokens, DeFi, stablecoins | Confidential payments, privacy-preserving DeFi, institutional settlements |
One important difference is that ERC-7984 is not directly compatible with ERC-20 interfaces. Existing wallets, trading platforms, and DeFi protocols cannot automatically recognize or process ERC-7984 tokens simply because they support ERC-20.
OpenZeppelin provides ERC-20 wrapper and conversion components that allow developers to build conversion mechanisms between regular and confidential tokens. However, the conversion process itself may still expose deposits, withdrawals, or related information on the public chain. Wrapping therefore does not mean that all historical fund flows automatically receive privacy protection.

Traditional ERC-20 transfers generally require smart contracts to process explicit values. For example, when User A transfers 100 tokens to User B, the contract deducts 100 from A's balance and adds 100 to B's balance. The related transfer event also generally records the amount.
The basic idea behind ERC-7984 is for the transfer interface to receive a reference to a confidential amount rather than requiring a publicly provided plaintext value. A specific implementation may use an encrypted computing system to process balance changes and an access-control mechanism to determine which participants can view the corresponding amount.
Using an FHE-based implementation as an example, a confidential transfer can be understood as follows:
The sender specifies the transfer amount in a wallet or application that supports confidential computing and generates the corresponding encrypted input.
The wallet submits a reference to the encrypted amount and the necessary input proof to the token contract.
The smart contract processes the balance check and transfer through the underlying confidential computing mechanism.
The system updates the corresponding confidential balances of the sender and recipient.
Participants with the appropriate access permissions can read the information they are authorized to view through the relevant decryption process.
For example, a company pays a supplier 50,000 confidential stablecoins. The public chain may still show the addresses of both parties and the transfer event, but external observers cannot directly read the plaintext amount from the event as they could with a regular ERC-20 transfer.
This does not mean that external observers cannot obtain any transaction information. Transaction times, address relationships, Gas usage, and other metadata may still be exposed. ERC-7984 therefore provides confidentiality for specific data dimensions rather than absolute anonymity.
Fully Homomorphic Encryption (FHE) is a cryptographic technology that allows systems to perform computations directly on encrypted data. In an appropriate implementation, a computing system can perform operations such as addition and comparison without first decrypting the data, producing a result that remains encrypted.
This capability closely aligns with the needs of confidential tokens.
For regular tokens, a smart contract must determine whether a user's balance is sufficient, calculate the deduction amount, and update the recipient's balance. With traditional plaintext execution, the contract generally needs direct access to these values.
FHE allows these computations to be performed on encrypted data. The system can process balance changes and certain conditional checks without exposing amounts to ordinary on-chain observers.
OpenZeppelin's ERC-7984 implementation uses Zama's fhEVM technology to represent confidential balances as encrypted values and associate them with the underlying computing system through on-chain ciphertext handles. The implementation also supports input proofs, authorization operations, and disclosure of encrypted amounts.
However, the standard and its implementation should be distinguished. ERC-7984 itself does not require all developers to use FHE. Its technology-neutral design allows developers to explore zero-knowledge proofs, trusted execution environments, or other privacy mechanisms that satisfy the interface requirements.
FHE is therefore an important technology path for understanding the current ERC-7984 ecosystem, but ERC-7984 should not be equated simply with FHE tokens.
FHE and zero-knowledge proofs (ZK) can both be used for privacy protection, but they address problems in different ways.
The core capability of a zero-knowledge proof is to allow a prover to demonstrate that a statement is true without disclosing all underlying information to the verifier. For example, a user can prove that they meet a qualification requirement without revealing all of their personal data.
FHE focuses on performing computations while data remains encrypted. For example, a system can operate on an encrypted balance without first exposing the plaintext balance to the party performing the computation.
| Comparison Dimension | FHE | ZK |
|---|---|---|
| Core Objective | Compute on encrypted data | Verify a statement while disclosing limited information |
| Typical Capabilities | Encrypted balance operations, confidential state updates | Eligibility proofs, state-validity verification |
| Data Processing | Computation can use encrypted data | Generally centers on proof generation and verification |
| Role in Tokens | Process confidential amounts and balances | Prove that a transaction meets specific conditions |
| Main Challenges | Computational cost, ciphertext management, performance | Proof-generation cost, circuit design |
The two technologies are not mutually exclusive. A confidential financial application can use FHE to process sensitive amounts while using ZK to prove that specific transaction or identity requirements have been met.
For ERC-7984, the most important consideration is not the name of the technology selected, but whether the underlying implementation can reliably support confidential value processing, accurate balance updates, and appropriate access control.
A standard interface can form an ecosystem only when it receives support from development tools and applications.
OpenZeppelin has long provided Ethereum smart contract development components. Its Confidential Contracts project provides reference implementations and extension modules for ERC-7984. Zama provides FHE-based confidential computing technology, enabling developers to build smart contracts around encrypted data.
OpenZeppelin's related components include not only basic confidential tokens but also regular ERC-20 wrappers, account freezing, access restrictions, observer permissions, and RWA-specific extensions. These modules address different business requirements.
For example, ERC7984ObserverAccess allows an account to grant a designated observer permission to view confidential balances or transfer amounts; ERC7984Restricted can be used to enforce account restrictions; and ERC7984Rwa provides certain controls applicable to regulated asset scenarios.
In March 2026, OpenZeppelin also released a security audit report for Confidential Contracts version 0.3.0, covering multiple ERC-7984 extensions. This indicates that the related ecosystem is developing the functionality required for financial applications, but it does not mean that all subsequent versions or deployments have received the same level of security validation.
Meanwhile, Zama's development tools are beginning to encapsulate complex encryption operations into interfaces that are easier to integrate. They are also exploring authorized decryption mechanisms that allow specific participants to access necessary information when permitted by the applicable rules.
These developments provide a technical foundation for confidential tokens to enter real-world applications. However, usable development tools, available contract components, and large-scale adoption by financial institutions are three different stages and should not be conflated.
Stablecoins are one of the most notable potential applications for ERC-7984.
Many stablecoins currently circulate on public blockchains, allowing users to view transfer amounts and address balances directly. This may not necessarily be a problem for ordinary on-chain transactions, but corporate settlements generally have greater commercial confidentiality requirements.
For example, a multinational company uses stablecoins to pay different suppliers. If the amount of every transaction is public, external observers may infer procurement volumes, business relationships, and fund arrangements from on-chain data.
Confidential stablecoins based on ERC-7984 could attempt to address this issue. Companies could continue using on-chain tokens for payments without directly exposing the amounts to the public. Recipients could confirm the amount received after obtaining the appropriate permissions.
For financial institutions, confidential stablecoins could also support interinstitutional fund transfers, client fund management, and automated settlements. In scenarios involving sensitive transaction amounts, confidentiality may reduce institutions' concerns about using public blockchains.
However, privacy does not eliminate compliance obligations. Stablecoin issuers and financial institutions may still need to conduct identity verification, transaction monitoring, sanctions screening, and source-of-funds reviews.
A confidential stablecoin suitable for institutional adoption would therefore generally need to provide amount protection, authorized disclosure, and risk controls—not merely hide transfer values.
RWA, or real-world assets, refers to the model of representing and managing rights related to bonds, funds, stocks, or other real-world assets through blockchain-based tokens.
In a public token model, the amount of assets held by an institution may be directly queried by external observers. If the assets represent bond holdings, fund shares, or other financial interests, public balances may reveal part of an investment portfolio.
ERC-7984 can provide confidential balance and transfer amount processing for these assets, allowing holdings to remain undisclosed.
For example, a tokenized fund could explore using confidential tokens to represent fund shares, allowing eligible investors to transfer shares while using additional rules to restrict participation by ineligible accounts.
OpenZeppelin's RWA extensions provide functionality for freezing, account restrictions, and operations by designated roles. This allows developers to add certain controls required for regulated assets on top of confidential tokens. However, these technical functions cannot replace securities issuance requirements, investor eligibility reviews, or other legal requirements.
In DeFi, confidential tokens could also support privacy-preserving payments, confidential fund management, and certain confidential trading strategies.
However, existing DeFi protocols are generally designed around public values. For example, automated market makers need to calculate asset reserves and exchange prices, while lending protocols need to assess collateral ratios and liquidation conditions. If the relevant amounts become confidential, protocols must redesign their calculation, verification, and interaction methods.
ERC-7984 therefore cannot automatically give existing DeFi protocols privacy features. It is better understood as a foundational interface for the next generation of confidential financial applications.
In addition to the confidentiality of balances and amounts, ERC-7984 uses a different mechanism for authorizing third-party transfers.
In ERC-20, users generally use approve to set the amount of tokens that a particular address may use. For example, a user may authorize a DeFi protocol to use up to 100 tokens.
ERC-7984 uses an Operator model. A user can authorize an operator to transfer tokens on their behalf before a specified expiration time, rather than managing the authorization through a public Allowance value.
This design is related to how confidential amounts are handled. Because token balances and transfer amounts themselves need to remain confidential, a traditional public allowance may not be suitable for direct reuse.
However, this authorization method also introduces an important risk: during the authorization period, an Operator may have the right to transfer all tokens in the account rather than only a preset amount.
Users should therefore pay close attention to the trustworthiness of the authorized address, the scope of its permissions, and the expiration time. Applications involving automated payments or institutional fund management also require additional business rules and security controls to limit potential losses.
This shows that the security design of confidential tokens involves not only cryptography but also account permissions, application interactions, and user-operation risks.
On-chain privacy and financial regulation are not necessarily incompatible, but they must be connected through specific technical and institutional arrangements.
On traditional public blockchains, anyone can view most token transfer amounts. This transparency lowers some auditing barriers but also exposes commercially sensitive information to unrelated third parties.
ERC-7984 attempts to provide another approach: the public does not need to see every plaintext amount, while authorized participants can still access specific data when required for business purposes.
For example, a company can allow financial auditors to view relevant transaction amounts, regulated financial institutions can conduct necessary checks around customer identities and fund activity, and issuers can establish freezing or transfer restrictions in accordance with applicable laws.
OpenZeppelin's observer permissions and RWA extensions provide technical components for this selective disclosure. Whether they satisfy specific regulatory requirements, however, depends on identity verification, permission management, record retention, data disclosure procedures, and applicable laws.
It is important to note that the ERC-7984 base standard does not automatically provide a complete compliance framework. Developers still need to design additional business controls to ensure that privacy features do not hinder necessary risk management or legal obligations.
In the long term, this type of controllable confidentiality may be more suitable for certain institutional financial applications than a model that is entirely public or entirely anonymous.
The first challenge is computational performance. FHE requires complex encrypted computations, and its performance costs are generally higher than those of ordinary plaintext operations. For high-frequency payments and complex DeFi protocols, computation latency, infrastructure costs, and system throughput may all affect the practical user experience.
The second challenge is wallet and application compatibility. ERC-7984 is not directly compatible with ERC-20. Wallets need to support confidential amount inputs, encrypted data processing, and authorized decryption. Trading platforms and DeFi protocols also need to adapt to the relevant interfaces.
The third challenge is key and access-permission management. The security of confidential data depends not only on the encryption algorithm but also on who can decrypt the data, how permissions are granted, and how access is revoked. If permissions are configured incorrectly, sensitive amounts may still be read by participants who should not have access to them.
The fourth challenge is the privacy boundary. The ERC-7984 base standard primarily protects balances and amounts. It does not automatically hide addresses or all transaction metadata. Even when amounts remain confidential, external observers may still analyze account activity through transaction relationships and timing patterns.
The fifth challenge is standard maturity and security validation. ERC-7984 is still evolving, and specific implementations depend on underlying privacy-computing mechanisms. Different versions of contracts, extension components, and deployment environments may have different security assumptions. Developers need to assess their risks independently.
The final challenge is the ecosystem network effect. ERC-20's advantages come not only from its technical interface but also from broad support across trading platforms, wallets, lending protocols, and payment tools. If ERC-7984 is to form a similar application network, more infrastructure providers and developers will need to participate.
These issues mean that ERC-7984 is better viewed as an important infrastructure exploration for confidential on-chain finance rather than a mature solution that can seamlessly replace all public tokens.
ERC-7984 is an Ethereum proposal for establishing standard interfaces around confidential fungible tokens. Its core objective is to protect account balances and transfer amounts while preserving the ability to transfer tokens and interact with smart contracts.
Compared with traditional ERC-20 tokens, the important change introduced by ERC-7984 is not simply the addition of a privacy option. Instead, it incorporates confidential data representation, transfer interfaces, and permission management into the token design. Through underlying technologies such as FHE, developers can explore ways to perform certain on-chain financial operations without exposing plaintext amounts.
OpenZeppelin and Zama's related implementations provide a reusable development foundation for confidential stablecoins, institutional payments, RWAs, and privacy-preserving DeFi. However, the standard is still evolving, and computational performance, application compatibility, permission security, and regulatory requirements remain important challenges for practical adoption.
From a broader industry perspective, the value of ERC-7984 lies not in making blockchains completely lose their transparency, but in exploring how to provide the commercial confidentiality required by different financial activities on top of public and verifiable infrastructure. As on-chain financial applications gradually expand into corporate payments and institutional asset management, this type of controllable confidentiality may become an important development direction for future token standards.
ERC-7984 is a proposal for a confidential fungible token standard. It aims to protect token balances and transfer amounts through confidential value references while preserving the ability to transfer tokens and interact with smart contracts.
ERC-20 generally exposes balances and transfer amounts, while ERC-7984 treats these values as confidential data. The two standards use different interfaces and should not be considered fully compatible.
ERC-7984 itself does not mandate the use of FHE. However, OpenZeppelin's related implementation uses Zama's FHE technology to process encrypted balances and transfer amounts.
The base standard does not automatically hide sender and recipient addresses. Its primary privacy-protection targets are token balances and transfer amounts. Address privacy requires additional mechanisms.
Yes. It can serve as a technical foundation for confidential stablecoins, allowing stablecoin transfer amounts to remain undisclosed to the public. Specific issuance, reserve, and compliance requirements must still be met by the issuer.
Yes. Developers can add account restrictions, freezing, and authorized observer functionality on top of confidential tokens to support certain regulated asset scenarios.
ERC-7984 is a token interface standard, while zero-knowledge proofs are a type of cryptographic technology. ERC-7984 can use different privacy implementations, including mechanisms related to ZK.
It can support adapted DeFi applications, but existing ERC-20 protocols generally cannot directly process ERC-7984's confidential values. Additional development and integration are required.
Operator authorization is time-limited, but during the authorization period it may allow the operator to transfer all tokens in the account. Users should carefully select authorized parties and control the authorization period.
As of October 2026, ERC-7984 remains at the proposal stage. Although reference implementations and development components are available, its final specification and ecosystem support may continue to change.
* The information is not intended to be and does not constitute financial advice or any other recommendation of any sort offered or endorsed by Gate.
* This article may not be reproduced, transmitted or copied without referencing Gate. Contravention is an infringement of Copyright Act and may be subject to legal action.





