Frequently asked questions

Can the operator or a block producer front-run my order?

There is no trader-set price to front-run, which is the signal front-running usually keys on. Orders carry no limit price: matching runs deterministically on chain by arrival order, and the clearing price is sampled from an oracle reference at the matched block.

Be clear about what v1 does not yet hide. Order size and side are stored in cleartext on chain and are readable by anyone with chain access — only the amount commitment is Pedersen-hidden. Transaction ordering can influence FIFO order IDs, and the operator can change which oracle a pool reads (setDexOracle). Committing size and side, and constraining the oracle, are part of the production design rather than properties of the proof-of-concept.

How does confidential trading stay compliant with AML and sanctions rules?

Access is permissioned via ERC-3643: every wallet carries verified, on-chain credentials (KYC / AML, jurisdiction) issued before it can trade. Order details stay hidden from the operator and the market, but a compliance officer — or, on an authorized request, a regulator — can obtain a scoped, party-to-party disclosure of a participant's identity and compliance status, recorded in the audit log and invisible to other traders. Disclosures can be cryptographically attested where supported. This is the line between this design and an anonymity mixer.

Is KYC / KYB mandatory?

That is the deploying institution's choice. Cocoon provides the pluggable identity and screening infrastructure; the venue operator sets policy — mandate KYC / KYB for a restricted OTC desk, or relax it for a permissionless pool — and the protocol enforces whatever the pool is configured with.

Who is on the other side of my trade, and where does liquidity come from?

Counterparties are other credentialed members of the same pool. Neither side learns the other's identity — a fill shows a pseudonymous, pool-scoped address, not a persona — though a compliance officer can resolve it on an authorized request. Matching is intra-pool today (the single Default Pool); the forward design adds cross-pool liquidity via shared, fungible DBCs.

What is the settlement model — can a counterparty fail to deliver?

Settlement is atomic delivery-versus-payment: the settler executes the asset leg and the payment leg in one step, and either both clear or neither does. There is no half-settled state and no counterparty credit risk. Funds are non-custodial throughout — the trader holds the spend keys, and the pool coordinates rather than taking custody.

How is my execution price set, and what stops a bad print?

At match time the trade is stamped with a block reference; the settler then samples an external DEX reference price at that block and clears there. A P1 order also sets a price band, and a fill can never land outside it. Because the matcher is volume-only and the price comes from an independent oracle at a fixed block, neither the operator nor a counterparty can move the execution price.

What is the latency?

On the demo chain (2-second blocks) a trade goes from order to settled in roughly 7–9 seconds — matching in one block, settlement in the next. Block time is an operator-tunable parameter, so latency-sensitive venues can run faster blocks.

What can I actually trade today?

A single P1 (reference-price cross) pool runs end to end today: mint, confidential order, FIFO volume match, DVP settlement, and melt. Periodic auctions (P2), negotiated RFQ (P3), and the multi-pool topology are forward design — previewed in the Interface guide and specified in the Product spec and Technical spec.