ERC-7945 - Confidential Transactions Supported Token

Created	2025-05-09
Status	Review
Category	ERC
Type	Standards Track
Authors	Zhe Han (@iampkuhz) <hanzhe.hz at ant-intl.com>
Requires	EIP-20

Abstract

Classic token contracts like ERC-20 enable their token holders to make transfers and/or approve others to make transfers on their behalves. The generality of token standard ERC-20 catalyzed decentralized finance and many other blockchain applications. However, when it comes to privacy, although some technical schemes have been proposed, few standards have been established, which limits the evolution of privacy-preserving blockchain applications.

This proposal draws up a standard interface for fungible token contracts supporting confidential transactions. It provides basic transfer functionality without loss of generality, and allowance and approve functionalities. Contracts following the standard can provide confidentiality for users’ balances and token transfer value, and can enable other blockchain applications to make transfers on behalf of owners, which empowers more privacy-preserving capabilities for blockchain applications.

Motivation

Confidential transactions have been implemented in many blockchains, either natively through blockchain protocols like Monero and Zcash, or through smart contracts like Zether^1 without modifying the blockchain protocol.

However, few standards are proposed on Ethereum (and/or other EVM-compatible blockchains) to illustrate privacy-preserving contracts without modifying the underlying protocol. Users and applications cannot easily detect whether a token contract supports confidential transactions or not, and so cannot reliably make transfers without revealing the actual amount.

Consequently, this proposal is to standardize confidential-transaction-supported token contracts, without loss of generality, by only specifying core methods and events.

Such a standard interface allows confidential transactions of tokens to be applied by certain parties that are sensitive to transfer amounts, or by privacy-preserving applications.

Compared with application-specific confidential token designs, such as ERC-7984 using bytes32 pointers representing confidential balances, open-source projects Tornado Cash and Zeto implementing a UTXO model in smart contracts, this proposal standardizes only the minimum interoperable surface in the setting of an account-based model: balance queries, transfers, delegated transfers, approvals, and related events. This allows different proof systems, ciphertext encodings, and compliance workflows to coexist behind a common interface, so wallets, bridges, exchanges, and other applications can support confidential tokens without being tightly coupled to one implementation.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Contract Interface

Compliant contracts MUST implement the following interface:

interface IERC7945 {
    function confidentialBalanceOf(address owner) external view returns (bytes memory confidentialBalance);

    function confidentialTransfer(
        address _to,
        bytes memory _confidentialTransferValue,
        bytes memory _proof
    ) external returns (bool success);

    function confidentialTransferFrom(
        address _from,
        address _to,
        bytes memory _confidentialTransferValue,
        bytes memory _proof
    ) external returns (bool success);

    function confidentialApprove(
        address _spender,
        bytes memory _confidentialValue,
        bytes memory _proof
    ) external returns (bool success);

    function confidentialAllowance(address _owner, address _spender)
        external
        view
        returns (bytes memory _confidentialValue);

    event ConfidentialTransfer(
        address indexed _spender,
        address indexed _from,
        address indexed _to,
        bytes _confidentialTransferValue
    );

    event ConfidentialApproval(
        address indexed _owner,
        address indexed _spender,
        bytes _currentAllowancePart,
        bytes _allowancePart
    );
}

Additionally, compliant contracts MAY implement the following interface:

interface IERC7945Metadata {
    function name() external view returns (string memory);
    function symbol() external view returns (string memory);
    function decimals() external view returns (uint8);
}

`IERC7945Metadata`

Methods

`name`

function name() external view returns (string memory)

Returns the name of the token - e.g. "MyConfidentialToken".

OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect this value to be present.

`symbol`

function symbol() external view returns (string memory)

Returns the symbol of the token, e.g. "cHIX".

OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect this value to be present.

`decimals`

function decimals() external view returns (uint8)

Returns the number of decimals the token uses - e.g. 8, meaning the token amount should be divided by 100000000 to get its user representation.

OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect this value to be present.

`IERC7945`

Methods

`confidentialBalanceOf`

function confidentialBalanceOf(address owner) 
external view returns (bytes memory confidentialBalance)

Returns the confidential balance of the account with address owner.

`confidentialTransfer`

function confidentialTransfer(
  address _to,
  bytes memory _confidentialTransferValue, 
  bytes memory _proof
) external returns (bool success)

