> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chance.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# Limitless

> Venue-aware verification for Limitless — pass the exact signed CLOB order, get a verdict on the real market and outcome, bound to those bytes.

Chance understands Limitless natively. Submit the **exact `POST /orders` payload** your agent is about to send — the signed EIP-712 order struct plus its market slug — and the harness will classify it deterministically, **resolve the slug against the live market** (question, outcome, current price, status, deadline), and judge it against your mandate with Limitless's own documentation in the loop — returning a signed verdict whose `requestHash` binds to those exact bytes.

## What gets recognized

| Family       | Payloads                                                                                     |
| ------------ | -------------------------------------------------------------------------------------------- |
| `order`      | New orders (signed order structs — GTC, FOK, FAK, post-only), single/batch/all cancellations |
| `position`   | Redemption of winning positions on resolved markets                                          |
| `withdrawal` | Server-wallet withdrawals (amount, token, destination)                                       |

For orders, the classifier decodes side (`0`/`1` → BUY/SELL), derives price and size from the **signed** `makerAmount`/`takerAmount` — not from the advisory price field — and computes cost. Limitless payloads name the market twice: a human-readable slug at the top level and an opaque uint256 outcome token inside the signed struct. The harness resolves both and cross-checks them, so the judge reasons over:

```text theme={null}
BUY 500 shares @ 4.0¢ of outcome token 775923…194664 on market "btc-100k-weekly"
(GTC) ≈ $20.00 cost (max) — resolved: this is the "No" outcome of "Will BTC close
the week above $100k?". Market currently prices this outcome at 3.6¢.
Market status: FUNDED. Market deadline: 2026-07-05.
```

That cross-check catches two classic failures at once: the side-inversion (a thesis that says *"back the favorite"* while the order quietly buys the cheap opposite token) and the market-swap (a signed token that belongs to a **different market** than the slug the agent claims to be trading). If the slug can't be resolved, or the token matches neither outcome of the named market, the verdict leans ESCALATE rather than trusting the agent's own description: fail closed, never allow on assumption.

## Use it from your bot

Wrap the order you were already going to submit:

```ts theme={null}
const payload = {
  order: {
    salt: "1778155025318314496",
    maker: "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    signer: "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    taker: "0x0000000000000000000000000000000000000000",
    tokenId: "77592343650315158711139664020320961095667533157390815861422126188027765194664",
    makerAmount: 20000000,  // $20.00 (scaled 1e6)
    takerAmount: 500000000, // 500 shares
    expiration: "0",
    nonce: 0,
    price: 0.04,
    feeRateBps: 0,
    side: 0, // BUY
    signatureType: 0,
    signature: "0x…",
  },
  ownerId: 12345,
  orderType: "GTC",
  marketSlug: "btc-100k-weekly",
};

const res = await fetch("https://harness.chance.cc/api/v1/intent", {
  method: "POST",
  headers: { "x-api-key": process.env.CHANCE_API_KEY!, "Content-Type": "application/json" },
  body: JSON.stringify({
    intent: "High-probability favorites only: enter only when the chosen side is priced >= 95c. Max $25 per market.",
    venue: "limitless",
    action: payload, // the exact payload — the verdict binds to these bytes
  }),
});

const { verdict, reasoning, mode } = await res.json();
if (verdict !== "ALLOW") throw new Error(`Blocked: ${reasoning}`);
// only now POST the payload to api.limitless.exchange/orders
```

`venue` is optional — Limitless order shapes are auto-detected — and freeform `action` descriptions still work (`mode: "semantic"`).

## Use it from Claude or ChatGPT

Add the hosted connector (`https://harness.chance.cc/api/mcp`, see [Connectors](/connectors)) and give your agent one standing instruction:

> Before placing any Limitless order, call `verify_intent` with my rules as the intent and the exact signed order payload as the action, with `venue: "limitless"`. Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.

Agents with Limitless execution tools then get gated automatically; agents without them still give you provable pre-trade checks in chat.

## How the harness knows Limitless

The judge works from a **versioned snapshot of Limitless's own docs** — order placement and EIP-712 signing, amount semantics for GTC/FOK/FAK, cancels, market data and the venue system, dynamic fee curves, negrisk markets and share conversion, resolution and redemption, authentication scopes and withdrawals — plus a curated brief of the venue's footguns (numeric side semantics, signed amounts vs. the advisory price field, FOK's missing price protection, the no-expiry rule, recurring micro-markets with timestamped slugs, the `onBehalfOf` privilege surface). Static knowledge is never fetched at verdict time; the only live call is the public market lookup that resolves the order's slug and token to a market, outcome and current price, and what it resolves is recorded in the verdict's hash-chained transcript. Every documentation page the judge consults is chained with its content hash — the receipt proves exactly which knowledge, at which version, informed the decision. See [Architecture](/concepts/architecture).

## What the receipt adds for Limitless

On top of the standard proof bundle (transcript root, judge signature, onchain anchor), venue-aware verdicts carry `venue: "limitless"`, the `actionFamily`, the venue `actionType`, `mode: "structured"`, the knowledge-snapshot version — and the resolved market identity (question, outcome, live price, status and deadline at verdict time), all inside the hash-chained transcript.

<Note>
  **Roadmap:** escrowed execution — the same contract, but an ALLOW triggers order placement by a Chance-held signer and a BLOCK physically never reaches one. The payload-first contract above is forward-compatible with it.
</Note>