Skip to main content
Every verification follows the same path, whether it arrives from the dashboard sandbox, the HTTP API, or an MCP connector:

1. One contract, two action forms

A request always carries the intent (the mandate — operator rules, risk limits, thesis, in plain English) and the action. The action comes in two forms:
  • Freeform — a plain-English description of what the agent wants to do. Judged semantically; works for anything.
  • Structured — the exact API payload the agent is about to submit to a supported venue (e.g. a Hyperliquid exchange-endpoint action). Strongly preferred for bots: the verdict’s requestHash then binds to the exact bytes that will be executed, not a paraphrase of them.
The response tells you which strength you got: mode: "structured" | "semantic".

2. The venue layer

Supported venues plug in as adapters — a deterministic classifier plus a versioned knowledge module. Nothing else in the pipeline knows venue specifics. The classifier (code, not AI) types the payload by its discriminator field, resolves assets against a snapshot of the venue’s own metadata, computes notional, and renders a grounded human-readable summary. The judge reasons about those numbers — arithmetic is done by code, meaning is judged by the model. Classification also tags every scan with an actionFamily (order, withdrawal, staking, vault, …). The knowledge module is a set of markdown pages snapshotted from the venue’s own documentation, versioned in the repository and reviewed like code — never fetched live at verdict time. The judge receives the pages relevant to the classified action family up front, and can pull additional pages on demand through a load_venue_doc tool. A short curated brief adds the footguns raw docs don’t emphasize. Knowledge updates are deploys: a re-ingest script refreshes the snapshot from the venue’s docs, the diff is reviewed by a human, and the new snapshot hash ships with the next release.

3. The judge

The judge is an agentic LLM loop (with web search and, for venue-aware runs, the doc tool). It receives the mandate, the classifier’s summary, the raw payload, and the venue brief — and must cite the specific mandate clauses and doc facts behind its decision. It concludes with exactly one outcome: ALLOW, BLOCK, or ESCALATE. Fail-closed is the contract: anything other than ALLOW means do-not-execute, and an unverifiable fact means ESCALATE, never ALLOW-on-assumption.

4. The proof

Everything above lands in a hash-chained transcript: the venue classification (with the knowledge-snapshot version and the hash of every preloaded page), every doc the judge consulted (agent.doc events with content hashes), every search, every reasoning step, and the decision. The chain root is signed by the attested judge key and, when configured, anchored onchain. The receipt therefore proves not just what was decided, but which version of which knowledge the decision rested on — something no retrieve-at-runtime setup can offer.

Venue coverage

The verification brain is venue-agnostic — a venue integration is knowledge and classification, not new infrastructure. That’s why new venues land in days, not months: the judge, the proof pipeline, and the API contract never change. Hyperliquid is live today; if you want your venue supported, get in touch.