# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.redact.money/architecture/fherc20-token-standard.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.