VoltageGPU evidence bundle: single-GPU RTX PRO 6000 Blackwell Server Edition, Intel TDX guest
Captured 2026-10-09 21:53:58 UTC from inside a VoltageGPU Confidential VM (SKU rtx6000b-small),
rented through the public API like any customer, by the proof run (scripts/proof-run/run.mts),
its first end-to-end run. The same job now repeats it weekly; later runs are published on
/verified/<id> pages and shown on the home page without a new folder here.

What this shows
  Both proofs, generated inside the VM on a fresh random challenge chosen by the tenant:
  1. An Intel TDX quote (v4, TEE 0x81, 4 940 bytes) whose report_data is the SHA-512 of the
     manifest, checked up to the pinned Intel SGX Root CA with the Intel collateral embedded
     in the bundle. Platform TCB UpToDate.
  2. NVIDIA GPU attestation tokens from NRAS whose eat_nonce is the SHA-256 of the same
     manifest: measurements ok, secure boot on, debug off, report signature and chain validated.
     GPU-0 GB20X, driver 595.71.05, vbios 98.02.9E.00.01.
  Verified OFFLINE, on the operator's machine, never on the VM, with voltage-verify 0.2.1:
    voltage-verify verify bundle.json --offline --challenge 627ba9c5... --hwmodel GB20X --gpus 1
  RESULT: VERIFIED, 14 of 14 checks (verify.txt). The same bundle with a wrong challenge:
    RESULT: NOT VERIFIED (manifest.challenge)            (verify-wrong-challenge.txt)
  Public result page, re-checked by the website verifier, bundle downloadable:
    https://voltagegpu.com/verified/lDf9-pBDNN9pB6azPSEyMg

Environment read inside the guest (conf-compute.txt, gpu.txt, kernel.txt)
  systemd-detect-virt: kvm, /dev/tdx_guest present, kernel 6.8.0-110-generic
  nvidia-smi conf-compute: CC State ON, Multi-GPU Mode None, CPU CC INTEL TDX,
  GPU CC Capable, CC GPUs Ready State Ready
  Protected memory 99 463 296 KiB, unprotected 0 KiB
  GPU: NVIDIA RTX PRO 6000 Blackwell Server Edition, 595.71.05, 98.02.9E.00.01, 97887 MiB

How it ran (base https://api.voltagegpu.com, header X-API-Key, a test account)
  1. GET  /api/confidential/vm/tiers           rtx6000b-small, 3.80 $/h, attestation verified
  2. POST /api/confidential/vm/deploy          21:51:34 UTC, one hour (3.80 $) prepaid
  3. GET  /api/volt/pods                       polled until ssh_ready, 126 s
  4. ssh ubuntu@<vm> 'bash -s' < ../two-proofs-in-the-vm.sh
                                                19 s, output in in-the-vm.txt
                                                (voltage-verify 0.2.0 from PyPI inside the VM)
  5. files copied out over SSH; SHA256SUMS, computed in the VM, re-checked here
  6. POST /api/volt/pods/{id}/stop             21:54:15 UTC, 161 s of VM time,
                                                refund 3.63 $, net 0.17 $ at the customer price
                                                (about 0.08 $ of provider time)
     workload confirmed deleted at the provider (no longer listed, 0 replicas)
  7. voltage-verify 0.2.1 with --offline, on the operator's machine: RESULT: VERIFIED
  8. bundle uploaded through https://voltagegpu.com/verify/share -> /verified/lDf9-pBDNN9pB6azPSEyMg

What we found
  The first attempt, six minutes earlier, stopped inside the VM at line 16 of the published
  script: "set: pipefail: invalid option name". The copy of two-proofs-in-the-vm.sh served on
  voltagegpu.com had Windows line endings (CRLF), so bash read "pipefail" plus a carriage
  return. Anyone who downloaded the script and piped it into a VM hit the same wall. The same
  conversion had changed the bytes of the served evidence files, so the files of
  ../rtx6000b-2026-09-17/ no longer matched their published SHA256SUMS. Both fixed on
  2026-10-09: scripts are served with LF and evidence folders byte for byte (.gitattributes).
  That attempt cost 0.16 $ at the customer price (148 s of VM time), stopped and refunded the
  same way.

Files
  manifest.json              the manifest with the random challenge (voltage-verify manifest --challenge auto)
  bundle.json                TDX quote + NVIDIA NRAS tokens bound to that manifest
  verify.txt                 offline verification output, computed outside the VM
  verify-wrong-challenge.txt the same bundle checked against a challenge it was not made for
  in-the-vm.txt              what the published script printed inside the VM
  conf-compute.txt           nvidia-smi conf-compute -q and -gm
  gpu.txt                    nvidia-smi name, driver, vbios, memory
  kernel.txt                 uname -r, /dev/tdx_guest, systemd-detect-virt
  SHA256SUMS                 checksums computed inside the VM before download

Reproduce on your machine
  pip install voltage-verify    (0.2.1 or later: 0.2.0 and earlier trusted the NVIDIA signing
                                 keys a bundle carried, see the 0.2.1 changelog)
  voltage-verify verify bundle.json --offline --challenge 627ba9c51d4719038e917c7431675b183ac576c819d712178dc8a100f4409a45
  A wrong --challenge answers NOT VERIFIED. Without --offline the Intel collateral is fetched
  from Intel PCS instead of read from the bundle. Or upload bundle.json on /verify/share.

Limits, stated plainly
  In this run the challenge was drawn inside the VM by the published script (--challenge auto),
  then passed to verify --challenge. From the next weekly run on, it is drawn on the verifying
  machine and passed into the VM (CHALLENGE=...), so a VM could not even replay an older bundle;
  the script accepts it since 2026-10-09.
  This is one GPU. On 8-GPU nodes NVIDIA runs Protected PCIe mode and the NVSwitch fabric is
  not verified from inside a TDX guest (see ../nscq-retest-2026-09-19-10h11/). Earlier runs of
  the same SKU: ../rtx6000b-2026-09-17/ and ../rtx6000b-api-2026-09-17/. Every published run
  is listed in ../runs.json.

Checksums (sha256)
  computed in the VM before download (SHA256SUMS):
  1d24e25c7623367d3d71082fae1f22e4f755a3c39fd9e82ef491b6e14beb506b  manifest.json
  cbe67c5fc88cf618e7dcfef6eaf31c3a23ee92a4b47e923f2f63e3f19ecc106b  bundle.json
  917204776869f0028b6b82cad452b6cabaf0aef737ae571b6ff7aed6b4435e05  conf-compute.txt
  bf8c6451fe67ebdf7431c470b5ecc2f6367f7eb9e03e3251bfed59f33aa4bf5e  gpu.txt
  c35ba3226e0e135835aceb296639a9a7ee0a16ad95d2caa7dd364a3db096dcb1  kernel.txt
  computed on the verifying machine:
  9ce95753a665965d785ef3387ce671fa2b5d1cdc354bf3c855bc649315e0bd69  verify.txt