Two Venues — AMM and CLOB

GoMarket trades the same kind of question through two different matching systems, and they are designed to coexist rather than replace one another.

	AMM	CLOB
Program	`high-market-program`	`markets`
Program ID	`4Pe4r9Fpa…`	`GoFTc9SFq…`
Status	Live on mainnet, Zokyo-audited	Devnet only, audit scheduled
Counterparty	The curve itself	Another trader
Price comes from	LMSR over `q_yes`, `q_no`, `b`	The order book, price-time priority
Liquidity from	The `b` parameter	Makers’ resting orders
Will it fill?	Always — the AMM always quotes	Only if there’s a resting order
Slippage	Deterministic from the cost function	Depends on book depth
You send	`buy_shares` / `sell_shares`	A signed order → `execute_trade`
Matching	None — priced on-chain	Off-chain, in the Order Manager

Why both

(The reasoning below is the design intent. The CLOB half of it is devnet today.)

An order book with no makers is an empty screen. A new market has no liquidity on day one, and asking a user to be the first bid is asking them to do the venue’s job.

The AMM always has a price. The LMSR cost function quotes both sides continuously, funded by the b liquidity parameter rather than by anyone’s inventory. That makes it the right instrument for a market’s first hours, for the long tail of low-volume questions, and for anything where a user should never see “no liquidity.”

What it costs you is the spread. LMSR slippage is a function of b, not of how much genuine interest exists — a market everyone agrees on still charges curve slippage, and a market maker who could quote tighter has no way to.

The CLOB is the opposite trade-off. Price discovery is real: the spread is whatever competing makers will accept, and a liquid market can quote far tighter than any curve. But it only works once makers show up.

So the two are complements, not competitors. The AMM bootstraps and backstops; the book takes over where there’s flow.

This is the part that makes coexistence tractable — the two venues agree on almost everything except how a price is formed.

The same unit of account. USDC, 6-decimal fixed point. 1 USDC = 1,000,000 units, 1 share = 1,000,000 units, on both sides.

The same outcome model. A binary YES/NO pair that always sums to exactly one dollar, represented as two SPL mints derived from the market PDA:

YES mint   seeds = ["yes_mint", market_pda]
NO mint    seeds = ["no_mint",  market_pda]
Vault      seeds = ["vault",    market_pda]     // per-market USDC collateral

Same seeds, same shape, in both programs.

The same event grouping. Markets are grouped into events, with a MarketEventLink PDA per member, and events coordinate resolution across their members. That grouping is also what the parlay’s correlation guard reads.

The same resolution lifecycle. Open → Closed → proposed resolution → dispute window with bonds → Resolved, or Cancelled. Winners redeem 1:1 against the market vault either way.

The same price accumulator. Both maintain a one-hour TWAP with an identical structure — a running price_cumulative_yes integral plus rolling anchors. The CLOB’s implementation is a direct port of the AMM’s accrue_twap: same window, same anchor roll, same 50/50 initialisation.

That last one is the clearest evidence the coexistence is deliberate rather than accidental. A downstream consumer reads one field shape and gets a comparable number regardless of which venue produced it. The AMM advances the accumulator inside buy_shares and sell_shares; the CLOB advances it inside execute_trade.

The same admin model. Squads multisig, and the backend never signs.

What differs, in practice

Getting a fill

On the AMM, a trade is one transaction and it always succeeds at the quoted price. There is no order to manage, nothing rests, nothing expires.

On the CLOB you sign an order, and what happens next depends on the book — it may cross immediately, rest, be partially filled, expire, or be ejected at game start. That’s the price of price discovery, and it’s why the CLOB has a whole order lifecycle and the AMM doesn’t.

Where the collateral sits

The AMM mints shares against its vault as you buy — q_yes and q_no are the outstanding supply. The CLOB moves existing tokens between traders, and only touches the vault when a match needs a pair minted or merged.

That’s why MINT and MERGE matching exist on the CLOB and have no AMM equivalent: the AMM is always the counterparty, so it never needs to pair two same-side traders.

Who takes the other side

The AMM’s counterparty is the curve — effectively the protocol’s liquidity. The CLOB’s counterparty is another trader, and the protocol takes no position at all. Non-custodial in both cases, but the risk sits in different places.

Which venue am I on?

The market account’s owner tells you:

Owner program	Venue
`4Pe4r9FpaAtdU2fkyVLgNSKqhULXs6udKvDZf7Wm1yVE`	AMM
`GoFTc9SFqn2E5Z9UZ8reQL5NUSr8kNL7f5o2kXnqCmCB`	CLOB

The account layouts are similar but the types live in different crates, and both are named Market — so the Anchor discriminator is identical and will not distinguish them. Check the owner, not the discriminator. The parlay program relies on exactly this check.

The catalogue surfaces are also split: CLOB markets are in the Markets API, keyed by condition ID, while the Platform API’s /api/markets/ serves the product view.

Parlays pick one — for now

GoCombo legs are AMM markets only. The parlay program’s EXPECTED_AMM_PROGRAM_ID is a compile-time constant, and read_market enforces account.owner == amm_program_id, so a CLOB market is rejected outright.

The CLOB accumulator was built to line up with what the parlay reads, so the intent is clearly for CLOB markets to become legs. Three things still block it, and they need a parlay-program change. → CLOB Markets as Legs

If you’re integrating, treat a market’s venue as a property to read rather than assume.

Where to go next


Trading Overview	The CLOB: matching, settlement, non-custody
Outcomes & Tokens	The YES/NO pair both venues share
Resolution & Disputes	The lifecycle both venues share
CLOB Markets as Legs	The TWAP accumulator, and the parlay gap
Contracts & Audits	Program IDs, multisig, audit reports