Skip to main content

Lium (Subnet 51)

Lium (Subnet 51) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Lium — an AI/Compute / Infra project on Bittensor (subnet), token (symbol: —).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a platform for renting GPU resources on top of Bittensor Subnet 51: a network of GPU providers (miners) and validators.
  • Who it’s for: for teams/developers who need GPU rentals; and for GPU providers who want to earn by connecting as miners.
  • Why onchain/token: the Bittensor onchain layer is used for participant accounting and subnet incentives; a separate project token utility is not confirmed per Tier‑1.
  • What you can actually touch (Tier‑1): registration/dashboard on lium.io and/or the CLI (lium init → lium ls → lium up).

How it works (very briefly)

  1. The renter does: registers on the platform or sets up the CLI.
  2. The system does: shows the available GPU executors and their parameters.
  3. The renter receives: a running GPU pod (with the ability to SSH/copy files/execute commands).
  4. Where the blockchain is: the Bittensor subnet provides the incentive model/participant accounting; rental/pod management operations take place via the platform/CLI.
  5. Token role (if any): a separate project token and its role are not confirmed by Tier‑1.

Quick links: AI thesis fit

Project passport

Field Value
Project name Lium (Subnet 51)
Also known as (aliases) Celium (in listings); Lium Subnet 51
Logo (logo) ../assets/448_celium_logo.ico
Token symbol (ticker) —
Category AI/Compute | Infra
Primary chain (chain) Bittensor
Type Appchain
Network status mainnet
Consensus (consensus) PoS
Launch date (launch_date) —
Project status (status) active
Token (standard) —
Token contract —
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) Payment/top‑up and billing are described as features; token mechanics are not disclosed per Tier‑1
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) Datura-ai (core contributors)
Funding (investors/funding) —
AI component (ai_component) GPU rentals for AI workloads
Use‑case (use_case) GPU pod rental
DecAI Fit — AI thesis fit 2/6 — low alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 2 / 0 / 0
Last verified 2026-02-11

General project overview

Lium describes itself as a GPU compute rental platform built on Bittensor’s subnet infrastructure (Subnet 51). From a product standpoint, it is a “compute marketplace”: providers supply GPU resources via the network, and renters get access to them through a web interface and a CLI.

The Tier‑1 documentation emphasizes the basic rental flow: viewing available GPUs, creating a pod, managing the pod (SSH/copying files/executing commands), as well as convenience features such as auto‑termination and backups (in the CLI).

Features/modules

  • Web platform: registration and management of rentals via the interface.
  • CLI: the commands lium init/ls/up/ps/ssh/exec/scp/rsync/rm and auxiliary ones (volumes/backups/schedules).
  • Decentralized subnet layer: GPU providers (miners) and validators (per the description in the docs).

Typical scenarios

  • Scenario 1 (renter): selects a GPU → launches a pod → deploys code/data and runs computations.
  • Scenario 2 (GPU provider): connects a GPU as a miner → provides resources → receives rewards/income (Tier‑1 does not disclose the details).
  • Scenario 3 (DevOps): manages pods via the CLI (creation, TTL/until, backups/restore, volumes).

Getting started (wallet/network)

  • What you need: an account on lium.io and/or Python 3.9+ to install the CLI.
  • Network/chain: Bittensor mainnet (Subnet 51).
  • Fees: the rental cost depends on the executor; Bittensor onchain fees are standard (details not disclosed in Tier‑1).

Architecture/tech (non‑AI)

  • Components: the Bittensor subnet (miners/validators), the Lium platform, the CLI client, GPU pods (executors).
  • Participant roles: renters, GPU providers (miners), subnet validators.
  • Where logic runs: rental/pod management — offchain via the platform/CLI; subnet accounting/incentives — in the Bittensor layer.
  • Dependencies: providers’ GPU infrastructure; network access for SSH/copying.

Token/economics (expanded, no forecasts)

  • Token utility: Tier‑1 does not describe a separate project token and its utility; payment/billing are described as part of the product.
  • Protocol necessity drivers: to pay for compute rentals and to incentivize GPU providers.
  • Who pays fees: renters pay for rentals; providers receive income/rewards (terms not disclosed by Tier‑1).
  • Where fees go: the distribution of income/fees is not established per Tier‑1.
  • Issuance/burn / token distribution: not established per Tier‑1.
  • Security/incentive mechanisms: incentives at the subnet level (miners/validators); slashing/penalty details are not established per Tier‑1.
  • Treasury: not established per Tier‑1.

Governance

  • Who makes decisions: not established per Tier‑1.
  • How protocol parameters change: via updates to the platform/CLI and the subnet; a formal DAO process is not described.
  • Where decisions are discussed/made: GitHub/Discord (see links_*).

