# Introduction ## Links * Github: ## Overview Redact is the first dApp built on the Fhenix CoFHE Coprocessor. Redact is a confidential asset management platform, using Fully Homomorphic Encryption (FHE) to enable confidential token balances and private token transactions. Redact provides an entry point for users to interact with confidential ERC-20 tokens ([fhERC20](https://github.com/FhenixProtocol/encrypto-contracts/blob/master/FHERC20.MD)) and in the future will support FHED, a confidential stablecoin. By integrating with Fhenix’s [CoFHE](https://cofhe-docs.fhenix.zone/), Redact enables users to perform on-chain transactions while maintaining complete data privacy. Unlike traditional DeFi platforms, where transactions and balances are publicly visible, Redact ensures that amounts and balances details remain private while maintaining compliance with on-chain verifiability. ### Key Objectives Redact is designed to achieve the following: * Confidential Transactions: Users can send and receive assets privately, with transaction details encrypted. * fhERC20 Support: Standard ERC-20 tokens can be wrapped into fhERC20, enabling confidential DeFi interactions. * Seamless User Experience: A browser-based wallet allows users to wrap (encrypt), unwrap (decrypt), send, receive, and manage balances with an intuitive UI. ### Why Confidentiality Matters Traditional blockchain networks expose all transaction details, creating concerns around financial privacy, front-running, and surveillance. With Redact: * Users retain full privacy over their financial data. * Businesses and institutions can execute confidential transactions without exposing sensitive financial flows. * DeFi applications can offer private financial services without compromising transparency. Redact facilitates the processing of encrypted transactions on-chain without disclosing their contents, ensuring that confidentiality does not compromise verifiability. By providing users with a simple way to convert their public erc20 tokens into confidential fhERC20 tokens, Redact serves as an entry point into confidential DeFi. Read more about the motivation behind Redact here: {% content-ref url="/pages/1Dbvw0HYYBaGpfZVrZOj" %} [Motivation](/motivation) {% endcontent-ref %} ## Core Functionalities Redact enables users to: * Wrap ERC-20 Tokens: Encrypt and convert standard ERC-20 tokens into fhERC20 for private transactions. * Send & Receive Confidential Transactions: Execute on-chain transactions while keeping amounts private. * Manage Confidential Balances: Maintain user balance confidentiality.

Confidential Transaction Flow

Confidential Balance Flow

### How It Works Redact’s core mechanism consists of: 1. Confidential Tokenization: Users wrap ERC-20 tokens into fhERC20 to enable private transactions. 2. Confidential Stablecoin Minting: Users mint FUSD by locking stablecoins in a secure contract. 3. Confidential Transactions: When transferring tokens, only the sender and receiver are visible, while amounts and balances remain hidden. 4. Fhenix Coprocessor Execution: All confidential computations (wrapping, minting, sending) run off-chain on the CoFHE, ensuring scalability and security. # Motivation Privacy -> FHE -> CoFHE -> Redact ### Why Privacy? Blockchains are excellent for ensuring transparency, security, and trust, but this transparency comes at a cost—everything is public. Every transaction, smart contract interaction, and account balance is openly visible, which isn’t ideal for use cases involving sensitive data like finance or healthcare. On public blockchains like Ethereum, every transaction, smart contract interaction, and account balance is fully accessible to anyone. While this extreme transparency is key to building trust and enabling verification, it introduces serious privacy challenges. Fully Homomorphic Encryption (FHE) addresses this tradeoff by allowing data to remain completely encrypted while still enabling the blockchain to verify its accuracy and authenticity. This means sensitive information can be processed and validated without ever being exposed, delivering the best of both worlds: robust privacy and trustless verification. ### Why FHE? Fully Homomorphic Encryption (FHE) is a groundbreaking cryptographic method that enables computations to be performed on encrypted data without ever decrypting it. Unlike traditional cryptographic techniques, which protect data only until it is actively used, FHE keeps the data encrypted even during processing, ensuring that sensitive information remains secure at every stage. This innovation prevents data leaks and represents a major advancement in privacy-preserving technology. FHE works by allowing users to encrypt their data into ciphertext, after which the blockchain can perform computations directly on the encrypted data. The results of these computations remain encrypted and can only be decrypted by the authorized user. This ensures that data remains private throughout the entire process. By combining this level of privacy with the functionality of smart contracts, FHE enables logic to be executed securely on encrypted inputs while generating encrypted outputs. This means users retain complete control of their data without relying on trusted third parties, making FHE a transformative solution for privacy, security, and decentralized trust. ### Why CoFHE? CoFHE is the ideal solution for enabling privacy, scalability, and security in Ethereum and other EVM-compatible chains by allowing smart contracts to process encrypted data without exposing sensitive information. It works off-chain for speed and scalability while maintaining compatibility with existing frameworks, requiring no chain migration and integrating effortlessly via a simple Solidity library. With features like asynchronous execution for cheaper transactions, comprehensive developer tools like Remix and Hardhat, and a decentralized, trustless design leveraging threshold key management and execution verifiability, CoFHE empowers developers to build confidential smart contracts that handle encrypted data securely, scale efficiently, and remain fully composable within the Ethereum ecosystem. ### Why Redact? Redact delivers true on-chain privacy to Ethereum and Arbitrum by encrypting all token balances and transaction payloads using fully homomorphic encryption. It enables confidential transfers while keeping your balances hidden, serving as the foundation for private DeFi. With Redact, there’s no more front-running or balance snooping—only you (and those you explicitly authorize) can view your holdings. To everyone else, transactions appear as standard EVM transfers, ensuring total confidentiality without compromising composability. Despite its advanced privacy features, Redact functions like any other application. You can connect through MetaMask or any standard wallet and interact with familiar tools and dApps. Looking ahead, Redact will evolve into the gateway for a fully private DeFi ecosystem—offering lending, borrowing, swapping, and liquidity provision, all under complete privacy. # Roadmap Redact roadmap consists of 5 phases: 1. Phase 0 - Testnet Deployment (current stage) 2. Phase 1 - Mainnet Launch 3. Phase 2 - Core Components Polish 4. Phase 3 - Ecosystem Expansion 5. Phase 4 - UX Optimization