Transfers value amount of tokens (behind _confidentialTransferValue) to address _to, and MUST fire the ConfidentialTransfer event. The function SHOULD revert if the message caller’s _proof of this transfer fails to be verified.

Note:

Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned.
Implementations can fully customize the proof system, (de)serialization strategies of bytes, and/or the business workflow. For example, when implementing "Zether"^1 confidential token contracts, the _confidentialTransferValue and accounts' confidential balances will be encrypted homomorphically under ElGamal public keys, and _proof will consist of 3 parts to check:
- _confidentialTransferValue is well encrypted under both the caller's public key and _to's;
- The plaintext value behind _confidentialTransferValue is non-negative;
- The caller's confidential balance is actually enough to pay the plaintext value behind _confidentialTransferValue.

`confidentialTransferFrom`

function confidentialTransferFrom(
  address _from,
  address _to,
  bytes memory _confidentialTransferValue,
  bytes memory _proof
) external returns (bool success)

Transfers value amount of tokens (behind _confidentialTransferValue) from address _from to address _to, and MUST fire the ConfidentialTransfer event.

The confidentialTransferFrom method is used for a withdrawal workflow, allowing contracts to transfer tokens on your behalf. This can be used, for example, to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. The function SHOULD revert unless the _from account has deliberately authorized the sender of the message via some mechanism, and SHOULD revert if the message caller’s _proof of this transfer fails to be verified.

Note:

Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned.
Implementations can fully customize the proof system, (de)serialization strategies of bytes, and/or the business workflow. For example, when implementing "Zether" confidential token contracts, the _confidentialTransferValue and accounts' confidential balances will be encrypted homomorphically under ElGamal public keys, and _proof will consist of 3 parts to check:
- _confidentialTransferValue is well encrypted under public keys of _from's, _to's, and caller's;
- The plaintext value behind _confidentialTransferValue is non-negative;
- The caller's confidential allowance is actually enough to pay the plaintext value behind _confidentialTransferValue.

`confidentialApprove`

function confidentialApprove(
  address _spender,
  bytes memory _confidentialValue, 
  bytes memory _proof
) external returns (bool success)

Allows _spender to withdraw from caller's split part of balances multiple times, up to the amount (allowance value) behind _confidentialValue to 0. This function SHOULD revert if the message caller’s _proof of this transfer fails to be verified.

Caution:

This function behaves much differently from approve(address,uint256) in ERC-20.

Calling confidentialApprove splits the confidential balance of caller's account into allowance part and the left part.

The values behind two parts above after calling confidentialApprove, and the value behind the original confidential balance of caller's account before calling confidentialApprove, satisfy the equation:

$$ value_{Behind\ Allowance\ Part} + value_{Behind\ Left\ Part} = value_{Behind\ Original\ Confidential\ Balance} $$

The allowance part of the confidential balance allows _spender to withdraw multiple times through calling confidentialTransferFrom until _spender does not call it any more or the value behind this part is 0.
- Every time _spender calls confidentialTransferFrom, the value behind this part will be decreased by the value behind _confidentialTransferValue.
The left part remains as the new confidential balance of the caller's account.

If this function is called again, it:

merges the existing allowance part into the confidential balance of the caller's account; and then
overwrites the current allowance part with _confidentialValue.

Note:

Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned.
Implementations can fully customize the proof system, (de)serialization strategies of bytes, and/or the business workflow. For example, when implementing "Zether" confidential token contracts, the _confidentialValue and accounts' confidential balances will be encrypted homomorphically under ElGamal public keys, and _proof will consist of 3 parts to check:
- _confidentialValue is well encrypted under public keys of caller's and _spender's;
- The plaintext value behind _confidentialValue is non-negative;
- The caller's confidential balance is actually enough to pay the plaintext value behind _confidentialValue.

`confidentialAllowance`

function confidentialAllowance(address _owner, address _spender)
external view returns (bytes memory _confidentialValue)

Returns the allowance part that _spender is still allowed to withdraw from _owner.

Events

`ConfidentialTransfer`

event ConfidentialTransfer(
  address indexed _spender,
  address indexed _from, 
  address indexed _to, 
  bytes _confidentialTransferValue
)

MUST trigger when tokens are transferred.

