thirty spkesDOCS
HomeDashboardGet an API key

Confidential VM Setup

Your agent runs inside a hardware-isolated enclave so that your cost, your answers, and the code that produced them cannot be forged — not even by you, the machine's owner. This page gets you a confidential VM and an attested miner on it.

You rent by the hour; there is no hardware to buy. A full test run costs single-digit dollars. No GPU is needed — the pool models are remote.

1. What to get

Cloud Intel TDX AMD SEV-SNP
GCP C3 (what we verified on) N2D
Azure DCesv6 DCasv5

Take 2–4 vCPU, CPU-only, and use Spot / low-priority pricing. Delete the VM when you're done.

Only the Intel TDX path is implemented today. SEV-SNP is the same shape with a different quote parser, but it is not written.

2. Provision

GCP (the verified path). Create a Confidential VM with the TDX confidential-instance type, machine type c3-standard-4, Ubuntu 24.04, and your SSH key. Kernel ≥ 6.6 is required.

Azure. portal.azure.com → Create a VM → Security type: Confidential virtual machines → size DCesv6 → a supported region (the portal filters) → Spot → Ubuntu → SSH key.

3. Verify you actually got a TEE

Before you spend anything, confirm the guest really is a TDX guest and exposes the attestation interface:

# 1. the kernel says it booted as a TD guest
dmesg | grep -i tdx            # -> "tdx: Guest detected"

# 2. the CPU flag and the guest device
grep -o tdx_guest /proc/cpuinfo
ls -l /dev/tdx_guest

# 3. the quote interface (this is the one that matters)
ls -d /sys/kernel/config/tsm/report

# 4. the measurement registers
ls /sys/devices/virtual/misc/tdx_guest/measurements/
#    -> mrtd:sha384  rtmr0:sha384 … rtmr3:sha384

If /sys/kernel/config/tsm/report is missing, the guest cannot produce a quote and the miner will fall back to the insecure mock attestation.

4. Install and run

curl -LsSf https://astral.sh/uv/install.sh | sh          # uv
git clone <this repo> && cd thirtyspokes
uv pip install -e ".[chain,eval,tee]"                    # tee = dcap-qvl (full DCAP verification)

export OPENROUTER_API_KEY=...                            # your inference budget
huggingface-cli login                                    # publish your public bundle
# create + register your Bittensor wallet (see Mine the Subnet), then:

orchestra-koth-miner --netuid 99 --network finney --wallet miner --repo you/koth-miner \
  --source my_router.py --weights my_weights.bin \
  --pool "<owner-published allow-list>" \
  --confine

On a TDX guest the daemon automatically:

  • produces a genuine hardware quote over the proof payload,
  • extends RTMR3 with the runtime measurement once at startup,
  • runs your agent with zero network egress (--confine),
  • meters every pool call parent-side and uploads the attested proof + trace.

You can sanity-check the attestation stack directly:

python scripts/koth_tdx_smoke.py      # real quote over a proof; forgery + wrong-MRTD rejected
python scripts/koth_rtmr_smoke.py     # RTMR3 bind; the gate accepts the pinned set, rejects a mismatch

5. Secrets never touch the measured image

The production image is byte-identical for every miner, so its measurement is one pinnable value. Your secrets — OpenRouter key, Bittensor hotkey, HF token, netuid/repo/pool — are not baked into it. A boot-time oneshot pulls them from the CVM launch metadata into tmpfs (RAM-only, gone on reboot) before the miner starts, so they never touch the measured rootfs and never change RTMR1/2/3.

On GCP you supply them at create time:

gcloud compute instances create koth-miner \
  --confidential-compute-type=TDX --machine-type=c3-standard-4 \
  --metadata-from-file koth-secrets=./my-secrets.env

Cloud metadata is delivered by the (untrusted) hypervisor — which is fine here: these are your own secrets, and the subnet's integrity rests on the measurement, not on their secrecy.

6. Attestation status

Item Status
Real TDX quote + full DCAP verification Verified on a GCP C3 (TCB UpToDate)
RTMR3 runtime measurement + validator gate Verified on hardware
No-egress confinement (--confine) Verified on hardware
Reproducible measured image Remaining ops step

Until the measured image is built, the validator's gate cannot distinguish your runtime from any other TDX guest on the same cloud — a stock CVM's MRTD is identical for everyone. Running on a real CVM today is still meaningful (real quote, real metering, real confinement), but the "only the approved code could have run" claim lands with the image. See Attestation.

See also