Redact Roadmap Illustration

## Phase 0 → Testnet Deployment **Goal:** Launch Redact on the testnet to introduce confidential DeFi for initial use * **Encrypt** Encrypt ERC20 token balances into fhERC20 confidential token balances. * **Decrypt**\ Decrypt fhERC20 token balances back into ERC20 public token balances. * **Confidential Transactions**\ Privately send confidential tokens between wallets, the amount sent is encrypted and private (confidentiality), but the sender and receiver are public (non-anonymous). ## Phase 1 → Mainnet Launch **Goal**: Deploy Redact on mainnet * **Mainnet launch**\ Deploy contracts, update frontend network configs, run pre-launch smoke tests. * **Performance & load testing**\ Validate end-to-end flows at scale (wrapping, minting, transfers). * **Monitoring & alerts**\ Stand up on-chain telemetry and on-call dashboard for quick incident response. ## Phase 2 → Core Components Polish **Goal:** Round out foundational UX & privacy flows * **Multi-wallet connect**\ Ensure users can connect multiple wallets. * **Smart wallet integration**\ Finalize Alchemy Smart Wallet SDK flows: creation, import, signing. * **Wallet optimization**\ Triage and fix performance/UI glitches in the in-dApp wallet. ## Phase 3 → Ecosystem Expansion **Goal:** Grow reach via incentives and new chains * **Deployment on additional EVM-chains**\ Roll out Redact contracts & UI to one or two testnet/mainnet EVM forks (e.g. Polygon, BSC). * **Rewards mechanism release**\ Launch the opt-in yield-rewards module on mainnet. ## Phase 4 → UX Optimization **Goal:** Drive adoption with polished experiences * **Mobile version optimization**\ Refactor responsive layouts, performance budgets, touch-flow refinements. * **Ongoing wallet optimization**\ Iterate on UX (batch txs, gas-fee hints, balance sync), reduce latency further. * **Confidential tx hardening**\ Add final checks (fraud-proofs, replay protection) and audit fixes for confidential transfers. * **Shared permits integration**\ Wire up fhERC-20 permit issuance on login for confidential-data decryption.
# FAQ #### Q: What are confidential tokens A confidential token contract with an encrypted balance. All ConfidentialERC20s have an underlying ERC20 that they are paired with. (eETH / ewBTC / ePEPE). #### Q: What is a confidential tx? A confidential transaction in the context of token transfers ensures that the amount of tokens sent remains private, visible only to the sender and receiver, while remaining hidden from anyone observing on-chain data. #### Q: Why can’t I see my confidential balance? Redact keeps all balances encrypted and only shows them once you’ve decrypted with a valid self-permit. If you haven’t created or loaded your Cofhejs “self” permit (or it’s expired after 24 hours). #### Q: Why does my balance in my wallet look like this: “0.5001”? Wallets and block explorers can’t display encrypted balances without CoFHE integration. Instead, they show an “indicated” balance between 0 and 1, increasing or decreasing by 0.0001 with every transfer (e.g., 0.5005 → 0.5006 when receiving tokens). This counter shows balance changes and their direction without exposing the actual value or amount transferred. As FHE adoption grows, wallets and explorers are expected to integrate and display true encrypted balances. #### Q: What are Permits? Fhenix Permits are signed EIP712s (via Cofhejs) that authorize off-chain decrypt and seal operations on encrypted balances. Available in “self,” “sharing,” and “recipient” types, they’re network-specific, expire after 24 hours by default, and require signature checks to prevent misuse. In Redact, permits let you—and only those you authorize—query and decrypt your confidential token balance (with future support for transaction history and DeFi actions). #### Q: When will I need to "Deploy" a Confidential token? Redact can wrap any arbitrary ERC20 token into a confidential fhERC20 token (ConfidentialERC20.sol smart contract). Every ERC20 must have a matching ConfidentialERC20 deployed before any ERC20 balance can be encrypted. Once the matching confidential token is deployed, it can be used by anyone to encrypt their underlying token balances. #### Q:Why do I need to provide an allowance every time I want to encrypt? Many applications allow users to request approval for a large amount in advance, eliminating the need to provide approval every time they execute a transaction. While this approach improves user experience, it also exposes you to unnecessary risks. To ensure security, we request approval for the exact amount needed each time you encrypt tokens. # Technical Walkthrough This walkthrough goes through the core functionality of Redact, namely **Encrypting** your ERC20 balances, performing an **Encrypted Transfer**, and **Decrypting** your encrypted balance back into a public balance. During the walkthrough we will also discuss the underlying technology behind an encrypted token balance, including FHE and Fhenix's CoFHE coprocessor. #### Terms
NameDescription
ERC20

A standard token contract with a public balance

(WETH / wBTC / PEPE)

ConfidentialERC20

A confidential token contract with an encrypted balance. All ConfidentialERC20s have an underlying ERC20 that they are paired with.

