Skip to content

Case study / illustrative workflow

One agent.
Every call on the record.

How a research agent runs on models its operator did not pick by hand, while every answer arrives with evidence the operator can check.
An illustrative walkthrough of how Verify Route is designed to work. It is not a customer result, not a record of a live transaction, and not investment advice.

The starting point

A team runs a research agent that answers questions for clients. The clients ask a fair question: which model wrote this, on whose hardware, and did anyone else see the prompt? The team wants to answer with evidence, not a policy page, without rewriting the agent.

  1. 01 /

    Set the policy.

    The operator creates a key for the agent with a verified-only policy: providers must hold a 10,000 USDG bond on Robinhood Chain and a canary pass rate of at least 99% over the last day. The key also carries a monthly USDG cap and a model allowlist, so the agent cannot drift to anything else.

  2. 02 /

    Route the request.

    The agent keeps its usual request: model and messages. A lane header asks for the attested lane, and the verify block restates the policy. Providers that fail any condition are filtered out before the call is priced.

    Verified-only request
    {
  "endpoint": "POST /api/v1/chat/completions",
  "headers": {
    "Authorization": "Bearer <VERIFYROUTE_API_KEY>",
    "X-VR-Lane": "attested"
  },
  "body": {
    "model": "author/model",
    "messages": [
      { "role": "user", "content": "Your prompt" }
    ],
    "verify": { "bond_min": 10000, "canary_min": 0.99 }
  }
}

  3. 03 /

    Check before answering.

    The router confirms the provider's bond is posted, its latest canary set passed and its enclave quote is fresh. If the attested host's evidence is stale, the call fails closed instead of quietly moving to a weaker lane, and the agent gets a clear refusal.

  4. 04 /

    Keep the evidence.

    The reply comes back with a signed receipt: model, provider, lane, token counts, USDG cost, hashes of the request and reply, and the hash of the attestation quote. The receipt root is anchored on Robinhood Chain. The operator pastes the receipt into the checker and verifies the signature in a browser, without asking anyone.

Operator control

Cap. Restrict. Revoke.

A spending limit, a provider policy and a key that can be switched off at once.

Checkable result

Follow the receipt.

Model, provider, cost, attestation and anchor in one signed record.

Try it

Two parts work today: connect a wallet to open the workspace and see your Robinhood Chain balances, and check a signed sample receipt in your browser. Keys, bonded providers and attested lanes follow the roadmap.

Check a receipt Open the workspace