FHERC20 Token Standard
Motivation
FHERC20 Standard Goals:
Compatibility: Ensure maximum compatibility with existing ERC20 infrastructure, including wallets and etherscan platforms.
Conflict Reduction: Minimize potential conflicts with existing ERC20 integrations.
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:
Non-interacted: Returns a
balanceOf
(indicatedBalance) of 0.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 thevalue
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
.
Encrypting:
The
encrypt
function withdrawswETH
from a user’s address and deposits it into theeETH
contract.The user receives a corresponding
encMint
of the encrypted balance.
Decrypting:
The
decrypt
function reverses this process, burning theeETH
and returning thewETH
to the user's address.
Last updated