(eETH / ewBTC / ePEPE)

FHEFully Homomorphic Encryption. An encryption scheme that allows math operations to be performed on encrypted values without knowing the unencrypted value.
CoFHEFhenix's offchain coprocessor which uses an FHE engine to perform FHE operations and decryptions.
cofhejsA javascript package released along side the CoFHE coprocessor that allows integration with a dApp.
### Encrypting your ERC20 balance {% hint style="success" %} To Encrypt your ERC20 balance in Redact, see this usage guide: [Encrypting](/using-redact/encrypting) {% endhint %} Redact[^1] uses FHE to encrypt any ERC20 token balance. An existing ERC20 cannot be changed because smart contracts are immutable, so in order to encrypt a balance, we must first deploy a corresponding ConfidentialERC20. {% hint style="info" %} We have deployed ConfidentialERC20s for some of the most trusted and widely used tokens on Ethereum and Arbitrum, however since any ERC20 can be used to deploy a ConfidentialERC20, the first user to perform a balance encryption for an arbitrary ERC20 may be required to first deploy a new ConfidentialERC20 token. *(This is similar to creating a new Uniswap pool)* {% endhint %} Encrypting[^2] your ERC20 balance is easy, first we approve the amount you want to encrypt, and then we call the encryption function on the ConfidentialERC20. Under the hood, the amount you want to encrypt is converted into an FHE encrypted variable. In the ConfidentialERC20 smart contract, this looks like: ``` euint128 eAmount = FHE.asEuint128(amount) ``` This `euint128` variable is then added to your balance: ``` eBalance = FHE.add(eAmount, eBalance) ``` In the end, your encrypted balance is increased by the new amount being encrypted, just as it would with a standard ERC20, however when your balance is queried the result will be a value like this: ``` euint128 eBalance: 44737007662638353742293290064938024389209573332104467622358026769121523303424 ``` This value is called a `ctHash`, it represents a hash of the true ciphertext that is created when a value is encrypted or an FHE operation takes place. It is this full ciphertext that holds the encrypted value, the ctHash is a pointer to the full value. As you can see, this encrypted value hash doesn't expose any information about the true amount of tokens you hold. This is the magic of FHE, it means that you can do an operation like this: ``` FHE.add( 44737007662638353742293290064938024389209573332104467622358026769121523303424, 115747559174423067489356306390877806995718991284442275570070818829210672923648 ) = 110692103698438822018438792470625059183234012775043055013737988615198382031872 ``` And without ever decrypting the values, the addition can be performed (5 + 10 = 15 in this case). ### Reading your Encrypted Balances {% hint style="success" %} For more on the embedded wallet and how to use it, see this guide: [Confidential Balances (Wallet)](/using-redact/confidential-balances-wallet) {% endhint %} We now have an encrypted balance, but what good is a balance you can't see? There are two ways to decrypt this balance, the first is on-chain using `FHE.decrypt` (this will be discussed in the **Decrypt and Claim** flow below), and the other is off-chain using `cofhejs`. We want to see our encrypted balance in the Redact dApp, so we will use the off-chain decryption. Your encrypted balance is only viewable by you (what good is an encrypted balance this is publicly available), so we must first prove our identity by creating and signing a `Permit` that verifies that you have knowledge of your wallet's privateKey. This Permit is then packaged with the `ctHash` pointing to your encrypted balance and sent to a component of CoFHE called the **Threshold Network** (TN).\ \ The TN validates the provided Permit and `seals` (re-encrypts) your encrypted balance so that only you can reveal it (under the hood this uses a generated keypair, the public key of which is sent as part of your Permit). The `sealed` data is then revealed locally inside of Redact, where it is then shown to you as a plain number. ### Encrypted Transfer {% hint style="success" %} To send encrypted tokens in Redact, see this usage guide: [Confidential Transfer (Sending)](/using-redact/confidential-transfer-sending) {% endhint %} Now that we have some encrypted tokens (and we can see how much we have), we can make an encrypted transfer to another account. This operation involves an extra step, which is to hide the amount that is being transferred by using an **encrypted input**. Encrypting an input involves two steps: **encryption** and **verification**. The encryption step is handled locally inside of Redact, and the verification step is handled in the Threshold Network (TN) component of CoFHE. We use a FHE public key fetched from CoFHE to encrypt the amount of ConfidentialERC20 to be transferred. This encrypted value is then sent to the Threshold Network, where its encryption is verified to be valid. {% hint style="info" %} Only the encrypted amount is sent to the TN, the raw amount is only used to perform the encryption, after that it is discarded. {% endhint %} The TN then signs a message that this encrypted amount is valid, and returns it along with a `ctHash` that represents the encrypted amount. Together, the signature and ctHash form an encrypted input. In Redact, since all the values are represented by encrypted `euint128`this encrypted input is an `InEuint128`. This is great, because this is exactly what we need to call this function in the ConfidentialERC20 contract: ``` function encTransfer(address to, InEuint128 memory inValue) ``` The `encTransfer` function is very simple, it removes the transferred amount from the sender's encrypted balance using `FHE.sub`, and adds it to the receiver's balance using `FHE.add`. Both the senders' and receivers' encrypted balances are updated, but it is unknown by what amount since the input amount is encrypted. #### Caveat: Invalid Transfer Amount There is one caveat with FHE operations, which is that we don't know the value of the variables when we're doing an FHE operation, so how would we know if the user tried to send 20 encrypted tokens, but only owned 10? We won't get into the specifics of what this looks like on-chain (it uses `FHE.select` and `FHE.gte`) but the result is that if an invalid amount is transferred, that amount is replaced with 0. This means that if the user Bob tries to send 20 encrypted tokens while only owning 10 to another user Alice, the transfer amount would be compared to Bob's balance, seen to be invalid, and replaced with 0. Bobs transaction would still succeed, but he would have sent 0 tokens to Alice. Even though the amount transferred was ultimately 0, both Bob's and Alice's encrypted balance variables would have been updated (by an unknown encrypted amount). In the future as CoFHE adoption grows, it is the encrypted transfer that will be the core of an encrypted defi ecosystem including confidential swaps/lending/borrowing/etc. ### Decrypting ConfidentialERC20 and Claiming ERC20 {% hint style="success" %} To Decrypt your confidential tokens in Redact, see this usage guide: [Decrypting](/using-redact/decrypting) {% endhint %} To unwrap or decrypt your confidential balance, we will go through the Decrypt & Claim flow. Note that you are decrypting your balance by transferring it from an encrypted state in the ConfidentialERC20 contract to a readable, or cleartext, state in the original ERC20 contract. This process requires two separate transactions, the first performs an on-chain decryption using `FHE.decrypt`. CoFHE, which is watching the chain for messages that signal that an operation has been requested, will pick up this message, and perform the decryption. The result of this decryption is then updated on-chain by a transaction sent by the coprocessor (this usually takes between 5-10 seconds to fully finalize). Once the decryption is finalized and the result stored on-chain, the user is then able to Claim those decrypted tokens. This transaction then transfers the decrypted amount of the ERC20 back to the user, completing the process. This flow requires two separate transactions in order for the asynchronous decryption to be performed by the coprocessor. [^1]: i afraied that it's going too deep too soon - we should first explain what Redact provides/does before diving into the limitations and the technical details\ [Rogue Rotkosky](mailto:undefined) [^2]: again, i'd suggest that it's going to deep to fast - first why not providing a high-level bullet point list of the flow/process? # Confidential Balances (Wallet) Redact has a built in wallet that can be used to: 1. View your token balances as a breakdown between public and confidential balances. 2. View your past transactions (including confidential transactions). 3. Transfer encrypted tokens between wallets. The wallet can be opened by pressing the **CONNECT** button in the top right corner of the dApp. If you are already connected, the button will display your connected wallet address instead:
Once open, you will see your native token balance, as well as a list of ERC20 tokens. Each token in the list shows the breakdown of public vs confidential balance. The history tab shows a list of all transactions that have been executed in Redact.
{% hint style="info" %} Note that ETH/WETH are combined in this view. Both ETH and WETH are encrypted into the same confidential token **eETH** so they have been combined in the token list. You can read more about ETH/WETH in the [ConfidentialERC20.sol](/architecture/confidentialerc20.sol)page. {% endhint %} Each of the rows in this list can be expanded to view the individual balances and claimable amounts for each token. As an example, lets open the LINK token page:

