action. Before the judge runs, a venue adapter reads it. The adapter is deterministic code, and it does four things:
- It types the action with an
actionFamilyshared by all venues and anactionTypespecific to the venue. - It writes a summary with computed values (side, size in units and dollars, recipient, allowance) and adds notes on risks it can see in the payload, such as an unlimited approval or an output sent to a different wallet.
- For ten venues, it looks up live facts from a public API.
- It chooses which pages of the venue’s documentation the judge reads first.
How the adapter is chosen
- If the request sets
venueand the name resolves, that adapter is used. If the payload is not a shape it knows, the action is typedunknownwith a note saying so. - Otherwise each adapter tests the payload in this order, and the first match wins:
hyperliquid,limitless,polymarket,dimes,myriad,orderly,derive,lifi,meow,liquid,robinhood,x402,agentcards,uniswap,solana,starknet,alchemy. Specific shapes go first. A Limitless order also matches Polymarket’s order shape, so Limitless is tested before Polymarket. Alchemy is last because any object withtoanddatais an EVM transaction. - If nothing matches, the object is judged as plain JSON with
mode: "semantic"andvenue: null.
venue is set. Each venue page lists them.
A string action with a venue gets the venue’s brief, and the judge can open its documentation, but nothing is classified: mode is semantic, actionFamily is unknown and actionType is null.
Venue names
Over HTTP (POST /api/v1/intent), venue is lowercased and stripped of everything except letters and digits. It is then matched against the venue ids, then the aliases listed on each venue page, then by prefix, so Hyperliquid perps resolves to hyperliquid and dimes.fi to dimes. A name that matches nothing is ignored without an error, and the payload is auto-detected.
Over MCP (verify_intent), venue must be one of the 17 ids below, or evm for Alchemy. Any other value fails validation.
Action families
The family is returned as
actionFamily, stored with the verification and shown to the judge. It does not allow or block anything by itself.
Live lookups
Each lookup has a timeout (3.5 seconds for most, 6 to 7 seconds for LI.FI, Uniswap and x402) and a cache (60 seconds for quotes and x402 terms, 5 minutes for everything else). A failed lookup never fails the request. The adapter adds a note that the fact is unverified, and the judge weighs that against your rules.
Hyperliquid, Robinhood, Liquid, Meow, AgentCard, Solana and Starknet have no live lookup. Each page says why.
Venue knowledge
Each adapter ships a snapshot of the venue’s own documentation as markdown pages, plus a short curated brief of the venue’s pitfalls. Nothing is fetched from the venue’s docs at verdict time. The snapshot changes only when the harness is redeployed. The judge’s instructions include the brief, the adapter’s summary and notes, and the pages the adapter chose for this action type. The judge can open any other page in the snapshot with itsload_venue_doc tool.
What you get back
The HTTP response carries four venue fields:
The MCP tool returns the same fields except
actionType.
The summary and notes are not in the response. They are in the run’s transcript, a hash chain whose root the judge signs. Three events carry the venue work:
venue.contextholds the venue id, the knowledge snapshot version (a hash over every page and the brief), the family and action type, the summary and notes including anything a live lookup resolved, and the topic and sha256 of each preloaded page.agent.docis recorded for each page the judge opens withload_venue_doc, with its sha256 and the snapshot version.run.startholds the full task, including the raw payload.
$TRANSCRIPT_URI is proof.transcriptUri from the response. See Receipts for how the transcript is verified.