Every node on the network has measured and reported its connection speed since January. The number is stored on the node, it is shown on the public network map, and anyone could read it.
On 8 June, the day after we made that measurement stable, we published a hardware requirements page asking providers for 100 Mbps.
We never connected the two. For seven months the platform collected exactly the number it needed and no code path ever read it to decide anything.
In August we finally looked. Of the nodes we were actively offering to renters, five were below the requirement we had published — 15 Mbps, 28, 34, 87, and one running three datacentre GPUs on a link that measured 19 Mbps one minute and 38 the next.
Nobody lied. Nothing was hidden. The data was on the screen the whole time, and it was decoration.
Why it mattered more than it looks
A rental starts by pulling a 13 GB image. At 15 Mbps that is just under two hours before the renter sees a terminal. Then they pull their own data — a dataset, a model, a checkpoint — through the same link, for the entire session.
We watched it happen. One node took nineteen minutes to start a rental. The next two attempts on the same machine were abandoned by the renter before anything appeared, one at seven minutes and one at twelve.
From the renter's side there is no signal at all. The node is listed, it looks like every other node, and then nothing happens. They do not think "this provider has a slow connection." They think the platform is broken.
That is the real cost of a requirement nothing enforces: it does not fail on the provider who missed it, it fails on the customer who trusted the listing.
The obvious fix is wrong
Read the last speed test, compare it to 100, done.
Except the same node measured 19 Mbps at 07:58 and 38 Mbps at 08:02. Four minutes apart, on an idle machine. Bandwidth is not a property, it is a sample.
Gate on the latest reading and you will eventually exclude a perfectly good node because its measurement landed during someone's backup. The provider will run their own speed test, see 400 Mbps, and open a support ticket you cannot win, because you are both right.
So we keep the readings instead of the reading. Each node stores its last 24 measurements — one an hour, so roughly a day — and the gate takes the best one in the window. A node that reached 100 Mbps at any point today is a node that can reach 100 Mbps.
This is deliberately generous. It errs toward keeping nodes in, because a false exclusion costs a provider real income and costs us a support conversation, while a false inclusion costs one slow rental. We would rather be wrong in the direction that is cheaper to correct.
One rule worth stealing
Show exactly the number you gate on.
The dashboard does not display "your connection speed." It displays the best reading of the last 24 hours, which is the same value the check uses. If a provider disagrees, they are disagreeing with a specific number from a specific window, and that is a conversation with an end.
Display an average, or the latest, or anything the decision does not use, and every disagreement becomes unresolvable.
Why we didn't disconnect them
The tempting version is to refuse the connection outright. A node below the requirement is not a node, throw it back.
We didn't, for a reason that took a measurement to see. A slow node is bad at rentals and perfectly good at inference.
Rentals are bandwidth-shaped: pull a large image, pull user data, stay interactive. Inference is compute-shaped: download the model once, then serve requests that are a few kilobytes each. One of the nodes below our threshold is serving a language model as this is published, and doing it well.
Cutting the group off entirely would have removed 116 GB of VRAM — around a third of the online fleet at the time — to solve a listing problem. So the gate applies to the rental pool only. Excluded nodes stay connected, keep earning uptime rewards, and keep serving inference.
The general form: in a network made of other people's hardware, capability is not one axis. A machine that fails one workload can be excellent at another, and a single yes-or-no on network membership throws away most of your supply.
Telling the provider
The uncomfortable discovery was that rent_ready — the flag deciding whether a node is offered at all — had never been visible to the person who owned the node. A node without the rental image was excluded in silence and had been for months. Bandwidth would just have been a second invisible reason.
Each node now carries a reason, shown on its card:
- Preparing for rentals: downloading the rental image. Nothing to do, clears on its own.
- Not receiving rentals: your connection is below the 100 Mbps minimum (best measured in the last 24h: 34 Mbps). Inference and uptime rewards are unaffected.
Only the second one is amber. The image cases resolve themselves within a day, and if they looked identical to a problem the provider must fix, providers would either panic at both or learn to ignore both.
The last sentence of the bandwidth message is the one we argued about most. Without it, "not receiving rentals" reads as you have been removed from the network, and the rational response is to unplug the machine. Which is precisely the outcome the whole design was built to avoid.
What this still doesn't solve
We check download, the docs say upload matters more. Renters pull through the provider's upload path, so upload is the honest metric. The agent only measures download, so that is what the gate uses, as a proxy. It correlates, and a link that downloads at 15 Mbps is not uploading at 200. But it is not the thing we said we cared about, and we would rather write that down than let someone find it.
An hour is a long time to wait. Measurements are hourly, so a provider who fixes their connection sits outside the pool for up to an hour with no way to ask for a recheck. The obvious answer is a button, which needs a new agent release. Measuring more often is not the answer: each test downloads 50 MB, and quadrupling that on the connections we already consider too slow would be a strange way to help.
The threshold is a straight line through a curve. A node at 87 Mbps is not meaningfully worse than one at 103, and today one of them is listed and the other is not. A ranking would serve renters better than a cliff. We started with the cliff because it is the number already published, and moving a threshold is easier than explaining a score.
The DePIN version of the lesson
A conventional cloud buys hardware that meets its specification by construction. The specification is an instruction to a supplier.
A distributed network cannot do that. Every requirement it publishes is a request to strangers, and the gap between the request and reality stays open until something acts on it. Measuring is not acting. We had the measurement for seven months and a published requirement for two, and the pool still contained a node at 15 Mbps, because no line of code ever compared them.
If you run anything like this, the useful question is not what do we measure. It is which measurements change a decision — and for everything else, why are we collecting it.
The pattern is the same one behind verifying GPUs by measurement rather than trusting what a node reports about its own hardware. There we did not believe the card. Here we did not believe the connection. Both come from the same place: on a network of machines you do not own, anything you have not measured is a guess — including your own documentation.
The current split, live: 13 nodes rentable, 4 held on bandwidth, 4 still pulling the image.
Curious how the hardware side works? How We Prove a GPU Is Real covers verification by measurement. Thinking of connecting a machine? The full requirements are at /docs/hardware-requirements.
FAQ
What is the connection requirement to run a ParalonCloud node? 100 Mbps, as published in the hardware requirements. Since August it is enforced for rentals: a node measuring below it is not offered to renters.
My connection is fast but my node was excluded. Why? The check uses the best measurement from the last 24 hours, taken hourly from inside the node's container. If that number looks wrong, it usually means something local is throttling the container rather than the line itself. Tell us and we will look.
Does a slow connection get my node removed from the network? No. It stays connected, keeps earning uptime rewards, and keeps serving inference. Only the rental listing is affected.
How quickly do I come back after fixing it? At the next measurement, so within the hour.
Why measure download when upload matters more for renters? Because that is what the agent measures today. It is a proxy, and we say so rather than pretend otherwise. Measuring upload requires an agent change.
Is there a speed requirement for inference too? Not currently. Inference is far less bandwidth-hungry per request, though downloading a large model over a slow link is its own problem, and one we are still working on.
