Dark Pools
The multi-pool institutional design described under Forward design — cross-pool DBC fungibility, pool-to-pool bridging, the search/discovery layer, and trust-minimised matching — is forward-looking (v2 / Stage 3+) and not yet on the active implementation queue.
A working single-pool DEX dark pool runs today. It is a Cocoon node (Erigon + in-process services) with the matcher, settler, DBC bridge, and price oracle deployed as genesis contracts, plus a trader UI that mints, commits, matches, and settles confidential orders end to end. The How it works and Using the dark pool sections below describe that running system; the deeper specifications are in this section's sub-pages.
What this is
Cocoon's dark pool is a private trading venue that adds a confidential intent-matching layer over the existing settlement pipeline. Traders commit encrypted intent — price, size, and side hidden in Pedersen commitments — and no one (not the operator, not other traders, not MEV searchers) sees the order until after it is matched and settled. The venue eliminates information leakage, front-running, and MEV extraction.
Dark pools reuse the Confidential Cash (DBC) primitives already present in Cocoon — Pedersen commitments, RingCT, and stealth addresses. Orders never trade ERC-20 directly: tokens are first minted into DBC bearer coins, traded privately, then melted back.
Why it's needed
Three institutional use cases that a transparent venue does not serve:
| Use case | Problem |
|---|---|
| Block trades on tokenized RWAs | Pre-trade size is itself market-moving information |
| MMF rebalancing | A fund's redemption signals stress to the rest of the venue |
| Repo collateral matching | A desk's funding ask reveals its liquidity position |
The shared theme is front-running: on a transparent venue, simply placing a large order leaks strategy. The dark pool hides intent until the moment of match, then settles against an external reference price that the block-production process cannot influence.
How it works today
The running proof of concept is a single Cocoon node — one cocoon-node binary that embeds Erigon (execution + consensus, a dev chain at 2-second blocks, chain ID 1337) and the Cocoon service layer, which exposes a JSON-RPC gateway on port 3100. All contracts are deployed at genesis; there are no deploy scripts and no external dependencies.
The trader's journey
- Deposit. ERC-20 tokens are minted into DBC bearer coins via the
DBCBridge(the bridge escrows the ERC-20 and creates a Pedersen-committed coin owned by a stealth address). - Trade. The trader commits a private order; size, side, and price live inside a Pedersen commitment.
- Match + settle. A deterministic matcher pairs orders and settlement happens atomically.
- Withdraw. The trader melts DBC back to ERC-20 on chain at any time.
Matching model
The matcher is deterministic and runs after each order's on-chain confirmation:
- FIFO priority — orders match in creation-time order.
- Price band — each order specifies an acceptable deviation from the oracle price, in basis points.
- Clearing price — the oracle mid-price at match time. The matcher pairs on quantity; it does not set price.
- Partial fills — large orders fill incrementally against multiple counterparties.
- Automatic settlement — matched orders settle immediately via DVP.
Reference price — the oracle interface
The dark pool reads prices from an external oracle and uses them as the matching reference. It needs no integration or permission from the price source — it reads publicly available on-chain state.
| Oracle source | Interface | Maturity |
|---|---|---|
| On-chain DEX (Uniswap, Curve, …) | Read AMM state (sqrtPriceX96, reserves, last trade) | Live in the demo (DEXPriceOracle) |
| Chainlink price feeds | AggregatorV3Interface.latestRoundData | Designed (same contract slot) |
| CEX feeds (Binance, Coinbase) | Off-chain relay writes the on-chain oracle | Designed (same write path) |
Atomic settlement (DVP)
Matched trades settle as a single delivery-versus-payment transaction with two legs — the asset (token) leg from seller to buyer, and the cash (DBC) leg from buyer to seller. Both legs commit together or neither does, so neither party can default. The privacy boundary is precise: minting and melting are visible bridge events, but everything between the committed order and the settled swap is confidential.
| Leg | On-chain visibility | Privacy |
|---|---|---|
| Mint (ERC-20 → DBC) | Token, amount, bridge address | Public |
| Commit (DBC → pool) | Pedersen commitment, key-image hash, stealth recipient | Private — price/size/side/identity hidden |
| Match | — | Private — counterparties learn each other only at match |
| Settle (atomic swap) | Key-image hashes, encrypted blobs | Private — values never exposed |
| Melt (DBC → ERC-20) | Amount, recipient | Public |
What's running
The node deploys these genesis modules: identity (ERC-3643 identity + claims), onboarding (compliance-gated enrollment), darkpool (commitments, matching, settlement), dbc (spent-book + ERC-20 bridge), dex (price oracle), and six demo ERC-20s (WBTC, WETH, SOL, LINK, AAVE, USDT). The RPC gateway exposes 93 methods across 8 namespaces (pool_, dbc_, dex_, token_, id_, explorer_, dbcbridge_, stable_) — see the RPC reference.
Compliance
Order details stay private, but every participating wallet carries verified credentials via the ERC-3643 permissioned-token standard, with identity and claims (KYC, accreditation, jurisdiction) enforced on-chain. Compliance visibility is a scoped, party-to-party relationship — selective disclosure, not a backdoor: the operator cannot see order prices, sizes, or sides, cannot move trader funds, and cannot identify traders beyond pseudonymous pool-scoped addresses.
Using the dark pool
This walkthrough follows the proof-of-concept trader UI. The interface is a single composite view: on-chain assets and private balances on the left, the live open orders → matches → settlement on the right. There is deliberately no public order book — a trader only ever sees their own state.
For a screen-by-screen tour with screenshots — sign-in, onboarding, the order forms for all three pricing modes, and the operator surfaces — see the Interface guide.
1. Bring assets onto the chain
The On-chain assets (ERC-20) panel lists current holdings (e.g. WBTC, WETH, SOL, USDT). Trading first converts an asset into a DBC — a private bearer coin whose amount and holder are hidden.
Click Mint to DBC on the chosen asset. The amount moves from On-chain assets into Private balances (DBC).
Minting and melting are not private actions — they are visible bridge events. Privacy comes from what happens between them: the committed order and the dark match.
2. Place a confidential order
In Private balances (DBC), use Sell (or Buy). Pick the token and amount, choose a match type (Mid = oracle reference price, Auction = batch, RFQ = negotiated), set a price band (bps deviation from the oracle), and set an expiry.
The order is sent as a resting order with a hidden quantity (a Pedersen commitment) and appears in Open Orders with its side, token, and expiry — but the size is never exposed. The committed amount is reserved to the pool so the match is guaranteed to settle.
3. A counterparty hits the order
When another trader submits the opposite side, the matcher pairs them.
The Matches panel populates with token, side, fill quantity, and the reference price at the match point. A partial fill is normal — an order for 40 may fill 20 now and leave 20 resting.
4. Atomic settlement at the reference price
Immediately after the match, the settler executes a DVP settlement.
The Settlement panel shows each leg marked
SETTLED, and both wallets' private balances update automatically — asset to the buyer, DBC cash to the seller, in one atomic step. No counterparty risk, no partial settlement.
5. (Optional) Melt back to L1
To take proceeds back as a public ERC-20, use Melt to bridge the DBC back to the chain.
Roles at a glance
| Role | Can | Cannot |
|---|---|---|
| Trader | Place/cancel orders, authorise settlement of own trades, melt own funds | See others' orders or identity; influence the deterministic match |
| Operator (venue runner) | Define pool parameters, run the matcher, see aggregate stats, pause the pool | See order prices/sizes/sides; move trader funds; identify traders; alter match results |
| Compliance officer | Review applications (KYC/AML), request scoped selective disclosure | See the live order book; move funds; access data without delegated authority |
Forward design
The forward design generalises the running single pool into a multi-pool institutional dark trading layer — none of it is in the running PoC. The Technical spec and Product spec carry the full detail and the staged roadmap (v1 core → v2 advanced → Stage 3 interop → Stage 4 trust-minimised):
- Multi-pool topology — parallel pools with DBCs fungible across them via a shared
PoolRegistry(Technical spec §5.2). - Matcher trust tiers — T1 signed → T2 optimistic → T3 ZK/TEE (Technical spec §6.1).
- Pricing modes — P1 reference-price → P2 periodic auction → P3 negotiated cross (Technical spec §6.2).
- Composite wallet across pool memberships, plus an encrypted search & discovery layer with no global order book (Design outline).
- L1 / cross-L2 entry — Railgun on-ramp and EIL cross-L2 funding, Stage 3+ (Product spec).
In this section
Deeper specifications are published as dedicated pages:
- Interface guide — a screenshot walkthrough of the trader, operator, and DEX-flow surfaces
- Technical spec — Order / Match / Settlement across pools; full architecture (12 sections + 2 appendices)
- Product spec — vision, target users, key features, roadmap
- Design outline — architecture summary + open design questions
- TradFi background — traditional-finance dark pools & crossing engines
- Decentralized context — existing decentralized dark-pool designs
- Security model — what the architecture removes by construction, and proof-of-concept status
- FAQ — common questions on privacy, compliance, settlement, and execution