DEV Community: VoltageGPU

What a tenant can check on an H100 confidential VM in under 4 minutes

VoltageGPU — Wed, 28 Oct 2026 13:36:54 +0000

On 28 October 2026 at 11:11 UTC (12:11 in Paris), we rented a single-GPU NVIDIA H100 Confidential VM (Intel TDX) through our public API, with one of our test accounts, for our weekly attestation proof. Inside it we produced an Intel TDX quote and an NVIDIA GPU attestation on a challenge drawn outside the VM. We stopped the VM after 203 seconds and verified the bundle offline, on another machine, with voltage-verify 0.2.3, our open-source verifier. Fifteen checks passed, none failed, no warnings.

What ran, and when

Times are UTC, from the run log. The deploy request left at 11:11:03. Most of the 203 seconds went to provisioning and boot: the VM reported running at 154 s and SSH answered at 158 s. Our published script then ran inside for 28 seconds, installing voltage-verify and producing both attestations. Files were out at 201 s, the API stop came at 203 s, and the offline verification ran on our machine at 11:14:30. From deploy request to verdict: 3 minutes 27 seconds.

One challenge, two hashes

Our runner drew 32 random bytes on its own machine and passed them in over SSH:

ssh ubuntu@<vm> "CHALLENGE=<hex> bash -s" < two-proofs-in-the-vm.sh

In the VM, voltage-verify manifest wrote this file around the challenge. It is complete:

{
  "challenge": "45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85",
  "created_at": "2026-10-28T11:14:03+00:00",
  "format": "voltage-verify-manifest/1",
  "statement": null,
  "workload": {
    "artifacts": [],
    "extra": {},
    "image": null
  }
}

The tool serializes it canonically (sorted keys, no spaces, UTF-8) and hashes it twice. The SHA-512 becomes the 64-byte report_data of the TDX quote. The SHA-256 is the nonce sent to NVIDIA's Remote Attestation Service (NRAS), which signs it back as eat_nonce. From the script's output in the VM:

commitment256    931334dd9e84418be8c805dda9bdec1f6514d9a8fa794504f6ad787d1dbb02ec   (NVIDIA nonce)
commitment512    4b640c4650dd729d197db4c48b666b9c3085c2f0c69b93918ec0f68bd04fc7e1...   (TDX report_data)
[...]
Nonce generated: 931334dd9e84418be8c805dda9bdec1f6514d9a8fa794504f6ad787d1dbb02ec
[...]
**** Attestation Successful ****
bundle written to bundle.json (single-gpu, 4940-byte quote)

No bundle made before this challenge existed, or for another one, can carry these values.

Re-run the check on your machine

You need Python 3.10 or later. We re-ran all of this the same day, between 11:42 and 12:00 UTC, on a Windows 11 PC, in Git Bash and a fresh virtual environment (Python 3.12.4). On Linux or macOS, type python3 where we typed python.

