Subnet 128: ByteLeap
ByteLeap is Bittensor Subnet 128. The ByteLeap website describes the project as a decentralized public cloud on Bittensor, while the ByteLeap Miner README source frames the repository as the resource aggregation component of a distributed compute platform.
What ByteLeap Provides
The ByteLeap Miner README describes the repository as the resource-aggregation component of the ByteLeap distributed compute platform. In that architecture, miners connect to Bittensor Subnet 128, aggregate worker resources, and coordinate between validators and workers.
At the subnet level, ByteLeap turns compute resource availability and completed work into a miner-scoring signal. The README describes a three-tier system made of validators, miners, and workers: validators coordinate and score, miners aggregate resources and route tasks, and workers monitor hardware and execute compute challenges.
Miner and Validator Roles
Miners manage worker resources and communicate with the Bittensor network. The README describes miner responsibilities as worker lifecycle management, resource reporting, challenge distribution, task routing, and result collection.
Validators coordinate scoring for the network. The README describes validators as creating challenges, validating scores, and calculating weights. It also describes scoring as based on active compute rentals with an availability multiplier, while challenges target workers that are not under active lease.
Relationship to Yuma Consensus
ByteLeap validators convert resource-rental activity, availability, and challenge results into miner scores before calculating weights for Subnet 128. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for miners registered on a subnet.
In ByteLeap’s context, those weights are tied to the compute network’s three-tier model: validators coordinate scoring, miners aggregate worker resources, and workers execute compute tasks or challenges. The Emission documentation describes how consensus weights determine each participant’s share of subnet emission across miners and validators.
Worker Aggregation Context
ByteLeap’s subnet design separates compute participation into validators, miners, and workers. The README describes validators as the coordination and score-validation layer, miners as the resource aggregation and Bittensor interface, and workers as the hardware-monitoring and compute-execution layer.
That role split matters because a ByteLeap miner is not just a single machine advertising capacity. The miner aggregates worker resources, reports availability, routes tasks, and collects results from workers that execute compute challenges or provide leased compute capacity.
The website’s public-cloud framing matches this architecture. ByteLeap is presented as cloud infrastructure, but the README narrows the subnet mechanism to a three-tier compute network where the miner coordinates worker resources on behalf of the Bittensor-facing subnet participant.
Lease and Challenge Context
The README describes two important scoring contexts: active compute rentals and computational challenges. Active leases generate the primary score, while availability affects the final score through a multiplier. Challenges are directed at workers that are not currently under active lease.
This means ByteLeap has both marketplace and verification dimensions. Leased workers represent productive compute demand, while unleased workers can still be challenged so validators have a way to test the resources miners report.
The result is a compute subnet where miner value depends on aggregated worker capacity, worker availability, and completed work rather than on a miner merely registering a hotkey. The README’s three-tier description keeps those responsibilities separate: validators coordinate checks, miners aggregate and route, and workers perform the hardware-side execution.
On-Chain Identity
Live SN128 subnet data is available on TaoStats. The source-backed worker aggregation, lease, and challenge details in this article come from the ByteLeap website and Miner README rather than from live identity fields.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For ByteLeap (SN128), 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, ByteLeap (SN128) is registered as the live production subnet at netuid 128. 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.
Netuid 128 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 128 is the subnet registered at netuid 128 (Glossary: Netuid). The Understanding Subnets reference explains that each subnet runs its own incentive mechanism while sharing the same underlying Subtensor chain, so the netuid is the stable handle that distinguishes ByteLeap from every other subnet.
For a reader, this means “Subnet 128” and “netuid 128” refer to the same on-chain slot. A claim about ByteLeap should be tied to that netuid rather than to the registered name alone, because the name field can be changed on-chain while the netuid stays fixed.
Reader Boundary
Subnet 128 ByteLeap should not be read as generic Bittensor subnet documentation, a guarantee of available compute capacity, or a retail cloud-hosting service. It names one subnet’s distributed-compute network where miners aggregate worker resources for compute leases and validator challenges on netuid 128 (Understanding Subnets, Glossary: Netuid).