LINK token page

This page shows the encrypted balance (5 eLINK), public balance (16 LINK), and claimable balance (3 LINK). The encrypted balance, 5 in this case, is a value that is ***only*** visible to the owner of the account. In order to view this data, it is fetched from the CoFHE coprocessor as a `sealed` value (meaning it is still in an encrypted state, but it can be unsealed locally within Redact), and then `unsealed` locally using an autogenerated Permit. # Encrypting Encrypting is the process of converting your ERC20 balance into a confidential and private FHERC20 balance. The full process for encryption involves 3 steps: 1. Add a new token (optional) 2. Approval (skipped if ERC20 allowance is sufficient) 3. Encrypt ### 1. Add a new token In addition to the pre-deploy tokens, the system allows you to add a custom token by clicking the "Add Token" button. This option is available in both the main tokens section and the portfolio section. To add a token, the user must first provide the contract address of the public ERC20 token. The system will then search for it. If the confidential token has already been deployed, the user simply needs to click "Add," and the confidential version of the token will be added to the token list. If the confidential token has not been deployed, the user must also click "Add." In this case, only the public version of the token will be added to the list, and the first time the user encrypts the token, the contract for the confidential version will be deployed. Once deployed, the eToken will automatically be included in the token list. image placeholder #### FHERC20 Deployment The FHERC20 contract ([FHERC20 Token Standard](/architecture/fherc20-token-standard)) is responsible for holding your encrypted balances, and performing encrypted transfers. More specifically, the ConfidentialERC20 contract ([ConfidentialERC20.sol](/architecture/confidentialerc20.sol)) is built on the FHERC20 core, and inherits the encrypted functionality. Therefore, in order to encrypt your ERC20 balance, we must first deploy a "paired" ConfidentialERC20 which points at the underlying ERC20 we wish to encrypt. {% hint style="info" %} Each ConfidentialERC20 (and paired ERC20) only needs to be deployed once. Once it is deployed, all future wrapping and unwrapping will use this contract for all users. {% endhint %} In Redact, deploying a new ConfidentialERC20 is simple, and only requires a single transaction. This is what the Deployment flow looks like in the Redact UI:

Deployment flow diagram. (1) Initial, (2) Pending, (3) Success

