The router as a Swarm application · Confidential Router

Confidential Router is an application deployed on Super Swarm, attested like anything else running there. What that means for its surfaces, its images and its digest.

Confidential Router is not part of the platform. It runs as a deployment on Super Swarm, and it carries exactly the evidence properties any other deployment there carries: its images and configuration are in one snapshot, that snapshot has a digest, and the deployment publishes a signed document naming it.

This framing is the whole trust story. You are not asked to trust the router's description of itself. You check the deployment the same way you would check any other workload on the cloud, with a verifier the deployment did not supply.

What is in the deployment

The production deployment's published snapshot contains these images, by digest, and no others:

Image	What it is
`ghcr.io/super-protocol/confidential-router/router-api`	the API, the meter, the ledger and the console's GraphQL
`ghcr.io/super-protocol/confidential-router/router-ui`	the console
`ghcr.io/super-protocol/confidential-router/gatekeeper`	the egress verifier, for external model endpoints
`ghcr.io/zalando/spilo-17`, `quay.io/coreos/etcd`	the deployment's PostgreSQL and its coordination
`docker.io/library/haproxy`, `docker.io/library/busybox`	the database's proxy and an init helper

There is no model server and no model image in that list, and no GPU in the deployment. The models this router serves run elsewhere, as separate deployments, and the next page draws that.

The three surfaces

Surface	Hostname	What it is
Landing page	`router.superprotocol.com`	the public page and the invitation links; a static site, not part of this deployment
Console	`console.router.superprotocol.com`	sign-in, API keys, chat, credits and usage
API	`api.router.superprotocol.com`	the OpenAI-compatible endpoint under `/v1`

The console and the API are separate hostnames of the same deployment, and TLS terminates for both inside the confidential environment. That is a requirement rather than a preference: a verifier compares the certificate it observes on its own connection against the fingerprint the signed evidence names, so a front door that terminated TLS outside and re-encrypted inward would break the binding and would be able to read every prompt.

What changes the digest

Any change to what is deployed: a new version of the software, a different image, or a configuration change. Secrets reach the pods through a Kubernetes Secret and do not move the digest.

For anyone who pinned the old digest, a change is not an error but a deployment they have not approved yet. Expect to be told about it, and to compare and pin the new digest: Connect Gatekeeper.

What the router is trusted for, and what it is not

The router meters tokens and bills for them, and it holds the accounts, keys and credit ledger. It never stores prompt or completion content, and that property is part of the snapshot you pin rather than a promise made on a page.

It forms no verdict about itself. It has no registration endpoint for verifiers, no verdict header, no callback and no field in any table for one. Verdicts about the router are formed by your own software; verdicts about the model endpoints the router uses are formed by the router, which is a different direction and is covered under external model endpoints.

Next: Deployment topology.