Orderbook & AMM

CloudBank implements a hybrid liquidity model combining an on-chain constant-product AMM with an off-chain orderbook engine. Orders are routed through a unified API that splits execution across both venues for optimal price discovery.

BinaryCPMM — On-Chain AMM

The BinaryCPMM contract implements a constant product formula for binary outcome tokens:

x * y = k

where x is the YES reserve and y is the NO reserve. The pool charges 0% swap fee, relying on the spread between YES and NO prices as the implicit cost.

Price Calculation

Outcome token prices are derived from pool reserves at 1e18 precision:

priceYes = noReserve * 1e18 / (yesReserve + noReserve)
priceNo  = yesReserve * 1e18 / (yesReserve + noReserve)

Prices always sum to exactly 1e18 (representing $1.00 in collateral), ensuring the market is always fully collateralized.

Trading Paths

Function	Direction	Description
swapCollateralForOutcome	Buy	Deposit collateral, mint YES+NO via CTF, swap unwanted side back into pool
sellOutcomeForCollateral	Sell	Deposit outcome tokens into pool, receive collateral back
swap	Token-to-token	Swap YES for NO or vice versa directly through the pool

Liquidity Management

• addLiquidity(amount) — Deposits collateral, splits it into YES and NO tokens via the CTF, and adds both to the pool proportionally. The caller receives LP tokens representing their share.
• removeLiquidity(lpAmount) — Burns LP tokens and returns the caller's proportional share of YES and NO outcome tokens (not collateral directly). The caller can then sell or redeem these positions.

Off-Chain Orderbook Engine

The orderbook engine is implemented in Go as part of the backend services and maintains an in-memory order book with price-time priority matching.

Order Authentication

All orders are signed using EIP-712 typed structured data. The domain separator includes the chain ID and a verifying contract address, preventing replay attacks across chains and contracts. The backend verifies signatures before accepting orders into the book.

Order Types

Type	Behavior
GTC (Good-Til-Cancelled)	Remains on the book until filled or explicitly cancelled
GTD (Good-Til-Date)	Automatically expires at a specified timestamp
FOK (Fill-Or-Kill)	Must be fully filled immediately or the entire order is rejected
FAK (Fill-And-Kill)	Fills as much as possible immediately, cancels the remainder

WebSocket Heartbeat

Active makers maintain their orders via a WebSocket connection:

wss://api.cloudbank.com/api/v1/orderbook/heartbeat/ws

If a maker's heartbeat connection drops, their resting orders can be flagged as stale. This mechanism protects takers from executing against quotes from disconnected market makers.

Hybrid Order Routing

The unified routing endpoint evaluates both liquidity sources to find the best execution:

POST /api/v1/orderbook/route

The router calculates the effective price across both venues and splits the order to minimize slippage. For example, a large buy order might fill the best resting asks on the orderbook first, then sweep remaining size through the AMM.

Routing Logic

1. Query the orderbook for available liquidity at the limit price.
2. Query the AMM for the effective price at the remaining size.
3. Compare marginal prices and allocate volume to the cheaper venue.
4. Execute on-chain AMM trades atomically and settle orderbook matches.

Polymarket Alignment

The CLOB (Central Limit Order Book) architecture follows conventions established by Polymarket, including EIP-712 order signing, binary outcome token pairs, and a hybrid AMM+orderbook model. This alignment facilitates familiarity for traders migrating between platforms and enables potential future cross-platform liquidity sharing.