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.
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.
Privacy Model
Understanding what DBC hides — and what it does not — is important before deploying it in a regulated context.
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.
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.
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.
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:
Produces a ring signature (MLSAG) that proves one of the ring members owned the input note, without revealing which one.
Produces a key image — a deterministic, unlinkable fingerprint of the spent note — which is registered in the
SpentBookcontract to prevent double-spending.Produces output notes encrypted to the receivers' stealth addresses.
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:
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:
The investor mints DBC from their ERC-20 stablecoin balance.
The subscription contract locks the DBC payment in escrow.
On settlement, the token contract mints fund shares to the investor.
The escrow releases the DBC to the fund's treasury wallet.
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).
Key RPC Methods
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.
Last updated