How @nordiccompute turned three idle 4090 rigs into $412/month

Three single-GPU rigs, one RTX 4090 each. Two are retired gaming builds, the third came out of a small studio that upgraded. Nothing exotic: 24 GB of VRAM per card, a 100 Mbit/s symmetric line, Ubuntu with Docker, and enough airflow that the cards do not throttle under a sustained load.

They were already bought and already sitting idle. The question this article answers is what connecting them to the network adds on top of that, and how the number is produced. It is not an argument that $412 is a good return on hardware, because the hardware is a sunk cost in this scenario and the arithmetic would look different if it were not.

Everything past this point is arithmetic. There is no reselling, no tenants and no per-customer support burden. An operator installs the agent, the node passes its health probes, and the scheduler starts placing jobs on it.

AI teams bid for GPU capacity in hourly auctions. Bids are sealed, the auction settles at the top of every UTC hour, and the winner pays the second-highest bid. That price is what the hour clears at, and the charge is the only money entering the system. Operator earnings are a share of it, not a subsidy and not a deposit-funded yield.

Which sets the expectation correctly. If nobody bids for capacity in your VRAM class in a given hour, there is no clearing price and nothing to split. Operator income tracks demand for GPU time, and demand for GPU time is uneven across the day, across the week and across the release cycle of whatever models people are training this quarter.

For each settled hour the network computes two numbers before anything reaches an operator.

Platform commission is 20% of what the hour billed. The operator pool is the other 80%. There is no third line: no per-node fee, no bandwidth charge, no listing cost, nothing deducted for the scheduler.

The pool is then divided in proportion to verified GPU-hours delivered. Each operator receives the pool multiplied by their share of the hour’s total verified GPU-hours. This is the part most people guess wrong, because the split is not per GPU connected. Connecting ten idle cards does not raise your share; delivering GPU-hours does. A card that sat in the candidate set all hour without being scheduled contributes nothing to the numerator.

Verified means the hour was measured on both ends. The node agent reports it, and the control plane’s own probes and the job completion record have to agree with the report. Time a node claims but cannot demonstrate enters neither the numerator nor the denominator.

Take 14:00 UTC on a Tuesday. The 24 GB class cleared at $0.30 per GPU-hour, and the network verified 2,940 GPU-hours in that hour. All three of @nordiccompute’s cards were busy for the whole hour, so they contributed 3 of those GPU-hours.

Hour billed: $0.30 × 2,940 = $882.00. Commission: $882.00 × 0.20 = $176.40. Operator pool: $882.00 − $176.40 = $705.60.

Share of verified GPU-hours: 3 ÷ 2,940 = 0.102%. Payout for the hour: $705.60 × (3 ÷ 2,940) = $0.72.

There is a shortcut hiding in that. When a single price clears the whole hour, the pool arithmetic collapses to 80% of the clearing price for every GPU-hour you delivered, so $0.30 × 0.80 × 3 gives the same $0.72 without touching the pool at all. The pool framing still matters, because a real hour settles several VRAM classes at several prices and the pool blends them. The shortcut is exact only when you are looking at one class in isolation, which is what this example does.

Seventy-two cents is not a number that excites anyone, and multiplying it by the 720 hours in a 30-day month is the wrong move. That would give $518.40, and it assumes all three cards are busy in all 720 hours. They are not.

Over the month in question the three rigs delivered 1,716 verified GPU-hours against a theoretical maximum of 2,160, which is 3 cards times 720 hours. That is 79.4% utilization. Good, and roughly what a well-placed node in a region with real demand sees, but not 100%. The other 444 GPU-hours earned exactly nothing, which is the previous section restated as a number.

At 80% of a $0.30 clearing price, each verified GPU-hour paid $0.24. So 1,716 × $0.24 = $411.84. That is the $412 in the title, and it is the whole derivation.

The honest caveat is that this holds the clearing price flat across the month at the one value taken from the worked hour, and no month works that way. Prices move with demand for the class, the denominator moves with how much of the network is busy, and your share moves with both. Treat the monthly figure as what a sustained good month extrapolates to, not as a forecast.

The direction of the error is worth knowing too. As the network grows, total verified GPU-hours grows, so an unchanged 1,716 becomes a smaller slice of a larger denominator. Growth in the supply of GPUs is not automatically growth in your cut. It is growth in your cut only if demand grows alongside it, because demand is what lifts the clearing price and the pool together with the denominator.

Power is not deducted from your payout, so it does not appear in the arithmetic above. It is still real, and leaving it out of the comparison would make the number look better than it is.

A 4090 rig under sustained load draws roughly 420 W at the wall once the rest of the machine is counted. Across 1,716 delivered GPU-hours that is about 721 kWh. At $0.14 per kWh, a rate worth replacing with whatever your own utility charges, the electricity for those hours costs about $101 and leaves roughly $311.

Idle hours draw far less and are excluded here, as is cooling, which depends entirely on where the rigs physically sit. Depreciation is the other omission: cards under continuous load age faster than cards that game four hours a night. Neither is a reason not to run a node, but both belong in the calculation before the headline number does.

Verified GPU-hours delivered is the only term in the payout formula you directly influence, and it is downstream of being picked by the scheduler at all. A node has to be ACTIVE and hold a health score above 70 to be in the candidate set. Below that floor it receives nothing, however good the card is.

So uptime compounds. A node that stays healthy is scheduled more often, which raises the numerator, which is the entire payout. A node that starts dropping probes is pulled from the candidate set automatically and does not return until the probes agree it has recovered, which means an hour of flakiness costs more than an hour of earnings.

The second lever is VRAM class. A 24 GB card serves the 24 GB class and can absorb smaller jobs when the smaller classes are exhausted, so it draws from a wider band of work than a 16 GB card does. That is a hardware decision, made once, and it is the main reason the 16 GB bar exists at all.

The third is placement, and it is the one you cannot tune from the machine. The scheduler prefers the nearest healthy node that meets the job’s VRAM class, so a card in a region where jobs outnumber eligible nodes is scheduled more than an identical card in a saturated one. Worth checking before buying a fourth card rather than after.

Hourly earnings settle to the operator balance as they are computed, one transaction per distribution, so every cent traces back to the hour that produced it and to the GPU-hours that earned it. Nothing is batched into an opaque monthly figure.

Withdrawals are available from $10, paid in USDC on Polygon, Base or Arbitrum, or by bank transfer over ACH or SEPA. There is no lock-up and no minimum term. An operator who disconnects keeps whatever has already settled.

For scale: 3,180 GPUs are online across 41 regions right now, and $1.24M has been paid to operators to date. The first number is the denominator you are competing inside; the second is the track record. Neither tells you what your node will earn, but both are worth holding in mind before extrapolating from a worked example.