awesome-private-inference a registry of TEE-verified inference

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)
Backend attested
Gateway cryptographically verified the backend TDX quote

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:

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