Deployment topology

The router and the models it serves are separate deployments in separate clouds, each attested on its own. That separation is not an operational accident; it is what the design rests on, and it is what this page draws.

What is where

The router runs in its own Swarm cloud on Azure. Its published snapshot contains the API, the console, the database and the egress verifier, and nothing else: no model server, no weights, and no GPU. It serves api.router.superprotocol.com and console.router.superprotocol.com, and TLS terminates for both inside the confidential environment.

The model runs in a different deployment, in a different Swarm cloud, on a bare-metal host whose node holds the GPU. It publishes its own evidence, under its own certificate authority, with its own digest. The router reaches it as a client over the public network, exactly as any other client would.

Today the production router serves one model this way, Qwen3-Coder 30B A3B Instruct, registered as an external endpoint. Nothing in the design limits it to one, and nothing requires the model to be on bare metal: a model deployment on Azure is the same arrangement with a different host underneath.

The catalogue is readable without an account, which is how you check that sentence rather than take it. It is the models query on the API host's GraphQL endpoint, not the REST path: GET /v1/models needs a key like every other /v1 route, and the console host redirects an anonymous caller to its sign-in page.

shCopy
curl -s https://api.router.superprotocol.com/graphql \  -H 'content-type: application/json' \  -d '{"query":"{ models { id name available origin } }"}'

Who verifies what

Two verifications happen, in opposite directions, and conflating them is the easiest mistake to make here.

1. You verify the router. Gatekeeper on your machine fetches the router deployment's evidence, checks it, confirms the live TLS certificate is the one that evidence names, and only then forwards your request. The router is not told the outcome.
2. The router verifies the model deployment. The egress verifier inside the router deployment, which is the same Gatekeeper binary, fetches the model deployment's evidence, requires its cloud measurement to be on the administrator's trust list and its digest to equal the pinned one, and pins the certificate before a prompt is proxied. The vocabulary for that direction is verified by this router, never a bare verified, because there the verifying party is the router and not you.

Your pin on the router's digest covers the router deployment, the egress verifier included, because that verifier is a container inside the snapshot you pinned. It does not transitively cover the model deployment: the trust list and the pinned upstream digest are database state, not part of the snapshot. What you get instead is transparency, and it is worth being exact about it: the model deployment's own evidence is relayed to you unmodified at GET /v1/evidence/<endpoint>, so you can verify the other end yourself rather than taking the router's word for it.

Why the separation is safe

• A compromise does not spread by assumption. Each deployment has its own certificate authority, its own snapshot and its own digest. A change to either shows up as evidence that no longer matches what was approved, and the party that approved it fails closed: your Gatekeeper refuses to forward, or the router drops the model from /v1/models and closes connections in flight.
• The router cannot read what the model holds. The weights sit in the model deployment's protected memory. The router is a client of an OpenAI-compatible endpoint there; it has no access to the node, the memory or the storage behind it.
• The model operator cannot impersonate the router. The hostnames are different deployments with different certificate authorities, and a verifier compares the certificate on its own connection against the one the signed evidence names.
• Credentials do not travel further than they must. The upstream model's API key is held by the router and injected into the egress request; the egress verifier itself holds no credential, and the model deployment never sees a router user's key.

What this topology does not cover

• The GPU is passed through to the confidential VM and is not separately attested today. The evidence covers the VM image and the deployment's containers. There is no GPU attestation in what this documentation describes, and nothing here should be read as implying one.
• Traffic analysis is out of scope. Sizes, timings and TLS client fingerprints are visible to whoever carries the connection; see the boundary on the evidence chain.
• A model deployment you did not pin is one you are trusting the administrator about. Your verification stops at the router. If the identity of the model deployment matters to you, read its relayed evidence and compare the digest yourself.
• Availability is not attested. Evidence says what is running, not that it is reachable or healthy.

Reading it yourself

The field-by-field description is on Evidence endpoints.