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:

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

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.

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.