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

# LI.FI

> Venue-aware verification for LI.FI — pass the exact quote request or route, get a verdict grounded in an independent re-quote, bound to those bytes.

Chance understands LI.FI natively. Submit the **exact quote request or route object** your agent is about to execute and the harness will classify it deterministically, **re-estimate the route through LI.FI's own public quote API** (fresh output, guaranteed minimum, bridge used), and judge it against your mandate with LI.FI's own documentation in the loop — returning a signed verdict whose `requestHash` binds to those exact bytes.

## What gets recognized

| Family | Payloads                                                                                                                                                                                                              |
| ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `swap` | Quote requests (`fromChain`, `toChain`, `fromToken`, `toToken`, `fromAmount`, `slippage`, …), advanced routes requests, and the quote/route/step objects LI.FI returns (`action` + `estimate` + `transactionRequest`) |

For every payload, the classifier decodes token amounts out of their raw decimals-scaled form, resolves chain ids to names, reads the slippage and integrator-fee settings, and checks whether the output is being redirected to a different wallet. Because a route object carries its *own* claimed economics next to opaque calldata, the harness never takes them on faith — it independently re-quotes the same trade against LI.FI's live API. The judge reasons over:

> *LI.FI ROUTE via mayan: 2,500 USDC on Arbitrum → 2,497.2 USDC on Base (claimed min 2,489.4) ≈ \$2,496.10, slippage 0.5% — Independent re-quote via LI.FI /v1/quote: fresh estimate 2,496.8 USDC (guaranteed min 2,494.3). Claimed toAmountMin is 0.19% below the fresh minimum.*

That re-quote step is what catches the classic aggregator failure: an agent presenting a stale or fabricated `toAmountMin` — or a 50%-slippage escape hatch dressed up as a routine bridge — while the calldata quietly commits to much worse. If the trade can't be re-quoted, the verdict leans ESCALATE rather than trusting the agent's own numbers: fail closed, never allow on assumption.

## Use it from your bot

Wrap the transfer you were already going to request:

```ts theme={null}
const transfer = {
  fromChain: 42161,           // Arbitrum
  toChain: 8453,              // Base
  fromToken: "USDC",
  toToken: "USDC",
  fromAmount: "2500000000",   // 2,500 USDC (6 decimals)
  fromAddress: "0x552008c0f6870c2f77e5cC1d2eb9bdff03e30Ea0",
  slippage: 0.005,
};

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: "Treasury rebalancing only: USDC in, USDC out, Arbitrum to Base, max 0.5% slippage, funds stay in the treasury wallet.",
    venue: "lifi",
    action: transfer, // 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 request the quote from li.quest and submit the returned transaction
```

You can also pass the full quote/route object LI.FI returned — the harness recognizes both shapes and compares the route's claimed numbers against its own fresh estimate. `venue` is optional — LI.FI payload 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 executing any LI.FI swap or bridge, call `verify_intent` with my rules as the intent and the exact quote request or route object as the action, with `venue: "lifi"`. Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.

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

## How the harness knows LI.FI

The judge works from a **versioned snapshot of LI.FI's own docs** — the quote and advanced-routes APIs, core objects (Quote, Route, Step, Action, Estimate), data schemas and validation rules, status tracking and PARTIAL/REFUNDED semantics, error codes, rate limits, and the Composer mechanics that can turn a "swap" into a DeFi deposit — plus a curated brief of the venue's footguns (decimals-scaled amounts, slippage-as-fraction, `toAmountMin` vs `toAmount`, recipient redirection, integrator-fee value leaks, non-atomic cross-chain legs). Static knowledge is never fetched at verdict time; the only live call is the independent re-quote against LI.FI's public quote API, 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 LI.FI

On top of the standard proof bundle (transcript root, judge signature, onchain anchor), venue-aware verdicts carry `venue: "lifi"`, the `actionFamily`, the venue `actionType` (quote request, routes request, or route object), `mode: "structured"`, the knowledge-snapshot version — and the independent re-quote (fresh output estimate, guaranteed minimum, bridge or DEX selected, and the gap against the payload's claimed numbers at verdict time), all inside the hash-chained transcript.

<Note>
  **Roadmap:** full simulation of the route's attached transaction, and escrowed execution — the same contract, but an ALLOW triggers submission by a Chance-held signer and a BLOCK physically never reaches one. The payload-first contract above is forward-compatible with both.
</Note>