Market Order

Fill a signed order against the AMM immediately; nothing rests. The matching engine holds limit orders only — a market order fills straight against the AMM pool, and that happens here, in the settlement bridge: a different service on a different base URL from the engine (both are on the Overview page). Requires write.

1. Quote the pool

GET https://app-staging.daejin.xyz/clob-engine/quote?market=373               ← SolanaGET https://app-staging.daejin.xyz/clob-engine/quote?chain=97&market=314      ← EVM{ "market": 373, "yes": 655, "no": 345 }

Prices in ticks, same scale as an order: 1000 = $1.00. Use the side you are buying as your signed price limit, or a worse one to allow slippage — the fill is bounded by what you signed.

2. Send the signed order

POST https://app-staging.daejin.xyz/clob-engine/market-ordercontent-type: application/json

The order is signed exactly as a limit order — same message, same scheme (see the engine's POST /orders). What differs is where you send it and one extra field.

Chain	Body
EVM	The signed order plus `chainId`. `market` is the bare on-chain id.
Solana	`market`, `user`, `action`, `outcome`, `price`, `size`, `salt`, `expiry`, `signature`, and optionally `appMarketId`. No `chainId`.

EVM, end to end

// The message is signed exactly as for POST /orders — same domain, same struct.// market inside the SIGNATURE is always the bare id; it is a uint256 on chain.import { Wallet } from "ethers";const wallet = new Wallet(process.env.PRIVATE_KEY);   // the market maker's own key; it never leaves your machineconst EXCHANGE = process.env.CLOB_EXCHANGE;           // ClobExchange contract address on chainId 97// API_KEY: an API key with the write scope, from the portal's keys pageconst signature = await wallet.signTypedData(  { name: "tokenplay-clob-order-v1", version: "1", chainId: 97, verifyingContract: EXCHANGE },  { Order: [      { name: "user", type: "address" }, { name: "market", type: "uint256" },      { name: "action", type: "uint8" }, { name: "outcome", type: "uint8" },      { name: "price", type: "uint256" }, { name: "size", type: "uint256" },      { name: "salt", type: "uint256" }, { name: "expiry", type: "uint256" } ] },  { user: wallet.address, market: 314n, action: 0, outcome: 0,    price: 700n, size: 10000000n, salt: 1725440000000n, expiry: 0n });await fetch("https://app-staging.daejin.xyz/clob-engine/market-order", {  method: "POST",  headers: { "content-type": "application/json", "X-API-Key": process.env.API_KEY },  body: JSON.stringify({    chainId: 97,          // picks the EVM adapter — omit it and the request goes to Solana    market: 314,          // the ON-CHAIN id, NOT the engine label "evm:97:314"    user: wallet.address,    action: "buy", outcome: "YES",    price: 700,           // a LIMIT, not a target: quote first, then sign some slippage room    size: "10000000",    salt: 1725440000000, expiry: 0,    signature,  }),});

Or, with the bundled client: npm run mm -- quote then npm run mm -- market-order --action buy --outcome YES --price 700 --size 10000000.

The mistake worth naming. Every other endpoint on the engine speaks the label evm:97:314, so a body built by copying a working POST /orders call carries it here too — and the EVM adapter reads it as a number, gets NaN, and answers 422 bad market id. There is no marketId field on this route; the field is market. Both spellings are accepted now, but the bare id is the one to write.

The routing rule is the whole trick. The bridge serves both chain families on one set of paths and decides which adapter answers by asking one question: does the body have a chainId field? If yes it goes to EVM, if no it goes to Solana. A Solana order that carries chainId is handed to the EVM adapter and comes back as an unknown market. An EVM order without it is recognised by its 0x address and refused with a 400 that says to add chainId.

Solana, from a terminal

curl -s -X POST https://app-staging.daejin.xyz/clob-engine/market-order -H "X-API-Key: <your API key>" -H 'content-type: application/json' \  -d '{"market":880201,"user":"<pubkey>","action":"buy","outcome":"yes",       "price":700,"size":5000000,"salt":123,"expiry":0,"signature":"<base58>"}'# {"ok":true,"sig":"…","execPrice":500}curl -s "https://app-staging.daejin.xyz/clob-engine/quote?market=880201"# {"yes":667,"no":333}    ← the AMM sold YES, so YES got dearer

Your signed price is a limit, not a request: 700 here means "fill me at 70¢ or better", and it filled at 50¢.

Returns 200 with the fill — Solana { ok, sig, execPrice }, EVM { ok, tx, bookFilled, ammFilled, execPrice } — or 422 when the pool cannot fill it at your signed limit. Unlike POST /orders, nothing is left resting afterwards.

Authorization

X-API-Key<token>

Developer-portal API key (tp_live_… / tp_test_…), also accepted as Authorization: Bearer tp_….

In: header

Response Body

curl -X POST "https://example.com/market-order"

Empty