lium.io — subnet 51

What it does

lium.io is a marketplace: people who own GPU hardware get paid to rent it out, and people who need GPU compute pay to use it.

lium.io runs a decentralised compute rental market on top of Bittensor. Miners contribute GPU-equipped machines to a shared pool; renters pay to run workloads — machine learning, data analysis, and similar jobs — on that hardware; validators check that a miner's machine actually is what it claims to be and score it, and the subnet pays miners out of new TAO emission according to that score. [source] [source]

Of the whole group of subnets this course tracks together, lium.io is the single largest earner: its emission share is 31.8% @ 8871732, rank 1 @ 8871732 of the tracked set, placing it in the top tier (A @ 8871732). 55 @ 8871732 active miners are currently earning, judged by a small committee of validators — the exact count is in the technical section below — and 6651 @ 8871732 separate wallets hold its alpha token. 256 @ 8871732 of its 256 @ 8871732 registered slots are filled.

How the incentive mechanism works

A miner's machine is scored on GPU type, GPU count, bandwidth, and overall performance — better hardware and better delivered performance pay more. [source] What makes this checkable at all is a separate verification layer, VerifyX: the validator issues a cryptographic challenge over SSH to a miner's machine, the machine's executor runs it and returns a cipher response, and the validator checks that response against a hash-pinned shared library rather than trusting whatever the miner's software self-reports. [source] [source] [source]

The repository's own guide for miners and support engineers names the specific ways this check can fail — a machine that cannot complete the SSH exchange at all, one whose executor process crashes before producing a valid answer, one that returns an implausibly short or empty response, and one whose cipher is structurally plausible but is rejected because the executor is running a different build of the verification library than the validator expects. [source] [source] [source] [source]

Underneath the published guide, the repository's own production scoring path (neurons/validators/src/incentive/default.py) shows what a completed job actually carries into a score: mining_score = score × gpu_portion × gpu_count / total_gpu_count, then scaled down further by a secure-runtime multiplier, a minimum-driver-version multiplier, and an uptime multiplier that a machine with collateral deposited is exempted from entirely. [source] [source] [source] [source] [source] The shape of that calculation is fully visible in the repository, but the one figure that actually decides how much an H100 is worth against an RTX3090 is not: gpu_portion is fetched at run time with await self.redis_service.get_portion_per_gpu_type(job_result.gpu_model), a live lookup against operator-controlled Redis state rather than a constant committed anywhere in the source. [source] Nothing pinned in this repository fixes what that lookup returns, so the actual per-GPU-model weighting cannot be read from source at all — only the fact that a weighting exists, and exactly where the validator fetches it from.

What miners are actually optimising

The stated goal, in lium.io's own introduction, is fair pay for GPU quality and performance. [source] What the mechanism actually measures is narrower than that: passing a cryptographic hardware challenge, running inside the required secure container, meeting a minimum driver-version floor, and — unless it has collateral deposited — maintaining measured uptime against a Redis-tracked clock. [source] [source] [source] [source] None of that is the same thing as a renter's actual experience running a real workload; a machine can pass every one of those checks and still be a mediocre place to run a job, because nothing in what this dossier could read scores renter-side outcomes directly. [source]

That gap is exactly what the debugging guide's failure classes exist to police, which is itself a sign the gap is real: a CIPHER_REJECTED result specifically anticipates an executor quietly running mismatched verification code, and a miner's own dashboard is told to check the verifier library's checksum against the validator's rather than to trust its own report. [source] [source] Whatever renters actually need, what a miner here is optimising for is passing an automated attestation, not being independently judged good.

Why it earns

Mechanism evidence

What the code actually rewards is checkable in outline, though not completely: the calculation's shape is in the repository, mining_score = score × gpu_portion × gpu_count / total_gpu_count, but gpu_portion — the figure that sets how much any given GPU model is actually worth — is fetched from operator-controlled Redis state at run time rather than committed to source, so it cannot itself be audited from the pinned repository. [source] Being checkable in outline is not the same as saying it explains lium.io's earnings, either way. Cross-subnet emission is set by one formula, applied identically to every subnet: each one's share of new emission is its own moving-average alpha price, discounted by a miner-burn penalty, against the same total for every other subnet. [source] [source] Mechanism quality does not appear in that formula at all; it can only reach emission indirectly, by making people want to hold the token in the first place. lium.io is the only subnet in this cohort's pinned sources with a working, code-level answer to "how do you know the hardware is real" — a signed challenge-response protocol checked against a pinned shared library, not a self-report. [source] [source] Whether that is what actually drives demand for its alpha is not something this dossier's evidence can confirm; its rank-1 emission share is not, on its own, proof the mechanism works.