TX: [https://sepolia.etherscan.io/tx/0x21a...b7d](https://sepolia.etherscan.io/tx/0x21a2917fdcc7f6d6bbac6f8feeb147a7566bf033446e6fdb5c85ae4caa9d2b7d) ### 2. Approval In order to encrypt (or wrap) your ERC20 tokens, they must first approve them for use in the ConfidentialERC20 smart contract. Only the amount to wrap must be approved. In the Redact UI, this is step 2 of the wrapping process, and appears like so:

Approval flow diagram. (1) Initial, (2) Pending, (3) Success

Tx: [https://sepolia.etherscas.io/tx/0x777...d0b](https://sepolia.etherscan.io/tx/0x777454fa9843eb190a472e9a1d0ef0b75ee4dd85a1e368f5af5006a56bea5d0b) ### 3. Encryption Now that the ConfidentialERC20 has been deployed, and the amount to encrypt has been approved for spend, we can encrypt our ERC20 balance to make it confidential. [ConfidentialERC20.sol#L80-L85](https://github.com/FhenixProtocol/redact/blob/master/packages/hardhat/contracts/ConfidentialERC20.sol#L80-L85) shows the internal logic that handles encrypting of balances: ```solidity function encrypt(address to, uint128 value) public { if (to == address(0)) to = msg.sender; _erc20.safeTransferFrom(msg.sender, address(this), value); _mint(to, value); emit EncryptedERC20(msg.sender, to, value); } ``` This function withdraws the ERC20 token from the sender's wallet, and in turn performs an encrypted `_mint` operation which uses `FHE.add` to increase the sender's encrypted balance of the ConfidentialERC20. In the Redact UI, the wrapping processes appears like this:

Encryption flow Diagram. (1) Initial, (2) Pending, (3) Success

After the Encryption transaction succeeds, we can see that in the wallet the encrypted balance has been updated. Each account's balance is only visible to that account and this balance will be seen as encrypted to all other accounts. Lets quickly take a look at this transaction in a block explorer: TX: [https://sepolia.etherscan.io/tx/0xb03...22f](https://sepolia.etherscan.io/tx/0xb03e2a8e17425495cb9b01ccbbca329d94074550733ecb0ef49f1f98217ad22f)

Example "Encrypt" transaction in Etherscan

Notice that in the transaction screenshot above that the amount of LINK transferred is public (1 LINK), but the amount of eLINK transferred is private and is shown as an *indicated* amount (0.0001 eLINK).\ Read more about indicated balances here: [FHERC20 Token Standard](/architecture/fherc20-token-standard#indicated-balances) This shows that *some unknown* amount of eLINK has been minted (aka transferred from the zero address), but it is not revealed how much has been minted. {% hint style="warning" %} Note that in this situation we can infer the amount minted from the public LINK transferred, but that is not true for confidential transfers: [Confidential Transfer (Sending)](/using-redact/confidential-transfer-sending) {% endhint %} # Decrypting Decrypting is the process of converting your confidential FHERC20 balance back into a public ERC20 balance. This process has 2 steps: 1. Decrypting some amount of FHERC20 2. Claiming the decrypted amount as ERC20 {% hint style="info" %} When converting from a confidential balance to a public balance, we must perform an on-chain decryption using `FHE.decrypt` . In this case, we must use `FHE.decrypt` on the amount of token that has been transferred. This decryption request is picked up by CoFHE, which will perform the decryption and post the result back on-chain. This asynchronous on-chain decryption is what forces "Decrypt" and "Claim" to be handled by two separate transactions. {% endhint %} ### 1. Decrypting FHERC20 Balance After selecting the FHERC20 token to decrypt and the amount to decrypt, we execute the Decrypt transaction. In [ConfidentialERC20.sol](/architecture/confidentialerc20.sol) the function `decrypt()` is used, which burns the FHERC20 and requests an on-chain FHE decryption of the amount burned. Once the on-chain FHE decryption is finalized, that amount is marked as "Claimable" and can be claimed as the underlying ERC20 in the upcoming step. In Redact, this is the expected Decrypt flow:

Decryption flow diagram. (1) Initial, (2) Pending, (3) Success

TX: [https://sepolia.etherscan.io/tx/0x7a2...a71](https://sepolia.etherscan.io/tx/0x7a29ec13573d1c0f5f11c48a52d8a04d1578800f8f9a7ed7e04fa90ed12f8a71) After the Decryption transaction has succeeded, you can note that in the wallet the public ERC20 balance has been replaced with two balances: The **public** balance, and the **claimable** balance. You can claim these decrypted tokens either from the main page component, or from within the wallet using the **CLAIM** button ### 2. Claiming ERC20 Balance After the successful on-chain FHE decryption has resolved, we are ready to claim the ERC20s. Claiming will add the claimable amount to your ERC20 balance, and in Redact it looks like this: In order to encrypt (or wrap) your ERC20 tokens, they must first approve them for use in the ConfidentialERC20 smart contract. Only the amount to wrap must be approved. In the Redact UI, this is step 2 of the wrapping process, and appears like so:

Approval flow diagram. (1) Initial, (2) Pending, (3) Success

Tx: [https://sepolia.etherscan.io/tx/0x401...cc2](https://sepolia.etherscan.io/tx/0x40101268d1a87e51f89e979298e51732875bae2702885370bc166a99cec41cc2) {% hint style="info" %} Notice that in the transaction above, it is public LINK that is being transferred during the claim flow. {% endhint %} If you would like to read more about claiming take a look here: [ConfidentialERC20.sol](/architecture/confidentialerc20.sol#claim-system) # Confidential Transfer (Sending) Transferring confidential tokens between accounts is essential to a functional defi ecosystem. In Redact, transferring tokens is performed from within the Wallet using the **SEND** button. Transferring confidential tokens requires setting the transaction mode to **confidential**, entering the amount to send, and the address to send to. In Redact, this is how it appears:

Transfer flow diagram. (1) Form Populated, (2) Pending, (3) Finalized

TX: [https://sepolia.etherscan.io/tx/0x7a2...a71](https://sepolia.etherscan.io/tx/0x7a29ec13573d1c0f5f11c48a52d8a04d1578800f8f9a7ed7e04fa90ed12f8a71) This example transaction sends 1 eLINK between accounts, but as you can see from the block explorer link, only an indicated amount is shown:

Explorer transfer of 0.0001 eLINK (indicated amount)

### Encrypted Input In order to preserve the confidentiality of the amount to be transferred, it must be encrypted *before* it is sent to the blockchain to be used in a transaction. In the case of the tx above, we must first encrypt the value **1**. This encryption is handled using `cofhejs.encrypt` which converts the input value into an `InEuint128`, a datatype that is used in `FHERC20.encTransfer(address to, InEuint128 calldata amount)` This information is not necessary to use Redact, as it is all handled in the background, but it is crucial information in understanding *how* Redact and CoFHE preserve data confidentiality. # Add Token Tokens can be already deployed or not...
# 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. # FHERC20.sol ### Overview [FHERC20.sol](https://github.com/FhenixProtocol/redact/blob/master/packages/hardhat/contracts/FHERC20.sol) is an implementation of the ERC20 standard that incorporates Fully Homomorphic Encryption (FHE) to enable confidential token balances and confidential transfers. To read more about the design of the FHERC20 standard go here: [FHERC20 Token Standard](/architecture/fherc20-token-standard) ### External Functions #### View Functions **`isFherc20()`** * Returns `true` to indicate this is a FHERC20 token * Intended to be used by explorers and wallets in the future to change how the encrypted balances and encrypted transactions are displayed. **`name()`** * Returns the token name. * In Redact, the token name of a ConfidentialERC20 is prefixed with `Confidential` . For example `Chainlink Token` would become `Confidential Chainlink Token`. **`symbol()`** * Returns the token symbol. * In Redact, the token name of a ConfidentialERC20 is prefixed with `e` . For example `LINK` would become `eLINK`. **`decimals()`** * Returns the number of decimals for token display * In Redact, the number of decimals of a ConfidentialERC20 is the same as the underlying ERC20. **`totalSupply()`** * Returns the **indicated** total supply **`encTotalSupply()`** * Returns the `ctHash` of the encrypted total supply. **`balanceOfIsIndicator()`** * Returns `true` to indicate that `balanceOf` returns an indicator value rather than a true balance value. **`indicatorTick()`** * Returns the size of the indicator tick **`balanceOf(address account)`** * Returns the **indicated** balance for an account * Value ranges from 0.0000 to 0.9999 * Increases by 0.0001 when receiving confidential tokens, reduces by 0.0001 when sending. * Read more here: [FHERC20 Token Standard](/architecture/fherc20-token-standard#indicated-balances) **`encBalanceOf(address account)`** * Returns a `ctHash` representing the true encrypted balance of an account #### State-Changing Functions **`encTransfer(address to, InEuint128 memory inValue)`** `encTransfer(address to, euint128 inValue)` * Transfers encrypted tokens from sender to recipient * Can either accept an encrypted input variable, or an encrypted uint128, as the amount to transfer. * Emits both a Transfer event (with an indicated amount) and an EncTransfer event (with an encrypted `ctHash` amount) **`encTransferFrom(address from, address to, InEuint128 memory inValue, FHERC20_EIP712_Permit calldata permit)`** * Transfers encrypted tokens on behalf of another address * Requires valid FHERC20\_EIP712 permit signature * Emits both a Transfer event (with an indicated amount) and an EncTransfer event (with an encrypted `ctHash` amount) #### Restricted Functions The following standard ERC20 functions are intentionally restricted to prevent accidental usage: * `transfer(address, uint256)` * `allowance(address, address)` * `approve(address, uint256)` * `transferFrom(address, address, uint256)` These functions will revert with `FHERC20IncompatibleFunction()` to prevent the contract from being treated as a standard ERC20. ### Events #### `Transfer(address indexed from, address indexed to, uint256 value)` * Emitted on token transfers * Uses **indicated** balance values for compatibility #### `EncTransfer(address indexed from, address indexed to, uint256 value)` * Emitted on token transfers * Includes the encrypted transfer value as a `ctHash` ### Confidentiality Considerations 1. All balance operations use FHE to maintain confidentiality 2. Traditional allowances are replaced with FHENIX\_EIP712 permits to be used during a transaction 3. Indicated balances are used for UI/UX only and should not be used for any logic # ConfidentialERC20.sol ### Overview [ConfidentialERC20.sol](https://github.com/FhenixProtocol/redact/blob/master/packages/hardhat/contracts/ConfidentialERC20.sol) (and [ConfidentialETH.sol](https://github.com/FhenixProtocol/redact/blob/master/packages/hardhat/contracts/ConfidentialETH.sol)) is an implementation of the FHERC20 standard that enables confidential token operations for any ERC20 token. It wraps existing ERC20 tokens to provide confidential balance and transfer functionality while maintaining compatibility with the original token's properties. ### Key Concepts #### Token Wrapping * ConfidentialERC20 wraps existing ERC20 tokens to provide confidential functionality * The wrapped token maintains the same name (prefixed with "Confidential") and symbol (prefixed with "e") * Decimals are preserved from the original token * The original token can be deposited and withdrawn through the contract using `encrypt` and `decrypt` #### Confidential Balances * Inherits all FHE functionality from FHERC20 * Balances are stored as encrypted values (`euint128`) * Uses **indicated** balances for UI/UX compatibility * See FHERC20 Documentation for detailed balance mechanics: [FHERC20.sol](/architecture/fherc20.sol) #### Claim System The contract implements a claim system through the `ConfidentialClaim.sol` contract that enables: * Creation of confidential claims for token amounts * Decryption of claimed amounts * Tracking of user claims * Batch claiming functionality ### External Functions #### View Functions **`underlying()`** * Returns the address of the underlying ERC20 token * Used to identify the original token being wrapped **`isConfidentialERC20()`** * Returns `true` to indicate this is a ConfidentialERC20 token **`getClaim(uint256 ctHash)`** * Returns claim information for a specific encrypted amount * Includes requested amount, decrypted amount, and claim status * Only accessible to authorized parties **`getUserClaims(address user)`** * Returns all claims associated with a user * Includes both pending and claimed amounts * Only accessible to authorized parties #### State-Changing Functions **`encrypt(address to, uint128 amount)`** * Deposits the specified amount of the underlying token * Mints an equivalent amount of confidential tokens * Requires approval of the underlying ERC20 **`decrypt(address to, uint128 amount)`** * Burns the specified amount of confidential tokens * Transfers the equivalent amount of the underlying token * Requires sufficient confidential token balance ### ConfidentialETH ConfidentialETH is a special case of ConfidentialERC20 that wraps the native ETH token. ConfidentialETH allows encrypting of both ETH (using `encryptETH` ) and WETH (using `encryptWETH`). When decrypting ConfidentialETH, it is always decrypted as ETH, never WETH. **Symbol** * ConfidentialETH symbol is `eETH` #### Encrypt Process * Uses `msg.value` instead of token approval when encrypting `ETH` into `eETH` * No need for separate token approval #### Withdrawal Process * Unwraps WETH back to ETH * Sends native ETH to the recipient * Handles gas considerations for ETH transfers ### Claim System Details (ConfidentialClaim.sol) #### Claim Structure ```solidity struct Claim { uint256 ctHash; // Hash of the encrypted amount uint128 requestedAmount; // Original requested amount uint128 decryptedAmount; // Decrypted amount after processing bool decrypted; // Whether the amount has been decrypted address to; // Claim recipient bool claimed; // Whether the claim has been processed } ``` #### Claim Process 1. **Creation** * A claim is created with an encrypted amount * The claim is associated with a specific recipient * The encrypted amount is stored with its hash 2. **Decryption** * The encrypted amount is decrypted using FHE * The decrypted amount is verified against the original request * The claim status is updated 3. **Processing** * The decrypted amount is transferred to the recipient * The claim is marked as claimed * The claim is removed from the user's active claims #### Batch Operations * Users can claim multiple amounts in a single transaction * Gas efficient for processing multiple claims * Maintains confidentiality of individual amounts ### Events #### `Deposit(address indexed user, uint256 amount)` * Emitted when underlying tokens are deposited * Includes the deposit amount #### `Withdraw(address indexed user, uint256 amount)` * Emitted when confidential tokens are withdrawn * Includes the withdrawal amount #### `ClaimCreated(address indexed user, uint256 ctHash, uint256 amount)` * Emitted when a new claim is created * Includes the claim hash and amount #### `ClaimProcessed(address indexed user, uint256 ctHash, uint256 amount)` * Emitted when a claim is processed * Includes the claim hash and decrypted amount # RedactCore.sol ### Overview [RedactCore.sol](https://github.com/FhenixProtocol/redact/blob/master/packages/hardhat/contracts/RedactCore.sol) is the central management contract for the Redact protocol. It handles the deployment and tracking of confidential tokens (ConfidentialERC20) and manages special cases like ConfidentialETH. The contract maintains a registry of all deployed confidential tokens and their relationships with underlying ERC20 tokens. ### Key Concepts #### Token Registry * Maintains a mapping between ERC20 tokens and their confidential wrappers * Uses `EnumerableMap` for efficient iteration and lookup * Prevents duplicate deployments of confidential wrappers #### Special Token Handling * Manages ConfidentialETH (eETH) as a special case * Tracks stablecoins separately for potential special handling * Maintains WETH integration for ETH operations #### Access Control * Implements `Ownable2Step` for secure ownership management * Restricts critical operations to the contract owner (EX: renaming ConfidentialERC20s) ### External Functions #### View Functions **`getFherc20(address erc20)`** * Returns the address of the confidential wrapper for a given ERC20 token * Returns `address(0)` if no wrapper exists * Used to look up confidential token addresses **`getIsStablecoin(address erc20)`** * Returns whether a token is registered as a stablecoin * Used for special handling of stablecoin tokens **`getIsWETH(address erc20)`** * Returns whether a token is the WETH contract * Used for ETH-specific operations **`getDeployedFherc20s()`** * Returns an array of all deployed confidential tokens * Includes both the original ERC20 and its confidential wrapper * Useful for UI integration and monitoring #### State-Changing Functions **`deployFherc20(IERC20 erc20)`** * Deploys a new ConfidentialERC20 wrapper for the specified token * Prevents deployment for: * Already wrapped tokens * Stablecoins * WETH (handled separately) * Emits `Fherc20Deployed` event **`updateStablecoin(address stablecoin, bool isStablecoin)`** * Updates the stablecoin status of a token * Restricted to contract owner * Emits `StablecoinUpdated` event **`updateFherc20Symbol(ConfidentialERC20 fherc20, string memory updatedSymbol)`** * Updates the symbol of a deployed confidential token * Restricted to contract owner * Emits `Fherc20SymbolUpdated` event ### Special Cases #### ConfidentialETH (eETH) * Pre-configured during contract deployment * Uses WETH as the underlying token * Handles native ETH wrapping/unwrapping * Special gas optimizations for ETH operations #### Stablecoins * Can be marked as stablecoins for special handling * Prevents deployment of confidential wrappers for stablecoins * Allows for future implementation of stablecoin-specific features * Prepares for a future unified encrypted stablecoin. ### Events #### `Fherc20Deployed(address indexed erc20, address indexed fherc20)` * Emitted when a new confidential token is deployed * Includes both the original and confidential token addresses #### `StablecoinUpdated(address indexed erc20, bool isStablecoin)` * Emitted when a token's stablecoin status is updated * Includes the token address and new status #### `Fherc20SymbolUpdated(address indexed fherc20, string symbol)` * Emitted when a confidential token's symbol is updated * Includes the token address and new symbol ### Error Handling #### Custom Errors * `Invalid_AlreadyDeployed()`: Attempted to deploy wrapper for already wrapped token * `Invalid_Stablecoin()`: Attempted to deploy wrapper for stablecoin * `Invalid_WETH()`: Invalid WETH address provided * `Invalid_eETH()`: Invalid eETH address provided ### Integration Guide #### Deployment 1. Deploy WETH contract if not already deployed 2. Deploy ConfidentialETH (eETH) contract 3. Deploy RedactCore with WETH and eETH addresses #### Adding New Tokens 1. Check if token is already wrapped using `getFherc20` 2. If not wrapped, call `deployFherc20` with the token address 3. Monitor `Fherc20Deployed` event for confirmation #### UI Integration 1. Use `getDeployedFherc20s` to list all available confidential tokens 2. Use `getFherc20` to look up specific token wrappers 3. Handle special cases for ETH and stablecoins appropriately ### Security Considerations 1. **Access Control** * Critical functions restricted to owner * Two-step ownership transfer process * Careful management of stablecoin status 2. **Deployment Safety** * Prevention of duplicate deployments * Validation of WETH and eETH addresses * Protection against stablecoin wrapping 3. **Token Management** * Secure symbol updates * Proper event emission for tracking * Safe handling of special cases # CoFHE Overview ## **Overview** The Fhenix's Fully Homomorphic Encryption (FHE) CoProcessor - **CoFHE -** is a key component of the **Redact application**, enabling **confidential computations** on EVM-compatible blockchains. It allows **dApps to integrate encrypted data into their smart contracts**, ensuring **private transactions, confidential token minting, and secure data queries** while preserving the benefits of blockchain transparency. By leveraging FHE, CoFHE enables computations on **encrypted data without decryption**, ensuring **data confidentiality throughout the entire transaction lifecycle**. [Link](https://cofhe-docs.fhenix.zone/) to CoFHE Documents ### **Key Capabilities** CoFHE enhances Redact by enabling: * **Confidential Token Wrapping:** Converts ERC-20 tokens into **fhERC20** without revealing transaction details. * **Confidential Transactions:** Redact users can send and receive assets **without exposing balances or transaction amounts**. * **Permit-Based Decryption:** Users can selectively share encrypted data **without compromising security**. ## **How CoFHE Works** CoFHE operates as an **off-chain computation layer** that processes **encrypted operations asynchronously** and returns verified encrypted results back to the blockchain. This ensures **scalability, security, and privacy** without compromising blockchain integrity. #### **Transaction Flow** 1. **A user initiates an FHE operation** (e.g., sending confidential token or querying confidenital balances). 2. **The Task Manager Contract** (on-chain) processes the request and generates an encrypted handle. 3. **The Aggregator (off-chain) receives the request** and forwards it to the **fheOS Server** for computation. 4. **The fheOS Server executes the FHE operation**, ensuring the data remains encrypted. 5. **Results are verified and sent back on-chain**, maintaining confidentiality throughout the process. ## **CoFHE Architecture** CoFHE consists of several components that work together to **secure and process encrypted transactions**: 1. **FHE.sol Library** 1. A Solidity library that allows smart contracts to execute confidential operations. 2. Imported directly into dApps to enable confidential token wrapping, minting, and transactions. 2. **Task Manager Contract** 1. Acts as the entry point for dApps integrating with CoFHE. 2. Handles requests for FHE computations and confidential transactions. 3. **Aggregator** 1. Collects and processes FHE operation requests in a secure and structured manner. 2. Sends requests to fheOS Server for execution. 4. **fheOS Server** 1. The computation engine responsible for executing encrypted transactions. 2. Ensures data remains encrypted throughout the entire process. 5. **Threshold Network (Decentralized Decryption)** 1. Uses multi-party computation (MPC) to handle decryption requests securely. 2. Ensures no single entity can access decrypted data, maintaining trustless confidentiality. ## **Security & Privacy Measures** CoFHE implements **multiple security mechanisms** to ensure **data privacy and integrity**: * **Fully Homomorphic Encryption (FHE):** Keeps data encrypted during computation. * **Threshold Network Encryption:** Prevents unauthorized decryption. * **Zero-Knowledge Proofs (ZKPoK):** Ensures computations are valid without revealing data. * **Access Control Mechanism (ACL.sol):** Restricts who can decrypt and interact with encrypted data.