Subnet 75: Hippius
Hippius is Bittensor Subnet 75. The Hippius website describes the project as decentralized cloud infrastructure for storage, virtual machines, and applications. The Hippius README source frames the subnet around distributed storage, compute, blockchain management, IPFS integration, resource marketplaces, and offchain workers for system metrics.
What Hippius Provides
Hippius provides infrastructure for decentralized cloud services. Its public materials describe file storage, virtualized compute resources, and application-oriented cloud services as the main workloads coordinated by the subnet.
The README frames the system around storage and compute resources. Storage work is tied to IPFS-based file handling, capacity tracking, file health, and replication status. Compute work is tied to virtualized resources, task execution, resource allocation, and performance metrics.
Miner and Validator Roles
Hippius describes two miner roles. Storage miners run IPFS nodes, manage storage infrastructure, and report storage capacity, file health, and replication status. Compute miners provide virtualized compute resources, manage task execution, and report resource availability and performance.
Validators verify network operations and collect performance data. The README also says validators monitor storage and compute usage and help manage replication and task assignment. At the Bittensor level, validator weights are processed through Yuma Consensus.
Storage Placement Context
The Hippius incentives guide describes file placement goals for the storage side of the subnet: maintain a target number of replicas, spread replicas across independent families, prefer reliable and available miners, respect storage capacity, and heal under- or over-replication.
For storage miners, Hippius storage work is not just raw disk space. The source materials connect that work to replica diversity, miner availability, capacity headroom, and ongoing health checks.
The guide also gives the storage mechanism an anti-centralization dimension. Its family-diversity rules aim to avoid placing every replica of a file inside the same linked miner family, and its rebalancing notes describe retrying under-replicated files rather than treating partial placement as a final state.
The same failure-handling section says existing replicas are kept when no candidate meets the constraints, so placement can continue later without dropping already healthy copies.
The same guide distinguishes placement rules from marketplace alpha routing and other on-chain flows. That distinction keeps the storage explanation focused: placement logic describes how files are assigned and kept healthy, while broader reward and marketplace mechanics belong to separate system components.
On-Chain Identity
Live SN75 subnet data is available on TaoStats. The source-backed storage, compute, and placement details in this article come from the Hippius website, README, and incentives guide rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 75 uses Yuma Consensus to convert the storage-and-compute performance weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Hippius’s context, validators verify network operations, collect performance data, and score storage miners by family-wide pin success, storage share, and temporal smoothing, then translate those scores into weight vectors for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Subnet 75, that sequence applies to the standard Bittensor lifecycle: localnet for isolated development, testnet for shared non-production testing, and mainnet for live operation with real emissions.
On mainnet, Subnet 75 is registered as the live production subnet at netuid 75. The Bittensor Networks reference separates mainnet, testnet, and localnet. Participation examples or emission outcomes from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 75 Hippius should not be read as generic Bittensor subnet documentation, a centralized cloud provider, or a durability or uptime guarantee. It names one subnet’s blockchain-backed decentralized cloud — IPFS-based storage and virtualized compute coordinated across storage miners and compute miners — on netuid 75 (Hippius site — hippius.com, Understanding Subnets, Glossary: Netuid).
Miners report storage capacity, file health, and replication or compute performance that the subnet measures, so the article describes the coordinated resource model rather than a commitment that any file or task is permanently available.