Anyone can tell you they have an H100. nvidia-smi output is a string. A hardware
report is JSON a machine sends about itself. On a network assembled from other
people's computers, every one of those is a claim, and a claim is worth nothing.
So we don't accept claims. Before a node serves anyone — an inference request, a render job, a rental — it has to prove its GPU by running on it. This is how that works, what the measurements actually look like across the fleet, and where the method stops.
Why a marketplace can't run on trust
Three things go wrong when you take a node's word for it, and all three are ordinary rather than exotic.
The card isn't what it says. Reporting tools can be intercepted. A VM can be told to describe hardware it doesn't have. Somewhere between an honest mislabelled listing and outright fraud, a renter pays 5090 rates for a 3060.
The card is real but already busy. More common, and more damaging, than spoofing. A GPU with 24 GB of VRAM that is already holding 18 GB of someone else's model is not a 24 GB GPU for your purposes. A hardware report showing "24564 MB total" is technically true and practically useless.
One machine, registered twice. A provider connects the same box under two node tokens and collects two sets of uptime rewards for one piece of silicon. Nothing is spoofed; the accounting is simply wrong, and it dilutes everyone who is honest.
None of these are caught by asking. All three are caught by measuring.
The method: make the GPU do work
Verification is a container. The scheduler sends a node a command to run a pinned, allowlisted benchmark image, and the agent runs it with the GPUs attached. It does three things that a claim cannot fake.
It allocates the memory. Rather than reading a "total VRAM" field, the benchmark asks CUDA for a large block and walks downward in 256 MB steps until an allocation succeeds. What comes back is allocatable VRAM — memory the card will actually hand over right now, on this machine, in its current state. A card that reports 24 GB and yields 6 GB has told us something a spec sheet never would.
It measures achieved memory bandwidth. A kernel streams a 256 MB buffer repeatedly and the throughput is timed over multiple iterations. Memory bandwidth is a good verifier because it is physically bound to the silicon — you cannot report an HBM3 figure from a GDDR6 card, and you cannot fake it by patching a driver string. It also degrades honestly: a card under load, thermally throttled, or shared with another workload reports lower, and that is information we want.
It records the GPU's own identity. UUID, compute capability, per-GPU results on multi-card rigs, and whether every card in the box is the same model — which matters, because homogeneous groups are what the scheduler can plan tensor parallelism across.
The benchmark image itself is allowlisted by content digest. Only builds we have published and registered can run as a verifier, so a provider cannot substitute a friendlier one that reports whatever they like.
What the numbers actually look like
Every verified node stores its measurement. This is the current fleet — mean achieved bandwidth per GPU model, across 80 verified nodes:
| GPU | Nodes | Mean achieved bandwidth |
|---|---|---|
| H100 80GB HBM3 | 1 | 2,408 GB/s |
| H100 PCIe | 3 | 1,630 GB/s |
| A100 80GB PCIe | 3 | 1,504 GB/s |
| RTX 5090 | 17 | up to 1,534 GB/s |
| RTX 3090 Ti | 1 | 856 GB/s |
| RTX 4090 | 9 | up to 922 GB/s |
| RTX 3080 Ti | 4 | 812 GB/s |
| RTX 3090 | 17 | up to 840 GB/s |
| RTX 4080 SUPER | 2 | 585 GB/s |
| RTX 3060 | 5 | up to 334 GB/s |
These are achieved figures, not datasheet figures, and they land where you'd expect them to: an H100 with HBM3 roughly three times a 3090, a 5090 comfortably above a 4090, a 3060 an order of magnitude below the datacentre parts. A card claiming to be something it isn't does not land in the right band, because it cannot move memory it doesn't have.
The spread is the interesting part
Look at the same models across different machines and the range is wide. Among seventeen 5090s the best node measures 1,534 GB/s and the weakest 245. Nine 4090s span 428 to 922. That is not noise, and it is not fraud — it is what a fleet of real computers in real rooms looks like. A card sharing a PCIe lane with three siblings, a workstation mid-render, a rig in a hot room in August, a laptop-class part behind a thermal budget: all of them measure lower, honestly.
This is exactly why we score the machine rather than the model name. Two nodes can both be "an RTX 5090" and be very different products to rent. The number that matters is the one the machine produced ten minutes ago.
Verification is not a one-time gate
A node that passes once and is never checked again is a node you are trusting again by a slower route. So the fleet re-verifies continuously, with three properties that matter.
On a randomised schedule. Each pass sets the next check somewhere between 20 and 28 hours out, chosen randomly per node. There is no fixed hour to prepare for and no cadence to schedule around — a machine that only behaves during a predictable window would eventually be measured outside it.
Never on a rented node. Verification is skipped entirely for any node with a live container. Nobody's paid session gets interrupted so we can run a benchmark, and no benchmark competes for VRAM with the renter who is paying for it.
With a limp-along path. A check that starts and never reports is itself a signal; nodes stuck mid-verification are reset and re-queued rather than left in limbo. Only a small number of verifications run concurrently, so the process never becomes load of its own.
Failure is not fatal, but it is consequential. A node marked failed or
suspicious is not given inference work, and it is filtered out of live
availability and pricing entirely — it stops existing as far as renters are
concerned until it passes again.
One machine, one node
Separately from the GPU itself, every agent reports a stable machine identifier derived from the host. If a second node token tries to connect from hardware already registered under another live node, the connection is rejected — checked both at authentication and again when hardware is reported, in case an agent reports later than it connects. When there is a conflict, the older registration wins.
The effect is that a provider cannot double-register one box to double their uptime points, and the leaderboard reflects hardware rather than tokens.
The same allowlist logic applies to the agents themselves. An agent authenticates with its node token and the digest of its own image; native Mac agents present a binary hash. Only builds we have published and registered can join the network at all — so a modified agent that lies on behalf of its machine never gets a session in the first place.
Where the fleet stands today
Of the GPU nodes registered on the network right now:
- 80 verified — measured, in-band, scheduled.
- 54 unverified — registered but not yet through a full pass, typically because they haven't been online and idle at the same time.
- 5 failed — measured and rejected. They receive no work.
We publish the failed count on purpose. A verification system with a zero rejection rate is either running on a perfect fleet or not running at all.
What this does not catch
The honest part, because a security post without one is marketing.
A good card that degrades between checks. We measure on a randomised daily cycle, not continuously. A machine that develops a fault an hour after passing carries a stale attestation until its next check — mitigated by health checks and by workers expiring from the registry within a minute of a node going quiet, but not eliminated.
A sufficiently determined virtualised liar. Our measurements are strong against reported-string spoofing and against silently shared cards, because both show up in allocatable memory and achieved bandwidth. A setup that genuinely passes real work through a real GPU of the right class is, by definition, giving you a real GPU of the right class.
Anything above the hardware. Verification proves what the silicon is, not what the operator does. Container isolation, one workload per node, allowlisted images and the outbound-only tunnel are separate mechanisms doing separate jobs.
We don't publish the tolerances. How far outside its band a card can measure
before it is rejected, and what triggers suspicious rather than failed, stay
internal. Publishing the acceptance window would tell anyone trying to defeat it
precisely what to aim for. The method is worth explaining; the thresholds are not.
Why it matters on both sides
If you rent: the GPU you are shown has proved itself by working, recently, with its memory actually available — not by describing itself in a JSON payload. Nodes that fail don't appear.
If you provide: your hardware is measured rather than assumed, so a good machine is scheduled ahead of a mediocre one and a well-cooled 5090 is worth more than a throttled one. And nobody is quietly registering one box twice while you run yours honestly.
A network built out of other people's computers only works if trust is replaced with evidence. Measurement is the cheapest evidence there is.
Want the architecture this sits inside? Inside the Paralon Engine covers the agent, the scheduler and how a new workload becomes a row in a table. Ready to connect a machine? Start at /become-provider.
FAQ
How do you verify a GPU is real? By making it work. A pinned benchmark container allocates VRAM in descending steps to find what the card will actually hand over, and streams a buffer through memory to measure achieved bandwidth. Both are physically bound to the hardware and neither can be produced by a card that isn't there.
Why memory bandwidth rather than a compute score? Bandwidth is tightly coupled to the memory subsystem — a GDDR6 card cannot produce an HBM3 figure — and it degrades honestly under sharing and throttling, which is information we want. Compute scores vary far more with kernel and driver.
How often is a node re-verified? Roughly daily, on a per-node randomised interval between 20 and 28 hours, and never while the node is rented.
What happens to a node that fails? It receives no inference work and is excluded from live availability and pricing until it passes a later check.
Can a provider register the same machine twice? No. Agents report a stable machine identifier and a duplicate is rejected at connection; the older registration wins.
Can I run a modified agent? No. Agents authenticate with their image digest (or binary hash on macOS) against an allowlist of published builds.
