> ## 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.

# Liquid

> Venue-aware verification for Liquid Co-Invest — pass the exact MCP tool call your agent is about to make, get a verdict bound to those bytes before the order fills.

Chance understands **Liquid Co-Invest** natively. Liquid (liquid.trade) is a self-custodial multi-asset terminal — crypto perps, tokenised equities, commodities, FX and prediction markets, executing primarily on Hyperliquid — and its Co-Invest MCP server lets any MCP-capable client research markets and place real orders on the user's account. Submit the exact tool call your agent is about to make (`execute_order`, `close_positions_batch`, `execute_prediction_order`, …) and the harness will deterministically classify it, judge it against your mandate with a snapshot of Liquid's own tool schemas in the loop, and return a signed verdict whose `requestHash` binds to those exact bytes.

## Why this venue needs a gate

Liquid's published safety model is a human tap: nothing executes until you press Confirm. The intended flow is `suggest_trade` → confirmation widget → the widget calls `execute_order`.

That last step is a **normal MCP tool**. `execute_order`, `execute_orders_batch`, `execute_tpsl`, `close_position`, `generate_deposit_address` and `create_onramp_session` all describe themselves as internal to the widget — "The model must NEVER call this tool directly" — while being listed in `tools/list` and callable by any client holding the `trade` scope. The instruction is prose addressed to a model, not a server-side rule.

So an agent that calls `execute_order` itself has walked straight past the Confirm tap, and the Chance verdict is the only gate left. The classifier says so explicitly in its notes whenever it sees one of those tools called directly.

## What gets recognized

The MCP **tool name** is the discriminant. Both the raw `tools/call` envelope and the simplified `{ name, arguments }` form are accepted, and client prefixes like `mcp__liquid-co-invest__…` are stripped. A `mcp__hyperliquid__…` prefix is never claimed — Hyperliquid is its own venue here, despite the shared substring.

| Family                          | Tool calls                                                                                                                                              |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `order`                         | `execute_order`, `suggest_trade`, `execute_orders_batch`, `suggest_trades_batch`, `cancel_order`, `execute_prediction_order`, `cancel_prediction_order` |
| `position`                      | `close_position`, `close_positions_batch`, `close_prediction_position`, `modify_position`, `execute_tpsl`                                               |
| `margin`                        | `update_leverage`                                                                                                                                       |
| `swap` / `transfer` / `payment` | `convert_balances`, `generate_deposit_address`, `create_onramp_session`                                                                                 |
| `permission`                    | `enable_paper_trading`, `disable_paper_trading`, `reset_paper_account`                                                                                  |
| reads                           | `analyze_market`, `get_portfolio`, `search_prediction_markets`, … classify benignly so a gated agent's research never escalates                         |

Anything outside the snapshot that is not clearly read-shaped classifies as an unverified state-changing call and is judged fail-closed.

## The two traps the classifier exists to catch

**`size` means different things in different directions.** On `execute_order`, `suggest_trade` and the prediction tools, `size` is **USD notional (collateral × leverage)** — the schema is explicit: "250 means $250 of exposure, not 250 units". On `close_position` and `close_positions_batch`, `size` is **coin units**. The classifier renders the notional, divides by leverage to state the collateral actually at risk, and flags anything under Liquid's documented $15 minimum:

> *Liquid ORDER (execute\_order): BUY \$2,000 notional at 40× BTC at market (market, tif gtc)*
>
> with the note: *size is USD notional, so this is $2,000 of exposure on about $50 of collateral at 40× — NOT 2000 units of BTC*

**Several of the largest actions carry no dollar figure at all.** `close_positions_batch` with `confirmed: true` and no selection closes *every* open position. `disable_paper_trading` puts every subsequent order back on real funds. Raising leverage on an open position moves its liquidation price without trading anything. Removing a stop-loss strips protection with no notional in the payload. A mandate written only in dollar limits does not constrain any of them, and the classifier calls each one out.

## Previews and the `confirmed` flag

`close_position`, `close_positions_batch`, `execute_prediction_order`, `close_prediction_position`, `cancel_prediction_order` and `update_leverage` preview when `confirmed` is absent or false and execute when it is true. A preview is normally followed by the identical call with the flag flipped, so the harness judges it as the action it previews and says which of the two it is looking at.

## Use it from Claude or ChatGPT

Your agent already talks to Liquid over MCP, so add the Chance connector (`https://harness.chance.cc/api/mcp`, see [Connectors](/connectors)) alongside it and give the agent one standing instruction:

> Before calling any Liquid tool that trades or moves funds, call `verify_intent` with my rules as the intent and the EXACT tool call — `{ "name": "execute_order", "arguments": { ... } }` — as the action, with `venue: "liquid"`. Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.

The harness never holds your Liquid OAuth token. It judges the payload; your agent keeps the keys, and funds stay in your own wallet throughout.

## Use it from your bot

```ts theme={null}
const toolCall = {
  name: "execute_order",
  arguments: {
    symbol: "BTC",
    side: "buy",
    size: 250,          // USD notional — $250 of exposure, not 250 BTC
    type: "market",
    leverage: 5,        // so ~$50 of collateral is at risk
    sl: 58000,          // a stop the mandate can actually check
  },
};

const verdict = await verifyIntent({
  intent: myMandate,
  action: toolCall,
  venue: "liquid",
});

if (verdict.verdict !== "ALLOW") throw new Error(verdict.reasoning);
```

## Provenance

The tool names, argument names, enums and sizing semantics behind this venue come from the Liquid MCP server's own `tools/list` (45 tools, server identifying as `Liquid-MCP` 1.0.0, captured 2026-09), not from a reconstruction. Field meaning beyond the schema descriptions is inference and is labelled as such inside the knowledge module.