Skip to main content

Complient Confidential Transactions

The Core Tension​

Confidential transaction systems built on blockchains face a structural conflict: full transparency (the default in most chains) destroys financial privacy, while full opacity (as in many "privacy coin" designs) makes regulatory oversight impossible and invites abuse for money laundering or sanctions evasion. Fully Homomorphic Encryption (FHE) is attractive precisely because it does not force a binary choice. It allows balances and transfer amounts to remain encrypted on-chain while still permitting computation, verification, and, critically, selective decryption by authorized parties. This is what separates an FHE-based design from either a fully transparent ledger or a zero-knowledge "black box."

Protect the Transaction Privacy​

A confidential transaction system built on FHE typically follows several stages.

  • Deposit: a user converts a plaintext balance (e.g., a ERC-20 token) into encrypted form (the new encrypted ERC-20 token) by having an off-chain FHE node encrypt the amount under the system's public key, producing a ciphertext handle that the contract records as the user's balance, while the plaintext never touches the chain.
  • Transfer (with encrypted ERC-20 token): the sender encrypts the transfer amount locally, submits the ciphertext on-chain, and an off-chain computation node performs homomorphic subtraction on the sender's balance and homomorphic addition on the receiver's balance, writing back two new ciphertext handles without either party's amount or running balance ever being decrypted.
  • Balance query: a user retrieves their own ciphertext handle and requests authorized decryption (typically via wallet-signature verification) to see their real balance in plaintext, while any other observer sees only an opaque handle and a standard transfer event with no recoverable amount.
  • Withdraw: the user submits a withdrawal request for an encrypted amount, an authorized decryption confirms it against (and reduces) their ciphertext balance, and the contract releases the equivalent amount (the plain ERC-20 token) in plaintext.

How FHE Produces the Auditable Confidentiality Layer​

In the architecture described, value is represented entirely as ciphertext once it enters the privacy system:

  • Encrypted state, not encrypted messages. Balances themselves are stored on-chain as FHE ciphertext handles rather than plaintext values. This differs from approaches that only encrypt transaction payloads while leaving balances or amounts inferable.
  • Computation without decryption. Transfers are executed as homomorphic subtraction and addition directly on ciphertexts (balance_from − amount, balance_to + amount), performed off-chain by a dedicated computation node and written back as new ciphertext handles. No party, including the node performing the computation, ever sees the plaintext amount or resulting balances.
  • Default-deny access. An access-control (ACL) layer governs who may request decryption of any given ciphertext handle. By default, only the asset owner can decrypt their own balance, and on-chain observers including block explorers and other contracts, see only opaque handles and a standard Transfer event with no plain amount.

This gives genuine confidentiality at the data layer, not just at the network layer: the privacy guarantee survives even if all on-chain data is public and permanently archived. FHE's core contribution here isn't making data available to regulators. It's making it inaccessible to everyone by default, including infrastructure operators, while preserving a provable, accountable path back to plaintext: the ACL layer adds a regulatory tier where any decryption request requires authorization and is permanently logged on-chain. zkTLS can be further integrated at the front-loads compliance screening, letting users prove they passed the KYC check without revealing their identity.