Specifically, if tokens are transferred through function confidentialTransferFrom, _spender address MUST be set to caller's; otherwise, it SHOULD be set to 0x0.

A confidential token contract:

which creates new tokens SHOULD trigger a ConfidentialTransfer with the _from address set to 0x0 when tokens are minted;
which destroys existing tokens SHOULD trigger a ConfidentialTransfer with the _to address set to 0x0 when tokens are burned.

`ConfidentialApproval`

event ConfidentialApproval(
  address indexed _owner,
  address indexed _spender,
  bytes _currentAllowancePart,
  bytes _allowancePart
)

MUST trigger on any successful call to confidentialApprove(address,bytes,bytes).

Rationale

Optional Accessor of "Confidential Total Supply"

function confidentialTotalSupply() external view returns (bytes memory)

Confidentiality of transfer amount makes it hard to support a field like totalSupply() in ERC-20. When it comes to token minting or burning, if every user in this contract can access totalSupply() as well as decrypt it, these users will know the actual token value minted or burned by comparing the totalSupply() before and after such operations, which means that confidentiality no longer exists.

Contract implementations can optionally support confidentialTotalSupply() by evaluating whether anti-money laundering (see next part) and audit are required. That would be much more plausible by allowing a small group of parties to know the plaintext total supply behind confidentialTotalSupply().

Anti-money Laundering and Audit

To support audit of confidential transactions and total supply, especially when such token issuers are banks or other financial institutions supervised by governments or monetary authorities, confidential transactions can be implemented without changing the confidentialTransfer method signature, by encoding more information into parameters.

For example, in a Zether-like implementation^2, if token transfers are required to be audited, the confidentialTransfer caller encrypts transfer value redundantly under public keys of caller's, to's, and a group of auditors', which makes it possible for related parties to know the real value behind it exactly. So does confidentialTotalSupply().

Fat Token

A confidential-transactions-supported token can also implement ERC-20 at the same time.

Token accounts in such tokens can hold two kinds of balances. Such token contracts can optionally provide methods to hide ERC-20 plaintext balances into confidential balances, and vice versa, to reveal confidential balances back to ERC-20 plaintext balances.

ERC-20 interfaces will bring much more usability and utility to confidential-transaction-supported tokens, realizing general confidentiality in the meantime.

Backwards Compatibility

No backward compatibility issues found.

Security Considerations

To preserve confidentiality, implementations should avoid creating (minting) or destroying (burning) tokens with plaintext value parameters, since plaintext mint or burn flows may reveal sensitive amounts even if ordinary transfers remain confidential. Implementers should also ensure that any mint, burn, transfer, approval, and delegated transfer workflows use proof and encryption schemes that do not leak transfer values or balance information through calldata, events, or auxiliary state.

Copyright

{
  "type": "article",
  "id": 1,
  "author": [
    {
      "family": "Bünz",
      "given": "Benedikt"
    },
    {
      "family": "Agrawal",
      "given": "Shashank" 
    },
    {
      "family": "Zamani",
      "given": "Mahdi" 
    },
    {
      "family": "Boneh",
      "given": "Dan"
    }
  ],
  "DOI": "10.1007/978-3-030-51280-4_23",
  "title": "Zether: Towards Privacy in a Smart Contract World",
  "original-date": {
    "date-parts": [
      [2020, 2, 10]
    ]
  },
  "URL": "https://eprint.iacr.org/2019/191.pdf",
  "custom": {
    "additional-urls": [
      "https://dl.acm.org/doi/abs/10.1007/978-3-030-51280-4_23"
    ]
  }
}
```

{
  "type": "article",
  "id": 2,
  "author": [
    {
      "family": "Chen",
      "given": "Yu"
    },
    {
      "family": "Ma",
      "given": "Xuecheng"
    },
    {
      "family": "Tang",
      "given": "Cong"
    },
    {
      "family": "Au",
      "given": "Man Ho"
    }
  ],
  "DOI": "10.1007/978-3-030-58951-6_29",
  "title": "PGC: Decentralized Confidential Payment System with Auditability",
  "original-date": {
    "date-parts": [
      [2020, 9, 12]
    ]
  },
  "URL": "https://eprint.iacr.org/2019/319.pdf",
  "custom": {
    "additional-urls": [
      "https://link.springer.com/chapter/10.1007/978-3-030-58951-6_29"
    ]
  }
}
```