Put your GPU to work on jobs it can verify — and never read.
Operator nodes execute sealed inference jobs for Solidus identity products. Payloads arrive encrypted to your node alone, models are supplied as signed deploy config, and every result ships with a receipt your node signs. Your box does the work; it never learns what the data is.
The download is a signed onnx-cuda build: it compiles, links, and runs the CUDA execution provider on real NVIDIA hardware. A signed onnx-cpu preview also remains, for auditing the supply chain on any machine without a GPU. Anyone can download either, verify the signature chain, and generate a node identity today; earning work still requires allow-list admission.
What your box actually does
Receives sealed payloads
Each job carries a data key sealed to YOUR node’s X25519 key. The broker that routes jobs holds only references and sealed keys — it structurally cannot open the data it forwards. Decryption happens in your node’s memory and the plaintext is wiped the moment inference returns.
Runs models it never interprets
Your node is an opaque ONNX runner. A deploy-supplied routing config maps job-types to model files, input shapes and normalization constants; the node executes exactly that and nothing else. What a model computes is not encoded anywhere in the node software.
Signs a receipt for every job
Results return with a receipt signed by your node’s key, binding the encrypted input’s hash, the output hash, the model id and the latency. Receipts are batched and anchored, so your work history is provable — by you and to you.
Gets checked, honestly
The broker mixes known-answer canary jobs into real traffic and re-runs a sample of jobs against a reference. Correct answers build reputation; wrong answers cost it. Determinism rules (down to pinned image decoding) exist so an honest node is never flagged by accident.
What it pays
Verified work is credited in points. Points redeem for nothing today. There is no token.
Solidus has not issued a token, and running a node is not a claim on one. The points ledger exists to measure contribution — jobs completed, weighted by workload class and your node's reputation — and to give early operators a provable track record for whenever compute economics are defined. If that never happens, points were and remain worth nothing. Treat this, for now, as contributing hardware to a testnet you want to exist, with your work receipted and attributable — not as income.
Your accrued points are queryable per-node from the broker's accounting endpoint at any time — what you earned is never a number you have to take on faith.
Hardware
The GPU build (onnx-cuda) is published, signed, and verify-first.
The node's CUDA execution provider now compiles, links, and initializes on real NVIDIA hardware — the self-test allocates GPU memory and runs a session under error_on_failure, so a pass means CUDA is genuinely live, not a silent CPU fallback. It is labeled onnx-cuda in the signed manifest. A signed onnx-cpu preview also remains, so the supply chain can be audited on any machine without a GPU. What we have not yet measured is throughput or cost-per-job against the production model bundle — so no performance or earnings numbers appear anywhere on this page.
Admission — allow-listed, and it says so
Install and get your node identity
The installer verifies the release signature before anything runs, then generates your node’s DID — an identifier derived from its own keys.
Submit your DID to the waitlist
Admission v1 is a curated allow-list: we admit a small set of operators we can support properly, in the open, on testnet. Permissionless admission needs staking, slashing and spot-check economics that are not deployed yet — so we do not pretend it is permissionless.
Get allow-listed and configured
On admission your DID is allow-listed on the testnet registry and you receive the broker URL, staging origin, and a signed routing config + model bundle.
Register and serve
Your node signs its own registration (key-derived identity — nobody can register your DID but you), passes a self-test, and starts receiving sealed jobs. Receipts and points accrue from the first verified job.
A verified install, not a piped one
We will not teach operators to pipe an unverified root-level script into a shell. The installer fetches a signed release manifest, verifies its Ed25519 signature against a pinned key, verifies the artifact's SHA-256 against that signed manifest, and only then installs anything. You can audit the whole chain first — no root, no writes:
These commands work right now. --verify-only fetches the signed manifest, checks its Ed25519 signature against the pinned release key, re-hashes every artifact against that signed manifest, and prints what it found — then exits without writing anything. The installer refuses a manifest signed for a different product, and it names the exact execution-provider variant (onnx-cuda on the default stable channel) straight from the signed manifest.
Signed artifacts
Downloading a tarball directly skips the signature check the installer does for you. If you take that path, verify it yourself against the signed manifest above. The CUDA build is a separate, hardware-validated release that does not exist yet — when it ships, the waitlist gets it first, through this same verify-first flow.
Operator waitlist
Tell us how to reach you. The DID and GPU model are optional — a DID from an early --allow-no-gpu install speeds admission up.