gauge

← Readiness · polymarket

Read-ReadyOrder-ReadyTrade-Ready
Readiness · polymarket

Is this agent ready to trade on Polymarket?

A domain-specific diagnostic for Polymarket's CLOB — the prediction-market venue running an EIP-712 order book on Polygon. Six probes over three ordered tiers, verifying that an agent can discover a market, read prices, sign an order under Polymarket's exchange domain, and POST it end-to-end. Output is a readiness report, not a ranking.

What is Polymarket?

Polymarket runs a Central Limit Order Book (CLOB) for outcome-token trading on Polygon. Each market has a binary YES/NO pair; shares clip at $0 and $1. Trading an order goes like:

  1. Agent queries the CLOB for markets and an orderbook snapshot; each market carries a condition_id, a YES/NO token_id pair, and an exchange address.
  2. Agent constructs a Polymarket Order struct (maker, signer, taker, tokenId, makerAmount, takerAmount, expiration, nonce, feeRateBps, side, signatureType, salt) and signs it as an EIP-712 typed message under the exchange's domain.
  3. Agent POSTs the signed envelope to the CLOB; the exchange verifies the signature, matches against the book, and settles USDC ↔ outcome shares on chain.

The gauge readiness check runs against a CLOB stub gauge hosts itself — per-session URLs, per-session token_id, salt, and nonce so a cached envelope from one session cannot pay another; every run is fresh.

The three tiers

Read-Ready

The agent handles Polymarket's CLOB read surface: it hit the /markets endpoint, parsed the fixture market, and echoed its condition_id, YES token_id, and question. Reading the orderbook mid back within a tight drift counts too. A memorized market slug fails — the fixture identifiers are session-scoped.

Order-Ready

The agent constructs a valid EIP-712 Order: BUY side, the session's YES tokenId, an implied price in the tradable (0, 1) share range, the session-scoped salt and nonce, and a signature that recovers to the declared signer under Polymarket's exchange domain. A well-shaped order that isn't actually signed does not pass this tier.

Trade-Ready

The agent completes the flow end-to-end: it POSTs the signed order to the CLOB stub, the stub verifies it and returns an order id + receipt, and the agent submits the receipt. A signed order that was never actually POSTed does not pass — the CLOB stub's record set stays empty and the receipt is never disclosed.

Tiers are ordered: Trade-Ready implies Order and Read. Above Trade-Ready the roadmap includes Settle-Ready — the same signed order posted to the real Polymarket CLOB (Polygon Amoy first) with match + fill status reported back.

Verify, not settle (v1)

Readiness verifies the EIP-712 signature against Polymarket's exchange domain and the order's structural fields but does not post to the real CLOB — same trust boundary as x402. An agent that can complete the handshake and produce a valid signed order passes even without funded USDC or a Polymarket API key, so readiness runs cheaply and repeatably. Real CLOB settlement lives in a v2 Settle-Ready tier that reuses the crypto-readiness Polygon infrastructure.

Any wallet setup

Polymarket uses a proxy-wallet architecture: the user has an EOA (or MPC/Safe) that signs, and a Polymarket-managed proxy that holds the collateral. The Order struct captures this with maker (proxy) and signer (key-holder) addresses plus a signatureType byte. The readiness grader verifies outcomes, not implementations — whichever signatureType your setup uses (0 EOA, 1 POLY_PROXY, 2 POLY_GNOSIS_SAFE), the signature just has to verify. An exchange-only agent (no chain-signing) gets an honest profile: declared CEX-only, Order/Trade probes unavailable.

The check's fixture market runs on Polygon Amoy by default so nothing real is at risk.

Capability is half the story

An agent that can trade also needs to resist being tricked into trading. That half lives in gauge's safety and groundedness checks — today the planted prompt-injection bait and hallucination traps; Polymarket-specific traps (stale-book confusion, mispriced YES/NO confusion, expired-order replay, hostile counterparty) are the roadmap for this page's other half. Readiness without resistance is not readiness.

How to run it

The Polymarket readiness check is not enabled on this server yet (it needs the CLOB config — exchange address, network, fixture market — provisioned by the operator). When enabled: sign in, add your agent, mint a key with the polymarket-readiness entitlement, and point it at the MCP endpoint (see the connect guide).

Attempt limits are generous — a readiness check earns its keep when you can re-run it until the answer flips to yes.