# Confidential Cash Confidential Cash is the Cocoon component for private on-chain value transfer. It implements Digital Bearer Certificates (DBC) using RingCT — the same privacy construction used in Monero — adapted to run inside an EVM-compatible chain. The result is a cash instrument where transfer amounts and counterparty identities are hidden from on-chain observers, while the existence of a transfer remains public and the system remains auditable by parties with the appropriate keys. {% hint style="info" %} DBC is used as the settlement leg for token subscriptions, redemptions, and DVP trades in the Permissioned Tokens component. A standalone DBC deployment (without tokens) is also a valid configuration for confidential payment networks. {% endhint %} ## Privacy Model Understanding what DBC hides — and what it does not — is important before deploying it in a regulated context. | Property | Hidden? | Mechanism | | ------------------------ | ------- | ------------------------------------ | | Transfer amount | Yes | Pedersen commitments | | Sender identity | Yes | Ring signatures + stealth addresses | | Receiver identity | Yes | Stealth addresses + ECIES encryption | | That a transfer occurred | No | Transaction is visible on-chain | | Whether a note was spent | No | Key images are public | This is the same privacy model as Monero's RingCT. An on-chain observer can see that value moved and can see the set of possible senders (the ring), but cannot determine the actual sender, receiver, or amount. The receiver can identify and decrypt their incoming note using their private view key. {% hint style="info" %} DBC does not provide complete anonymity. If an external observer can correlate wallet activity with off-chain data (e.g. a KYC record linking a wallet to a person), they may be able to de-anonymize transactions. Compliance programs should evaluate whether DBC's privacy level meets their regulatory obligations. {% endhint %} ## Why RingCT Cocoon chose RingCT over alternatives (Zcash-style zk-SNARKs, Tornado-style mixing) for the following reasons: * **No trusted setup**: RingCT requires no ceremony or toxic-waste parameters. The construction is based on standard discrete-log assumptions. * **Incremental verification**: Each transfer can be verified independently without needing to process the entire transaction history. * **Mature cryptographic library**: The primitives (Pedersen commitments, MLSAG, Bulletproofs) have years of production use and formal security analysis behind them. * **EVM compatibility**: The verification contracts fit within EVM gas limits without requiring a separate proof system runtime. ## Lifecycle: MINT, TRANSFER, MELT DBC operates on a three-phase lifecycle. Value enters the confidential layer through MINT, moves privately through TRANSFER, and exits back to the transparent ERC-20 layer through MELT. ```mermaid flowchart LR ERC20["ERC-20 Token\n(transparent)"] DBC["DBC Notes\n(confidential)"] ERC20 -- "MINT\nlock ERC-20 in bridge\ncreate DBC note" --> DBC DBC -- "TRANSFER\nring signature\nstealth address\nPedersen commitment" --> DBC DBC -- "MELT\nspend DBC note\nrelease ERC-20 from bridge" --> ERC20 ``` ### MINT The caller locks a quantity of ERC-20 tokens in the `DBCBridge` contract. The bridge mints a DBC note — a cryptographic object that encodes the value as a Pedersen commitment and encrypts the amount and blinding factor to the receiver's public key using ECIES. The original ERC-20 amount is now hidden; from this point forward, on-chain observers see only commitments, not values. ### TRANSFER A DBC transfer consumes one or more input notes and produces one or more output notes. The transfer: 1. Produces a ring signature (MLSAG) that proves one of the ring members owned the input note, without revealing which one. 2. Produces a key image — a deterministic, unlinkable fingerprint of the spent note — which is registered in the `SpentBook` contract to prevent double-spending. 3. Produces output notes encrypted to the receivers' stealth addresses. 4. Proves, via a range proof, that all output amounts are positive and that the sum of inputs equals the sum of outputs (no inflation). ### MELT The caller proves ownership of a DBC note, submits the key image to the `SpentBook`, and the `DBCBridge` contract releases the corresponding ERC-20 amount to a specified address. The ERC-20 amount reappears in the transparent layer, severed from any on-chain link to its DBC history. ## On-Chain Contracts Three contracts make up the DBC system: | Contract | Purpose | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SpentBook` | Key image registry. Records every spent note's key image to prevent double-spending. Verification contracts query this before accepting a transfer. | | `DBCBridge` | Mint/melt gateway. Holds ERC-20 tokens in escrow during their time in the confidential layer. Enforces 1:1 peg. | | `SpentBookPaymaster` | ERC-4337 paymaster that sponsors gas for DBC operations. Allows users to pay transaction fees using DBC value rather than requiring a separate ETH balance. | ## Cryptographic Primitives The following is a plain-language description of the cryptographic building blocks. No equations are required to use the component, but understanding the construction helps in security reviews. **Pedersen Commitments** — A way to commit to a number without revealing it. Two commitments can be added together, and the result is a valid commitment to the sum. This is what allows the protocol to verify that transfer inputs equal outputs without seeing the amounts. **MLSAG Ring Signatures** — A signature scheme where a signer proves they are one of a set of public keys (the ring) without revealing which one. In DBC, the ring is constructed from real unspent notes plus decoy notes selected from the note pool, so an observer cannot determine which note was actually spent. **Key Images** — A value derived from a spent note's private key in a way that is unique per note but unlinkable to the public key. Registering the key image in `SpentBook` prevents the same note from being spent twice, even if the spender uses a different ring each time. **Range Proofs (Bulletproofs-compatible)** — A compact proof that a committed value lies within a valid range (e.g. 0 to 2^64). This prevents a sender from creating a note with a negative value to inflate their balance. **Stealth Addresses** — A one-time address derived from the receiver's public key. Each transfer creates a fresh address, so multiple incoming payments to the same user cannot be linked on-chain. Only the receiver (with their private view key) can identify which outputs belong to them. **ECIES Hybrid Encryption** — The amount and blinding factor for each output note are encrypted to the receiver's public key using ECIES (Elliptic Curve Integrated Encryption Scheme), so only the intended receiver can decrypt and reconstruct their note. ## Post-Quantum Design DBC includes a hybrid post-quantum layer to protect against future quantum adversaries: * **Signatures**: All signing uses a hybrid ECDSA + ML-DSA (CRYSTALS-Dilithium) scheme. Both signatures must be valid for a transaction to be accepted. A quantum computer that can break ECDSA cannot forge a transaction because the ML-DSA signature remains valid. * **Key Wrapping**: Note encryption uses ML-KEM-768 (CRYSTALS-Kyber) for key encapsulation, with the symmetric key then used for ECIES. Breaking the classical ECDH key agreement does not expose the plaintext because the ML-KEM wrapper remains secure. This hybrid approach means the system is secure today under classical assumptions and secure in the future under post-quantum assumptions. It does not require a flag-day migration. ## Gas Sponsorship DBC users who have not yet acquired the chain's native token (e.g. ETH or the Cocoon gas token) can have their transaction fees sponsored by the `SpentBookPaymaster`. The paymaster accepts a small DBC note as payment for gas, atomically verifying and spending it in the same transaction that executes the user's DBC operation. This removes the onboarding friction of requiring users to acquire gas tokens before they can transact. ## Integration with Permissioned Tokens When an investor subscribes to a tokenized fund, the cash leg of the subscription moves through DBC: 1. The investor mints DBC from their ERC-20 stablecoin balance. 2. The subscription contract locks the DBC payment in escrow. 3. On settlement, the token contract mints fund shares to the investor. 4. The escrow releases the DBC to the fund's treasury wallet. 5. The fund melts the DBC back to ERC-20 stablecoin for off-chain settlement. The effect is that the amount an investor paid for their subscription is not visible to other investors or market participants on-chain, while the number of shares issued remains transparent for reporting purposes. The same flow applies to redemptions (investor returns shares, receives DBC) and DVP secondary trades (buyer pays DBC, seller delivers tokens atomically). ## Regulated Payments Standard DBC transfers are fully confidential: amounts and counterparty identities are hidden from on-chain observers. This confidentiality blocks institutional payments that require compliance metadata — Travel Rule disclosures, KYC attestations, or proof of accredited-investor status cannot be attached to a raw DBC transfer. Regulated payments solve this by wrapping a DBC payment inside a UCAN-authenticated envelope that carries per-recipient selective disclosures alongside the confidential value transfer. **Envelope structure.** A `RegulatedDBCPayment` envelope contains: * The sender's address and the list of recipients. * The underlying DBC payment (the confidential cash transfer). * Disclosure attachments: references to on-chain claims by topic (e.g. a KYC claim reference for topic 1, a Travel Rule profile reference for topic 8), selectively revealed per recipient. * Automatic escalation rules: for example, Travel Rule metadata is triggered automatically when the payment amount exceeds CHF 1,500, in line with FINMA guidance. **Privacy model.** The envelope uses layered encryption so each party sees only what they are entitled to: | Party | What they see | | --------------------------- | --------------------------------------------------------------- | | Recipient investor | The DBC note (the cash) | | Counterparty bank | KYC claim reference + Travel Rule originator data | | Regulator | The full packet (DBC note + all disclosures + Travel Rule data) | | Any other on-chain observer | Nothing — the envelope is opaque | **Receipt mechanism.** When the counterparty accepts the payment, a `PaymentReceiptIssued` event is emitted on-chain for non-repudiation. A signed `PaymentReceipt` is encrypted back to the sender and the regulator simultaneously. If the counterparty rejects the payment or the confirmation window times out, the DBC note is automatically refunded to the sender. Call `dbc_getPaymentReceipt(paymentId)` to poll for confirmation status. ## UCAN Capabilities DBC operations are gated by UCAN capability delegations. The following capability namespace applies: | Capability | Held by | Description | | ------------------------- | ------------------------ | ------------------------------------------- | | `/dbc/shield` | Investor | Convert stablecoins to DBC (mint) | | `/dbc/unshield` | Investor | Convert DBC back to stablecoins (melt) | | `/dbc/transfer` | Investor | Send DBC to another investor | | `/dbc/balance` | Investor | View own DBC balance | | `/dbc/escrow/view` | Fund Manager, Compliance | View aggregate DBC bridge escrow | | `/dbc/escrow/melt` | Fund Manager | Melt fund DBC reserves to stablecoin | | `/dbc/regulated-transfer` | Investor | Send a regulated (UCAN-wrapped) DBC payment | ## Key RPC Methods | Method | Description | | -------------------------- | -------------------------------------------------------------------------------------------------------------- | | `dbc_mint` | Lock ERC-20 and create a DBC note. | | `dbc_transfer` | Spend input notes and create output notes with ring signature and range proof. | | `dbc_melt` | Spend a DBC note and release ERC-20 from the bridge. | | `dbc_getBalance` | Scan the note pool for outputs belonging to the caller's view key and return the spendable balance. | | `dbc_getHistory` | Return the caller's transaction history (received and sent notes, as visible to their view key). | | `dbc_verifyNote` | Verify that a note is unspent and validly formed without revealing the value. | | `dbc_getEscrow` | Return aggregate DBC bridge escrow holdings by token symbol. Fund manager view. | | `dbc_sendRegulatedPayment` | Send a UCAN-wrapped DBC payment envelope with per-recipient selective disclosures and Travel Rule attachments. | | `dbc_getPaymentReceipt` | Return the status and signed receipt for a regulated DBC payment. | --- # 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://cocoon.erigon.tech/components/confidential-cash.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.