DarkPool

Dark Pool is a permissionless, decentralized OTC trading protocol where price discovery is intent-based, not market-driven. Traditional dark pools are centralized, the operator sees every order and users just have to trust them not to front-run. On-chain order books fix the trust problem but leak trade details to the entire network. Dark Pool takes a different approach.

When a user submits an order, the frontend hashes it with Poseidon and commits only that hash on-chain. The blockchain never sees the actual order details. The real order goes to an off-chain matching engine that pairs counterparties using price-time priority with partial fill support. Once a match is found, a Groth16 ZK proof is generated and verified on-chain, proving the match was executed honestly without revealing what either order actually was.

Settlement flows through Yellow Network's state channel layer. Users deposit to a Custody contract on-chain, their unified balance gets credited, and from there all trading happens off-chain through App Sessions. When a match settles, funds move directly between counterparties through these sessions with no bridges and no challenge periods. Users sign once when they connect their wallet through a session key with a 30-day expiry, and every trade after that settles instantly without any further wallet interaction.

The whole system is chain-agnostic thanks to Yellow's unified balance layer. Deploy the router contract on any EVM chain, the matching and settlement works the same, and users can withdraw their funds on whichever chain they want.

The frontend is Next.js 14 with wagmi, viem, and RainbowKit for wallet connection. When a user places an order, we compute the Poseidon hash client-side and submit only that hash to our DarkPoolRouter Solidity contract. We went with Poseidon over keccak256 because it's ZK-friendly, around 250 constraints versus 150k, which keeps proof generation fast when the backend needs to prove matches later.

From the frontend, users also go through the full Yellow Network deposit lifecycle. We create a channel with the clearnode, deposit to the Custody contract on-chain, then resize the channel to credit their unified balance. One tricky part was getting the resize flow right for returning users. When someone comes back with an existing channel from a prior session, we have to read the last valid state directly from the Custody contract's getChannelData view function to build a valid preceding state proof, otherwise the on-chain adjudicator rejects it.

Once an order is committed on-chain, the details go over gRPC to Warlock, our matching engine written in Go. Warlock runs price-time priority matching with partial fill support, stores state in PostgreSQL, and streams match events back to the backend when two orders cross. The backend is Node.js/Express and acts as the glue between everything. It holds a persistent WebSocket to the Yellow Network clearnode, manages session key authentication so users only sign once, and proxies all channel and balance operations. When Warlock sends a match, the backend generates a Groth16 ZK proof and calls proveAndSettle on the DarkPoolRouter. The contract verifies the proof without ever learning what the orders were, just that the match was valid.

After proof verification, the backend opens a Yellow Network App Session between both parties and closes it with swapped allocations, moving funds from seller to buyer. Yellow's "Game with Judge" governance model gives the engine instant settlement authority with no challenge period. Session keys mean users sign once at wallet connect with a 30-day expiry and never touch their wallet again for subsequent trades. Because Yellow's unified balance layer is chain-agnostic, we can deploy the DarkPoolRouter on any EVM chain and users withdraw wherever they want.