Subnet 105: Beam
Beam is Bittensor Subnet 105. Public Beam materials describe participant software for coordinating bandwidth work across orchestrators, worker gateways, workers, and validators.
The Beam README describes participant software for the subnet’s orchestrator, worker gateway, worker, and validator processes. It says participants contribute bandwidth, execute transfer chunks, and set Bittensor weights from BeamCore’s verified performance data.
What Beam Provides
Beam provides software for coordinating data movement between storage endpoints. The README’s runtime flow places BeamCore, the orchestrator gateway, the orchestrator, the worker gateway, and the worker in the coordination path, while workers move data directly between storage sources and destinations.
BeamCore is the coordination stack behind this workflow. The public BeamCore transparency README identifies reference code for transfer assignment and PRISM scoring, including orchestrator selection, chunk allocation, stale reassignment, score computation, and scheduled metrics refresh.
Participant Flow Context
The Beam README source describes Beam participant software around orchestrator, worker gateway, worker, and validator processes. The orchestrator maintains the gateway connection, advertises the worker gateway, routes task offers to workers, and reports worker decisions and results. Workers register with BeamCore, connect through the worker gateway, execute assigned transfer chunks, and post payment evidence.
That role split is useful for understanding the subnet without turning the article into an operator guide. BeamCore coordinates the transfer lifecycle and scoring services, while the byte movement happens outside BeamCore. The source says object bytes do not pass through BeamCore; workers receive task-scoped source and destination URLs for the chunk they are assigned.
For readers, the key boundary is therefore between coordination and execution. BeamCore organizes tasks, gateways, evidence, and validator-facing summaries. Workers perform the transfer work against the assigned storage endpoints. Validators then read BeamCore epoch summaries, set subnet weights, and post weight proofs.
Reference: Beam participant README
Assignment and Scoring Context
The BeamCore transparency README identifies public reference code for two specific pieces of BeamCore: transfer assignment and PRISM scoring. Its file list describes assignment code for orchestrator selection, chunk allocation, and stale reassignment, plus PRISM code for score computation and scheduled metric refresh.
Those public copies make the article’s scoring boundary more precise. Beam’s participant README describes workers posting payment evidence after chunk work, while the BeamCore transparency source shows where assignment and scoring logic are documented for review. The validator-facing output is not a raw bandwidth claim by itself; it is the result of BeamCore’s assignment, evidence, and scoring path.
This also explains why Beam is best read as a coordinated transfer subnet rather than a generic VPN or endpoint-uptime network. The source-backed workflow starts with assigned transfer work, records payment evidence from workers, computes PRISM-related scores, and exposes epoch summaries that validators can use when setting weights.
References: Beam README source, BeamCore transparency README source
Miner and Validator Roles
Beam’s public materials describe miners as orchestrators and workers. Orchestrators coordinate bandwidth work through BeamCore, while workers execute assigned transfer chunks and post payment evidence.
Validators read BeamCore scores and PRISM inputs and set weights on Bittensor. This maps Beam’s bandwidth-transfer workflow onto the broader Mining and Validating pattern, with validator weights ultimately flowing through Yuma Consensus.
On-Chain Identity
Live SN105 subnet data is available on TaoStats. The mechanism details in this article are tied to Beam’s participant README and BeamCore transparency README rather than to live identity fields.
Relationship to Yuma Consensus
Subnet 105 uses Yuma Consensus to convert the bandwidth-contribution weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Beam’s context, validators read BeamCore epoch summaries and PRISM scoring outputs that reflect orchestrator selection, chunk allocation, and worker evidence collected during the transfer cycle, translating those verified performance 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 105, this sequence gives readers a boundary for interpreting subnet examples and network-context notes.
Localnet examples are isolated and reflect local chain state, so they are useful for controlled experiments rather than evidence of live Bittensor behavior. Testnet examples add shared non-production conditions, which can reveal integration behavior without touching mainnet state.
On mainnet, Subnet 105 examples should be read as live production subnet behavior on the production Bittensor network.
The Bittensor Networks reference separates mainnet, testnet, and localnet, so outcomes from one environment should not be treated as proof of behavior in another.
Reader Boundary
Subnet 105 Beam should not be read as generic Bittensor subnet documentation, a consumer VPN service, or proof that endpoint uptime alone earns subnet weight. The Beam README source describes orchestrators and workers coordinating assigned transfer chunks with payment evidence posted back to BeamCore.
Transfer Data Stays Outside the Coordination Layer
The same README states that object bytes do not pass through BeamCore and that workers receive task-scoped source and destination URLs for assigned chunks. BeamCore’s coordination and scoring role should be separated from the byte movement workers perform between storage endpoints.
Weights Follow PRISM Summaries, Not Raw Bandwidth Claims
The BeamCore transparency README documents public reference code for transfer assignment and PRISM scoring. Validator-facing weights are tied to BeamCore epoch summaries built from assignment, evidence, and PRISM outputs rather than to unaudited bandwidth assertions alone.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).