FHERC20 Token Standard

Motivation

FHERC20 Standard Goals:

1. Compatibility: Ensure maximum compatibility with existing ERC20 infrastructure, including wallets and etherscan platforms.

2. Conflict Reduction: Minimize potential conflicts with existing ERC20 integrations.

3. Confidentiality: Protect token balance confidentiality by utilizing Fully Homomorphic Encryption (FHE) operations.

This standard aims to seamlessly integrate FHE into the ERC20 framework, enhancing privacy and compatibility.

Concepts

Encrypted Balances

Utilizing the Fhenix CoFHE coprocessor, Fully Homomorphic Encryption (FHE) operations are integrated into the blockchain environment. This ensures that an ERC20 token's balance is maintained in an encrypted state, accessible only under specific conditions as:

Manually decrypted

A user or contract can request to decrypt their own balance. This decrypted balance will be publicly available, so care must be taken to only decrypt a balance when necessary.

Decrypted with sealing.

A user or contract can provide the publicKey component of a sealingKey pair. The privateKey component is stored locally and privately by the user. Thus, when the sealed result is made available, it is only viewable by an entity that knows the privateKey component of the sealingKey pair. The sealed balance is thus only available to the requestor.

As part of an FHE operation.

The encrypted value can be used as part of an FHE operation, such as FHE.add, FHE.sub, or FHE.select (branching). The value remains encrypted throughout these FHE operations, and no data is revealed at any stage.

Indicated Balances

The ERC20 standard is mature, having existed for over a decade, with a comprehensive infrastructure built around it. Public block explorers like Etherscan have integrated ERC20 balances and transfers as an integral part of the blockchain ecosystem. The FHERC20 standard, while keeping the true encrypted balance confidential, introduces an indicator that minimally leaks an address's encrypted balance. This indicator is designed to ensure FHERC20s remain compatible with existing ERC20 infrastructure, focusing primarily on wallets, portfolios, and block explorers.

FHERC20 Token Mechanics

The existing ERC20 functions and events reveal a balance indicator rather than the true encrypted balances. This indicated balance has two possible states:

1. Non-interacted: Returns a balanceOf (indicatedBalance) of 0.

2. Interacted: Returns a balanceOf ranging from 0.0001 to 0.9999.

Interaction States

• Initial Interaction: The first user interaction with an FHERC20 token changes the state from non-interacted to interacted, setting the indicated balance to 0.5001.

• Subsequent Interactions: Each subsequent interaction alters the indicated balance by 0.0001. For instance:

  • Receiving Tokens: Increases the balance by 0.0001 (e.g., from 0.5001 to 0.5002).

  • Transfer Event: Emits a Transfer event with the value field set to 0.0001, reflecting the balance change.

When users receive FHERC20 tokens, they will notice an increase in their wallet balance, although the actual encrypted balance remains concealed. On Etherscan, a transfer will indicate that Bob sent 0.0001 FHERC20 to Alice. Consequently, Bob's FHERC20 balance will decrease by 0.0001, while Alice's will increase by the same amount. These changes will be visible in the balances displayed

In the future, as the FHERC20 standard evolves, users will gain secure access to true encrypted balances. The indicatedBalance, once returned by balanceOf for interoperability and compatibility, may become obsolete. Users will have the option to disable indicated balances through exposed FHERC20 hooks.

Existing ERC20 transfer functions revert.

In scenarios where users attempt to deploy liquidity on UniSwap using an FHERC20, they may encounter a transaction failure. This occurs because the transfer function will revert when called by the UniV2Pair contract. The FHERC20 token is intentionally designed to avoid being mistaken for a standard ERC20 token, with balances ranging between 0.0000 and 0.9999, thereby breaking backward compatibility to prevent misuse in existing smart contracts. The mint, burn, and transfer functions are set to revert by default to ensure this distinction. These functions have been replaced by enc-prefixed versions, such as encMint, encBurn, and encTransfer, to facilitate safe operations.

Removal of allowances.

FHERC20 Standard Overview

The FHERC20 standard leverages EIP712 permissions as the exclusive method for granting fund access. It refines the existing ERC20 transfer function by splitting it into transfer and transferFrom. Here's how it works:

• transfer: Usable only by the fund owner.

• transferFrom: Usable by any user or contract but requires a valid EIP712 permission to specify the maximum transferable amount for that transaction.

Notably, these permissions are single-use and do not grant ongoing access, irrespective of the permitted or transferred amounts.

Changes to Allowances

In traditional ERC20 tokens, allowances enable smart contracts to withdraw user funds, typically set using the approve function. However, with EIP712:

• Allowances removed: The need for allowance reporting is eliminated, protecting the confidentiality of encrypted balances.

• Security: Removing allowances avoids revealing how much of a user's balance has been transferred and necessitates additional Fully Homomorphic Encryption (FHE) operations.

Additional Standards

Overview

EncryptionWrappedFHERC20 is a contract that securely stores cleartext ERC20 tokens, while also allowing for their encrypted counterparts to exist. This setup is beneficial in scenarios where the ERC20 tokens may need to be managed differently, such as generating yield through a rebasing FHERC20.

Key Features

• Flexible Handling: The hooks _encryptHandleCleartextERC20 and _decryptHandleCleartextERC20 facilitate management of the underlying cleartext ERC20 during the encryption and decryption processes.

• Core and Wrapping Standards: The FHERC20 contract serves as the core standard, and is accompanied by EncryptionWrappedFHERC20, which wraps an FHERC20 functionality around an existing ERC20 token.

Example

Consider wETH, an ERC20 that can be transformed into an encrypted FHERC20 called eETH using EncryptionWrappedFHERC20.

1. Encrypting:

   • The encrypt function withdraws wETH from a user’s address and deposits it into the eETH contract.

   • The user receives a corresponding encMint of the encrypted balance.

2. Decrypting:

   • The decrypt function reverses this process, burning the eETH and returning the wETH to the user's address.