Security and incidents

  • Audits: not established per Tier‑1.
  • Bug bounty: not established per Tier‑1.
  • Incidents: not established per Tier‑1.
  • Threat model: security of access to pods/keys and trust in the execution providers; Tier‑1 does not disclose the details.

Project status and timeline

  • Current status: active (Subnet 51).
  • Key releases/milestones: CLI changes are recorded in CHANGELOG.md (see links_*).
  • Roadmap: not established per Tier‑1.

Ecosystem/integrations

  • Integrations: Bittensor; scenarios — any GPU tasks (AI training/inference, HPC), depend on the user.
  • Partners: not established per Tier‑1.
  • Where it’s actually used: renting GPU pods via the web interface/CLI.

AI component of the project

  • What is real AI here? Lium is GPU compute infrastructure: it is not itself a model/agent, but is intended for running computational tasks (including AI workloads) on rented GPUs.
  • What is truly onchain? Subnet participants/incentives on Bittensor; rental/pod management operations are described as product‑level (offchain).
  • Why is a token needed? The utility of a separate project token is not established per Tier‑1.
  • Red flags (based on the information found): AI‑washing (if an “AI protocol” is claimed while in fact it is GPU rental); token‑washing (Tier‑2 listings without Tier‑1 utility); what to double‑check: the token model and onchain components beyond the subnet.

DecAI Fit component summary

  • DecAI Fit: 2/6 — low alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity medium 2
Token necessity low 0
Evidence Tier‑1 present (AI/OC) 0
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): A roadmap about AI as a separate component is not recorded in Tier‑1.
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): The documentation describes a GPU rental product, without a separate AI roadmap.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): Per Tier‑1, Lium does not perform AI features itself but provides GPU infrastructure.
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): GPU rental is described, without AI algorithms/models.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): There is a step‑by‑step CLI quickstart for launching a GPU pod and a link to registration on the web platform.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/Datura-ai/lium/main/README.md; Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): Tier‑1 contains the commands lium init/ls/up and a link to registration/the dashboard.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): Quality metrics of AI models are not applicable; performance metrics of the GPU service are not disclosed in Tier‑1.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): Roles (renters/providers), product features and CLI commands for pod management are described.
  • Evidence: Tier‑1 — https://docs.lium.io/intro; Tier‑1 — https://raw.githubusercontent.com/Datura-ai/lium/main/README.md
  • Why sufficient / why not (one line): There is a sufficient tech description of the interface/rental and management operations.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Bittensor
  • Addresses/identifiers: subnet 51 (Lium)
  • Evidence: Tier‑1 — https://docs.lium.io/intro; Tier‑2 — https://taostats.io/subnets/51/chart
  • Why sufficient / why not (one line): Tier‑1 states directly that the product runs on Bittensor Subnet 51; Tier‑2 provides subnet metrics.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: participant accounting and subnet incentives (miners/validators) in the Bittensor layer; not reducible to “just a token”.
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): Tier‑1 records the Bittensor subnet architecture as the basis of the product.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: without the Bittensor onchain, subnet incentives/accounting are lost; but Tier‑1 does not prove that the GPU market cannot be implemented offchain.
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): A replaceability test has not been performed in Tier‑1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The existence/absence of a separate project token is not confirmed by Tier‑1.
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): Tier‑1 does not describe a token; CoinGecko — a reference Tier‑2.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): Payment for rentals via a project token is not confirmed by Tier‑1.
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): The documentation talks about payment/billing but does not record token mechanics.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): Tier‑1 does not describe incentives/collateral/penalties via a project token.
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): Incentives are described at the subnet level, without a separate token.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): Governance via a project token is not described (Tier‑1).
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): There are no Tier‑1 statements about a governance token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): Without Tier‑1 utility of a project token, the replaceability assessment is invalid.
  • Evidence: Tier‑1 — https://docs.lium.io/intro
  • Why sufficient / why not (one line): It is not established what exactly is to be “replaced”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.lium.io/intro The project runs on Bittensor Subnet 51; description of the GPU rental product and roles (renters/providers)
Tier‑1 https://raw.githubusercontent.com/Datura-ai/lium/main/README.md CLI quickstart and pod management commands (lium init/ls/up/ps/ssh/scp/rm) — confirmation of “what you can touch”
Tier‑1 — No Tier‑1 source for claim “there is a separate project token and a clear utility/tokenomics” was found / not confirmed by Tier‑1.
Tier‑2 https://taostats.io/subnets/51/chart Context: metrics of subnet netuid 51
Tier‑2 https://www.coingecko.com/en/coins/celium Context: reference listing (not counted as proof of utility)

No comments to display

Back to top