Dark pools — product specification
Status: Forward-looking design — Stage 3+ work. Not on the immediate implementation queue.
Audience: product / business / institutional-finance stakeholders. Companion docs are written for engineers and architects.
1. Vision
A private, multi-pool dark trading layer on cocoon-L2 for institutional finance. Traders place intent without revealing price, size, side, or counterparty pre-match. Matched fills settle through cocoon's existing confidentiality machinery — token + cash leg atomic, compliance attested, regulator-reachable via selective reveal. Multiple pools run in parallel, peer-bridged, with DBCs fungible across them.
2. Problem statement
Three institutional finance use cases that the existing OrderRegistry (cleartext subscription/redemption against a single permissioned token) does not serve:
| Use case | Why the existing flow doesn't work |
|---|---|
| Block trades on tokenized RWAs | Pre-trade size is itself market-moving information; revealing it on order placement leaks the trader's strategy |
| MMF rebalancing | A fund's redemption signals stress to the rest of the venue; the existing flow makes this visible |
| Repo collateral matching | A desk's funding ask reveals its liquidity position to competitors |
Dark pools close this gap by hiding intent (price + size + side + counterparty) until match, then routing matched pairs through cocoon's existing Order → Invoice → Payment → Receipt pipeline.
3. Target users
| User | Need |
|---|---|
| Institutional trader (buy-side desk) | Block-size liquidity without market impact; cross-venue participation without locking funds at each |
| Fund administrator (issuer) | Confidential rebalancing flows; settlement compliance gates |
| Operator (venue runner) | Mandate to run matching with auditable code; reputation accrual; routing fees |
| Compliance officer / regulator | Party-attributed compliance proofs; selective reveal under jurisdiction-scoped UCAN |
4. Key features
-
Pre-trade intent privacy. Price / size / side hidden via Pedersen commitments on chain; stealth-address recipients. Counterparties learn each other only at match; the rest of the market never learns.
-
On-chain matcher with operator-Party trust. Match logic is registered code on cocoon-L2 (canonical, immutable). A designated operator-Party runs the matcher off-chain for latency. Three verification tiers — T1 signed (v1), T2 optimistic (near-term), T3 ZK/TEE (Stage 4+) — selectable per pool.
-
Multi-pool topology. Many pools run in parallel, each with its own L1 bridge to mainnet + its own operator-Party. Traders may participate in any number of pools simultaneously.
-
Cross-pool DBC fungibility. A DBC minted in one pool can settle in another via three routing mechanisms — direct cross-chain lookup, lease + commit, or burn-mint migration. Spend authority always remains with the canonical SpentBook of the DBC's home pool.
-
Configurable price discovery. Each pool deploys with one of three modes — reference-price cross via NAVOracle, periodic auction with uniform clearing, or negotiated cross with reveal. The mode is part of the pool's on-chain identity; traders consent at pool-join.
-
Composite wallet across pools. A trader's wallet operates pool-agnostically. The UI presents a single unified view of holdings, open orders, active leases, and fills across every pool the trader participates in.
-
Wallet-as-lessor market-making. A trader leases DBC liquidity to a pool's operator-Party for a defined window. The pool fills orders against the pledged DBC while the trader is offline; unused capacity returns to the wallet on lease expiry. Event-driven lifecycle — no polling.
-
Overcommitted interest with SpentBook safety. Advanced model: a trader posts interest across multiple pools backed by the same DBC. SpentBook's lease primitive guarantees only one cross can win; concurrent attempts at other pools are atomically rejected. No double-spend risk even though interest is over-committed.
-
Auto-aggregator. A pool can route trader orders to foreign pools when its internal book has no cross. Trader sees a single fill; the front-pool bears settlement responsibility from the trader's perspective.
-
Pool-as-searcher (SOR). A pool's operator-Party actively scans foreign pools for matching liquidity. Each pool registers an on-chain liquidity policy declaring jurisdictions, instruments, accepted mechanisms, fees, and lease-window preferences. Other pools discover these declarations via chain-coordinated services.
-
Search and discovery layer. Intra-pool: traders submit search hints (encrypted-to-operator-Party metadata) alongside Pedersen commitments to enable triage. Cross-pool: digest publication + neutral discovery agent + bilateral handshake. No global shared order book.
-
L1 entry via Railgun on-ramp. Privacy-preserving funds-in from Ethereum mainnet, with temporal-decoupling guaranteeing the EOA → pool link is unobservable. Symmetric withdrawal.
-
EIL external interop (Stage 3+). Ethereum Interoperability Layer integration lets traders fund cocoon dark-pool orders from any EIL-compatible L2 with one signature.
-
Party-attributed compliance. Every fill carries three independent compliance attestations — venue, buyer, seller. Cross-pool fills require both pools' compliance to agree. Regulators are reachable via selective reveal as a relationship, not a backdoor.
5. Use cases — worked examples
5.1 Tokenized RWA block trade
A buy-side desk holds a 500k-share position in tokenized REIT-X and wants to unwind without signalling. They submit a Pedersen-committed sell 500k @ NAV-0.01% to NAV+0.01% to dark pool P (mode P1, NAV-referenced). An institutional buyer submits buy 500k @ NAV-0.005% to NAV+0.005%. Pool P's operator-Party identifies the price-band overlap via search hints, requests reveals from both sides, proposes a match at NAV-0.005% to the on-chain matcher. The matcher verifies + settles via DVP; both legs land in one tx. No public order-book entry. Lit-market participants see only the post-trade audit log (jurisdiction-scoped).
5.2 MMF redemption rebalance
A fund needs to redeem 50M USD by end of day. Without dark pools, the redemption is visible in OrderRegistry and triggers correlated redemptions from other funds. With dark pools, the fund posts a Pedersen-committed redeem 50M USD to dark pool P; the fund administrator (counterparty) matches privately. Redemption settles without visible front-running.
5.3 Repo collateral cross
A desk needs intraday repo funding against Treasury collateral. Pool P specialises in repo (mode P3, negotiated cross with reveal). Desk submits repo 100M USD overnight against UST collateral. Pool P's operator-Party matches against a counterparty desk; reference rate (custodial publisher) sanity-bands the negotiated price.
6. Differentiators
| Alternative | What cocoon dark pools add |
|---|---|
| Traditional dark pools (ATSs, broker-internal pools) | On-chain audit trail with party-attributed compliance; programmable settlement via DVP atomicity; no broker as silent gatekeeper |
| Other on-chain dark pools | First-class regulator reachability; integration with permissioned-token + KYC stack; party-attributed compliance proofs |
| Railgun standalone | Matching layer + settlement DVP; institutional compliance gates; persona-bound rather than fully anonymous |
| CEX dark pools | Self-custodied throughout; no operator with funds custody; cryptographic spend-book guarantees against double-spend |
7. Roadmap stages
| Stage | Scope |
|---|---|
| v1 (core) | Single-pool + multi-pool, T1 signed verification, mode P1 reference-price, NAVOracle, three routing mechanisms, composite wallet, search hints + DiscoveryRegistry |
| v2 (advanced) | T2 optimistic verification, over-commitment policy, pool-as-searcher with liquidity policy, full auto-aggregator flow, periodic-auction mode P2, negotiated-cross mode P3 |
| Stage 3 (interop) | L1 Railgun on-ramp, EIL canonical bridge, external L2 funding |
| Stage 4 (trust-minimized) | T3 ZK/TEE-verified matching, ZK on-chain matching with hidden inputs, DECO-style privacy oracles |
8. Out of scope (v1)
- ZK on-chain matching with hidden inputs (Stage 4)
- MEV mitigations beyond commit-reveal (threshold encryption, VDFs)
- Cross-chain non-cocoon-ecosystem settlement (Stage 3+ EIL handles this layer)
- Operator economics + fee model
- Multi-asset / portfolio / iceberg orders
Full technical specification: dark-pools.md. Open design questions blocking implementation: dark-pools-design-outline.md.