fidrouter checking…
The neutral verification network for LLM relays

Don't trust. Verify.

An open, neutral network anyone can use to verify LLM relays. Independently attest that a relay runs the exact published, no-log code — and that your prompts stay end-to-end encrypted — before you trust it. We run one you can verify; anyone can register theirs.

Verify an endpoint →Register your relay

How it works

Your prompt is verified end-to-end and served in an attested, no-log enclave — the gateway never sees it.

partner control plane · never in the data path Gateway (New API)identity + billing cp-adapterkey → capability token Platform / consolemetering · receipts Your appprovider key + SDK Enclave (TEE)attested · no-logplaintext in RAM only LLM providerAnthropic / OpenAI Neutral registrymeasurement → source ① sk- validate + quota ② encrypted prompt + token (E2EE) upstream ∈ registry ③ receipt → metering reconcile usage → New API
1 · TokenYou keep your provider key. cp-adapter (beside the gateway) validates it against the gateway's billing/quota and swaps it for a capability token — the gateway itself never sits in the data path.
2 · VerifyThe SDK checks the enclave's attestation against the neutral registry and fails closed on mismatch.
3 · SealYour prompt is end-to-end-encrypted straight to the attested enclave and opened only in its memory — the enclave verifies the token offline against the baked-in CP key.
4 · ReceiptThe enclave returns a signed metadata receipt (no content) and posts the same to the console for metering — verify it anytime.
For developers

Use it with the key you already have

You send prompts. Keep using your provider's key — the drop-in SDK verifies the enclave and E2EEs your prompt, fail-closed.

  • Drop-in from fid import OpenAI
  • Verifies attestation before sending
  • Verify any response's signed receipt
How to use →Verify a receipt
For relay operators

Run a verifiable, no-log relay

You run a gateway. Offer a verifiable lane to your users while your gateway stays the identity + billing system, never in the data path.

  • Default (managed): point cp-adapter at our enclave — Claude + OpenAI out of the box
  • Inject your key operator-blind, in your browser
  • Advanced: deploy your own enclave for a fully independent trust domain
Partner sign in →Read the docs

Use it — with the key you already have

Get your key from your provider, as today. Point the drop-in SDK at the relay; it exchanges the key, verifies the enclave, and E2EEs the prompt — automatically, fail-closed. No login; the platform never sees your prompt.

from fid import OpenAI                       # pip install fidrouter — drop-in
client = OpenAI(api_key="sk-...",            # the key from your provider
                base_url="https://<relay>")   # SDK verifies + E2EE under the hood
client.chat.completions.create(model="claude-opus-5",
    messages=[{"role":"user","content":"hi"}])   # → served in the verified enclave

← back

Verify a live relay

Independent check — the same attestation your SDK runs. No account needed.

Verify any relay

Enter any endpoint URL to attest it live and check its measurement against the neutral registry — whether or not it's registered here.

Registered endpoints

One enclave = one measurement = one verifiable endpoint; a single enclave can route many providers/models at runtime (that's config, not attested). Separate rows here are genuinely different enclaves — different measurement, independent verification.

Verify a receipt

Every response carries a signed X-Fid-Receipt (metadata only). Paste one to confirm it was signed by a registered enclave and the model wasn't downgraded.

loading…

Partner sign in

Run a verifiable relay? Sign in to register your enclave, inject your key operator-blind, and see usage. Signup is open; endpoints go live only after review.

Operator / internal login

Partners sign in with GitHub / Google. ← back

Usage

Per-user usage from signature-verified receipts (metadata only — the platform never saw a prompt, can't inflate these).

User / tenantRequestsIn tokOut tokModels

Your enclave endpoints

Each is live-attested. Register → review → an admin publishes (refused unless it attests).

NameBase URLMeasurementStatusAttest

Register a new endpoint

cp-adapter runs beside your gateway and holds your CP seed. The enable.sh one-liner installs it and prints this URL (default port 8091).

Onboard your relay

Stand up a verifiable, no-log relay bound to your gateway.

  1. CP keypair — generate below; the public half bakes into your enclave, the seed stays with your cp-adapter (we never see it).
  2. Build + deploy the enclave — reproducible build at github.com/aoraki-labs/fidrouter → get base_url + measurement.
  3. Register the endpoint — the Endpoints tab (live-attested).
  4. Bundle cp-adapter beside your gateway (fidrouter-cp-adapter).
  5. Inject your key — the BYOK tab (operator-blind, in your browser).
  6. Metering → point the enclave's FIDPROXY_METERING_URL at .

Generate a CP keypair (in your browser)

Seed shown once, never sent to us.

Inject your upstream key — operator-blind, in your browser

The plaintext key is sealed in this browser to your attested enclave; we only receive ciphertext. Every check goes green before it seals.

1
Measurement pinned from the registry
2
Endpoint attests green (independent)
3
Sealing key signed by the attested identity
4
Sealed in-browser (plaintext never sent)
5
Ciphertext submitted → enclave accepted

Admin — endpoint review

Publish refused unless the endpoint attests green; then publish the registry.

NameBase URLMeasurementAttest