Protocol
Protocol Overview
Design principles and component map of the Raycash protocol.
The Raycash protocol is a set of smart contracts that convert cleartext ERC-20 tokens into FHE-encrypted confidential tokens, enforce compliance policy via hooks, and enable privacy-preserving deposits and withdrawals.
Design Principles
- Privacy by default — All balances are FHE-encrypted. Transfers use
FHE.selectto avoid balance-revealing reverts. - Exit always callable — Burns and unwraps are never blocked by hooks. Users can always leave the encrypted domain.
- Custody/policy separation — The immutable wrapper holds tokens; configurable hooks enforce compliance policy.
- Counterfactual deposits — Users send tokens to a pre-computed CREATE2 address. No on-chain interaction required from the depositor.
- Permissionless finalization — Both wrap finalization and unwrap finalization can be triggered by anyone with valid proofs.
- Rage quit — Users can always recover cleartext tokens from their depositor address, even if the admin never calls
initWrap().
Component Map
| Component | Contract(s) | Description |
|---|---|---|
| ConfidentialERC20 | ERC7984, ConfidentialERC20, ERC7984ERC20Wrapper | FHE-encrypted balances (via OpenZeppelin ERC7984) and amount scaling |
| Wrapping | RaycashWrapper | Operator-gated initWrap() flow with CREATE2 depositors, encrypted recipients, and decoys |
| Unwrapping | RaycashWrapper | Two-phase unwrap flow with permissionless relayer finalization |
| Hooks | 3 interfaces, RaycashKycHook | Policy enforcement separated from token custody |
| Attestation | RaycashKycAttesterResolver | EAS-based KYC attestation with single-attester policy |
| Deposits | RaycashDepositor (CREATE2) | Counterfactual CREATE2 deposits with FHE-encrypted recipients, integrated into the wrapper |
| Card Escrow | CardChargesEscrow | Passive escrow for card charge settlement via unwrap flow |
Contract Dependency Graph
Was this page helpful?