Methodology

The dashboard scores each (provider × model) pair across eight capability layers. This page explains exactly what each layer means and how we re-verify it.

Scorecard layers

Nonce bound: Client-supplied nonce appears in TDX report_data
TDX quote: Intel TDX quote accepted by Phala's public verifier
report_data binds key: report_data commits to signing address + nonce
GPU attested: NVIDIA NRAS returned PASS on the GPU payload
Key derives to addr: keccak(signing_public_key) == signing_address
compose_hash committed: mr_config starts with 0x01 || sha256(app_compose)
Prod OS image: vm_config.image is the production dstack OS image, not dstack-nvidia-dev. The dev image ships sshd + debug-tweaks + tools-profile; with DSTACK_AUTHORIZED_KEYS it gives the operator host-network-namespace root SSH inside the CVM (prompts in /proc//mem exfiltratable). Flips ✅ when the fleet runs dstack-nvidia-* prod.
Serving code attested: The code on the prompt-plaintext path (serve.py) and the served model are committed to a measured register. Red on Chutes: serve.py is CFSV-excluded and in no RTMR, so the operator (or Chutes) can read or exfiltrate the decrypted prompt AND silently substitute the model — neither detectable from the quote. Live proof: all -TEE models share one MRTD. chutesai/chutes#75.
Backend attested: Tri-state: ✅ gateway code self-attests + compose_hash is on-chain authorized + image digest is in our analyst-pair audit ledger. ○ chain-authorized + self-consistent but the audit ledger hasn't caught up (analyst backlog, NOT a provider fault). ❌ quote not self-consistent or compose not on the on-chain authorized set.

Independent re-verification

We intentionally do not trust the provider's own "server_verification" field when the provider exposes one (e.g. Venice). We forward the TDX quote to Phala's public TDX verifier and the NVIDIA payload to NVIDIA NRAS. We then recompute the key-derivation and the report_data binding in-process. This means a compromised provider cannot fake a ✅ by lying about its own verification result.

Known upstream TODOs

The Phala verifier itself decodes NRAS and Intel Trust Authority JWTs with verify_signature=False. We inherit that limitation. See devproof-audits-guide/LEARNINGS.md.

Why "Stage 0" on every provider

Even when every layer in the matrix shows ✅, the provider is Stage 0 in the ERC-733 / devproof sense for at least one of:

Backend code not pinned at the gateway. NEAR's cloud-api now inline-verifies each backend's TDX quote + RTMR3 + GPU NRAS and pins the TLS fingerprint before serving (PR #552 / #558, Apr–May 2026) — the dashboard's Backend attested column reflects this. But ALLOWED_COMPOSE_HASHES is still unset server-side, so any TCB-current TDX TD the operator points the gateway at passes. Closed-chain clients close the gap by pulling compose_hash out of the attestation themselves and checking it against the on-chain addComposeHash set on Base. Tracking issue: nearai/cloud-api#224.
Operator-mutable routing. Database field controls which backend a gateway calls (admin-gated; bounded but not eliminated by the inline-verify hop above).
KMS opacity. Mutable image tags, no upgrade log on the KMS providing key material.

How `Backend attested` is decided

For providers with a gateway→backend hop, we cross-reference three signals before marking the column. The cell is tri-state, and the middle state is deliberate: we want to distinguish "provider shipped code we haven't audited yet" from "provider is doing something wrong."

✅ Verified. The gateway's TDX quote self-attests its measured compose (mr_config = 0x01 ‖ sha256(app_compose)), the compose_hash appears in the ComposeHashAdded(bytes32) set on the gateway's DstackApp contract on Base (probes/onchain_sweep.py enumerates these), AND the cloud-api container image digest pulled from the measured docker-compose is in our analyst-pair audit ledger (data/audits/near-ai_cloud-api.json), with a link to the audit doc.
○ Audit pending (amber outline). All the chain + self-consistency checks pass, but the image digest is new — we haven't read the diff yet. Treat as "queue grew faster than the analyst pair did," not a provider regression. The details.cloud_api_image_digest in the snapshot identifies what's waiting to be reviewed.
❌ Rejected. Either the gateway quote doesn't self-attest the compose it claims, or the compose isn't in the on-chain authorized set — meaning someone deployed code the EOA owner never signed into the DstackApp.

Reproduce

git clone https://github.com/amiller/awesome-private-inference
cd awesome-private-inference
uv venv && source .venv/bin/activate
uv pip install -e .

git clone https://github.com/nearai/nearai-cloud-verifier _nearai-verifier
export NEARAI_VERIFIER_PATH="$(pwd)/_nearai-verifier/py"

export NEAR_API_KEY=...
export REDPILL_API_KEY=...
export VENICE_API_KEY=...

python -m probes.collect
python -m probes.render