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.

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 client you already have

No SDK swap. Point your existing OpenAI-compatible client at the relay (base_url + key); verification rides the transport, and every response is a verifiable receipt.

Keep your client — just set base_url
Verify the endpoint once, or run a local proxy
Every response carries a 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 — keep your OpenAI client

No SDK swap. Point your existing OpenAI-compatible client at the relay (base_url + key). The verifier is the transport, a tiny local proxy, or the public monitoring network — not a library you have to adopt. Every response carries a signed, content-free receipt you can check.

from openai import OpenAI                     # your existing client — no swap
client = OpenAI(api_key="<key>",              # your relay key
                base_url="https://<relay>")     # TLS terminates inside the attested enclave
r = client.chat.completions.create(model="claude-opus-5",
    messages=[{"role":"user","content":"hi"}])
r.headers["x-fid-receipt"]                    # signed proof: measurement · model · no-log

Pick how much you want to run — all keep base_url + key:

Pin once (standard client). Verify the endpoint once (fidrouter verify or the Verify tab) and pin its measurement; your normal TLS check then rides the attested channel. Every response is a verifiable receipt.
Local verify-proxy (any language). Run one command and set base_url to localhost — it attests + checks each call, fail-closed. No code change. (rolling out)
Trust the network. Just call; rely on always-on public attestation + receipts (an endpoint flips red in the registry if it ever fails). (rolling out)

Want it surfaced in code? The optional drop-in from fid import OpenAI auto-pins and exposes resp.verified — sugar, not a requirement.

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

X-Fid-Receipt value

loading…

Register your enclave endpoint, inject your key operator-blind, and see usage. New here? Continuing with GitHub or Google creates your account.

or with email

Email Password

← back

Usage

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

User / tenant	Requests	In tok	Out tok	Models

Recent requests

One row per verified call — newest first, metadata only (no prompt content).

Your enclave endpoints

Each is live-attested against the neutral registry. Registering attests and publishes in one step — no draft, no manual approval; the attestation is the gate. If it can't attest yet it stays pending with the reason so you can fix and re-register.

Name	Base URL	Measurement	Status	Attest

Register a new endpoint

Step 1 · Choose your enclave. Pick the managed demo (fills everything in) or “Advanced” to enter your own.

Enclave

Step 2 · Register. This attests the endpoint live and publishes it to the neutral registry immediately if it goes green.

Name

Base URL

Expected measurement

Identity pub (hex)

Platform

cp-adapter — required to serve users (it keeps their keys on your side)

cp-adapter URL

Required to serve users: nothing else can validate their keys. It runs on YOUR machine and holds YOUR signing key, which is what keeps their credentials and your spend authority on your side. Run this beside your gateway — it installs the helper and prints the URL to paste here:
curl -fsSL https://app.fidcore.xyz/enable.sh | bash

Advanced: run your own enclave (dedicated trust domain)

CP keypair — generate below; the public half bakes into your enclave, the seed stays with your cp-adapter (we never see it).
Build + deploy the enclave — reproducible build at github.com/aoraki-labs/fidrouter (bash scripts/reproduce.sh prints the measurement) → get base_url + measurement, then register it (Advanced option in the dropdown above).
Metering → point the enclave's FIDPROXY_METERING_URL at .

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. You can inject multiple upstream keys — repeat this once per Account id (each is isolated in your own account pool).

Endpoint Account id — a label for this key in your pool

Names the slot this key lives in inside your isolated pool (e.g. byok-anthropic, byok-openai). Use a different Account id for each upstream key.

Capability token — authorizes this inject; minted by your cp-adapter

Autofill the capability token from your cp-adapter

Paste a key from your gateway; it's exchanged via the selected endpoint's cp-adapter and the token is filled in. The key is relayed transiently, never stored.

Upstream provider key — the real sk-… sealed to the enclave

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

Billing & credits

You bill your own users; we bill you a small platform fee on verified usage — computed live from the enclave-signed receipts, so the bill is recomputable and auditable, not asserted. New accounts start with free credit.

Add credit

Amount (USD)

Rate card

What we charge per 1M tokens (USD), plus a — platform fee. Your price to your own users is entirely yours.

Model	Input / 1M	Output / 1M

Ledger

Time	Type	Amount	Status	Ref

Admin — endpoint review

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

Name	Base URL	Measurement	Attest