Attestation & Trust Model

A miner runs the benchmarks on hardware it owns. Everything about that arrangement is dangerous unless the hardware itself vouches for what ran. This page is the honest account of exactly what our attestation proves, what it does not, and what remains before it is airtight.

Implemented and verified on real hardware. The full stack below was verified end-to-end on a GCP C3 (genuine Intel TDX): a real TDX v4 quote, complete DCAP verification, RTMR3 runtime self-measurement, no-egress confinement, and on-chain governance. Live TCB status on that host: UpToDate.

What one signature asserts

The enclave produces a hardware quote over {measurement, report_data}, where report_data is sha256 of the entire proof payload minus the quote itself. That single signature asserts, simultaneously:

1. an approved enclave image ran (the measurement / register values), and
2. it produced exactly this payload — every answer, every metered cost, the artifact hashes, the epoch and nonce.

Mutate any field and report_data() changes, and the quote no longer verifies.

Generating the quote

Inside the confidential VM the runtime asks the Linux kernel's configfs TSM interface (/sys/kernel/config/tsm/report) for a genuine TDX v4 quote, writing the 64-byte REPORTDATA as the 32-byte payload hash, zero-padded. The quote embeds Intel's PCK certificate chain and is signed by an Intel-provisioned attestation key.

Verifying the quote

Verification is DCAP, in full — not just a signature check:

The owner's TCB policy defaults to accepting only:

Collateral (TCB Info, QE Identity, CRLs) is fetched and cached per FMSPC, or pinned offline by the owner for deterministic verification.

What the registers measure

On GCP TDX the measurement registers split by who controls them. This matters enormously, and getting it wrong is the classic mistake:

MRTD is not a per-image discriminator. It is Google's firmware, the same value for every TDX guest on the platform. Pin it only to assert "a genuine GCP TDX firmware." The real fingerprint of our image is RTMR2 (kernel + cmdline) and RTMR1 (GRUB/shim).

The GCP register mapping does not separately measure the initrd or rootfs — so we make RTMR2 cover the rootfs transitively by putting the dm-verity root hash on the kernel command line. Any rootfs change changes the cmdline, which changes RTMR2.

RTMR3: binding the runtime

At enclave startup the runtime extends RTMR3 with a digest of its own identity — the runtime version, the benchmark suite version, and the pinned pool allow-list:

RTMR3 = SHA384( 0×48 ‖ SHA384("koth-rtmr3-v1|runtime|suite|pool") )

The quote then carries that value, and the validator gates it against the owner's published expectation. Bump the suite or change the pool, and RTMR3 changes.

RTMR3 alone is advisory. A userspace extend is only load-bearing inside a locked image where nothing but the runtime can execute. On a general-purpose VM an operator could extend the "correct" value and then run different code. The anchor is the measured image; RTMR3 pins the dynamic parts within it.

The measured image — the remaining gap

This is the honest centre of the whole trust story.

The measurement gate only discriminates once the reproducible, locked-down image is built. Against a stock cloud CVM — whose MRTD is shared by every TDX guest on that provider — enforcement will admit any TDX guest. Building the measured image is the hard prerequisite for secure mainnet mining, not a polish item.

The image is a deterministic, dm-verity read-only appliance with no sshd, no getty, no shell, no package manager. It boots straight into the runtime as a systemd unit. Miner secrets (OpenRouter key, hotkey) arrive at boot from CVM metadata into tmpfs — never baked into the public, measured rootfs. Two people building from the same commit and lockfile must get the same RTMR1/RTMR2.

No-egress confinement

The miner's agent is arbitrary Python. Run in-process it could import socket and exfiltrate the task slice, or read the operator's secrets. So it doesn't run in-process:

parent (trusted runtime)                child (untrusted agent)
  holds the pool key                      unshare --net  →  zero egress
  meters every call        ← call_model ←  agent(prompt, call_model)
  makes the real API call  → response  →
  records the trace                        tmpfs over secret dirs, rlimits

The agent has no network, no pool key, a scrubbed environment, resource limits, and tmpfs over the host's secret directories. Its only channel is call_model, an IPC to the trusted parent, which meters the call and makes it. Metering is therefore un-bypassable.

Verified on the C3: an agent's socket.create_connection() → BLOCKED; a planted wallet file → FileNotFoundError; call_model still works and is metered.

Residual: prompt-based exfiltration. The agent can embed the nonce or the task text into a legitimate prompt sent to the pinned model, reaching a confederate through the sanctioned channel. A network namespace cannot close this. It is bounded by running the validator's probe audit against a trusted pool.

Fail-closed enforcement

The production validator daemon is secure by default. It refuses to score anything it cannot gate:

An unset gate disqualifies, rather than silently accepting a tampered runtime. A governance_ready() preflight refuses to start the daemon at all until the owner has published the set on-chain. --insecure reverts to the mock/no-gate mode, for testnet only.

On-chain governance

The owner publishes a signed, rotatable record; validators read it every epoch:

{
  "version": 1,
  "runtime_measurements": ["<sha256>"],
  "mrtd": ["<hex>"],
  "rtmr": { "1": "<hex>", "2": "<hex>", "3": "<derived>" },
  "tcb_accept": ["UpToDate", "SWHardeningNeeded"],
  "pool_allow_list": ["openai/gpt-4o-mini", "..."],
  "probe_commit": "<sha256 of the secret probe bank>"
}

orchestra-koth-owner \
  --mrtd <mrtd_hex> --rtmr1 <rtmr1_hex> --rtmr2 <rtmr2_hex> \
  --pool "openai/gpt-4o-mini,anthropic/claude-opus-4.7" \
  --tcb-accept UpToDate,SWHardeningNeeded \
  --probe-bank ./probe_bank.json \
  --netuid 99 --wallet owner --network finney

Rotating the image or recovering TCB = publish a new record and bump --version. Old images stop being accepted at the next epoch.

Residual trust

Stated plainly, because a trust model with no stated residue is a marketing document:

• Hardware vendor root. Trust reduces to Intel's attestation root and the absence of a full hardware break (side channels, physical extraction).
• Owner-authored measured image. You trust that the published measurement corresponds to the audited, public runtime source.
• Measurement governance. A careless approval admits a lying runtime. This is an owner responsibility, on-chain and rotatable.
• Provider content + TLS. The pinned pool is trusted for content, not for cost — cost is metered in-enclave.
• Prompt-based exfiltration (above) is not closed by the sandbox.
• The fresh-probe is statistical, not a proof.
• The measured image is not yet built — until it is, enforcement does not discriminate between runtimes on a stock CVM.

Status

See also

• The KOTH Protocol — what the attested payload contains
• Confidential VM Setup — get a TDX box and run the attested miner