Verifiable Off-Chain Compute: What "GPU Optional" Actually Means

Solidus shipped a signed CUDA build on 2026-07-15. This page is about the one number it doesn't have: throughput. No latency figure either, and no cost-per-job figure, for the GPU build or the CPU build it ships alongside. That's true today and it's the entire point of this page, not a caveat to soften later.

If you saw "GPU build shipped" in a changelog, or landed on node.solidus.network/gpu, the reasonable next question is "so what's the benchmark?" There isn't one. Nobody has run the numbers, and nothing below implies a date when they will. What you get instead is the one thing that's actually checkable today: a design property that makes it structurally impossible for a CPU build to quietly pass itself off as a GPU one.

The general problem

Model inference that runs off-chain, on hardware you don't control, creates a trust gap that doesn't exist when a computation happens inside consensus itself. A validator set can check a state transition because every honest node re-executes it and compares roots. Nobody re-runs an inference job that way: it's too expensive, and often the whole point of delegating it out was to avoid re-running it. So the question becomes: without re-executing the computation yourself, how do you trust that a specific model, on specific hardware, actually produced the result you were handed?

The general answer in this space is attestation: a signed, verifiable statement one party makes that another party can check without trusting the party who made it. A TLS certificate is an attestation ("this key belongs to this domain," signed by a certificate authority). A hardware TPM's remote-attestation report is one too ("this device booted this exact firmware," signed by the chip itself). The strongest version of this idea for AI inference specifically is often called sealed inference, running the inference step inside hardware that encrypts and isolates it so completely that not even the machine's own operator can see the model weights or the data passing through, with a signed hardware report as the only proof it happened inside a genuine sealed environment. NVIDIA's Hopper generation (H100/H200) was the first GPU line to support this as Confidential Computing; Intel TDX/SGX and AMD SEV do comparable work on the CPU side.

Solidus's node product touches both concepts as a checkable, concrete example, expanding them, not claiming to own either. See the Lexicon entries for Sealed Inference and Attestation for the fuller picture, including where Solidus's own tier is a weaker trust model than sealed inference proper.

What Solidus actually ships today

The node product ships two execution-provider builds: onnx-cpu, ONNX Runtime on the CPU execution provider, and onnx-cuda, the same ONNX Runtime paired with NVIDIA's CUDA execution provider. Both are signed under the same Ed25519 release key. The live manifest at releases.solidus.network/gpu-node/stable/latest.json, the file every auto-update client actually polls, reads, in full, as of this writing:

{
  "version": "v0.1.0-testnet",
  "channel": "stable",
  "product": "solidus-gpu-node",
  "variant": "onnx-cuda",
  "released_at": "2026-07-15T01:02:35Z",
  "rollout_percent": 100
}

(Trimmed here to the fields that matter for this page; the live document also carries the binary URL, its SHA-256, and the manifest signature.) That variant field is the whole mechanism. GPU is an optional tier of this product, not the product itself. Nothing here is a GPU network; it's verifiable off-chain compute with a GPU path an operator can choose.

The one thing this page can prove

The variant field isn't decorative, it's load-bearing. When the installer processes a manifest whose variant reads onnx-cpu, it prints a loud, unmissable CPU-execution-provider warning at install time, before the operator runs anything. There's no code path where a CPU build's manifest silently reports as onnx-cuda, and no code path where the installer stays quiet about which execution provider it's about to run. The signed manifest and the loud warning are the same integrity property from two directions: the manifest can't misrepresent what shipped, and the installer can't let an operator miss what they're about to run.

That's a design and supply-chain fact, checkable against the manifest above right now, by anyone. It is not a performance claim, and it's the strongest thing this page has to say with confidence: everything else about the GPU tier is still unmeasured.

What's still missing

No throughput number. No latency number. No cost-per-job number. Not for the CPU build, not for the CUDA build. Nobody has benchmarked either execution provider on this network, and nothing here implies that changes on any particular date, "not yet measured" is the complete and honest statement, not a placeholder for one that's coming.

Practically: if you're evaluating whether this tier is usable for a real, paid, or performance-sensitive inference workload today, the answer is no, there's nothing to price against, because there's no number to price. What exists is a signed, dual-variant release pipeline where a CPU build can't misrepresent itself as a GPU one. That's real, and it's the honest place this page stops.

Worth being precise about scope, too: solidus-gpu-node is its own signed product, sharing a release key with the L1 validator binary but distinct from it. Running a compute node, CPU or GPU variant, is not the same claim as running a validator, which requires separate staking and DID registration on a chain whose live consensus is a 4-node dev committee today, not the 21-of-100 committee the design specs. The shipped/roadmap status of both builds is tracked in full on the ledger page; the CPU/GPU variant choice as it appears in an actual install walkthrough is covered on running a node, honestly.