Stake evidence

Only 14.6% @ 8871732 of the judging power behind lium.io's validators traces to the root network rather than to stake placed directly in its own alpha — most of its ranking power is earned through its own token rather than borrowed from root. [source] But a validator permit is awarded purely by stake weight, the top-K accounts ranked by money behind them, recalculated every epoch with no separate judgment of scoring quality involved. [source] Only a handful of accounts hold a permit here at all (the exact figure is in the technical section below), so this subnet's rank-1 emission share rests on the judgment of a genuinely small group; nothing in what this dossier could read distinguishes a few judges who evaluate independently and happen to agree from a few accounts whose backing already agreed before any evaluation happened.

Price evidence

The formula in the mechanism section above is the whole story of cross-subnet emission: a subnet's share is its own moving-average alpha price against every other subnet's, discounted by a burn penalty, full stop. [source] [source] That means mechanism quality, if it matters at all, can only reach lium.io's 1 @ 8871732 rank by first moving this number: 0.075164953 @ 8871732 TAO per alpha token, up 1.45816798761914 @ 8871732% over the trailing week and 22.18304707820676 @ 8871732% over the trailing month. Mechanism and price are not two separate forces this dossier could weigh against each other — price is the only channel a working mechanism has to reach earnings at all, and nothing in the public record shows how much of this price is people paying for real GPU rentals versus ordinary speculation on the token.

Failure modes and attack surface

The chain-wide consensus rule that turns many validators' separate scores into one ranking clips toward whatever a majority of active stake already supports — not a majority of validators — and cannot itself tell independent agreement apart from coordinated agreement. [source] With so few accounts holding a permit here (see the technical section below for the count), a small coordinated minority is already a majority of the group. A validator that stops actually running VerifyX challenges and instead copies a stake-weighted average of what everyone else already revealed has, on other subnets, historically earned better standing per unit of stake than the honest judges it copied — this repository gives no indication of whether lium.io defends against that shortcut beyond the commit-reveal mechanism the wider network provides. [source]

On the miner side, the attack surface is the verification layer itself: the failure taxonomy in the debugging guide (SSH_TRANSPORT, EXECUTOR_CRASH, CIPHER_REJECTED) exists specifically because executors have already been seen failing to answer challenges correctly, whether from misconfiguration or from running mismatched or tampered verification code. [source] [source] A verification system this actively defended is also a verification system worth attacking.

A further, quieter exposure sits underneath that verification layer rather than inside it. The formula that turns a verified job into a score is visible in the repository — mining_score = score × gpu_portion × gpu_count / total_gpu_count — but gpu_portion, the one figure that says how much more an H100 earns than an RTX3090, is not a constant in that source at all. It is read at run time with await self.redis_service.get_portion_per_gpu_type(job_result.gpu_model), a live lookup against Redis state the operator controls and can change without a code change or a public commit. [source] A mechanism whose payout weights live in mutable runtime state rather than in its own source is not something a reader of that source can audit: the shape of the calculation is a real, checkable claim, and the actual weights behind it are not.

What to copy, what to avoid

What to copy: hardware you cannot inspect directly should not be trusted on a miner's word. lium.io's cryptographic challenge-response check, verified against a shared, hash-pinned library rather than the miner's own report, is a genuine defence against the single most obvious lie a compute-rental subnet's miners could tell. [source] [source]

What to avoid: scoring what is easy to attest instead of what the customer actually experiences, and putting the one number a renter would most want to audit — how much more an H100 is worth than an RTX3090 — behind a runtime lookup instead of in the repository. Nothing in what this dossier could read from lium.io's own source measures a renter's actual job outcome, and nothing in it fixes the per-GPU-model weighting either: the calculation's shape is visible, mining_score = score × gpu_portion × gpu_count / total_gpu_count, but gpu_portion itself is operator-set state fetched at run time, not a value committed to the repository. [source] A subnet that verifies inputs carefully but never measures the output a paying customer received is trusting that the two line up, not proving it — and a subnet whose payout weights live outside its own source cannot be fully audited from that source at all.