$ pip install "voltage-verify>=0.2.3"
[...]
Successfully installed cffi-2.1.1 cryptography-50.0.2 pycparser-3.12 pyjwt-2.15.1 voltage-verify-0.2.3
[...]
$ curl -fsSL -o bundle.json https://voltagegpu.com/verified/G4j3YHRBzc16tqt85IAvXg/bundle.json
$ sha256sum bundle.json
ed439c93ad318973b0917514d2b328ec3fa149fc8fe542acd764375ca0b1b089 *bundle.json
$ voltage-verify verify bundle.json --offline --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 --hwmodel GH100 --gpus 1
[PASS] manifest.format       manifest is well formed
[PASS] manifest.commitments  bundle commitments match the manifest
[PASS] manifest.challenge    challenge is the one this verifier issued
[PASS] tdx.structure         TDX quote v4, TEE 0x81, 4940 bytes
[PASS] tdx.debug             TD attributes 0000001000000000 (0x10000000), DEBUG (bit 0) off: not a debug TD
[PASS] tdx.report_data       quote report_data equals SHA-512 of the manifest
[PASS] tdx.signatures        attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral        TCB info and QE identity signed by Intel (bundle (fetched 2026-10-28T11:14:07+00:00))
[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
[PASS] tdx.revocation        PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation        PCK CA certificate not revoked (0 entries in CRL)
[PASS] nvidia.signatures     2 NVIDIA-signed tokens verify, keys from the bundle chained to a pinned NRAS intermediate (offline)
[PASS] nvidia.nonce          NRAS eat_nonce equals SHA-256 of the manifest
[PASS] nvidia.policy         overall result true, every GPU: measurements ok, secure boot on, debug off, nonce matched, report signature and chain validated
[PASS] nvidia.freshness      token issued 2s from bundle creation

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate
GPU: GPU-0 GH100 driver 595.71.05 vbios 96.00.CF.00.01 measurements success

RESULT: VERIFIED

The output matches, line for line, what our runner printed at 11:14:30. The page serves a 30,412-byte copy that keeps only the NVIDIA key that signed the tokens; the 577,850-byte original from the VM carries all 212 keys NRAS listed and gives the same fifteen lines.

Two bindings can be checked without our tool: the manifest hashes, and bytes 568 to 631 of the raw quote, where TDX keeps report_data. The signature checks still need the tool.

$ python -c "import json,hashlib;m=json.load(open('bundle.json'))['manifest'];c=json.dumps(m,sort_keys=True,separators=(',',':'),ensure_ascii=False).encode();print(hashlib.sha256(c).hexdigest());print(hashlib.sha512(c).hexdigest())"
931334dd9e84418be8c805dda9bdec1f6514d9a8fa794504f6ad787d1dbb02ec
4b640c4650dd729d197db4c48b666b9c3085c2f0c69b93918ec0f68bd04fc7e18d2206b8b142286030ad788ebc91b749b17421f17a20a0396ac2bb452fbb5a3d
$ python -c "import json,base64;s=json.load(open('bundle.json'))['tdx']['quote_b64'];q=base64.b64decode(s+'='*(-len(s)%4));print(q[568:632].hex())"
4b640c4650dd729d197db4c48b666b9c3085c2f0c69b93918ec0f68bd04fc7e18d2206b8b142286030ad788ebc91b749b17421f17a20a0396ac2bb452fbb5a3d

Change one character of the challenge and the verdict flips, with exit code 1. The selftest goes further: it tampers with the bundle nine ways, from a manifest field to NVIDIA tokens re-signed with an attacker's key, and passes only if every copy is rejected.

$ voltage-verify verify bundle.json --offline --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b86 --hwmodel GH100 --gpus 1 | grep -E "FAIL|RESULT"
[FAIL] manifest.challenge    challenge differs from the one this verifier issued (replay or foreign bundle)
RESULT: NOT VERIFIED (manifest.challenge)
$ voltage-verify selftest bundle.json --offline --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 | tail -1
SELFTEST: PASS

What the fifteen lines say

Three concern the manifest. manifest.format and manifest.commitments are bookkeeping: anyone can recompute those hashes. manifest.challenge compares the challenge with the one you pass. It counts only because the hardware lines bind the same manifest.

Eight are Intel's. tdx.structure says the blob is a version 4 TDX quote, not where it came from. tdx.signatures answers that, chaining the attestation key, the Quoting Enclave report and the platform's PCK certificate up to the Intel SGX Root CA pinned in the tool. tdx.report_data ties the quote to the manifest hash, and through it to the challenge. tdx.debug reads bit 0 of the TD attributes: a debug trust domain lets the host read and modify its memory, and its quote gets signed all the same. tdx.collateral, tdx.tcb and both tdx.revocation lines rate the platform against Intel's signed TCB info, Quoting Enclave identity and revocation lists.

Four are NVIDIA's. nvidia.signatures checks the NRAS verifier token and the GPU-0 token against a key chained to an NVIDIA intermediate pinned in the tool, here GPU Intermediate 004. nvidia.nonce finds the manifest's SHA-256 in them. nvidia.policy reads NVIDIA's verdict: measurements match reference values, secure boot on, debug off, and exactly one GH100, as --hwmodel GH100 --gpus 1 demands. nvidia.freshness wants the token issued within 15 minutes of the bundle's creation; the gap was 2 seconds.

The result page reads "13 / 13" because the site runs its own, stricter variant: it skips manifest.format and the challenge check (it cannot know which challenge you issued), merges the two revocation lines and adds nvidia.binding, which confirms the GPU token is the one NVIDIA's verifier token names by digest.

What this does not prove

The workload. This manifest names no image and no files. The run proves hardware and freshness, nothing about what ran. Even with an image digest in the manifest, checked with --image-digest, both proofs carry a hash of your description of the workload, not of the code the GPU executed. Closing that gap takes a measured launch that extends a TDX runtime register with the workload's measurement; in this quote, RTMR3 is still all zeros.

The boot image. MRTD and RTMR0 to RTMR2 measure the VM's initial state and boot chain. Nothing in the check compares them to a reference; matching them to an image you trust is your policy.

One machine. The quote and the NVIDIA tokens are linked only by the manifest hash they both carry. Nothing in the bundle proves this GPU sits in this trust domain.

Intel's verdict ages. --offline rates the platform with collateral captured at 11:14:07 UTC, whose nextUpdate is 27 November. Past that date the TCB line still says UpToDate and a warning is added. Our 12 September bundle (examples/hello-workload/ in the voltage-verify repository), checked offline today:

[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
[WARN] tdx.collateral_fresh  Intel collateral is past its nextUpdate; refetch online

Drop --offline to ask Intel's servers instead:

$ voltage-verify verify bundle.json --challenge 45a8c6a338042b0012d5dbd51954555376e6cd71015ddd607fb820bfd7dd2b85 --hwmodel GH100 --gpus 1 | grep -E "collateral|tcb|RESULT"
[PASS] tdx.collateral        TCB info and QE identity signed by Intel (Intel PCS, fetched now)
[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
RESULT: VERIFIED

What the VM says about itself. The bundle records nvidia-smi inside the VM: CC State ON, Multi-GPU Mode None. Software wrote that and nobody signed it. The same goes for the check we ran inside the VM; the one that counts ran outside.

The host. The evidence names Intel and NVIDIA hardware, not a company. Whoever runs the host can still stop the VM or cut its network, and the evidence says nothing about the minutes after 11:14 UTC.

Several GPUs. This is one GPU. On 8-GPU nodes the GPUs run in NVIDIA's multi-GPU Protected PCIe mode. We have verified per-GPU attestation there on 8x H100 only, and the NVSwitch fabric is not verified from inside the TDX guest.

Whose challenge. Only whoever drew a challenge knows it was fresh. For the one on our page, you have our word and nothing more. The strong version of this check is to rent a VM and draw your own.

On your own VM

The script is public: https://voltagegpu.com/blog/two-proofs/evidence/two-proofs-in-the-vm.sh. Draw the challenge on your machine, pass it as CHALLENGE, copy /tmp/proofs.tgz out and verify against your challenge. voltage-verify is MIT-licensed, at https://github.com/VoltageGPU/voltage-verify. When we wrote this, our public pricing feed listed the single-H100 tier at $6.95 per hour, billed per second.

This run's result page, with the bundle: https://voltagegpu.com/verified/G4j3YHRBzc16tqt85IAvXg

Drafted with AI assistance from the run's logs and files, then checked: every command above was re-run on 28 October 2026 and its output compared line by line.

Check an 8-GPU Node Before a Multi-Day Training Run

VoltageGPU — Tue, 27 Oct 2026 13:50:59 +0000

Key Takeaways

One command, about ten minutes. hwcheck.sh --acceptance checks the NVLink mesh, GPU-to-GPU and NCCL bandwidth, five minutes of full load, ECC and Xid errors, and what a previous tenant left. Exit code 0 is PASS, 1 is WARN, 2 is FAIL.
A real run, 24 October 2026. A production 8x H100 SXM bare metal node passed all 17 lines in 7 minutes, PyTorch download included: 387 to 391 GB/s per GPU pair, 478.5 GB/s of NCCL bus bandwidth, 669 to 689 TFLOPS bf16 per GPU, 69 C at most.
Ten minutes is not three days. A PASS covers the faults that show at once. It says nothing about an Xid at hour 30, a problem between nodes, or the firmware.

Before you start a training run of several days on a rented 8-GPU machine, run one read-only command on it:

On the node

curl -fsSL https://voltagegpu.com/hwcheck.sh | bash -s -- --acceptance --gpus 8 --bare-metal

It takes about ten minutes and prints one verdict line per measure (PASS, WARN or FAIL, 17 lines on an 8x H100 SXM node) in six blocks: topology, P2P, NCCL, load, errors and hygiene. The script is hwcheck, open source under the MIT license (github.com/VoltageGPU/hwcheck). It runs on any provider, on bare metal or in a VM.

On 24 October 2026 we ran it on a production 8x H100 SXM bare metal node rented through our public API, a few minutes after installing the NVIDIA driver on it. This tutorial goes through that run line by line, with the threshold behind each verdict, then its limits. Every output below is copied from the published files. The commands a reader runs (help, download, checksums) were run again on 24 October 2026 at 16:48 UTC, on Ubuntu 24.04 under WSL2, in a fresh directory.

Why test the node before a run of several days

Because what usually ruins a long job in its first hours can be seen in ten minutes, before you have paid for those hours. The acceptance test looks for:

A GPU off NVLink, or a link down. A GPU off NVLink talks to the others over PCIe, which tops out at 64 GB/s on Gen5 x16: 14% of the 450 GB/s per direction of NVLink on H100 SXM. A link down leaves a pair with fewer NVLinks than the model has.
A card at x8 instead of x16. That halves its PCIe bandwidth, and it is usually a badly seated card or riser.
A GPU that overheats, slows down or computes wrong. The load test compares the bits of repeated products, so silent data corruption shows as a FAIL.
ECC errors or a pending row remap. A pending remap means the GPU needs a reset.
Files from a previous tenant. If a previous tenant's credentials are still on the machine, whoever comes after you would find yours the same way.

On the node below the test took 425 seconds. At the public price of that machine ($49.80 per hour), that is about $5.88.

Before the test: install the NVIDIA driver and Fabric Manager

A bare Ubuntu image has no NVIDIA driver, so no test can see the GPUs. On NVSwitch boards such as HGX 8x H100, CUDA also does not start without NVIDIA Fabric Manager. Our bare metal is delivered that way: Ubuntu 24.04, login as ubuntu with sudo, no NVIDIA driver. On a node we rented earlier that day (13:05 UTC, another hostname), the listing check run before any driver printed this:

Command

curl -fsSL https://voltagegpu.com/hwcheck.sh | bash -s -- --gpu H100 --gpus 8

Output (hwcheck.txt, 24 October 2026)

VoltageGPU hardware check (read-only, nothing about this machine is sent anywhere)
  2026-10-24 13:05 UTC · bm-06e585be

                 LISTED                   MEASURED                           
  GPU            H100                     no GPU visible (nvidia-smi failed) DOES NOT MATCH
  CUDA compute                            not tested (no PyTorch)            info
  CPU                                     192 threads                        info
  RAM            -                        2015 GB                            info
  Disk (/)       -                        866 GB, 864 GB free                info
  Download                                613 Mbit/s (one stream)            info

RESULT: DOES NOT MATCH THE LISTING (no GPU visible)
Release the pod from your dashboard and write to contact@voltagegpu.com with this output.

On a bare node, that verdict only means the driver is missing. The last line is the tool's generic advice for any mismatch (raw output).

One script installs the driver and Fabric Manager, both pinned to the same version:

On the node, as ubuntu (sudo) or root

curl -fsSL https://voltagegpu.com/dedicated-setup.sh | bash

Read it before you pipe it into bash: dedicated-setup.sh is 137 lines. What it does, according to its own header and code:

It stops unless the machine runs Ubuntu 24.04 on x86_64, has at least one NVIDIA GPU on the PCI bus, has Secure Boot off (the kernel would refuse the modules that DKMS builds) and has no NVIDIA driver of another version already loaded.
It installs NVIDIA's repository key, cuda-keyring 1.1-1, after checking its SHA-256, then a version pin, then nvidia-open 595.112.07 (driver branch R595, open kernel modules built by DKMS) and, on NVSwitch boards only, nvidia-fabricmanager 595.112.07.
From Ubuntu it adds the running kernel's headers and compiler, python3-venv and pciutils, which the acceptance test uses.
It starts Fabric Manager and the persistence daemon, then waits until every GPU reports its fabric as Completed / Success.
Exit code 0 means ready, 1 an error (the last lines say why), 3 a reboot is needed, then run it again. It is safe to run again: what is done stays done.

On 24 October 2026, on the node tested below, the script printed:

The script's own lines (apt and DKMS output: 01c-dedicated-setup.txt)

[15:43:43] VoltageGPU dedicated setup: driver 595.112.07; 8 NVIDIA GPU(s) and 4 NVSwitch(es) on the PCI bus; kernel 6.8.0-139-generic
[15:43:43] 1/5 cuda-keyring from https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64
[15:43:43] 2/5 package lists, version pin, kernel headers, gcc gcc-13, python3-venv, pciutils
[15:43:57] 3/5 nvidia-open=595.112.07-1ubuntu1 nvidia-fabricmanager=595.112.07-1ubuntu1 (the DKMS build of the kernel modules takes a few minutes)
[15:44:41] 4/5 kernel modules
[15:45:27] 5/5 services
[15:45:52] ready in 2 min 12 s: 8 GPUs, driver 595.112.07, fabric Completed / Success on every GPU, Fabric Manager active, persistence Enabled
[15:45:52] next: nvidia-smi topo -m (NV18 between every pair on 8x H100 SXM), then the acceptance test:
[15:45:52]   curl -fsSL https://voltagegpu.com/hwcheck.sh | bash -s -- --acceptance --gpus 8 --bare-metal

2 min 12 s, with a caveat written in the evidence README: it was the second attempt, and the 358 MB of NVIDIA packages came from the apt cache of the first one, which had downloaded 365 MB in 14 s. Count about 15 s more on a fresh machine. The first attempt failed at the DKMS build, because NVIDIA's dkms package only recommends gcc and that version of the script installed packages without their recommendations. The current script installs gcc explicitly. The failed log, the cleanup and the first script are published too (files 01a, 01b and dedicated-setup-first-version-failed.sh). We have run the script on one node, ours.

Run the acceptance test

Run it once the driver is in, before you copy data or start the job. --gpus 8 makes it fail if fewer than 8 GPUs are visible. --bare-metal makes it fail if a hypervisor is detected; leave it out on a VM. The options, as the served script prints them:

Command

curl -fsSL https://voltagegpu.com/hwcheck.sh | bash -s -- --acceptance --help

Output

usage: acceptance.sh [--quick] [--burn-seconds N] [--gpus N] [--bare-metal] [--no-install] [--out DIR]
  --quick            skip the 5-minute load test (about 2 minutes instead of 10)
  --burn-seconds N   length of the load test in seconds, 10 to 3600 (default 300)
  --gpus N           GPU count of the listing: FAIL if fewer are visible
  --bare-metal       the listing says bare metal: FAIL if a hypervisor is detected
  --no-install       never download PyTorch; the tests that need it are skipped without it
  --out DIR          where to write the report files (default: the current directory)

What happens when you run it:

hwcheck.sh downloads hwcheck-acceptance.sh and runs it only if its SHA-256 matches the one pinned in hwcheck.sh. From a clone of the repository, it uses the acceptance.sh next to it.
If the image has no PyTorch that sees the GPUs, it installs a pinned build into a temporary directory, about 3 GB from download.pytorch.org, matched to the driver's CUDA version. The directory is removed at exit, Ctrl-C included. That download is the only network traffic. --no-install forbids it: on an image without PyTorch, the tests that need it are then skipped, and the result is WARN.
It writes three files in the current directory, or in --out: hwcheck-acceptance-<UTC time>.txt (what you saw), .json (every value) and .sha256 (the SHA-256 of both, to show later that the report was not edited).
Exit code 0 is PASS, 1 is WARN (read those lines before a long job), 2 is FAIL (do not start a long job there), 64 is a bad option.
Root is best: as another user, the lines it could not check say so.

On 24 October the same test ran from a copy of the repository at commit d13bd29, as user ubuntu:

Command

cd ~ && bash ~/hwcheck/hwcheck.sh --acceptance --gpus 8 --bare-metal --out ~/hwcheck-out

Console on the node (the first line is from our harness)

# started 2026-10-24 15:46:53 UTC, finished 2026-10-24 15:53:58 UTC, 425 s, exit 0
. VoltageGPU hwcheck acceptance test 1.1, about 10 minutes; nothing is sent anywhere
. PASS  GPUs: 8x NVIDIA H100 80GB HBM3
. PASS  Previous tenant: nothing found in the home directories, /tmp, /var/tmp and /workspace; not readable: /root (run as root to include it)
. PASS  SSH keys: 1 key can log in (ubuntu: 1)
. PASS  GPUs idle at start: no compute process, no GPU memory in use
. PASS  NVLink mesh: 56/56 GPU pairs on NV18 (NV18 expected on H100 SXM)
. PASS  NVSwitch: 4 NVSwitch chips visible (4 on an 8-GPU H100 SXM board)
. PASS  Fabric state: Completed / Success on 8/8 GPUs
. PyTorch not found: installing torch 2.14.1 (cu130) from download.pytorch.org into /tmp/hwcheck-acceptance.kD0SLr (about 3 GB, deleted at the end)
. PASS  CUDA init: 8/8 GPUs in PyTorch 2.14.1+cu130 (installed for this run, cu130)
. PASS  P2P copies: slowest pair 387 GB/s (GPU 0>2), median 389 GB/s (FAIL under 112, WARN under 270: H100 SXM line rate 450 GB/s)
. PASS  NCCL all-reduce: bus bandwidth 478.5 GB/s on 8 GPUs (4 GiB, NCCL 2.30.7); H100 SXM: about 370 GB/s in ring, about 480 with NVLink SHARP, PASS from 340
. load test: 300 s of matrix multiplications on every GPU, nvidia-smi read every 5 s
. PASS  Throughput: 8/8 GPUs ran it, median 684 TFLOPS (bfloat16), slowest GPU 2 at 669
. PASS  Thermal / power: max 69 C (GPU 2), no thermal or hardware slowdown; at the power cap in 95% of the samples (normal under full load)
. PASS  Clocks: median SM clock 1368 MHz, every GPU between 1335 and 1380 MHz, at least 90% busy
. PASS  PCIe links: Gen5 x16 on 8/8 GPUs under load, host-to-GPU copies 53.1 to 55.5 GB/s
. PASS  ECC / memory: ECC on 8/8 GPUs, no uncorrected error, nothing pending, 0 corrected since the driver loaded
. PASS  Kernel log (Xid): no Xid during the test, read with journalctl
. PASS  Virtualization: none detected (systemd-detect-virt): bare metal, as listed

425 seconds in total, the PyTorch download included. After this run we raised two P2P thresholds, using its own measurements (details in block 2, commit 4abbd70). The scripts served today carry those thresholds, so they are not byte for byte the copy that ran. With the current thresholds the same node still passes every line.

Read the result, block by block

Each line reads PASS, WARN or FAIL. N/A means the measure does not apply (no NVLink on a PCIe machine), INFO that it was measured without a reference to judge it, SKIP that it could not run, which makes the result WARN. The verdict lines of the 24 October report:

hwcheck-acceptance-20261024T154657Z.txt, verdict lines

  1 Topology  GPUs                PASS  8x NVIDIA H100 80GB HBM3
              NVLink mesh         PASS  56/56 GPU pairs on NV18 (NV18 expected on H100 SXM)
              NVSwitch            PASS  4 NVSwitch chips visible (4 on an 8-GPU H100 SXM board)
              Fabric state        PASS  Completed / Success on 8/8 GPUs
              PCIe links          PASS  Gen5 x16 on 8/8 GPUs under load, host-to-GPU copies 53.1 to 55.5 GB/s
  2 P2P       CUDA init           PASS  8/8 GPUs in PyTorch 2.14.1+cu130 (installed for this run, cu130)
              P2P copies          PASS  slowest pair 387 GB/s (GPU 0>2), median 389 GB/s (FAIL under 112, WARN under 270: H100 SXM line rate 450 GB/s)
  3 NCCL      NCCL all-reduce     PASS  bus bandwidth 478.5 GB/s on 8 GPUs (4 GiB, NCCL 2.30.7); H100 SXM: about 370 GB/s in ring, about 480 with NVLink SHARP, PASS from 340
  4 Load      Throughput          PASS  8/8 GPUs ran it, median 684 TFLOPS (bfloat16), slowest GPU 2 at 669
              Thermal / power     PASS  max 69 C (GPU 2), no thermal or hardware slowdown; at the power cap in 95% of the samples (normal under full load)
              Clocks              PASS  median SM clock 1368 MHz, every GPU between 1335 and 1380 MHz, at least 90% busy
  5 Errors    ECC / memory        PASS  ECC on 8/8 GPUs, no uncorrected error, nothing pending, 0 corrected since the driver loaded
              Kernel log (Xid)    PASS  no Xid during the test, read with journalctl
  6 Hygiene   Previous tenant     PASS  nothing found in the home directories, /tmp, /var/tmp and /workspace; not readable: /root (run as root to include it)
              SSH keys            PASS  1 key can log in (ubuntu: 1)
              GPUs idle at start  PASS  no compute process, no GPU memory in use
              Virtualization      PASS  none detected (systemd-detect-virt): bare metal, as listed

RESULT: PASS

Block	8x H100 SXM, 24 Oct 2026	FAIL when (H100 SXM)
1 Topology	NV18 on 56/56 pairs, 4 NVSwitch, fabric ready, Gen5 x16	fewer GPUs than --gpus, a pair over PCIe, or a GPU under load narrower than both ends allow
2 P2P	387 to 391 GB/s per pair, median 389	bytes differ, no peer access, or a pair under 112 GB/s (25% of 450)
3 NCCL	478.5 GB/s bus bandwidth	under 185 GB/s (PASS from 340)
4 Load	669 to 689 TFLOPS bf16, 69 C max, no thermal or hardware slowdown	a GPU fails to run or returns other bits for the same product; hardware thermal slowdown or power brake in 5% of samples
5 Errors	ECC on, 0 corrected, no Xid	an uncorrected error, a pending remap, or a hardware Xid during the test
6 Hygiene	nothing left, 1 SSH key, GPUs idle, no hypervisor	credential files found, or a hypervisor with `--bare-metal`

1. Topology: is every GPU on NVLink?

On an 8x H100 SXM board, nvidia-smi topo -m must read NV18 for all 56 GPU pairs. It did:

From the report

nvidia-smi topo -m:
        GPU0    GPU1    GPU2    GPU3    GPU4    GPU5    GPU6    GPU7    CPU Affinity    NUMA Affinity   GPU NUMA ID
    GPU0         X      NV18    NV18    NV18    NV18    NV18    NV18    NV18    0-23,96-119     0               N/A
    GPU1        NV18     X      NV18    NV18    NV18    NV18    NV18    NV18    0-23,96-119     0               N/A
    GPU2        NV18    NV18     X      NV18    NV18    NV18    NV18    NV18    0-23,96-119     0               N/A
    GPU3        NV18    NV18    NV18     X      NV18    NV18    NV18    NV18    24-47,120-143   1               N/A
    GPU4        NV18    NV18    NV18    NV18     X      NV18    NV18    NV18    48-71,144-167   2               N/A
    GPU5        NV18    NV18    NV18    NV18    NV18     X      NV18    NV18    48-71,144-167   2               N/A
    GPU6        NV18    NV18    NV18    NV18    NV18    NV18     X      NV18    48-71,144-167   2               N/A
    GPU7        NV18    NV18    NV18    NV18    NV18    NV18    NV18     X      72-95,168-191   3               N/A

The legend of nvidia-smi reads NV# = Connection traversing a bonded set of # NVLinks (04-nvidia-smi-topo.txt). The rules: on SXM boards (H100, H200, A100, B200, B300) every pair must read NV followed by a number. A pair that reads SYS, NODE, PHB, PXB or PIX goes over PCIe: FAIL. A pair with fewer links than the model has (18 on H100, H200, B200 and B300, 12 on A100) has a link down: WARN.

The same block counts the NVSwitch chips with lspci (4 expected on H100 and H200 boards, 6 on A100), reads the fabric state of every GPU (WARN unless Completed / Success), and keeps the best PCIe link seen during the tests, because an idle GPU drops to Gen1:

From the report

PCIe links, best generation and width seen:
    GPU 0: Gen5 x16 seen (Gen5 x16 possible), under load, host-to-GPU copies 55.5 GB/s
    GPU 1: Gen5 x16 seen (Gen5 x16 possible), under load, host-to-GPU copies 53.2 GB/s
    GPU 2: Gen5 x16 seen (Gen5 x16 possible), under load, host-to-GPU copies 55.5 GB/s
    GPU 3: Gen5 x16 seen (Gen5 x16 possible), under load, host-to-GPU copies 53.1 GB/s
    GPU 4: Gen5 x16 seen (Gen5 x16 possible), under load, host-to-GPU copies 53.9 GB/s
    GPU 5: Gen5 x16 seen (Gen5 x16 possible), under load, host-to-GPU copies 54.3 GB/s
    GPU 6: Gen5 x16 seen (Gen5 x16 possible), under load, host-to-GPU copies 53.9 GB/s
    GPU 7: Gen5 x16 seen (Gen5 x16 possible), under load, host-to-GPU copies 55.3 GB/s

A GPU under load that runs narrower than both ends allow is a FAIL. A generation below the maximum under load, or host-to-GPU copies under 70% of the median GPU, is a WARN. Here every GPU ran at Gen5 x16, with 53.1 to 55.5 GB/s from pinned host memory.

2. P2P: how fast is each GPU pair?

Each pair moved 387 to 391 GB/s in one direction, median 389 GB/s: 86% of the 450 GB/s line rate of NVLink on H100 SXM. The test copies 256 MiB from every GPU to every other one, 20 times, and compares the bytes afterwards:

From the report

GPU-to-GPU copies in GB/s (row = source GPU, column = destination GPU):
    GPU0        -    389    387    390    388    389    388    388
    GPU1      390      -    389    390    388    389    388    388
    GPU2      389    389      -    387    388    389    389    389
    GPU3      388    389    389      -    388    388    388    388
    GPU4      389    387    391    389      -    388    390    390
    GPU5      389    389    390    389    387      -    391    387
    GPU6      390    387    390    389    391    391      -    390
    GPU7      389    391    389    389    390    391    389      -

FAIL if bytes differ, if a pair lacks peer access on an NVLink mesh, or if a pair is under 25% of the line rate (112 GB/s on H100 SXM: under that, the pair is not really on NVLink). WARN if the median pair is under 75% of the line rate, or if one pair is under 90% of the median. The line rate is half the two-way figure of NVIDIA's datasheets: 900 GB/s for H100 SXM and H200 SXM, 600 GB/s for A100 SXM, 1.8 TB/s for B200 and B300, so 450, 300 and 900 GB/s per direction.

The report says "WARN under 270": that was 60% of the line rate, the rule at the time. After this run, the median rule went to 75% and the pair rule from 80% to 90% of the median. The slowest pair here is at 99% of the median, so the node passes both.

3. NCCL: does an all-reduce reach the expected bandwidth?

On 8x H100 SXM, expect about 370 GB/s of bus bandwidth in ring and about 480 GB/s with NVLink SHARP. This node reached 478.5 GB/s. The test runs torch.distributed with NCCL, one process per GPU, 4 GiB of float32 per GPU, 20 iterations, and checks the values:

From the report

all-reduce of 4 GiB per GPU, 20 iterations: algorithm bandwidth 273.4 GB/s, 15709 us per all-reduce

Bus bandwidth is the figure nccl-tests reports. For an all-reduce, busbw = algbw × 2(n−1)/n, so 273.4 × 14 / 8, about 478.5 GB/s on 8 GPUs. NCCL maintainers at NVIDIA put effective NVLink at about 370 GB/s (20% protocol overhead on 450) and the all-reduce peak with NVLink SHARP at about 480 GB/s on large sizes (nccl-tests#212). In nccl-tests#290, a result of 476 GB/s "looks to be in the expected range for H100".

Thresholds: on H100 SXM and H200, PASS from 340 GB/s, FAIL under 185 (half the effective rate), WARN in between. PASS from 340 accepts a node without NVLink SHARP. On A100 SXM, PASS from 210 and FAIL under 115, from about 230 GB/s at 8 GB (nccl-tests#149). B200 and B300 read INFO: no reference yet.

4. Load: five minutes at full power

All eight GPUs ran bf16 matrix products for five minutes at 669 to 689 TFLOPS each, reached 69 C at most, and stayed at their power cap in 95% of the samples, which is normal. The test multiplies 8192 by 8192 bf16 matrices on every GPU at once and reads nvidia-smi every 5 seconds:

From the report

    GPU  samples  busy  max C  HBM C  SM MHz   max W  TFLOPS  slowdown samples: power cap / thermal / hw / brake
    0         60  100%     58     49    1365     702   687.0  57 / 0 / 0 / 0
    1         60  100%     65     56    1350     701   676.3  57 / 0 / 0 / 0
    2         60  100%     69     56    1335     700   669.2  57 / 0 / 0 / 0
    3         60  100%     58     49    1372     701   684.5  57 / 0 / 0 / 0
    4         60  100%     62     53    1380     701   684.6  57 / 0 / 0 / 0
    5         60  100%     65     59    1380     701   688.7  57 / 0 / 0 / 0
    6         60  100%     65     55    1365     702   683.3  57 / 0 / 0 / 0
    7         60  100%     60     51    1380     701   682.9  58 / 0 / 0 / 0

Throughput. FAIL if a GPU does not run, returns non-finite values, returns other bits for the same product (silent data corruption), or runs under half the median GPU. WARN under 85% of the median, or if a GPU computes another result than an identical GPU.
Thermal and power. FAIL if hardware thermal slowdown or the power brake is active in 5% of the samples or more on a GPU. WARN on any thermal slowdown, any hardware slowdown, a power limit set under the GPU's default, or a GPU 10 C hotter than the median GPU.
Clocks. WARN if a GPU's median SM clock is under 85% of the median GPU, or if a GPU is under 90% busy.

The power cap column is not a warning: under a full matrix load an H100 runs at its power limit (up to 702 W here), as designed. The warning signs are the thermal, hw and brake columns, all at zero. GPU 2 was the hottest (69 C, for a median of 63.5 C) and the slowest (669 TFLOPS, about 98% of the median), inside the rules.

5. Errors: ECC and Xid

No uncorrected ECC error, nothing pending, 0 corrected errors since the driver loaded, and no Xid in the kernel log during the test. The test reads the ECC counters (volatile: since the driver loaded; aggregate: lifetime), retired pages and remapped rows, before and after the other tests.

ECC / memory. FAIL on any uncorrected error since the driver loaded, a pending row remap or page retirement (the GPU needs a reset), or a failed remap. WARN on ECC disabled, corrected errors during the test, lifetime uncorrected errors, or retired or remapped rows.
Kernel log (Xid). Read with dmesg, else journalctl -k, else sudo -n dmesg. FAIL on a hardware Xid during the test (48, 62, 64, 74, 79, 92, 94, 95, 119, 120 and 140 in NVIDIA's Xid catalog). WARN on another Xid during the test, or a hardware Xid earlier in the same boot.

The driver had been loaded a few minutes before, so "0 corrected since the driver loaded" covers a short window. The JSON report also holds the lifetime counters: 0 corrected and 0 uncorrected on all eight GPUs, and no remapped row.

6. Hygiene: did a previous tenant leave anything?

Nothing was found in the home directories, /tmp, /var/tmp and /workspace. One SSH key could log in, no process was on the GPUs, and systemd-detect-virt found no hypervisor.

Previous tenant. The test looks for credential files, shell histories, ML caches, model files, files in a home directory, and /tmp files older than the current boot. It records paths and dates only, never contents. FAIL on credential files (.netrc, .git-credentials, cloud and registry credentials, a Hugging Face token, private SSH keys). WARN on anything else.
SSH keys. WARN if more than one key can log in; their fingerprints are in the report.
GPUs idle at start. WARN if a process, or more than 2 GiB of memory, is already on a GPU.
Virtualization. INFO. With --bare-metal, FAIL if a hypervisor is detected.

The run was made as ubuntu, so /root was not searched, and the line says so. Run as root to include it.

What this proves, and what it does not

Shown by the published run, on that node, on 24 October 2026 between 15:46 and 15:53 UTC:

The driver reported eight H100 80GB HBM3 GPUs on a complete NV18 mesh, with 4 NVSwitch chips and the fabric ready on every GPU.
Every GPU pair copied 387 to 391 GB/s with the bytes intact, and an 8-GPU NCCL all-reduce reached 478.5 GB/s.
All eight GPUs computed bf16 matrix products at full power for five minutes, with no change of bits for the same product, no thermal or hardware slowdown, at Gen5 x16.
No ECC error, no Xid, nothing left in the usual places by a previous tenant, no hypervisor detected.

Not shown:

That the node will hold for days. Failures that come after hours, such as an Xid 79 at hour 30 or slowly growing ECC counts, need monitoring during the job.
Anything between machines. There is no InfiniBand or Ethernet test, only what happens inside the node.
Storage, CPU or RAM performance.
That the disk was wiped. The search looks in the usual places only, deleted files can survive in unwiped blocks, and other volumes are not searched. On our bare metal, the drives are wiped by the operator between tenants, and you cannot verify that it happened.
The BMC and the firmware. You cannot read the BMC or its firmware from the OS, and we publish no measurement of them. The GPU VBIOS and system firmware versions can be read, but nothing attests them.
Anything against a host determined to lie. The test reads what the driver reports, and whoever controls the machine can change that.
Exact figures. Bandwidths come from PyTorch (copy engines, the NCCL bundled with PyTorch) and can differ by a few percent from cuda-samples or nccl-tests.
Other nodes and other models. One node is one sample. The H100 SXM thresholds come from this run; the H200, A100 SXM, B200 and B300 values are still provisional, from NVIDIA's figures only.
That the published files are the unedited output of a real run. They are plain text with checksums we computed, not signatures (next section).
Confidentiality. Bare metal is not confidential: its memory is not encrypted against the operator. Need the data sealed from the operator? Use a Confidential VM (Intel TDX, attestation you verify yourself).

Re-check the published files

Download the evidence folder, check it against its SHA256SUMS, then compare the report with the copy in the public repository. Run on 24 October 2026 at 16:48 UTC:

Commands

mkdir bm-8xh100 && cd bm-8xh100
BASE=https://voltagegpu.com/blog/hwcheck/evidence/bm-8xh100-2026-10-24-setup
curl -fsSO "$BASE/SHA256SUMS"
for f in $(awk '{print $2}' SHA256SUMS); do curl -fsSO "$BASE/$f"; done
sha256sum -c SHA256SUMS
sha256sum -c hwcheck-acceptance-20261024T154657Z.sha256

Output

00-probe.txt: OK
01a-dedicated-setup-first-version-failed.txt: OK
01b-purge-after-failed-first-version.txt: OK
01c-dedicated-setup.txt: OK
02-nvidia-smi.txt: OK
03-nvidia-smi-q-fabric.txt: OK
04-nvidia-smi-topo.txt: OK
05-nvidia-smi-nvlink-s.txt: OK
06-services-and-packages.txt: OK
07-hwcheck-files.txt: OK
07-hwcheck-listing.txt: OK
08-acceptance-console.txt: OK
README.txt: OK
dedicated-setup-first-version-failed.sh: OK
hwcheck-acceptance-20261024T154657Z.json: OK
hwcheck-acceptance-20261024T154657Z.sha256: OK
hwcheck-acceptance-20261024T154657Z.txt: OK
hwcheck-acceptance-20261024T154657Z.txt: OK
hwcheck-acceptance-20261024T154657Z.json: OK

The first check covers the 17 files listed in SHA256SUMS. The second uses the .sha256 file that the tool itself wrote next to the report on the node.

Commands

GH=https://raw.githubusercontent.com/VoltageGPU/hwcheck/main
curl -fsSL "$GH/examples/h100-8x-acceptance.txt" | sha256sum
curl -fsSL "$GH/examples/h100-8x-acceptance.json" | sha256sum
curl -fsSL https://voltagegpu.com/hwcheck.sh | sha256sum
curl -fsSL "$GH/hwcheck.sh" | sha256sum
curl -fsSL https://voltagegpu.com/hwcheck-acceptance.sh | sha256sum
curl -fsSL "$GH/acceptance.sh" | sha256sum

Output

bb2851566238165c198a63ce41f90e644a5f256def1b99bb19a31650444837bb  -
a656867b05e85d35454111d53bc5d51dd874032adcb63cb3ada3fee3141db507  -
23b3e11e71ce3121b66db8dc35c011f465bc4cda420cfae4bb731fdd423f0c1f  -
23b3e11e71ce3121b66db8dc35c011f465bc4cda420cfae4bb731fdd423f0c1f  -
6bce8305ebf6903eb3c46b2a12423019817d81e8182542c8ef9fa1a3544f5e9d  -
6bce8305ebf6903eb3c46b2a12423019817d81e8182542c8ef9fa1a3544f5e9d  -

The report and its JSON in the repository's examples/ folder are byte for byte the published ones, and the two scripts the site serves are the ones on the repository's main branch. Last, the setup script:

Commands (in the same folder)

curl -fsSL https://voltagegpu.com/dedicated-setup.sh | sha256sum
head -1 01c-dedicated-setup.txt

Output

3bd4aafcc3017a30ca09e9be5834ddcc87d02f3f873c73166cf7108002ef9011  -
$ bash -s 2>&1 < dedicated-setup.sh   # as: curl -fsSL https://voltagegpu.com/dedicated-setup.sh | bash (sha256 3bd4aafcc3017a30ca09e9be5834ddcc87d02f3f873c73166cf7108002ef9011)

The script the site serves has the SHA-256 written on the first line of the log of the run.

What this shows: the files have not changed since we computed the checksums, and the site and the public repository hold the same bytes. What it cannot show: that the files are the unedited output of a real run. Both copies come from us, and a checksum is not a signature. The run that counts is the one you make on your own node. To read a published hardware check line by line, see Re-check a Published GPU Hardware Check; for the shorter listing check, see How to Check the GPU You Rented Is the One You Paid For.

If you rent the node from us

The machine above is our dedicated bare metal offer: a whole 8x H100 SXM machine with 192 vCPU and no hypervisor, with the ubuntu user and sudo over SSH. On 24 October 2026 its public price was $49.80 per hour for the whole machine, that is $6.23 per GPU-hour, billed per second from a prepaid balance. The first hour is charged at start, and if you release early the unused part comes back.

For a multi-day run, note the limit: the automatic release is mandatory, 24 hours by default and 72 hours at most, and the disk does not survive it. For a longer run, save your checkpoints off the machine and deploy again. Bare metal is open to verified accounts with at least $100 of card top-ups, the first one more than 14 days old, and no disputed payment. A newer account can ask for a manual review at contact@voltagegpu.com. Live price and availability: /dedicated. The test itself is the same on any provider; its source and its full rules are in the README.

FAQ

How long does the hwcheck acceptance test take?

About 10 minutes: a 5-minute load test plus the topology, P2P, NCCL, error and hygiene checks. --quick skips the load test (about 2 minutes). If the image has no PyTorch, add the download of a pinned build, about 3 GB. On the 8x H100 SXM node of 24 October 2026, the whole run took 425 seconds, PyTorch download included.

What NCCL all-reduce bandwidth should an 8x H100 SXM node reach?

About 370 GB/s of bus bandwidth in ring and about 480 GB/s with NVLink SHARP on large sizes, according to NCCL maintainers at NVIDIA (nccl-tests issue 212). The node tested on 24 October 2026 reached 478.5 GB/s with 4 GiB per GPU. hwcheck passes an H100 SXM node from 340 GB/s and fails it under 185 GB/s.

What should nvidia-smi topo -m show on an 8x H100 SXM node?

NV18 for each of the 56 GPU pairs: in the legend of nvidia-smi, NV18 is a connection through a bonded set of 18 NVLinks. A pair that reads SYS, NODE, PHB, PXB or PIX goes over PCIe, which hwcheck fails. A pair with fewer than 18 links has a link down, which hwcheck flags as WARN.

Is it a problem if the GPUs hit their power cap during the test?

No. Under a full matrix load an H100 runs at its power limit, as designed. On 24 October 2026 the eight GPUs were at the cap in 95% of the samples, at up to 702 W. The warning signs are thermal slowdown, hardware slowdown and the power brake, which hwcheck counts separately.

Does the acceptance test work on other providers, or in a VM?

Yes. It needs Linux with the NVIDIA driver (it is written for Ubuntu 22.04 and 24.04), bash, coreutils, awk and python3. In a VM that shows no NVSwitch chip, that line reads INFO and the NVLink lines judge the fabric. Pass --bare-metal only when the listing says bare metal: the run then fails if a hypervisor is detected.

Does the script send anything about my machine?

No. It is read-only and needs no account. Its only network traffic is the PyTorch download from download.pytorch.org when the image has none, with the usual pip user agent; --no-install forbids it. It writes three report files and a temporary directory that it removes at exit.

Does a PASS mean the node will hold for a multi-day run?

No. It shows that the node was healthy during those ten minutes. Failures that come after hours, such as an Xid 79 at hour 30 or slowly growing ECC counts, need monitoring during the job. The test also does not check the network between nodes, storage, or firmware.

Disclosure: I work on VoltageGPU, which rents out the node tested here. hwcheck is open source (MIT).

Ring zero on an attested H100

VoltageGPU — Fri, 23 Oct 2026 18:29:25 +0000

By Final Boss Technology Inc. (Abraham Manzano) and VoltageGPU

This is a joint write-up. Final Boss Technology Inc. (FinalBoss) wrote sections 1, 2, 3 and 8: the run, the gate, its signed receipts and the enforcement in the kernel. VoltageGPU wrote sections 4 to 7 and the "Reproduce it" box: the Intel TDX and NVIDIA proofs, how the receipt is tied to them, and what our verifier printed. In those sections, "we" means VoltageGPU. Each side approved the other's sentences about its own system before publication.

The evidence is FinalBoss's public archive, GUEST_EVIDENCE_PHASE2.tar.gz at commit a1c42c2 (https://github.com/805-ai/finalboss-proof/tree/a1c42c2af9d14c0c44df215414a1efe5f13f286d/ring-zero-20261018). A path written proof/... is a file inside that archive.

1. What ran, and when

On 18 October 2026, FinalBoss loaded three eBPF cgroup hooks (connect4, sendmsg4 and sock_create) into the kernel of a VoltageGPU H100 confidential VM (Intel TDX) with one GPU, running kernel 6.8.0-110-generic. The run had two phases.

Phase 1 was a bounded test. Under the hooks, 3,000 of 3,000 unpermitted socket() calls were denied, and 3,000 of 3,000 permitted loopback TCP calls went through with zero failures. The median deny time was 10.94 µs. Phase 1 used a test permit to exercise the hooks. It ended at 22:53:50 UTC.

Phase 2 was the long run: 21 cycles, one every 120 seconds, from 22:53:53 to 23:34:04 UTC. Each cycle took a new hardware attestation, confirmed all three hooks attached, and ran a deny probe. All 21 cycles passed: 21 of 21 attestations succeeded, plus one attestation for the permit (cycle 0); 21 of 21 deny probes were denied; and 3 of 3 hooks were attached in every cycle. Phase 2 drew its permit from a signed gate receipt verified by permitctl. At the end, the hooks were detached. In round numbers, the long run lasted about 40 minutes.

Scope: this run covers network enforcement in the kernel. It does not cover BPF-LSM, and it makes no AMD SEV-SNP claim.

Sources: proof/OBSERVATIONS.json, proof/LATENCY.json, proof/LONG_RUN_SUMMARY.json, proof/CYCLES.jsonl, proof/MANIFEST.sha256 (77 files).

2. The gate and its signed receipts

The FinalBoss gate sits in front of an action. In phase 2, nothing ran without a signed receipt. Before the action is allowed, the gate records the intent and signs it.

The receipt published with this run names the action (connect4 127.0.0.1 worker pid 3071), an effect ID (73df5891077b86bd950ecd92b8af8f2d), an idempotency key, the phase (INTENT) and the status (INTENT_RECORDED). It also carries a signing key ID, the fingerprints of both public keys, and the signature mode, hybrid-ed25519-mldsa87.

The receipt hash is SHA-256 of the canonical JSON of the receipt (sorted keys, no whitespace) with the hash and both signatures removed. For this receipt, that is f87320cf1bcea80f29ccf6675dec83c73fa62179233aa990a18f2e882dae0fbd. Both signatures are computed over the hex text of that hash.

There are two signatures because one is not enough for the long term. Ed25519 is fast and widely trusted today. ML-DSA-87 is a post-quantum signature standardised by NIST. A forgery stays impossible as long as one of the two schemes holds, provided the verifier requires both signatures.

The signing_key_id points to a hardware attestation. It is tdx: followed by the SHA-256 of the attestation bundle for cycle 0 (3a1e6e64d4d98ccbfbce1af128f23413b85dc23676571e725efb03b13816d390). The receipt therefore names the exact attestation it was issued against.

Key custody: the gate used an external signer outside the VM. This run does not claim the keys were inside the VM.

Sources: proof/gate_keys/receipt_73df5891077b86bd950ecd92b8af8f2d.json, proof/gate_keys/gate_ed25519.pub, proof/gate_keys/gate_mldsa87.pub.

3. Enforcement in ring zero

The gate decides. The kernel enforces. FinalBoss attaches three cgroup hooks, each guarding one way out of the workload: sock_create blocks opening a socket, connect4 blocks opening a connection, and sendmsg4 blocks sending UDP datagrams over IPv4. The default is deny. A process can only get through if a permit for it exists in the kernel's permit map.

In phase 2, permitctl checked the signed gate receipt and only then wrote the permit. Revocation works the same way in reverse. In phase 1, after the test permit was revoked, all three hooks returned EPERM: connect4, sendmsg4 and sock_create.

Latency was measured with a worker in the cgroup, timing each call with perf_counter_ns: 3,000 TCP connect, send and close calls to a loopback listener for the allow path, and 3,000 socket() calls returning EPERM for the deny path.

The hooks were built ahead of time on the operator's machine. No compiler was present on the target. They were loaded with bpftool v7.8.0. The SHA-256 of each object is published:

finalboss_kts_connect4.bpf.o:
b373e9be7fb3fc5a6972760ba19645b30c8d47fbe5ef0b5bf02f2f3b3876b984
finalboss_kts_sendmsg4.bpf.o:
507b10398a390739f5df3599c9bc7d679b1dcbcfc86d8e6c4c66cd78313406b7
finalboss_kts_sock_create.bpf.o:
c879aefdb4337db15e739024fdecb1dbe4badc26bc5717b032c028a96ebfa417
source: 9ce4ad08df55aaed1b7055fe4708c14c62aaf6577b83efa0d200014d25a59143

The objects themselves are available to qualified reviewers under NDA. At the end of the run, all hooks were detached.

Sources: proof/BPF_LOAD.txt, proof/CGROUP_ATTACHMENTS.txt, proof/BPF_UNLOAD.txt, proof/LONG_BPF_LOAD.txt, proof/LONG_BPF_UNLOAD.txt, proof/OBSERVATIONS.json, proof/cycles/cycle_0001.json to cycle_0021.json.

4. Two hardware proofs: the Intel TDX quote and the NVIDIA GPU attestation

The run used a VoltageGPU H100 confidential VM (Intel TDX) with one GPU. The archive holds 22 attestation bundles: bundle_0000, taken for the gate permit before cycle 1, and bundle_0001 to bundle_0021, one per cycle. Each was made inside the VM with voltage-verify 0.2.1 and holds two proofs over one manifest.

The manifest holds a challenge, a creation time, a statement and workload fields, all written by FinalBoss. In the 22 manifests, the workload fields carry the company name, the cycle number, the session nonce 9497347602a44f2088ed53b3a885a34c and the SHA-256 fingerprints of the two gate public keys (e4baefa2… and 511d1622…).

The Intel TDX quote carries the SHA-512 of the canonical manifest (keys sorted, no whitespace, UTF-8) as its 64-byte report_data. Intel's Quoting Enclave signs it, the chain ends at the Intel SGX Root CA, and Intel's signed collateral rates the platform's patch level.

The NVIDIA attestation is a set of tokens signed by NVIDIA's attestation service (NRAS), whose eat_nonce is the SHA-256 of the same manifest. Change one byte of the manifest and neither proof matches it.

What bundle_0000 shows (the same values in all 22 bundles):

Quote v4, 4,940 bytes. MRTD eea8b6a8…, the measurement of the VM's initial memory. RTMR3 is all zeros, so no runtime measurement was added. TD attributes 0000001000000000: debug off.
Intel: platform TCB, Quoting Enclave and TDX module TDX_01 all UpToDate (TCB level of 13 August 2025); the PCK certificate and its CA are not revoked.
NVIDIA: one GH100 GPU; measurements matched, secure boot on, debug disabled; driver 595.71.05, VBIOS 96.00.CF.00.01.

Inside the VM, nvidia-smi conf-compute reported CC State ON and Multi-GPU Mode None, the single-GPU confidential computing mode. The VM reported this itself; no signature covers it.

The MRTD equals the one in our public reference bundle of 12 September 2026 (examples/hello-workload/ in voltage-verify): the same virtual firmware image. RTMR0 to RTMR2 differ from that bundle's, and we publish no reference values for them.

What this proves, and what it does not. The 22 quotes come from one genuine Intel TDX platform that Intel rates UpToDate, NVIDIA issued the GPU claims, and each quote and its tokens commit to the same manifest. The proofs say nothing about software loaded after boot (RTMR3 is zero) or about what the GPU computed, and they commit to FinalBoss's statement and workload fields without checking them.

Sources: proof/cycles/ (manifests and bundles); section 6; docs/WHAT_IT_PROVES.md in voltage-verify; the public verification page of bundle_0000, https://voltagegpu.com/verified/Bf2xU9dGOQkHqrwrVQpyTw.

5. How the gate receipt is tied to the attestation

Section 2 describes the receipt. voltage-verify does not read it, so we checked the chain below with our own script, which recomputes each value from the published files (figure 1).

Keys to manifest. The SHA-256 of gate_ed25519.pub is e4baefa2… and the SHA-256 of gate_mldsa87.pub is 511d1622…: the two fingerprints in manifest_0000.json.
Manifest to hardware. The quote in bundle_0000.json carries the SHA-512 of that manifest as its report_data, and both NVIDIA tokens carry its SHA-256 as eat_nonce.
Receipt to attestation. The receipt's signing_key_id is tdx: followed by 3a1e6e64…, the SHA-256 of the file bundle_0000.json.
Receipt to keys. The receipt's two fingerprints equal the two key-file hashes. We recomputed the receipt hash as section 2 defines it and got f87320cf…, the value in the receipt, and both signatures verify over its hex text with the published public keys (Python cryptography 50.0.2). The hash covers signing_key_id and the fingerprints: when we changed one character of either, the hash changed and both signatures failed.
Every cycle. The 22 manifests carry the same two fingerprints and the same session nonce, so all 22 quotes and NVIDIA attestations commit to the same gate keys.
Time. The receipt contains the hash of bundle_0000.json, which holds an NVIDIA token issued at 22:53:57 UTC, so the receipt was signed after that time. The receipt has no time field of its own.

Figure 1. From the gate keys to the hardware proofs and back to the receipt. Values from FinalBoss's archive at commit a1c42c2; every arrow was recomputed by our script.

Legend: solid border, signed by Intel or NVIDIA; dashed border, signed with the gate keys; no border, unsigned file.

Figure 1 sources: proof/cycles/manifest_0000.json to manifest_0021.json, proof/cycles/bundle_0000.json and proof/gate_keys/ (commit a1c42c2).

What this proves, and what it does not. The receipt names the attestation in bundle_0000.json, and it is signed by the two keys whose fingerprints the attested VM put in its manifest. The keys were held by an external signer outside the VM, and this run makes no claim that they were inside it. The quote shows that software in the VM asked for a quote over a manifest holding those fingerprints, not who held the private keys. Nor does it show that the permit the kernel enforced came from this receipt: that rests on FinalBoss's logs.

Sources: proof/gate_keys/ (receipt and public keys); proof/cycles/ (manifests and bundle_0000.json); our check, in part 2 of the "Reproduce it" box.

6. What voltage-verify printed

We ran the "Reproduce it" box below on 22 October 2026, each time in a new directory with a new virtual environment: on Windows 11 with Git Bash (21:00:02 to 21:00:25 UTC) and on Ubuntu 24.04.1 (21:02:00 to 21:02:17 UTC). pip installed voltage-verify 0.2.3. Both runs printed the archive hash, 77 (every file in MANIFEST.sha256 matches) and RESULT: VERIFIED for all 22 bundles. voltage-verify 0.2.2 gives the same 22 results; on bundle_0000, its output differs from that of 0.2.3 only in the wording of the nvidia.signatures line.

The full output for bundle_0000 (offline, 0.2.3):

$ voltage-verify verify proof/cycles/bundle_0000.json --offline --challenge cb2f9a15fb882c3f1e9e3d5867b596d105f215d0bcad1bec2db437a3eebd37c6 --hwmodel GH100 --gpus 1
[PASS] manifest.format       manifest is well formed
[PASS] manifest.commitments  bundle commitments match the manifest
[PASS] manifest.challenge    challenge is the one this verifier issued
[PASS] tdx.structure         TDX quote v4, TEE 0x81, 4940 bytes
[PASS] tdx.debug             TD attributes 0000001000000000 (0x10000000), DEBUG (bit 0) off: not a debug TD
[PASS] tdx.report_data       quote report_data equals SHA-512 of the manifest
[PASS] tdx.signatures        attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral        TCB info and QE identity signed by Intel (bundle (fetched 2026-10-18T22:53:59+00:00))
[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
[PASS] tdx.revocation        PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation        PCK CA certificate not revoked (0 entries in CRL)
[PASS] nvidia.signatures     2 NVIDIA-signed tokens verify, keys from the bundle chained to a pinned NRAS intermediate (offline)
[PASS] nvidia.nonce          NRAS eat_nonce equals SHA-256 of the manifest
[PASS] nvidia.policy         overall result true, every GPU: measurements ok, secure boot on, debug off, nonce matched, report signature and chain validated
[PASS] nvidia.freshness      token issued 3s from bundle creation

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate
GPU: GPU-0 GH100 driver 595.71.05 vbios 96.00.CF.00.01 measurements success

RESULT: VERIFIED

All 22 bundles, 18 October 2026:

Bundle	NVIDIA token issued (UTC, signed by NVIDIA)	Intel collateral fetched (UTC, recorded in the bundle)	voltage-verify 0.2.3
bundle_0000	22:53:57	22:53:59	VERIFIED
bundle_0001	22:54:03	22:54:05	VERIFIED
bundle_0002	22:56:03	22:56:05	VERIFIED
bundle_0003	22:58:02	22:58:04	VERIFIED
bundle_0004	23:00:02	23:00:04	VERIFIED
bundle_0005	23:02:02	23:02:04	VERIFIED
bundle_0006	23:04:02	23:04:04	VERIFIED
bundle_0007	23:06:02	23:06:04	VERIFIED
bundle_0008	23:08:02	23:08:04	VERIFIED
bundle_0009	23:10:02	23:10:12	VERIFIED
bundle_0010	23:12:02	23:12:04	VERIFIED
bundle_0011	23:14:02	23:14:04	VERIFIED
bundle_0012	23:16:02	23:16:04	VERIFIED
bundle_0013	23:18:02	23:18:04	VERIFIED
bundle_0014	23:20:02	23:20:04	VERIFIED
bundle_0015	23:22:02	23:22:04	VERIFIED
bundle_0016	23:24:02	23:24:04	VERIFIED
bundle_0017	23:26:02	23:26:04	VERIFIED
bundle_0018	23:28:02	23:28:04	VERIFIED
bundle_0019	23:30:02	23:30:04	VERIFIED
bundle_0020	23:32:02	23:32:04	VERIFIED
bundle_0021	23:34:02	23:34:04	VERIFIED

The 22 quotes share one MRTD, one set of RTMR0 to RTMR3, one PCK certificate chain and one set of TCB values, and the 22 sets of NVIDIA tokens name one GPU (the same ueid). The 22 challenges are all different.

The selftest makes nine tampered copies of each bundle (manifest changes, a replayed challenge, an altered byte of the quote, an altered GPU claim, re-signed tokens, a duplicated signing key, stripped certificate chains) and checks that each one is rejected: 198 of 198 were.

Online, with Intel collateral fetched on 22 October 2026 at 21:04 UTC, bundle_0000 still verifies with the same ratings. We ran this for bundle_0000 only; the other 21 quotes come from the same platform with the same security version numbers.

Figure 2. The run on 18 October 2026, in UTC. Filled marks: times signed by NVIDIA. Hollow marks: times written by FinalBoss's harness or by the VM, not signed. Phase 1 ended before the first attestation.

Figure 2 sources: proof/OBSERVATIONS.json, proof/LONG_RUN_SUMMARY.json, proof/cycles/manifest_*.json, bundle_*.json and cycle_*.json (commit a1c42c2).

What this proves, and what it does not. Each bundle answers the challenge in its own manifest, but FinalBoss set those challenges, not an outside verifier, so they do not show freshness to a reader. NVIDIA's signed timestamps do: from 22:53:57 to 23:34:02 UTC on 18 October 2026 (2,405 seconds), 6 seconds between bundle_0000 and bundle_0001, then 119 to 120 seconds between cycles (figure 2). Twenty-two quotes from one platform with one set of measurements fit one VM running for about 40 minutes, but they do not formally prove a single VM instance. Phase 1 (section 1) ended at 22:53:50 UTC, 7 seconds before the first attestation in the archive, so no hardware proof covers it.

Sources: our runs of 22 October 2026 (box below); voltage-verify 0.2.3 and 0.2.2 from PyPI; proof/OBSERVATIONS.json.

7. What the hardware side proves, and what it does not

This is the list from docs/WHAT_IT_PROVES.md in voltage-verify 0.2.3 (https://github.com/VoltageGPU/voltage-verify/blob/v0.2.3/docs/WHAT_IT_PROVES.md), for the checks printed in section 6.

Check	Proves	Does not prove
`manifest.format`	the bundle is parseable	anything
`manifest.commitments`	bookkeeping is consistent	anything: an attacker can recompute them
`manifest.challenge`	the bundle was made for this session	anything without the TDX and NVIDIA checks below
`tdx.structure`	it is a TDX quote	anything about its origin
`tdx.debug`	the TD does not run in debug mode, in which the host can read and modify its memory and CPU state	anything on its own: the TD attributes are only Intel's word once `tdx.signatures` passes
`tdx.report_data`	the quote was requested with your manifest hash, so after your challenge	who requested it
`tdx.signatures`	the quote was produced by a genuine Intel TDX Quoting Enclave on Intel-provisioned hardware	that the platform's firmware is current
`tdx.collateral`	the collateral is Intel's	freshness (see `tdx.collateral_fresh`)
`tdx.tcb`	the platform is patched to a level Intel accepts	that no unknown vulnerability exists
`tdx.revocation`	Intel has not revoked this platform's provisioning identity	anything if CRLs are missing (then the line says NOT checked)
`nvidia.signatures`	NVIDIA issued these claims	when, until `nvidia.freshness`
`nvidia.nonce`	the claims were issued for your manifest hash, after your challenge	which VM: the TDX side does that
`nvidia.policy`	NVIDIA's service accepted the GPU's measurements and configuration	that the GPU executed your workload
`nvidia.freshness`	the token belongs to this attestation session	anything if the VM clock is wrong (the check then fails, which is the safe direction)

The quote's MRTD and RTMR0..3 are printed as facts. They measure the VM's initial state and boot chain. This tool does not compare them to a reference: whether a given MRTD is the image you expect is a policy decision that belongs to you.

The gap this tool does not close. Both proofs are bound to a description of the workload. Neither proof says that the described image or model was what the GPU computed on. Closing that gap requires a measured launch: a component inside the VM that measures the container image and the model before starting them and extends a TDX runtime measurement (RTMR) with the result, so that the quote itself carries the measurement. The Confidential Containers project (Kata + Trustee) and similar stacks do this. voltage-verify stops one step earlier on purpose, and says so.

Reproduce it

Part 1: the archive and the 22 hardware attestations

These lines download FinalBoss's archive at the pinned commit, check its hash and its 77 files, and verify the 22 hardware attestations offline, each against the challenge in its own manifest. On Windows with Git Bash, start with python -m venv vv && . vv/Scripts/activate instead; the rest is unchanged. python -I keeps Python from importing modules from the current directory, which holds downloaded files.

python3 -m venv vv && . vv/bin/activate && pip install "voltage-verify>=0.2.2"
voltage-verify --version
curl -sLO https://github.com/805-ai/finalboss-proof/raw/a1c42c2af9d14c0c44df215414a1efe5f13f286d/ring-zero-20261018/GUEST_EVIDENCE_PHASE2.tar.gz
sha256sum GUEST_EVIDENCE_PHASE2.tar.gz      # 6019ef19363e76ca1ea3cc0114c29d0b7afd9312cc0d363548b1bcaf10c66dc9
tar -xzf GUEST_EVIDENCE_PHASE2.tar.gz
(cd proof && sha256sum -c MANIFEST.sha256 | grep -c ': OK$')      # 77
for n in $(seq -w 0 21); do
  c=$(python -I -c 'import json,sys; print(json.load(open(sys.argv[1]))["challenge"])' proof/cycles/manifest_00$n.json)
  printf '%s ' "bundle_00$n"; voltage-verify verify proof/cycles/bundle_00$n.json --offline --challenge "$c" --hwmodel GH100 --gpus 1 | tail -n 1
done                                         # 22 x "RESULT: VERIFIED"

Output on Ubuntu 24.04.1, 22 October 2026, 21:02:00 to 21:02:17 UTC, without pip's own lines:

voltage-verify 0.2.3
6019ef19363e76ca1ea3cc0114c29d0b7afd9312cc0d363548b1bcaf10c66dc9  GUEST_EVIDENCE_PHASE2.tar.gz
77
bundle_0000 RESULT: VERIFIED
bundle_0001 RESULT: VERIFIED
bundle_0002 RESULT: VERIFIED
bundle_0003 RESULT: VERIFIED
bundle_0004 RESULT: VERIFIED
bundle_0005 RESULT: VERIFIED
bundle_0006 RESULT: VERIFIED
bundle_0007 RESULT: VERIFIED
bundle_0008 RESULT: VERIFIED
bundle_0009 RESULT: VERIFIED
bundle_0010 RESULT: VERIFIED
bundle_0011 RESULT: VERIFIED
bundle_0012 RESULT: VERIFIED
bundle_0013 RESULT: VERIFIED
bundle_0014 RESULT: VERIFIED
bundle_0015 RESULT: VERIFIED
bundle_0016 RESULT: VERIFIED
bundle_0017 RESULT: VERIFIED
bundle_0018 RESULT: VERIFIED
bundle_0019 RESULT: VERIFIED
bundle_0020 RESULT: VERIFIED
bundle_0021 RESULT: VERIFIED

Part 2: the receipt chain

To check the receipt chain of section 5 as well, run this in the same directory. It needs only the Python cryptography package, which pip installed with voltage-verify.

python -I - proof/gate_keys proof/cycles <<'EOF'
import base64, hashlib, json, sys
from pathlib import Path
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
from cryptography.hazmat.primitives.asymmetric.mldsa import MLDSA87PublicKey
keys, cycles = Path(sys.argv[1]), Path(sys.argv[2])
sha = lambda p: hashlib.sha256(p.read_bytes()).hexdigest()
r = json.loads(next(keys.glob("receipt_*.json")).read_text())
body = {k: v for k, v in r.items() if k not in ("hash", "signature_ed25519", "signature_pq")}
h = hashlib.sha256(json.dumps(body, sort_keys=True, separators=(",", ":")).encode()).hexdigest()
print("hash recomputed:", h == r["hash"], h)
print("signing_key_id is tdx: + SHA-256(bundle_0000.json):", r["signing_key_id"] == "tdx:" + sha(cycles / "bundle_0000.json"))
files = (sha(keys / "gate_ed25519.pub"), sha(keys / "gate_mldsa87.pub"))
print("receipt fingerprints = SHA-256 of the key files:", (r["public_key_fingerprint_ed25519"], r["public_key_fingerprint_pq"]) == files)
extras = [json.loads(m.read_text())["workload"]["extra"] for m in sorted(cycles.glob("manifest_*.json"))]
print("manifests carrying both fingerprints:", sum((e["ed25519_fpr"], e["mldsa87_fpr"]) == files for e in extras), "of", len(extras))
pub = lambda f: base64.b64decode((keys / f).read_text().strip())
Ed25519PublicKey.from_public_bytes(pub("gate_ed25519.pub")).verify(base64.b64decode(r["signature_ed25519"]), h.encode())
MLDSA87PublicKey.from_public_bytes(pub("gate_mldsa87.pub")).verify(base64.b64decode(r["signature_pq"]), h.encode())
print("Ed25519 and ML-DSA-87 signatures over the hex hash: valid")
EOF

Output on Ubuntu 24.04.1, 22 October 2026, 21:12:32 UTC (cryptography 50.0.2):

hash recomputed: True f87320cf1bcea80f29ccf6675dec83c73fa62179233aa990a18f2e882dae0fbd
signing_key_id is tdx: + SHA-256(bundle_0000.json): True
receipt fingerprints = SHA-256 of the key files: True
manifests carrying both fingerprints: 22 of 22
Ed25519 and ML-DSA-87 signatures over the hex hash: valid

On a copy of the receipt with one character changed (pid 3071 became pid 3072 in the action field), the recomputed hash no longer matched and the Ed25519 check stopped with InvalidSignature.

8. What the kernel run proves, and next steps

What this run shows, according to FinalBoss's logs: a signed gate receipt, which names a hardware attestation by its key ID, was checked before the kernel allowed network access. Three kernel hooks denied calls without a permit, stayed attached through 21 cycles, each with its own hardware attestation, and returned EPERM after the phase 1 permit was revoked.

Its scope: network hooks only, on Intel TDX. BPF-LSM was not part of this run, and there is no AMD SEV-SNP claim. Phase 1 used a test permit, and the receipt-to-permit binding comes from the FinalBoss logs.

What a reader can check today: the archive hash, all 77 file hashes and all 22 hardware attestations with the Reproduce it box, and the receipt hash and both signatures with the format given in section 2.

Next steps: FinalBoss plans to extend hardware attestation to cover the enforcement layer itself.

Contact: Abraham Manzano, Final Boss Technology Inc., Abraham@finalbosstech.com, (805) 420-5140.

Sources and links

FinalBoss's archive, pinned to commit a1c42c2af9d14c0c44df215414a1efe5f13f286d: https://github.com/805-ai/finalboss-proof/tree/a1c42c2af9d14c0c44df215414a1efe5f13f286d/ring-zero-20261018 (GUEST_EVIDENCE_PHASE2.tar.gz, SHA-256 6019ef19363e76ca1ea3cc0114c29d0b7afd9312cc0d363548b1bcaf10c66dc9, 77 files listed in MANIFEST.sha256).
voltage-verify, the open-source verifier used in sections 4 to 7: https://github.com/VoltageGPU/voltage-verify (package: https://pypi.org/project/voltage-verify/). What each check proves: https://github.com/VoltageGPU/voltage-verify/blob/v0.2.3/docs/WHAT_IT_PROVES.md.
The public verification page of bundle_0000: https://voltagegpu.com/verified/Bf2xU9dGOQkHqrwrVQpyTw.
Every proof VoltageGPU publishes, with the command that rechecks it: https://voltagegpu.com/proofs.

Final Boss Technology Inc. (Abraham Manzano) and VoltageGPU

Originally published at voltagegpu.com. A joint write-up by Final Boss Technology Inc. and VoltageGPU.

Calling open models inside a TEE with the OpenAI Python SDK

VoltageGPU — Fri, 23 Oct 2026 16:16:28 +0000

If you already call OpenAI from Python, switching to an open model that runs in a trusted execution environment (TEE) is two lines: the base URL and the key. Here is what that looks like, with real output captured on 23 October 2026.

The two lines that change

from openai import OpenAI
import os

client = OpenAI(
    base_url="https://api.voltagegpu.com/v1",
    api_key=os.environ["VOLTAGEGPU_API_KEY"],   # a vgpu_... key, never commit it
)

resp = client.chat.completions.create(
    model="google/gemma-4-31B-turbo-TEE",
    messages=[{"role": "user", "content": "In one sentence, what does a TEE protect?"}],
)
print(resp.choices[0].message.content)

Every model id ends in -TEE: the model runs in an Intel TDX guest with confidential-computing NVIDIA GPUs. Streaming works as usual (stream=True).

What came back

x-voltagegpu-model: google/gemma-4-31B-turbo-TEE
x-voltagegpu-confidential: tee
x-voltagegpu-cost-usd: 0.000025
answer: A TEE protects sensitive data and code from being accessed or modified by the rest of the device's operating system.
usage: 36 prompt + 25 completion tokens

The response headers tell you which model actually ran and what the call cost, so you can log it next to your own usage.

Listing the models

GET /v1/models is public and returns, for each model, its live status (available, busy, saturated, unavailable), the price per million tokens and the context length. On 23 October there were 14 models, from small ones such as Mistral Nemo up to Qwen3.5-397B, DeepSeek V3.2 and Kimi K3.

What the TEE does and does not give you

GET /v1/attestation returns the Intel and NVIDIA evidence of the running instances, bound to a nonce you choose. It proves genuine TDX guests with confidential-computing GPUs. It does not prove which instance served a given response, nor which code runs inside. If you need to check the hardware evidence yourself, offline, the open-source voltage-verify verifies an Intel TDX quote and NVIDIA attestation tokens against a manifest you control.

Same thing with LiteLLM, LangChain or LlamaIndex

Because the API is OpenAI-compatible, the usual integrations work by pointing them at the base URL. Tested examples for each, with their unedited output, are in the cookbook: github.com/VoltageGPU/voltagegpu-cookbook.

Disclosure: I build VoltageGPU.

Read an Intel TDX Quote, Field by Field

VoltageGPU — Thu, 22 Oct 2026 12:21:50 +0000

Originally published on voltagegpu.com, where the bundle and every raw file are linked.

Key takeaways

Every value below comes from one public quote, checked with voltage-verify 0.2.2.

Six things matter to a tenant: MRTD, RTMR0 to RTMR3, REPORTDATA, the TD attributes, the TCB status and the certificate chain.

Each proves something narrow. None shows that the VM runs software you trust.

voltage-verify reduces a TDX quote to one line: RESULT: VERIFIED. Here we open one: a quote captured on 17 September 2026 in a VoltageGPU Confidential VM with one NVIDIA RTX PRO 6000 Blackwell Server Edition. We check it, then read each field for what it proves and what it does not. The bundle is public; all outputs date from 22 October 2026.

What a TDX quote is, and who signs it

Intel TDX runs a VM as a trust domain (TD). A CPU-attested software module, the TDX module, sits between the host and the guest. It gives the guest a TD report: the TD's measurements, the platform's security versions and 64 bytes chosen by the guest, called REPORTDATA. A MAC protects the report, and only the local platform can check it.

So a Quoting Enclave, an Intel SGX enclave on the same host, checks the report and turns it into a quote anyone can verify. A version 4 quote has three parts:

a 48-byte header: version 4, key type 2 (ECDSA P-256), TEE type 0x81 (TDX);
the 584-byte TD report;
the signature data: quote signature, attestation key, the Quoting Enclave's report and the platform's certificate chain.

The attestation key signs the header and the TD report. The Quoting Enclave's report vouches for that key: its data starts with a SHA-256 of the key and the enclave's authentication data. The platform's PCK key signs that report. Intel issues the PCK certificate, whose chain ends at the Intel SGX Root CA. VoltageGPU appears nowhere in this chain.

Step 1: verify the bundle

The bundle holds the quote, a manifest, NVIDIA's GPU tokens and Intel's documents from the day of capture (README). The commands are written for Linux and macOS. We ran them on Windows 11 in Git Bash, where the interpreter is python.

pip install "voltage-verify>=0.2.2"
curl -fsSLO https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-2026-09-17/bundle.json
voltage-verify verify bundle.json --challenge d807768657e40ee62d430d9dc5eb924d520ba1d07e351bc44ee59dbe611085a7 --hwmodel GB20X --gpus 1

What it printed on 22 October 2026:

[PASS] manifest.format       manifest is well formed
[PASS] manifest.commitments  bundle commitments match the manifest
[PASS] manifest.challenge    challenge is the one this verifier issued
[PASS] tdx.structure         TDX quote v4, TEE 0x81, 4940 bytes
[PASS] tdx.debug             TD attributes 0000001000000000 (0x10000000), DEBUG (bit 0) off: not a debug TD
[PASS] tdx.report_data       quote report_data equals SHA-512 of the manifest
[PASS] tdx.signatures        attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral        TCB info and QE identity signed by Intel (Intel PCS, fetched now)
[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_03 UpToDate
[PASS] tdx.revocation        PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation        PCK CA certificate not revoked (0 entries in CRL)
[PASS] nvidia.signatures     2 NVIDIA-signed tokens verify, keys from the bundle chained to the pinned NRAS intermediate (NVIDIA's live JWKS fetched for its intermediates)
[PASS] nvidia.nonce          NRAS eat_nonce equals SHA-256 of the manifest
[PASS] nvidia.policy         overall result true, every GPU: measurements ok, secure boot on, debug off, nonce matched, report signature and chain validated
[PASS] nvidia.freshness      token issued 0s from bundle creation

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate
GPU: GPU-0 GB20X driver 595.71.05 vbios 98.02.9E.00.01 measurements success

RESULT: VERIFIED

Fifteen checks pass. This article reads the tdx.* lines. The nvidia.* lines are covered in the bundle tutorial.

Step 2: print every field

With --json, voltage-verify lists the main fields under facts.tdx, not the whole TD report or the certificates. This script prints everything, using the standard library and cryptography, which voltage-verify installs.

"""Print every field of the Intel TDX quote carried by a voltage-verify bundle.

Usage: python3 -I read_quote.py bundle.json
Layout of a TDX quote v4: a 48-byte header, the 584-byte TD report, then the
signature data. Standard library only, plus `cryptography` (installed with
voltage-verify) to read the certificates.
"""
import base64
import hashlib
import json
import struct
import sys

from cryptography import x509
from cryptography.hazmat.primitives import hashes

bundle = json.load(open(sys.argv[1], encoding="utf-8"))
b64 = bundle["tdx"]["quote_b64"]
quote = base64.b64decode(b64 + "=" * (-len(b64) % 4))

version, key_type, tee_type = struct.unpack_from("<HHI", quote, 0)
print(f"header: version {version}, key type {key_type}, TEE type 0x{tee_type:x}, {len(quote)} bytes")

# TD report fields: (name, offset in the quote, size in bytes)
FIELDS = [
    ("TEE_TCB_SVN", 48, 16), ("MRSEAM", 64, 48), ("MRSIGNERSEAM", 112, 48),
    ("SEAMATTRIBUTES", 160, 8), ("TDATTRIBUTES", 168, 8), ("XFAM", 176, 8),
    ("MRTD", 184, 48), ("MRCONFIGID", 232, 48), ("MROWNER", 280, 48),
    ("MROWNERCONFIG", 328, 48), ("RTMR0", 376, 48), ("RTMR1", 424, 48),
    ("RTMR2", 472, 48), ("RTMR3", 520, 48), ("REPORTDATA", 568, 64),
]
for name, off, size in FIELDS:
    print(f"{name:<14} {quote[off:off + size].hex()}")

attrs = int.from_bytes(quote[168:176], "little")
print(f"TD attributes 0x{attrs:x}: DEBUG (bit 0) = {attrs & 1}, SEPT_VE_DISABLE (bit 28) = {attrs >> 28 & 1}")

canonical = json.dumps(bundle["manifest"], sort_keys=True, separators=(",", ":"), ensure_ascii=False)
print("REPORTDATA == SHA-512(manifest):", hashlib.sha512(canonical.encode()).digest() == quote[568:632])

sig_len = struct.unpack_from("<I", quote, 632)[0]
sig = quote[636:636 + sig_len]  # quote signature (64), attestation key (64), certification data
cert_type, cert_len = struct.unpack_from("<HI", sig, 128)
qe = sig[134:134 + cert_len]  # QE report (384), its signature (64), auth data, PCK chain
prod_id, isv_svn = struct.unpack_from("<HH", qe, 256)
print(f"signature data: {sig_len} bytes, certification data type {cert_type}")
print(f"QE report: MRSIGNER {qe[128:160].hex()}, ISVPRODID {prod_id}, ISVSVN {isv_svn}")
auth_len = struct.unpack_from("<H", qe, 448)[0]
inner_type, inner_len = struct.unpack_from("<HI", qe, 450 + auth_len)
pem = qe[456 + auth_len:456 + auth_len + inner_len].rstrip(b"\0")
print(f"certification data type {inner_type}:")
for cert in x509.load_pem_x509_certificates(pem):
    print(f"  {cert.subject.rfc4514_string()}  (valid until {cert.not_valid_after_utc:%Y-%m-%d})")
print("root SHA-256:", cert.fingerprint(hashes.SHA256()).hex())

python3 -I read_quote.py bundle.json printed:

header: version 4, key type 2, TEE type 0x81, 4940 bytes
TEE_TCB_SVN    05030400000000000000000000000000
MRSEAM         476a2997c62bccc78370913d0a80b956e3721b24272bc66c4d6307ced4be2865c40e26afac75f12df3425b03eb59ea7c
MRSIGNERSEAM   000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
SEAMATTRIBUTES 0000000000000000
TDATTRIBUTES   0000001000000000
XFAM           e702060000000000
MRTD           eea8b6a814569a52bd1e12f6b869bb2d9c0c8a7a43e658ffc3b42c199f116157ea7f04d359c7fdfd8ac483152cc13542
MRCONFIGID     000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
MROWNER        000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
MROWNERCONFIG  000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
RTMR0          f9ac3522e05572c2ede103eb9f243bebddee62d8e8db65a526736ea2bd5eb6dbe69a5ff8082c8050865b5ddadae4fa8a
RTMR1          965b54adf526d37237906189a31d9b058c39fac8909d9689e3340505aac4176deed2c2f3374b226304b23137d4832ae9
RTMR2          c2f56e0459db5660608f8f3a312f67decc0d210d55e93d3d106fe7f939941c524b0b370d53c4a6d6290e2df3b9511397
RTMR3          000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
REPORTDATA     832791479ad739ef2c1d51e1fb1da7a7a1422b6c88afaf2ca1c292f1ae9ee7dbe5e571b9926390cfdd7f62672c696ccda0c004a0c779a30c16ff80ce461790b8
TD attributes 0x10000000: DEBUG (bit 0) = 0, SEPT_VE_DISABLE (bit 28) = 1
REPORTDATA == SHA-512(manifest): True
signature data: 4304 bytes, certification data type 6
QE report: MRSIGNER dc9e2a7c6f948f17474e34a7fc43ed030f7c1563f1babddf6340c82e0e54a8c5, ISVPRODID 2, ISVSVN 7
certification data type 5:
  C=US,ST=CA,L=Santa Clara,O=Intel Corporation,CN=Intel SGX PCK Certificate  (valid until 2033-03-13)
  C=US,ST=CA,L=Santa Clara,O=Intel Corporation,CN=Intel SGX PCK Platform CA  (valid until 2033-05-21)
  C=US,ST=CA,L=Santa Clara,O=Intel Corporation,CN=Intel SGX Root CA  (valid until 2049-12-31)
root SHA-256: 44a0196b2b99f889b8e149e95b807a350e7424964399e885a7cbb8ccfab674d3

The offsets match voltage-verify's parser (TD attributes at byte 168, REPORTDATA at 568), and the sizes add up: 48 + 584 + 4 (a length field) + 4,304 = 4,940 bytes. MRCONFIGID, MROWNER and MROWNERCONFIG, immutable software-defined IDs in Linux's description, are zero: they carry nothing here. We do not interpret XFAM or SEAMATTRIBUTES.

The quote of the 17 Sep 2026 bundle, byte by byte. Offsets as read by read_quote.py above. The cloud provider is not in the signature chain.

The fields, one by one

MRTD: what the TD started from

Value: eea8b6a8…2cc13542.

The TDX module computes MRTD while the host builds the TD, before the TD runs. Linux documents it as the measurement of the TD's initial contents: its initial configuration and firmware image.

What it proves. The TD started from contents with this hash, measured by the TDX module, not reported by the host.

What it does not prove. That this firmware is one you trust: that needs a reference value, ideally rebuilt from source, and we publish none for this image. Our data only shows stability: the same MRTD appears in all four RTX PRO 6000 bundles we have published.

RTMR0 to RTMR3: the boot chain

Values: RTMR0 f9ac3522…dae4fa8a, RTMR1 965b54ad…d4832ae9, RTMR2 c2f56e04…b9511397, RTMR3 all zeros.

RTMRs are run-time registers that software in the TD can extend, mixing new data into the current value. The UEFI specification (2.10, section 38.4.1), as implemented in the EDK2 firmware, maps PCR 1 and 7 to RTMR0, PCR 2 to 6 to RTMR1 and PCR 8 to 15 to RTMR2. Nothing maps to RTMR3. Typically, RTMR0 holds the firmware configuration, RTMR1 the boot loader and kernel, RTMR2 the kernel command line and initrd.

What they prove. The boot events recorded by firmware and the boot loader hash to these values.

What they do not prove. Which events those were. A hash chain cannot be read backwards: you replay the firmware's event log and compare, and the bundle does not include that log.

The published bundles show the limit. RTMR0 and RTMR1 are identical in all four, RTMR3 is zero in all four, and RTMR2 differs every time:

Bundle	RTMR2, first 16 hex digits
17 Sep, 00:00 UTC (this one)	c2f56e0459db5660
17 Sep, 12:28 UTC (deployed by API)	c67f740f73f8d900
9 Oct	d9d5a5c17828c2b8
17 Oct (weekly run)	49b10f1d50c9b0fe

We have not published the event log that would explain the change. Pinning RTMR2 would have accepted at most one of these VMs. Pinning MRTD, RTMR0 and RTMR1 would have accepted all four; expect them to change with image updates.

REPORTDATA: your challenge

Value: 83279147…461790b8 (64 bytes).

The guest software chooses these 64 bytes. voltage-verify writes there the SHA-512 of the manifest, serialized canonically (keys sorted, no spaces, UTF-8). The manifest holds a 32-byte challenge, here d8077686…611085a7, and the script confirms the hash. The SHA-256 of the same manifest is the nonce in NVIDIA's GPU tokens: that manifest is the only link between the two proofs.

A challenge the bundle was not made for fails (output trimmed):

$ voltage-verify verify bundle.json --offline --challenge 0000000000000000000000000000000000000000000000000000000000000000
[FAIL] manifest.challenge    challenge differs from the one this verifier issued (replay or foreign bundle)
RESULT: NOT VERIFIED (manifest.challenge)

What it proves. The quote was requested for this exact manifest. If you generated the challenge, the quote was produced after you asked, not replayed.

What it does not prove. Freshness to you, unless the challenge is yours: here it was drawn inside the VM. Generate yours on your machine; the published script two-proofs-in-the-vm.sh accepts it as CHALLENGE. The field also means only what the guest software decided: our inference run of 16 October puts a SHA-256 of a nonce and the instance's public key in its first 32 bytes.

TD attributes: the debug bit

Value: 0000001000000000, read as a little-endian 64-bit integer: 0x10000000.

Only bit 28 is set. Linux calls it SEPT_VE_DISABLE; in Linux 6.8, a guest not in debug mode panics at boot without it (this guest runs 6.8.0-110-generic). Bit 0, DEBUG, is 0.

A debug TD gives no confidentiality: the host can read and modify its memory and CPU state, and Intel's Quoting Enclave still signs its quote. voltage-verify 0.2.1 and earlier printed this field without checking it. Version 0.2.2, released on 21 October 2026, fails a quote with bit 0 set unless you pass --allow-debug. Here is a copy of the quote with bit 0 flipped:

$ python3 -I -c "import json,base64;s=json.load(open('bundle.json'))['tdx']['quote_b64'];open('quote.bin','wb').write(base64.b64decode(s+'='*(-len(s)%4)))"
$ python3 -I -c "q=bytearray(open('quote.bin','rb').read()); q[168]|=1; open('quote-debug.bin','wb').write(q)"
$ voltage-verify quote quote-debug.bin --offline
[PASS] tdx.structure   TDX quote v4, TEE 0x81, 4940 bytes
[FAIL] tdx.debug       TD attributes 0100001000000000 (0x10000001), DEBUG (bit 0) ON: a debug TD gives no confidentiality, the host can read and modify its memory
[FAIL] tdx.signatures  quote signature does not verify with the attestation key: 

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB ?  QE ?

RESULT: NOT VERIFIED (tdx.debug, tdx.signatures)

tdx.debug fails because the bit is set; tdx.signatures fails because the attestation key signed the original bytes. A genuine debug TD has a validly signed quote, so only tdx.debug would catch it.

What it proves. The TD was not created in debug mode.

What it does not prove. Anything about the software inside it.

TCB status: is the platform current?

TEE_TCB_SVN, 05030400000000000000000000000000, records the TDX module's security version at TD launch. voltage-verify reads the module's major version from its second byte (03, hence TDX_03) and its security version from the first (05). The PCK certificate adds the CPU's SGX security versions and the FMSPC, 20a06d080000, which identifies the platform family.

Intel publishes signed TCB info per FMSPC: a list of levels, newest first, where the first level the platform meets gives its status. In the copy stored in the bundle (issued 16 September 2026), the UpToDate level, dated 13 August 2025, requires TDX components of at least 05 00 04. This quote has 05 03 04.

Online on 22 October, Intel's current documents give platform TCB UpToDate, QE UpToDate, TDX_03 UpToDate, with no advisory IDs. Offline, the stored documents give the same verdict plus a warning, as they passed their nextUpdate date on 16 October 2026:

[WARN] tdx.collateral_fresh  Intel collateral is past its nextUpdate; refetch online

What it proves. On the date of Intel's documents, Intel rated the platform, the TDX module and the Quoting Enclave UpToDate.

What it does not prove. That this lasts. In the same TCB info, the level dated 14 May 2025 is rated OutOfDate. An offline check is only as current as the documents it reads.

The certificate chain: who vouches

The script output ends with the chain: PCK Certificate, PCK Platform CA, Intel SGX Root CA. voltage-verify checks each signature and validity date, and compares the root with the copy of Intel's root it ships, pinned by its SHA-256 (44a0196b…fab674d3). The Quoting Enclave's MRSIGNER (dc9e2a7c…0e54a8c5) and product ID (2) match Intel's signed identity for it, and its security version (7) meets the UpToDate level (4 in the stored identity). Last, the PCK certificate is not among the 57 entries of Intel's revocation list, and the root's list is empty. voltage-verify selftest also alters one byte of the quote body:

[PASS] quote-tamper       one byte of the TDX quote body altered  ->  rejected on tdx.signatures

What it proves. A genuine Intel platform, with an identity Intel issued, signed this quote, and the quote has not changed since.

What it does not prove. Who operates the machine, or where. The certificates name Intel, not a cloud provider.

What this proves, and what it does not

Together, the fields prove that on 17 September 2026 a trust domain, not in debug mode, ran on an Intel platform that Intel rated UpToDate, with the measurements above, and produced this quote for this manifest.

They do not prove:

that the firmware and kernel are ones you trust: no reference values are published for this image, and RTMR2 changes from one VM to the next;
anything about the GPU: the NVIDIA tokens are a separate proof, tied to the quote only by the manifest, so the two are not shown to share a machine;
which code ran after boot: RTMR3 is zero and the manifest names no image;
freshness to you, since this challenge was drawn inside the VM;
the state of the TD today: a quote describes the TD when it was produced.

Reproduce it

Tested on 22 October 2026 on Windows 11 (Git Bash, Python 3.12.4), with python for python3 and . vv/Scripts/activate for the venv.

python3 -m venv vv && . vv/bin/activate
pip install "voltage-verify>=0.2.2"
B=https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-2026-09-17
curl -fsSLO "$B/bundle.json"
curl -fsSLO "$B/SHA256SUMS"
grep ' bundle.json$' SHA256SUMS | sha256sum -c -
C=d807768657e40ee62d430d9dc5eb924d520ba1d07e351bc44ee59dbe611085a7
voltage-verify verify bundle.json --challenge $C --hwmodel GB20X --gpus 1
voltage-verify verify bundle.json --challenge $C --offline --json
voltage-verify selftest bundle.json --offline --challenge $C
python3 -I read_quote.py bundle.json   # the script from Step 2

Expected: bundle.json: OK, RESULT: VERIFIED, "ok": true with the tdx.collateral_fresh warning, SELFTEST: PASS, then the fields of Step 2. To compare RTMR2, run the script on the bundles in rtx6000b-api-2026-09-17/ and rtx6000b-2026-10-09/, next to this one, and on the weekly run listed on /proofs.

Re-check a Published GPU Hardware Check, Line by Line

VoltageGPU — Tue, 20 Oct 2026 14:27:25 +0000

On 16 and 17 October 2026 we rented one standard machine per GPU model and ran hwcheck on each. hwcheck is our open-source hardware check. The outputs are public. This tutorial takes one of them, the H100 run, and shows what you can check from the public files alone. You can confirm that the script is the open-source one. You can confirm that the printed result follows from its rules. You can see how the same tool behaves on your own machine. Then come the limits, and they are real: a published output is a text file, not a signature.

If you only want the one-liner to run on a machine you rent, How to Check the GPU You Rented Is the One You Paid For explains it. Every command below was run on 20 October 2026 on Ubuntu 24.04, in a fresh directory, exactly as printed. Outputs are pasted as printed, except our workstation's name.

Step 1: read the published run

mkdir hwcheck-audit && cd hwcheck-audit
curl -sSfO https://voltagegpu.com/hwcheck-proofs/2026-10-17/h100.txt
cat h100.txt

VoltageGPU hwcheck proof
date: 2026-10-17T18:20:18.246Z
machine: d4093d0c-8d7c-448a-b4e0-a34e44468ea8 (standard tier, rented directly from our standard provider: the machines our listing shows)
listing: 1x H100 (rented on a node of 8 GPUs)
command: curl -fsSL https://voltagegpu.com/hwcheck.sh | bash -s -- --gpu "H100" --gpus 1 --no-net
exit code: 0 (0 = matches the listing, 2 = does not)
VoltageGPU hardware check (read-only, nothing about this machine is sent anywhere)
  2026-10-17 18:20 UTC · 09c3eb27fd21

                 LISTED                   MEASURED                           
  GPU model      H100                     NVIDIA H100 80GB HBM3              OK
  GPU count      1                        1                                  OK
  VRAM per GPU   -                        80 GB                              info
  Driver / CUDA                           580.173.02 / 13.0                  OK
  CUDA compute                            matmul on 1/1 GPU                  OK
  CPU                                     192 threads                        info
  RAM            -                        124 GB (container limit)           info
  Disk (/)       -                        118 GB, 118 GB free                info

RESULT: MATCHES THE LISTING

The first six lines were written by our publishing script. The machine was one GPU of an 8-GPU node, rented directly from the provider behind our standard listing, not through a customer account. The command passed the model and the GPU count, and nothing else. The rest is what hwcheck printed. The short hex string after the date is the machine's hostname. The index of the 17 October runs lists the other models.

Step 2: check that the script is the open-source one

curl -fsSL https://voltagegpu.com/hwcheck.sh -o hwcheck-site.sh
git clone -q https://github.com/VoltageGPU/hwcheck
sha256sum hwcheck-site.sh hwcheck/hwcheck.sh
git -C hwcheck log --format='%h %ad %s' --date=iso-strict -- hwcheck.sh

a8120ccf8b1a33034ed836cbbd6ed5c55b901bafbfce8321c07c769d8053feeb  hwcheck-site.sh
a8120ccf8b1a33034ed836cbbd6ed5c55b901bafbfce8321c07c769d8053feeb  hwcheck/hwcheck.sh
9378d1a 2026-10-16T08:43:58+02:00 hwcheck 1.0: check a rented GPU machine against its listing

The file the site serves today is byte for byte the one on GitHub. The repository has a single version of the script, committed on 16 October, the day before the H100 run. The two test runs we published that morning print the first 16 hex characters of the script's hash, and they match: a8120ccf8b1a3303 (rtx3060ti-match.txt).

What this cannot show is which file the site served on 17 October. Git dates are also declared by whoever commits. They are a record, not a proof.

Step 3: compare a published file with the repository copy

The 16 October runs are also in the repository's examples/ folder. Take the RTX 4090 run:

curl -sSf https://voltagegpu.com/hwcheck-proofs/2026-10-16/rtx-4090.txt | sha256sum
sha256sum hwcheck/examples/rtx-4090.txt
git -C hwcheck log --format='%h %ad %s' --date=iso-strict -- examples/rtx-4090.txt

2884bfeed0f5e18dbd39a75d3ae586e522eba367f023901a74e03f248d0f9408  -
2884bfeed0f5e18dbd39a75d3ae586e522eba367f023901a74e03f248d0f9408  hwcheck/examples/rtx-4090.txt
fa2e458 2026-10-16T17:03:06+02:00 docs: four real runs on rented RTX 4090, RTX 5090, H200 and B300 machines, all matching

The two copies are identical. The repository copy was committed at 15:03 UTC, ten minutes after the run's timestamp (14:53 UTC). If we edited the site copy later, it would stop matching. Both copies still come from us, so this is not independent evidence. The 17 October runs, the H100 included, exist only on the site.

Step 4: see which lines were actually compared

Not every row in the output is a check. The script shows which ones are:

grep -n -E 'row "(VRAM per GPU|Driver / CUDA|CUDA compute)"' hwcheck-site.sh

71:    if at_least "$VRAM_GB" "$VRAM" 0.93; then row "VRAM per GPU" "$VRAM GB" "$VRAM_GB GB" "OK"
72:    else row "VRAM per GPU" "$VRAM GB" "$VRAM_GB GB" "DOES NOT MATCH"; fail "VRAM"; fi
73:  else row "VRAM per GPU" "-" "$VRAM_GB GB" "info"; fi
75:  row "Driver / CUDA" "" "${DRIVER:-?} / ${CUDA:-?}" "OK"
97:  if [ "$OKGPUS" -ge "$COUNT" ]; then row "CUDA compute" "" "matmul on $OKGPUS/$COUNT GPU" "OK"
98:  else row "CUDA compute" "" "matmul on $OKGPUS/$COUNT GPU" "DOES NOT MATCH"; fail "CUDA compute"; fi
100:  row "CUDA compute" "" "not tested (no PyTorch)" "info"

Read against the H100 run:

GPU model: compared. The rule is in step 5.
GPU count: compared. The machine must show at least the listed number.
VRAM per GPU: compared only when --vram is passed (line 71). The H100 run did not pass it, so "80 GB" is information (line 73).
Driver / CUDA: always OK once nvidia-smi answers (line 75). It is information, not a check.
CUDA compute: a 2048 by 2048 matrix product on each GPU, when the image has PyTorch. "matmul on 1/1 GPU" means it ran on the one GPU.
CPU, RAM, disk: information, unless --ram or --disk is passed. Neither was.
No download line: --no-net skips the speed test.

So in this run, three things were checked against the listing: the model name, the GPU count, and that CUDA work runs on every GPU.

Step 5: replay the model rule

The model check is two small shell functions. Extract them and feed them names:

sed -n '/^norm()/p; /^model_matches()/,/^}/p' hwcheck-site.sh > match.sh
. ./match.sh
for pair in "H100|NVIDIA H100 80GB HBM3" "RTX 4090|NVIDIA GeForce RTX 3060 Ti" \
            "H100|NVIDIA H100 PCIe" "H100 80GB HBM3|NVIDIA H100 PCIe"; do
  listed=${pair%%|*}; measured=${pair#*|}
  if model_matches "$listed" "$measured"; then r=OK; else r="DOES NOT MATCH"; fi
  printf '%-16s vs %-28s %s\n' "$listed" "$measured" "$r"
done

H100             vs NVIDIA H100 80GB HBM3        OK
RTX 4090         vs NVIDIA GeForce RTX 3060 Ti   DOES NOT MATCH
H100             vs NVIDIA H100 PCIe             OK
H100 80GB HBM3   vs NVIDIA H100 PCIe             DOES NOT MATCH

Every word of the listed name that contains a digit must appear in the name the driver reports. The first line is the published H100 run: it follows from the rule. The second is the case the tool exists for: a cheaper card under a bigger name. The last two show the rule's reach. "H100" alone also accepts a card whose driver reports "NVIDIA H100 PCIe", a different board. Passing the full name, "H100 80GB HBM3", rejects it.

Step 6: run it on your own machine

This needs a Linux machine with an NVIDIA GPU. Ours is a workstation with an RTX 3060 Ti, under WSL2, without PyTorch. First the true listing, then a false one:

curl -fsSL https://voltagegpu.com/hwcheck.sh | bash -s -- --gpu "RTX 3060 Ti" --gpus 1 --vram 8 --no-net; echo "exit code: $?"
curl -fsSL https://voltagegpu.com/hwcheck.sh | bash -s -- --gpu "RTX 4090" --gpus 1 --vram 24 --no-net; echo "exit code: $?"

VoltageGPU hardware check (read-only, nothing about this machine is sent anywhere)
  2026-10-20 13:13 UTC · <hostname>

                 LISTED                   MEASURED                           
  GPU model      RTX 3060 Ti              NVIDIA GeForce RTX 3060 Ti         OK
  GPU count      1                        1                                  OK
  VRAM per GPU   8 GB                     8 GB                               OK
  Driver / CUDA                           610.88 / ?                         OK
  CUDA compute                            not tested (no PyTorch)            info
  CPU                                     12 threads                         info
  RAM            -                        16 GB                              info
  Disk (/)       -                        1007 GB, 936 GB free               info

RESULT: MATCHES THE LISTING
exit code: 0
VoltageGPU hardware check (read-only, nothing about this machine is sent anywhere)
  2026-10-20 13:13 UTC · <hostname>

                 LISTED                   MEASURED                           
  GPU model      RTX 4090                 NVIDIA GeForce RTX 3060 Ti         DOES NOT MATCH
  GPU count      1                        1                                  OK
  VRAM per GPU   24 GB                    8 GB                               DOES NOT MATCH
  Driver / CUDA                           610.88 / ?                         OK
  CUDA compute                            not tested (no PyTorch)            info
  CPU                                     12 threads                         info
  RAM            -                        16 GB                              info
  Disk (/)       -                        1007 GB, 936 GB free               info

RESULT: DOES NOT MATCH THE LISTING (GPU model, VRAM)
Release the pod from your dashboard and write to contact@voltagegpu.com with this output.
exit code: 2

These match the two workstation files we published on 16 October (match, mismatch). Only the date and the free disk space differ. Note the "Driver / CUDA" row. The CUDA version shows as "?" because this driver's nvidia-smi labels it "CUDA UMD Version: 13.3", and the script looks for "CUDA Version:". The row still says OK, as line 75 predicts. Because the exit code is 0 or 2, you can put the command at the top of a startup script and stop as soon as a machine is wrong.

What this proves, and what it does not

Proved from the public files:

The script on the site is byte for byte the only version in the public repository, which was committed before the H100 run.
The published H100 result follows from that script's rules and the printed values. The driver name contains "H100", one GPU is visible, and a CUDA matrix product ran on it.
The tool says DOES NOT MATCH, and exits 2, when a card is listed under a bigger name. You can see that on your own machine.

Not proved:

That the published file is the unedited output of a real run. It is plain text, not signed. For that you trust us. The 16 October runs have a second copy in git; the H100 file does not.
Which script ran on 17 October. You can only check that today's site copy equals the public one.
Anything a host determined to cheat would hide. hwcheck reads what the driver reports, and whoever controls the machine can change that. Proof against the operator needs hardware attestation: a confidential VM where NVIDIA's service signs the GPU's evidence.
VRAM, RAM and disk in the H100 run. They were printed, not compared.
Which H100 board it was. The rule accepts any name containing "h100". The printed name, "NVIDIA H100 80GB HBM3", is the only clue.
Anything about another machine, or this one later. It is one machine at one moment, and the run used a direct rental, not a customer account.
Confidentiality. Standard machines have no enclave.

The run that counts is yours: rent the machine, pass every value from its listing (--gpu, --gpus, --vram, --ram, --disk), and keep the output. If you need proof that does not rest on what the host's driver says, rent a Confidential VM and generate the attestation yourself: https://voltagegpu.com/quickstart

Disclosure: I work on VoltageGPU, which published these runs. hwcheck is open source (MIT).

Verify a Confidential AI Inference Attestation Yourself

VoltageGPU — Tue, 20 Oct 2026 14:26:19 +0000

On 16 October 2026 we drew a random nonce and asked for the attestation evidence of every instance serving three confidential models. We published the raw responses, the nonce and the script that checked them. This tutorial re-checks one of the three, DeepSeek V3.2: nine instances, eight NVIDIA Hopper GPUs each. First online, against Intel and NVIDIA, the way the original run did it. Then the parts that need no network at all. You need no account, no API key and no GPU. At the end, what a pass proves and what it does not.

Every command below was run on 20 October 2026 on Ubuntu 24.04 with Python 3.12.3, in a fresh directory, exactly as printed. Outputs are pasted as printed; [...] marks a cut.

What was published

The files live under https://voltagegpu.com/inference-proofs/2026-10-16/. That path has no index page, so start with the README. For each model there are five files:

<model>.nonce.txt: our nonce, 32 random bytes in hex.
<model>.request.txt: the request, its time and its HTTP status.
<model>.evidence.json: the raw response, byte for byte. One entry per instance: an Intel TDX quote, the NVIDIA GPU evidence, a certificate, a signature and a signed body.
<model>.e2e-instances.json: each instance's end-to-end public key, read from the provider's instance listing.
<model>.verify.txt: the report printed on 16 October.

Plus the script, verify_inference_evidence.py, and SHA256SUMS.

One rule ties a quote to the nonce. The first 32 bytes of the quote's report_data must equal SHA256(nonce + e2e_pubkey), the nonce and the key joined as text. The GPU evidence uses the same value as its nonce. The rule comes from the model provider's public verification guide, which our inference docs point to.

Step 1: install the two verifiers

mkdir inference-check && cd inference-check
python3 -m venv .venv && . .venv/bin/activate
pip install -q voltage-verify==0.2.1 nv-attestation-sdk cryptography
voltage-verify --version
pip show nv-attestation-sdk | grep Version

voltage-verify 0.2.1
Version: 2.7.3

voltage-verify checks the Intel side. It is our open-source verifier (MIT, source). nv-attestation-sdk is NVIDIA's package for the GPU side. These are the versions the original run used.

Step 2: download one model's files and check the checksums

mkdir inference-2026-10-16 && cd inference-2026-10-16
BASE=https://voltagegpu.com/inference-proofs/2026-10-16
M=deepseek-ai_DeepSeek-V3.2-TEE
for f in README.txt SHA256SUMS verify_inference_evidence.py $M.nonce.txt $M.request.txt \
         $M.evidence.json $M.e2e-instances.json $M.verify.txt; do
  curl -sSfO "$BASE/$f"
done
sha256sum -c SHA256SUMS --ignore-missing

README.txt: OK
deepseek-ai_DeepSeek-V3.2-TEE.e2e-instances.json: OK
deepseek-ai_DeepSeek-V3.2-TEE.evidence.json: OK
deepseek-ai_DeepSeek-V3.2-TEE.nonce.txt: OK
deepseek-ai_DeepSeek-V3.2-TEE.request.txt: OK
deepseek-ai_DeepSeek-V3.2-TEE.verify.txt: OK
verify_inference_evidence.py: OK

The checksums come from the same site as the files. They catch a broken download, not a dishonest publisher. The checks below do not depend on them.

Step 3: re-run the published check

The script writes its report to <model>.verify.txt and replaces the published one, so keep a copy first.

cp $M.verify.txt published.verify.txt
python verify_inference_evidence.py . $M voltage-verify

For each instance, the script runs voltage-verify quote, which fetches Intel's current data for that platform. Then it sends the GPU evidence to NVIDIA's attestation service. Nine instances took about a minute and a half. Here is what our replay of these exact commands printed:

.../verify_inference_evidence.py:60: DeprecationWarning: nv-attestation-sdk is deprecated and will reach end of support on September 15, 2026. Please migrate to the C++ SDK: https://github.com/NVIDIA/attestation-sdk. Migration guide: https://docs.nvidia.com/attestation/attestation-client-tools-sdk/latest/migration_guide.html
  client = Attestation()
Using default Remote verifier URL: https://nras.attestation.nvidia.com/v3/attest/gpu
**** Attestation Successful ****
[... NVIDIA's progress lines, cut ...]
verified_at: 2026-10-20T13:08:06+00:00
nonce (ours, random 32 bytes): 28231ce10fdb9cfd72bf1199f05fdf46705966b74efe0c24fe2ee37490772b69
verifiers: voltage-verify 0.2.1; nv-attestation-sdk (NVIDIA NRAS, remote)
instances returned: 9

instance 2124d84a-d402-4914-9db4-fa4d94e2b24f
  intel tdx quote  : PASS (platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate)
  nonce binding    : PASS report_data[0:32] = fda470f1a58bd95116f318242689e0370436322b753816ae4ca1ef7a659a191e
  debug bit        : OFF (td_attributes 0000001000000000)
  key possession   : PASS
  nvidia gpus      : PASS (8 GPU(s), arch HOPPER)
  mr_td            : 261ce538b435e2d0e85fc97e254bc99154c507b7a8e13d59b69f8532384f1d0bfaadfddf3fccc6e0a411203840bbee8d

[... 3 instances with the same lines ...]

instance 4c1f21af-821a-4d25-99a3-d0451a146db9
  intel tdx quote  : FAIL tdx.tcb ()
  nonce binding    : PASS report_data[0:32] = b6476aacc2f17f27113cb7f5aa3a9067b8e18aaa6064fe8ce9e0b6c6aee6b1e0
  debug bit        : OFF (td_attributes 0000001000000000)
  key possession   : PASS
  nvidia gpus      : PASS (8 GPU(s), arch HOPPER)
  mr_td            : 261ce538b435e2d0e85fc97e254bc99154c507b7a8e13d59b69f8532384f1d0bfaadfddf3fccc6e0a411203840bbee8d

[... 4 instances with the same lines as the first ...]

RESULT: 8 of 9 instance(s) fully verified (Intel quote, our nonce, key possession, NVIDIA GPUs)
        1 instance(s) FAILED a check, see above

Each instance gets five checks:

intel tdx quote: the quote's signature chain up to Intel's root, the platform's security level according to Intel's current data, and revocation.
nonce binding: the rule above, report_data[0:32] == SHA256(nonce + e2e_pubkey).
debug bit: the guest's debug attribute is off.
key possession: the signed body verifies with the instance's certificate, and it carries our nonce and this same quote.
nvidia gpus: NVIDIA's service accepted the GPU evidence for the same nonce value.

The NVIDIA deprecation notice is printed by NVIDIA's own package. The remote check still answered on 20 October 2026.

If one instance fails: check it alone

One instance failed tdx.tcb, with nothing in the parentheses. Take its quote out and check it on its own:

jq -r '.evidence[] | select(.instance_id == "4c1f21af-821a-4d25-99a3-d0451a146db9") | .quote' \
  $M.evidence.json > failed.b64
voltage-verify quote failed.b64
python verify_inference_evidence.py . $M voltage-verify 2>/dev/null | grep RESULT

[PASS] tdx.structure   TDX quote v4, TEE 0x81, 4936 bytes
[PASS] tdx.signatures  attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral  TCB info and QE identity signed by Intel (Intel PCS, fetched now)
[PASS] tdx.tcb         platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
[PASS] tdx.revocation  PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation  PCK CA certificate not revoked (0 entries in CRL)

TDX: MRTD 261ce538b435e2d0e85fc97e254bc991...  TCB UpToDate  QE UpToDate

RESULT: VERIFIED
RESULT: 9 of 9 instance(s) fully verified (Intel quote, our nonce, key possession, NVIDIA GPUs)

The quote is fine, and the second full run passed all nine. The first failure was not about the quote. Each check makes four requests to Intel: platform data, quoting enclave identity and two revocation lists. voltage-verify does not retry them. If one request fails, the result is a tdx.tcb failure that carries the reason. The published script prints the detail of the fourth check in the list. In a normal run that is the TCB line. When the Intel data cannot be fetched, there is no fourth check, so the parentheses stay empty and the reason is lost. That day we also ran 54 direct checks with voltage-verify quote --json. One failed, and its JSON report gave this detail for tdx.tcb:

cannot reach https://api.trustedservices.intel.com/sgx/certification/v4/pckcrl?ca=platform&encoding=pem: [Errno 111] Connection refused

Two of our five full runs on 20 October hit one such failure, each on a different instance. The other three passed nine of nine. Once the run passes, compare it with the published report:

diff published.verify.txt $M.verify.txt

1c1
< verified_at: 2026-10-16T08:05:27+00:00
---
> verified_at: 2026-10-20T13:11:08+00:00

Only the date differs. Intel's view of a platform can change over time, so a re-check reflects Intel's data on the day you run it.

Step 4: the parts that need no network

Some checks need no outside service. We ran this step inside unshare -n, a shell with no network (curl could not resolve any host: exit code 6). The outputs were the same.

First, the quote signatures, up to the Intel root that voltage-verify pins:

for i in $(seq 0 8); do jq -r ".evidence[$i].quote" $M.evidence.json > quote-$i.b64; done
voltage-verify quote quote-0.b64 --offline
for i in $(seq 0 8); do voltage-verify quote quote-$i.b64 --offline | tail -1; done

[PASS] tdx.structure   TDX quote v4, TEE 0x81, 4940 bytes
[PASS] tdx.signatures  attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[WARN] tdx.collateral  Intel collateral skipped (--offline): TCB status and revocation not checked

TDX: MRTD 261ce538b435e2d0e85fc97e254bc991...  TCB ?  QE ?

RESULT: VERIFIED
RESULT: VERIFIED
RESULT: VERIFIED
RESULT: VERIFIED
RESULT: VERIFIED
RESULT: VERIFIED
RESULT: VERIFIED
RESULT: VERIFIED
RESULT: VERIFIED
RESULT: VERIFIED

The first block is quote 0 in full. The nine lines after it are one per quote. The WARN line says plainly what offline mode skips.

Next, the nonce binding and the debug bit, without any of our tools. A TDX quote is a fixed binary layout: a 48-byte header, then the guest's report. The attributes start at byte 168, the MRTD at byte 184 and report_data at byte 568. Save this as offline_check.py in the inference-check folder, one level above the evidence:

"""Offline re-check of published inference evidence: nonce binding and debug bit,
read straight from the TDX quote bytes. Standard library only, no network.
Usage: python3 offline_check.py <folder> <model-file-prefix> [nonce]"""
import base64
import hashlib
import json
import sys
from pathlib import Path

folder, prefix = Path(sys.argv[1]), sys.argv[2]
nonce = sys.argv[3] if len(sys.argv) > 3 else (folder / f"{prefix}.nonce.txt").read_text().strip()
evidence = json.loads((folder / f"{prefix}.evidence.json").read_text())["evidence"]
listing = json.loads((folder / f"{prefix}.e2e-instances.json").read_text())["instances"]
keys = {i["instance_id"]: i["e2e_pubkey"] for i in listing}

bound = 0
for inst in evidence:
    q = base64.b64decode(inst["quote"])
    # TDX quote v4: 48-byte header, then the TD report (attributes, MRTD, ..., report_data).
    version, tee = int.from_bytes(q[0:2], "little"), int.from_bytes(q[4:8], "little")
    td_attributes, mr_td, report_data = q[168:176], q[184:232], q[568:632]
    key = keys.get(inst["instance_id"])
    expected = hashlib.sha256((nonce + key).encode()).hexdigest() if key else None
    ok = expected == report_data[:32].hex()
    bound += ok
    print(f'{inst["instance_id"]}  v{version} tee={tee:#x}  nonce {"BOUND" if ok else "NOT BOUND"}  '
          f'debug {"ON" if td_attributes[0] & 1 else "off"}  mr_td {mr_td.hex()[:16]}...')
print(f"{bound} of {len(evidence)} quotes carry SHA256(nonce + e2e_pubkey) in report_data")

python3 ../offline_check.py . $M
python3 ../offline_check.py . $M 0000000000000000000000000000000000000000000000000000000000000000 | tail -2

2124d84a-d402-4914-9db4-fa4d94e2b24f  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
8fe1275c-a5a2-47e9-9d47-091f3242ef5a  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
e2db3683-5be1-4a33-a47c-cd422caadf3a  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
8c94bf65-2006-4de3-a526-f9f4e55c2604  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
4c1f21af-821a-4d25-99a3-d0451a146db9  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
b45cd4dc-7e41-468d-bc42-39aa7d6cfb3a  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
bd6f497a-64a1-4b5c-8ca6-45657db054dd  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
2bd97006-3ea4-4973-8f15-04ecb856f5e8  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
c39fa043-d22c-4ed5-bb71-d46644793740  v4 tee=0x81  nonce BOUND  debug off  mr_td 261ce538b435e2d0...
9 of 9 quotes carry SHA256(nonce + e2e_pubkey) in report_data
c39fa043-d22c-4ed5-bb71-d46644793740  v4 tee=0x81  nonce NOT BOUND  debug off  mr_td 261ce538b435e2d0...
0 of 9 quotes carry SHA256(nonce + e2e_pubkey) in report_data

With the published nonce, all nine quotes are bound. With any other nonce, none is. The MRTD values match the published report.

Reading report_data from the bytes only counts if those bytes are covered by Intel's signature. Flip one bit of report_data and check again:

python3 - quote-0.b64 tampered.b64 <<'PY'
import base64, sys
q = bytearray(base64.b64decode(open(sys.argv[1]).read()))
q[568] ^= 1  # flip one bit of report_data
open(sys.argv[2], "w").write(base64.b64encode(q).decode())
PY
voltage-verify quote tampered.b64 --offline

[PASS] tdx.structure   TDX quote v4, TEE 0x81, 4940 bytes
[FAIL] tdx.signatures  quote signature does not verify with the attestation key: 

TDX: MRTD 261ce538b435e2d0e85fc97e254bc991...  TCB ?  QE ?

RESULT: NOT VERIFIED (tdx.signatures)

So the two offline checks work together. The signature proves the bytes are Intel's. The byte reading proves those bytes commit to the nonce. Two things cannot be checked offline. The platform's security level and revocation need Intel's current data. The GPU evidence needs NVIDIA's service.

What this proves, and what it does not

Proved, for DeepSeek V3.2 at 08:04 UTC on 16 October 2026. Each of the nine instances serving the model:

returned a genuine Intel TDX quote. Its signature chain verifies up to Intel's root (offline), and Intel's data on 20 October rates the platform UpToDate (online);
had debug off;
put SHA256(our nonce + its E2E public key) in its quote. So the quote was made after that nonce existed, and it commits to that key;
signed a body carrying our nonce and that same quote;
had eight NVIDIA Hopper GPUs whose evidence NVIDIA's attestation service accepted, for the same nonce value.

All nine report the same MRTD (261ce538...), the TDX measurement of the guest's initial contents.

Not proved:

Which code the instances run. No reference measurements are published yet. The MRTD is a value you can compare over time, not a verdict.
That a given chat response came from one of these instances. The evidence covers the instances, not each response.
Anything about the path from you to the instance. Requests go through VoltageGPU's API over TLS. There is no end-to-end encryption from your client into the enclave.
Freshness relative to you. We drew this nonce, so you trust our date. For your own guarantee, draw your own nonce and call GET /v1/attestation. That needs an inference key.
Who issued the signing certificate. The certificate behind "key possession" arrives in the same response, issued by the provider's own certificate authority. The script checks the signature, not that issuer.
Instances missing from the provider's key listing. Their binding cannot be recomputed. In the same run, 12 of 55 Qwen 3.8 instances are reported NOT CHECKABLE for that reason.
A GPU result that will last. The GPU check depends on NVIDIA's service and on a Python package NVIDIA no longer supports. It still answered on 20 October 2026.

Every proof we publish, with the command to rerun it, is at https://voltagegpu.com/proofs.

To fetch evidence for your own nonce, create an inference key and start here: https://voltagegpu.com/quickstart

Disclosure: I work on VoltageGPU, which published this evidence.

Watch GPU Prices and Availability From a Public JSON

VoltageGPU — Tue, 20 Oct 2026 14:26:11 +0000

VoltageGPU publishes its live prices and stock as one public JSON document at https://voltagegpu.com/api/pricing/snapshot. There is no key and no account. The site's pricing pages are built from the same snapshot. This tutorial walks through its structure and explains what each field means, checked against the code that builds it. Then it gives you a 35-line Python script. The script prints the cheapest GPU in stock for each model and alerts you when a model comes back in stock.

Every command below was run on 20 October 2026 on Ubuntu 24.04 with Python 3.12.3 and jq 1.7, in a fresh directory, exactly as printed. Outputs are pasted as printed. Prices and stock are live, so yours will differ.

Step 1: fetch it once

curl -s https://voltagegpu.com/api/pricing/snapshot -o snapshot.json
jq 'keys' snapshot.json

[
  "confidential",
  "confidentialCpu",
  "confidentialVm",
  "gpus",
  "inference",
  "meta",
  "teeModelCount"
]

confidentialVm: Confidential VMs (Intel TDX), one entry per size in tiers.
confidential: the same VMs, summed up as one row per GPU model.
gpus: standard GPUs, with no enclave.
confidentialCpu: confidential CPU servers.
inference: per-token prices of the confidential (TEE) models.
teeModelCount: how many confidential models there are.
meta: when the snapshot was built, plus notes.

Step 2: read the metadata

jq '.meta' snapshot.json

{
  "updatedAt": "2026-10-20T13:07:49.258Z",
  "stale": false,
  "scope": "rentable",
  "notes": [
    "Only what can be rented today.",
    "confidential: one row per GPU model, derived from the Confidential VM tiers (pricePerGpuHour = VM price / GPU count, available = free GPUs). The confidential container tier retired on 2026-10-01 is no longer listed.",
    "confidentialVm.tiers[].pricePerHour is the whole VM per hour; pricePerGpuHour = pricePerHour / gpuCount.",
    "gpus: standard GPUs with no enclave (not confidential), live stock only.",
    "B200 and B300 are listed only when in stock, and NVIDIA GPU attestation is not verified on them."
  ]
}

updatedAt is when the server built this snapshot. stale turns true when the server got no live standard GPUs or no live model prices, and used stored values instead. It does not cover the Confidential VM inventory. If that read fails, confidentialVm.tiers comes back empty. scope: "rentable" means the feed lists only what can be rented today.

Step 3: the Confidential VMs

jq '.confidentialVm.tiers[0]' snapshot.json
jq -c '.confidentialVm.tiers[] | {resourceName, gpuCount, pricePerHour, pricePerGpuHour, available, gpuAttestation}' snapshot.json

{
  "resourceName": "rtx6000b-small",
  "model": "RTX 6000B",
  "gpuCount": 1,
  "vram": "96 GB",
  "pricePerHour": 3.8,
  "available": 7,
  "gpuAttestation": true,
  "pricePerGpuHour": 3.8,
  "enclave": "intel-tdx",
  "label": "Confidential VM (Intel TDX)"
}
{"resourceName":"rtx6000b-small","gpuCount":1,"pricePerHour":3.8,"pricePerGpuHour":3.8,"available":7,"gpuAttestation":true}
{"resourceName":"h100-small","gpuCount":1,"pricePerHour":6.95,"pricePerGpuHour":6.95,"available":6,"gpuAttestation":true}
{"resourceName":"h200-small","gpuCount":1,"pricePerHour":8.08,"pricePerGpuHour":8.08,"available":0,"gpuAttestation":true}
{"resourceName":"h100-xlarge","gpuCount":8,"pricePerHour":55.62,"pricePerGpuHour":6.95,"available":0,"gpuAttestation":true}
{"resourceName":"h200-xlarge","gpuCount":8,"pricePerHour":64.62,"pricePerGpuHour":8.08,"available":0,"gpuAttestation":false}

resourceName is the size's name. It is the value you pass as resource_name when you deploy; the quickstart uses rtx6000b-small.
pricePerHour is the whole VM, per hour, in US dollars. pricePerGpuHour is that price divided by gpuCount.
available is how many VMs of that size are free right now. A size at 0 stays in the list.
gpuAttestation is true when we have run NVIDIA GPU attestation successfully inside a VM of that model and size. It is false for h200-xlarge, the 8x H200 node, where we have not run it.
enclave is intel-tdx on every VM.

Next to tiers, confidentialVm repeats the fields of a single size (h200-small) for older readers of the feed. Read tiers.

Step 4: the same VMs, per GPU model

jq -c '.confidential[]' snapshot.json

{"model":"H200","vram":"141 GB","pricePerGpuHour":8.08,"available":0,"maxGpuCount":8,"provider":"confidential"}
{"model":"H100","vram":"80 GB","pricePerGpuHour":6.95,"available":6,"maxGpuCount":8,"provider":"confidential"}
{"model":"RTX 6000B","vram":"96 GB","pricePerGpuHour":3.8,"available":7,"maxGpuCount":1,"provider":"confidential"}

Each row is computed from the tiers above. pricePerGpuHour is the cheapest GPU-hour among the sizes in stock, or among all sizes when none is (H200 here). available counts free GPUs: free VMs times GPUs per VM. For H100 that is six free h100-small VMs with one GPU each. maxGpuCount is the largest size, here the 8-GPU h100-xlarge, even though none is free. Rows are sorted most expensive first.

Step 5: the standard GPUs

jq '.gpus[] | select(.model == "RTX 4090")' snapshot.json
jq -c '.gpus[] | {model, pricePerHour, available}' snapshot.json

{
  "model": "RTX 4090",
  "vram": "24 GB",
  "pricePerHour": 1.12,
  "available": 13,
  "provider": "standard",
  "enclave": "none",
  "gpuAttestation": false,
  "label": "Standard GPU (no enclave, not confidential)"
}
{"model":"RTX A4000","pricePerHour":0.24,"available":8}
{"model":"RTX 5060 Ti","pricePerHour":0.34,"available":6}
{"model":"RTX 5070 Ti","pricePerHour":0.8,"available":1}
{"model":"B300","pricePerHour":19,"available":32}
{"model":"B200","pricePerHour":9,"available":41}
{"model":"H100","pricePerHour":4,"available":66}
{"model":"A100","pricePerHour":2.38,"available":16}
{"model":"RTX PRO 6000","pricePerHour":4.18,"available":8}
{"model":"RTX 5090","pricePerHour":1.6,"available":9}
{"model":"RTX 4090","pricePerHour":1.12,"available":13}
{"model":"L40S","pricePerHour":0.76,"available":1}
{"model":"L40","pricePerHour":0.66,"available":1}
{"model":"RTX 6000","pricePerHour":1.6,"available":13}
{"model":"A6000","pricePerHour":0.84,"available":3}

Standard machines have no enclave. The feed says so in enclave, gpuAttestation and label, so you can filter them out.

Here pricePerHour is per GPU-hour: the lowest per-GPU price among free machines of that model. available counts the GPUs on machines that can be rented whole right now. A standard machine is rented whole, so a machine with 8 GPUs costs 8 times its per-GPU price, per hour. A model with no free machine is left out of gpus entirely, unlike a VM size, which stays at 0. vram can be an empty string when the site has no figure for a model; that was the case for the RTX A4000 that day.

Step 6: inference prices

jq '.inference[0]' snapshot.json
jq -c '[(.inference | length), .teeModelCount]' snapshot.json

{
  "id": "42ee92ba-a537-5a73-8741-876067750db7",
  "name": "google/gemma-4-31B-turbo-TEE",
  "category": "LLM",
  "priceInputPerM": 0.22,
  "priceOutputPerM": 0.68
}
[14,14]

These are US dollars per million input and output tokens, for the confidential models. name is the exact model id the API expects. The list is read from the model catalog, at most 15 rows. teeModelCount is the number of confidential models. On 20 October both were 14.

Step 7: how fresh it is

curl -s -D - -o /dev/null https://voltagegpu.com/api/pricing/snapshot | grep -i -E '^(cache-control|age|x-vercel-cache):'

age: 331
cache-control: public, max-age=60, s-maxage=300, stale-while-revalidate=600
x-vercel-cache: STALE

The edge keeps a copy for 5 minutes. For 10 more minutes it may serve that copy while it fetches a new one in the background. That is what STALE and an age of 331 seconds mean here. The server also keeps its own build for 5 minutes. So asking more often than every 5 minutes gets you the same answer, and the data can be several minutes old. meta.updatedAt tells you how old.

Step 8: a watcher in 35 lines

Save this as gpu_watch.py. It uses only Python's standard library.

"""Cheapest in-stock GPU per model, from VoltageGPU's public pricing feed.
Run it every 5 minutes at most (the feed is cached for 5). It prints an ALERT
for each model in stock now that was not in stock on the previous run."""
import json
import sys
import urllib.request
from pathlib import Path

FEED = "https://voltagegpu.com/api/pricing/snapshot"
STATE = Path(sys.argv[1] if len(sys.argv) > 1 else "gpu-watch-state.json")

request = urllib.request.Request(FEED, headers={"User-Agent": "gpu-watch/1.0"})
with urllib.request.urlopen(request, timeout=20) as response:
    feed = json.load(response)

# Confidential VM tiers stay listed at 0 when sold out; standard rows only when in stock.
offers = [(f'{t["model"]} confidential', t["pricePerGpuHour"],
           f'{t["resourceName"]}: {t["available"]} VM free, {t["gpuCount"]} GPU each')
          for t in feed["confidentialVm"]["tiers"] if t["available"] > 0]
offers += [(f'{g["model"]} standard', g["pricePerHour"], f'{g["available"]} GPU free, no enclave')
           for g in feed["gpus"] if g["available"] > 0]

cheapest = {}  # "H100 confidential" -> (price per GPU-hour, details)
for key, price, details in offers:
    if key not in cheapest or price < cheapest[key][0]:
        cheapest[key] = (price, details)

print(f'feed built {feed["meta"]["updatedAt"]}, stale: {feed["meta"]["stale"]}')
for key, (price, details) in sorted(cheapest.items(), key=lambda kv: ("standard" in kv[0], kv[1][0])):
    print(f"{key:24} ${price:6.2f}/GPU-h  {details}")

seen = set(json.loads(STATE.read_text())) if STATE.exists() else set(cheapest)
for key in sorted(set(cheapest) - seen):
    print(f"ALERT: {key} is in stock again, ${cheapest[key][0]:.2f}/GPU-h")
STATE.write_text(json.dumps(sorted(cheapest)))

What it does:

It keeps only offers that are in stock: VM sizes with available > 0, and standard rows.
It keys each offer by model and kind. "H100 confidential" and "H100 standard" are different products, and they stay apart.
For each key, it keeps the lowest price per GPU-hour. For a VM it also keeps the size to deploy.
It prints confidential offers first, then standard ones, each sorted by price.
It saves the keys that are in stock to a small state file. On the next run, a key that is in stock now but was not last time prints an ALERT. The first run only creates the file.

python3 gpu_watch.py

feed built 2026-10-20T13:07:49.258Z, stale: False
RTX 6000B confidential   $  3.80/GPU-h  rtx6000b-small: 7 VM free, 1 GPU each
H100 confidential        $  6.95/GPU-h  h100-small: 6 VM free, 1 GPU each
RTX A4000 standard       $  0.24/GPU-h  8 GPU free, no enclave
RTX 5060 Ti standard     $  0.34/GPU-h  6 GPU free, no enclave
L40 standard             $  0.66/GPU-h  1 GPU free, no enclave
L40S standard            $  0.76/GPU-h  1 GPU free, no enclave
RTX 5070 Ti standard     $  0.80/GPU-h  1 GPU free, no enclave
A6000 standard           $  0.84/GPU-h  3 GPU free, no enclave
RTX 4090 standard        $  1.12/GPU-h  13 GPU free, no enclave
RTX 5090 standard        $  1.60/GPU-h  9 GPU free, no enclave
RTX 6000 standard        $  1.60/GPU-h  13 GPU free, no enclave
A100 standard            $  2.38/GPU-h  16 GPU free, no enclave
H100 standard            $  4.00/GPU-h  66 GPU free, no enclave
RTX PRO 6000 standard    $  4.18/GPU-h  8 GPU free, no enclave
B200 standard            $  9.00/GPU-h  41 GPU free, no enclave
B300 standard            $ 19.00/GPU-h  32 GPU free, no enclave

The H200 Confidential VM is missing from the list because none was free. The state file and a second run:

cat gpu-watch-state.json

["A100 standard", "A6000 standard", "B200 standard", "B300 standard", "H100 confidential", "H100 standard", "L40 standard", "L40S standard", "RTX 4090 standard", "RTX 5060 Ti standard", "RTX 5070 Ti standard", "RTX 5090 standard", "RTX 6000 standard", "RTX 6000B confidential", "RTX A4000 standard", "RTX PRO 6000 standard"]

python3 gpu_watch.py | grep ALERT || echo "no alert"

no alert

Step 9: leave it running

Run it every 5 minutes. A loop is enough to try it; for good, use cron or a systemd timer. Here is the loop we left running for an hour on 20 October:

date -u +%FT%TZ > watch.log
for i in $(seq 12); do python3 gpu_watch.py | grep -E "^(feed built|ALERT)"; sleep 300; done >> watch.log 2>&1
date -u +%FT%TZ >> watch.log
cat watch.log

2026-10-20T12:55:00Z
feed built 2026-10-20T12:53:11.535Z, stale: False
feed built 2026-10-20T12:58:48.555Z, stale: False
feed built 2026-10-20T13:04:13.105Z, stale: False
ALERT: L40S standard is in stock again, $0.76/GPU-h
feed built 2026-10-20T13:07:49.258Z, stale: False
feed built 2026-10-20T13:13:38.191Z, stale: False
feed built 2026-10-20T13:13:38.191Z, stale: False
feed built 2026-10-20T13:21:00.445Z, stale: False
feed built 2026-10-20T13:26:13.620Z, stale: False
ALERT: H200 standard is in stock again, $8.14/GPU-h
feed built 2026-10-20T13:31:26.465Z, stale: False
feed built 2026-10-20T13:36:39.415Z, stale: False
feed built 2026-10-20T13:41:52.421Z, stale: False
feed built 2026-10-20T13:47:06.377Z, stale: False
2026-10-20T13:57:31Z

That is twelve polls, five minutes apart. The times are when each snapshot was built, not when we polled. Two polls in a row got the same snapshot (13:13:38): that is the cache from step 7. Two alerts fired. An L40S standard GPU came into stock in the snapshot built at 13:04, and an H200 standard GPU in the one built at 13:26. No alert concerned a Confidential VM. The five full snapshots we read that afternoon show the same five sizes, prices and stock.

What this tells you, and what it does not

It tells you the prices and stock the site shows, as of meta.updatedAt. GPU prices are public hourly prices in US dollars.

It does not tell you:

That a GPU will still be free when you deploy. Stock is a snapshot, and someone else can take the last VM between your read and your deploy.
What a standard machine costs in total. gpus[].pricePerHour is per GPU. The machine you rent may have several GPUs, and you pay for all of them.
That a confidential alert is real after a failed read. If the VM inventory cannot be read, confidentialVm.tiers comes back empty, and meta.stale does not flag it. The script then sees every confidential model as gone, and the next good read raises alerts for models that never left. Check that tiers is not empty before you act on a confidential alert.
Anything about the machine you will get. gpuAttestation: true means we have run NVIDIA GPU attestation successfully inside a VM of that model and size. It does not attest your VM. You generate that attestation yourself, inside your VM. The proofs we publish are listed at https://voltagegpu.com/proofs.
Confidentiality for standard GPUs. They have no enclave. The feed labels them so.

When the GPU you want shows up, the quickstart deploys a Confidential VM in three API calls: https://voltagegpu.com/quickstart

Disclosure: I work on VoltageGPU, whose public feed this is.

Verify an Intel TDX Quote From Any Cloud in One Command

VoltageGPU — Mon, 19 Oct 2026 11:42:46 +0000

A TDX quote is the CPU's signed statement that a virtual machine is a genuine Intel TDX trust domain, with its measurements and 64 bytes of data the guest chose. Any provider selling confidential VMs can hand you one. The useful part is checking it yourself, without trusting the provider or its tooling. That takes one command, and it works on a quote from any cloud.

Step 1: get a quote and the tool

This uses a public quote captured on 4 September 2026 inside an Intel TDX VM with one H200, together with the 64-byte report_data the tenant chose (README).

curl -sO https://voltagegpu.com/blog/two-proofs/evidence/quote.bin
curl -sO https://voltagegpu.com/blog/two-proofs/evidence/report_data.bin
pip install "voltage-verify>=0.2.1"

Step 2: verify it against Intel

voltage-verify quote quote.bin --report-data "$(xxd -p -c 64 report_data.bin)"

What it printed on my machine on 19 October 2026:

[PASS] tdx.structure    TDX quote v4, TEE 0x81, 4936 bytes
[PASS] tdx.report_data  quote report_data equals the expected value
[PASS] tdx.signatures   attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral   TCB info and QE identity signed by Intel (Intel PCS, fetched now)
[PASS] tdx.tcb          platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
[PASS] tdx.revocation   PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation   PCK CA certificate not revoked (0 entries in CRL)

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate

RESULT: VERIFIED

Structure first, then your report_data, then the signature chain up to the pinned Intel SGX root. Last, the verifier fetches Intel's current collateral and confirms the platform security level is up to date and nothing in the chain is revoked.

Step 3: see it refuse

The same quote, with a challenge it was not issued for:

voltage-verify quote quote.bin --report-data "$(printf '00%.0s' $(seq 64))"
# [FAIL] tdx.report_data  quote report_data does NOT equal the expected value: not issued for your nonce
# RESULT: NOT VERIFIED (tdx.report_data)

Without network, structure and signatures still verify, but the verifier says what it skipped:

voltage-verify quote quote.bin --offline
# [WARN] tdx.collateral  Intel collateral skipped (--offline): TCB status and revocation not checked
# RESULT: VERIFIED

Step 4: do it on your own TDX guest

On a Linux TDX guest that exposes configfs TSM (kernel 6.7 or later), pick a challenge, write its SHA-512 into a fresh report entry, read the quote back, and verify it on another machine:

NONCE=$(openssl rand -hex 32)
RD=$(printf %s "$NONCE" | sha512sum | cut -d' ' -f1)
sudo mkdir /sys/kernel/config/tsm/report/q1
printf %s "$RD" | xxd -r -p | sudo tee /sys/kernel/config/tsm/report/q1/inblob > /dev/null
sudo cat /sys/kernel/config/tsm/report/q1/outblob > quote.bin

voltage-verify quote quote.bin --report-data "$RD"

What a quote does not prove

It proves a genuine TDX guest on a platform Intel rates, and that the quote was not altered. It does not prove which software runs in the guest unless you compare MRTD and RTMR0 to 3 with a reference you trust, and it says nothing about a GPU: that takes a separate NVIDIA attestation, covered in the bundle tutorial.

Source of the tool: github.com/VoltageGPU/voltage-verify (MIT).

Disclosure: I work on VoltageGPU, where this quote was captured. The verifier is open source and does not trust us.

Verify a Confidential GPU Attestation Offline in Five Minutes, No Account Needed

VoltageGPU — Mon, 19 Oct 2026 00:12:31 +0000

Every confidential computing vendor says your workload runs in a sealed enclave. The useful question is whether you can check that claim without trusting the vendor.

This tutorial does exactly that with a real bundle captured on 9 October 2026 inside an Intel TDX virtual machine with one NVIDIA RTX PRO 6000 Blackwell GPU, rented through a public API like any customer would. You verify it with an MIT-licensed tool, on your laptop, offline if you like. No account, no GPU rental, about five minutes.

What is in a bundle

Two proofs, both tied to the same manifest. The manifest holds a random challenge.

The Intel TDX quote carries the SHA-512 of the manifest in its report_data, signed by the platform's quoting enclave with a key that chains to Intel.
The NVIDIA tokens carry the SHA-256 of the same manifest as their nonce, signed by NVIDIA's attestation service after it checked the GPU's own report.

The bundle also embeds the Intel collateral captured at attest time (TCB info, QE identity, revocation lists), which is what makes an offline check possible.

Step 1: download it and check the checksums

mkdir bundle && cd bundle
curl -sO https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-2026-10-09/bundle.json
curl -sO https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-2026-10-09/manifest.json
curl -sO https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-2026-10-09/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing
# manifest.json: OK
# bundle.json: OK

The checksums were computed inside the VM before download. The same folder has what the script printed inside the VM, nvidia-smi output and kernel details (README.txt).

Step 2: install the verifier

python3 -m venv .venv && . .venv/bin/activate
pip install "voltage-verify>=0.2.1"

Python 3.10 or later. Use 0.2.1 or later: 0.2.0 and earlier trusted the NVIDIA signing keys a bundle carried, 0.2.1 chains them to a pinned NVIDIA attestation service intermediate. Source: github.com/Jabsama/voltage-verify.

Step 3: verify, offline

voltage-verify verify bundle.json --offline \
  --challenge 627ba9c51d4719038e917c7431675b183ac576c819d712178dc8a100f4409a45 \
  --hwmodel GB20X --gpus 1

What it printed on my machine on 19 October 2026:

[PASS] manifest.format       manifest is well formed
[PASS] manifest.commitments  bundle commitments match the manifest
[PASS] manifest.challenge    challenge is the one this verifier issued
[PASS] tdx.structure         TDX quote v4, TEE 0x81, 4940 bytes
[PASS] tdx.report_data       quote report_data equals SHA-512 of the manifest
[PASS] tdx.signatures        attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral        TCB info and QE identity signed by Intel (bundle (fetched 2026-10-09T21:54:01+00:00))
[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_03 UpToDate
[PASS] tdx.revocation        PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation        PCK CA certificate not revoked (0 entries in CRL)
[PASS] nvidia.signatures     2 NVIDIA-signed tokens verify, keys from the bundle chained to the pinned NRAS intermediate (offline)
[PASS] nvidia.nonce          NRAS eat_nonce equals SHA-256 of the manifest
[PASS] nvidia.policy         overall result true, every GPU: measurements ok, secure boot on, debug off, nonce matched, report signature and chain validated
[PASS] nvidia.freshness      token issued 0s from bundle creation

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate
GPU: GPU-0 GB20X driver 595.71.05 vbios 98.02.9E.00.01 measurements success

RESULT: VERIFIED

Read it in three groups:

manifest: the bundle belongs to this manifest and to the challenge you passed.
tdx: the quote's structure, that it embeds the manifest hash, its signature chain up to the pinned Intel SGX root, the Intel-signed platform status (TCB UpToDate), and that nothing in the chain is revoked.
nvidia: NVIDIA's signatures, the nonce, and NVIDIA's own verdict on the GPU: measurements ok, secure boot on, debug off.

Step 4: try to fool it

A verifier that never says no is worth nothing. First, pretend the bundle answers a different challenge, which is what a replayed bundle looks like:

voltage-verify verify bundle.json --offline \
  --challenge 0000000000000000000000000000000000000000000000000000000000000000 \
  --hwmodel GB20X --gpus 1
# [FAIL] manifest.challenge    challenge differs from the one this verifier issued (replay or foreign bundle)
# RESULT: NOT VERIFIED (manifest.challenge)

Then change a single character inside the signed part of the quote:

python3 - <<'PY'
import json
b = json.load(open("bundle.json"))
q = b["tdx"]["quote_b64"]
b["tdx"]["quote_b64"] = q[:300] + ("A" if q[300] != "A" else "B") + q[301:]
json.dump(b, open("tampered.json", "w"))
PY

voltage-verify verify tampered.json --offline \
  --challenge 627ba9c51d4719038e917c7431675b183ac576c819d712178dc8a100f4409a45 \
  --hwmodel GB20X --gpus 1
# [FAIL] tdx.signatures        quote signature does not verify with the attestation key
# RESULT: NOT VERIFIED (tdx.signatures)

Both outputs are the ones I got. Each failure names the exact check.

What it proves, and what it does not

Proved: this manifest was bound by a genuine Intel TDX guest on a platform Intel rates up to date, with an NVIDIA GPU in confidential-computing mode whose measurements NVIDIA accepted, and the bundle has not been altered since.

Not proved by this check alone: which software ran in the guest (compare the printed MRTD and RTMR values with a reference you trust), and freshness relative to you, because here the challenge was drawn by the publisher's script. For your own guarantee, draw the challenge yourself on your own VM.

Do it on your own machine next

Renting the same tier takes three API calls (quickstart). Inside the VM, voltage-verify manifest --challenge auto and voltage-verify attest produce your own bundle; the full run, which cost $0.60, is written up in Confidential GPU by API alone.

Disclosure: I work on VoltageGPU, which runs the VM this bundle came from. The verifier is open source and does not trust us: if the bundle lied, it would say so.

Verifying Intel TDX and NVIDIA GPU attestation from inside a rented VM, and what it can't prove

VoltageGPU — Tue, 13 Oct 2026 11:37:50 +0000

I run a small confidential GPU cloud. We rent Intel TDX virtual machines with an H100, H200 or RTX PRO 6000 Blackwell passed through, and customers kept asking the only question that matters: how do I know the enclave is real, and that the provider is not in the loop?

"Trust our dashboard" is not an answer to that question. So I wrote a verifier the tenant runs themselves, with nothing from us in the trust chain. It's open source: voltage-verify.

The workflow

On your laptop, write a manifest with a fresh challenge:

voltage-verify manifest --image ghcr.io/you/app:1.4.2 --artifact model.safetensors \
    --statement "inference run for customer X" -o manifest.json

Copy it into the VM, then as root inside the VM:

sudo -E python -m voltage_verify attest --manifest manifest.json -o bundle.json

Copy the bundle back and verify it anywhere, offline if you like:

voltage-verify verify bundle.json --challenge <the challenge printed by manifest>
voltage-verify verify bundle.json --offline

Exit code 0 means verified, 1 means a required check failed.

How the two proofs are bound together

The manifest carries a random challenge.
Inside the VM, the tool asks the kernel's TDX interface (configfs TSM, /sys/kernel/config/tsm/report) for a quote whose report_data is the SHA-512 of that manifest. The quote is verified up to the pinned Intel SGX Root CA, with Intel's PCS collateral (TCB info, QE identity, CRLs) embedded in the bundle so it also verifies offline.
It asks NVIDIA's Remote Attestation Service for GPU tokens whose nonce is the SHA-256 of the same manifest, and checks measurements, secure boot, debug off, signature and certificate chain.

Both proofs answer the same challenge, so a bundle can't be replayed from another machine or another day. Neither path goes through our API: it's the Linux kernel and NVIDIA's own service. The same commands should work on any TDX host with a GPU in confidential mode, though we haven't tried every cloud.

Published bundles anyone can re-verify, a single H200, a single H100, an 8x H100 node and an RTX PRO 6000 Blackwell, plus a weekly run, are listed here: https://voltagegpu.com/api/attestation/evidence

What it does not prove

Our VMs boot a stock Ubuntu image and the tenant gets root. So this attests the hardware and the enclave, not which application runs inside. If someone with root on the VM wants to put a different hash in report_data, they can.

Proving workload identity to a third party would need a customer-supplied measured image (your own kernel, initramfs and a dm-verity root, no SSH), so the measurements cover the whole workload. We don't offer that today. I'd rather say it here than have someone discover it in production.

Two things I learned the hard way

NVSwitch doesn't verify from inside the guest. On 8-GPU HGX nodes the GPUs run in NVIDIA's multi-GPU "Protected PCIe" mode, and all eight attest fine. The NVSwitch fabric is another story. With the right libnvidia-nscq (unsuffixed, pinned to the driver version) the NSCQ session opens and switch evidence is collected, but it then fails certificate-chain validation because ocsp.ndis.nvidia.com is unreachable over TLS from the guest. So a tenant VM can't prove the NVLink fabric today. Raw logs: nscq-retest-2026-09-19.

"Random" attestation failures are often egress. The same OCSP problem makes nvattest's local check fail intermittently inside a CVM, while the remote path through NRAS succeeds, because NVIDIA runs the revocation checks on its side. If your GPU attestation fails one run in three, look at the guest's outbound network before you look at the GPU.

Try it

pip install "voltage-verify[attest]"

MIT, Python 3.10+. The repo has example bundles you can verify right away without renting anything. If you go into the TDX quote format or the NRAS token claims and something looks off, tell me in the comments, I'd rather fix it than defend it.

I asked whether my own API could get a customer both attestation proofs with nothing but a key. It could not. Here is what was missing.

VoltageGPU — Thu, 17 Sep 2026 13:34:25 +0000

I sell Intel TDX virtual machines with a NVIDIA GPU passed through, and the whole pitch is "you generate the attestation yourself, on a challenge you chose, and you verify it without trusting me". Yesterday a customer asked a simple question: does that also work through the API, end to end, no dashboard? I said yes. Then I checked, following only my own public documentation, and the honest answer was: not quite. Two things were broken. Both are fixed now, and the run that found them is public, so here is the whole thing.

The test

Rules I set myself: an API key, the documentation page, nothing else. No internal tools, no peeking at the provider console.

GET /api/confidential/vm/tiers returns the live inventory with price and, since this week, an attestation block per SKU: verified or not, on what date, the URL of the published evidence, and the exact commands to reproduce it inside the VM.
POST /api/volt/ssh-keys registers the tenant's ed25519 public key. A confidential VM binds the key at creation and cannot be given one later.
POST /api/confidential/vm/deploy with {"resource_name":"rtx6000b-small","hardstop_hours":1}. One hour (3.80 dollars) is charged upfront.
GET /api/volt/pods polled every 15 seconds until the VM answers.
SSH in, generate both proofs.
Copy the bundle out, verify it on my laptop.
POST /api/volt/pods/{id}/stop, unused part of the hour refunded per second.

Steps 1 to 3 went through in seconds. Step 4 is where it broke.

Broken thing number one: the SSH command the API gave was wrong

The pod listing returned a ready-made command, ssh wrk-xxx@ssh.voltagegpu.com. That gateway is for the container tier. A VM is reached directly, ssh -p <port> ubuntu@<ip>, and the listing simply did not contain the IP or the port. The dashboard knew them, because it reads a session-only route. An API user had no way to learn them at all. So the documentation said "ready to use SSH command" and the command answered Permission denied (publickey).

The fix is in production: the listing now returns provider_status, ssh_ready, ssh_host, ssh_port, ssh_user and a working ssh_command. One more detail I only learned by re-running the test: the address is assigned about 16 seconds after deploy, but sshd only answers once the provider reports running, around two minutes later. Between the two, ssh_ready is false and the command is null, so a script cannot connect too early.

Broken thing number two: the first reproduce command failed

The attestation block listed four commands, starting with pip install "voltage-verify[attest]". The VM image ships without pip. Anyone following the API to the letter would have failed on line one. The list now reflects what actually runs:

curl -sS https://bootstrap.pypa.io/get-pip.py | python3 - --user --break-system-packages
python3 -m pip install --user --break-system-packages "voltage-verify[attest]"
export PATH=$HOME/.local/bin:$PATH
voltage-verify manifest --challenge auto -o manifest.json
sudo env PATH=$PATH PYTHONPATH=$(python3 -c 'import site;print(site.getusersitepackages())') \
  voltage-verify attest --manifest manifest.json --mode single-gpu -o bundle.json
voltage-verify verify bundle.json --challenge <the challenge printed above>

Inside the VM this took 19 seconds wall clock, including the pip bootstrap. The manifest step prints a random challenge; the TDX quote carries its SHA-512 in report_data, the NVIDIA tokens carry its SHA-256 as nonce, so both proofs are bound to the same value the tenant chose.

The part that matters: verifying outside the VM

A proof you can only check on the machine that produced it proves nothing about the machine. So the bundle came out over scp, and on a Windows laptop:

voltage-verify verify bundle.json --challenge ac7258...7389 --hwmodel GB20X --gpus 1
RESULT: VERIFIED

voltage-verify verify bundle.json --challenge 0000...0000
RESULT: NOT VERIFIED (manifest.challenge)

voltage-verify verify bundle.json --offline --challenge ac7258...7389
RESULT: VERIFIED

The wrong challenge is the interesting line: a replayed bundle from another run, or another provider, is rejected. The offline run works because the Intel collateral (TCB info, QE identity, CRLs) is embedded in the bundle at attest time.

Then the stop call, and the refund: 3.20 of the 3.80 dollars came back. The whole run, deploy to verified bundle on my laptop to release, cost 0.60 dollars. Two more control runs after the fixes cost 0.14 dollars in total, one of them was stopped at 16 seconds and refunded in full because the machine had never actually started.

What is public

The bundle, the manifest, the checksums computed inside the VM, and the verification output from the laptop are at https://voltagegpu.com/blog/two-proofs/evidence/rtx6000b-api-2026-09-17/README.txt. Anyone can re-run verify on it. The public index of which SKUs have a published attestation, and which do not and why (8x H200, B200, B300 never available to test; the NVSwitch fabric not attestable from inside a TDX guest), is at https://voltagegpu.com/api/attestation/evidence, no account needed.

The verifier is MIT, on PyPI and GitHub: https://github.com/Jabsama/voltage-verify

What I take from it

"It works through the API" is a claim like any other. The only test that counts is the one that knows nothing but the documentation, and it found in ten minutes what a week of reading the code had not. If you sell attestation, run that test before a customer does.

DEV Community: VoltageGPU

What a tenant can check on an H100 confidential VM in under 4 minutes

What ran, and when

One challenge, two hashes

Re-run the check on your machine

What the fifteen lines say

What this does not prove

On your own VM

Check an 8-GPU Node Before a Multi-Day Training Run

Why test the node before a run of several days

Before the test: install the NVIDIA driver and Fabric Manager

Run the acceptance test

Read the result, block by block

1. Topology: is every GPU on NVLink?

2. P2P: how fast is each GPU pair?

3. NCCL: does an all-reduce reach the expected bandwidth?

4. Load: five minutes at full power

5. Errors: ECC and Xid

6. Hygiene: did a previous tenant leave anything?

What this proves, and what it does not

Re-check the published files

If you rent the node from us

FAQ

Ring zero on an attested H100

1. What ran, and when

2. The gate and its signed receipts

3. Enforcement in ring zero

4. Two hardware proofs: the Intel TDX quote and the NVIDIA GPU attestation

5. How the gate receipt is tied to the attestation

6. What voltage-verify printed

7. What the hardware side proves, and what it does not

Reproduce it

Part 1: the archive and the 22 hardware attestations

Part 2: the receipt chain

8. What the kernel run proves, and next steps

Sources and links

Calling open models inside a TEE with the OpenAI Python SDK

The two lines that change

What came back

Listing the models

What the TEE does and does not give you

Same thing with LiteLLM, LangChain or LlamaIndex

Read an Intel TDX Quote, Field by Field

What a TDX quote is, and who signs it

Step 1: verify the bundle

Step 2: print every field

The fields, one by one

MRTD: what the TD started from

RTMR0 to RTMR3: the boot chain

REPORTDATA: your challenge

TD attributes: the debug bit

TCB status: is the platform current?

The certificate chain: who vouches

What this proves, and what it does not

Reproduce it

Further reading

Re-check a Published GPU Hardware Check, Line by Line

Step 1: read the published run

Step 2: check that the script is the open-source one

Step 3: compare a published file with the repository copy

Step 4: see which lines were actually compared

Step 5: replay the model rule

Step 6: run it on your own machine

What this proves, and what it does not

Verify a Confidential AI Inference Attestation Yourself

What was published

Step 1: install the two verifiers

Step 2: download one model's files and check the checksums

Step 3: re-run the published check

If one instance fails: check it alone

Step 4: the parts that need no network

What this proves, and what it does not

Watch GPU Prices and Availability From a Public JSON

Step 1: fetch it once

Step 2: read the metadata

Step 3: the Confidential VMs

Step 4: the same VMs, per GPU model

Step 5: the standard GPUs

Step 6: inference prices

Step 7: how fresh it is