Skip to content
Beam Docs

Weights

Understand how verified production work becomes validator weight.

Beam validator weights are the final UID vector submitted to Bittensor. BeamCore materializes the vector from completed production work by qualified orchestrators in the PRISM evidence window, then validators read it and call set_weights.

Final weight formula

BeamCore first computes a base raw score for every qualified orchestrator with a subnet UID:

base_raw_i = verified_uploaded_mib_i * penalty_multiplier_i

It then ranks qualified orchestrators by base_raw and splits emissions into three tiers:

TierRank bandNominal emission bucket
ATop 10%80%
BNext 30%15%
CRemaining orchestrators5%

Within each active tier, that tier's bucket is split proportionally by base_raw:

tier_weight_i      = base_raw_i / SUM(base_raw in tier_i)
normalized_weight_i = effective_tier_bucket_i x tier_weight_i
uint16_weight_i     = floor(normalized_weight_i x 65535)

If Tier B or Tier C is empty or has zero total raw score, its bucket rolls up into Tier A. Zero-raw orchestrators never receive positive weight.

Example

Assume ten qualified orchestrators have positive raw score. Tier A contains one orchestrator, Tier B contains 3, and Tier C contains 6.

UIDbase_rawTierEffective tier bucketFinal weight
1250A80%80.00%
4730B15%7.50%
5220B15%5.00%
6110B15%2.50%
70-75split by rawC5%proportional share of 5%

Inputs

Weights are computed only for orchestrators in the qualified pool.

InputSource
verified_uploaded_mibWhole MiB from server-planned chunk sizes for completed production tasks in the PRISM evidence window (1 day by default)
penalty_multiplierQualified PRISM penalty multiplier from configured penalty pressure
UID and hotkeyCurrent orchestrator and metagraph state

The weights dashboard uses a separate scheduler-materialized task count for epoch views. Timeline, chart, detail, and table task labels show completed production tasks whose completed_at falls inside the selected epoch, not the PRISM evidence-window or lifetime task totals. Dashboard API routes must read those materialized summary columns and must not aggregate core.tasks at request time.

No-transfer behavior

If the PRISM evidence window has no completed production tasks, BeamCore marks the current summary as all-zero and serves the last valid nonzero epoch summary to validators.

If no valid historical summary exists, BeamCore falls back to the dust vector:

UID 0 burn share      = 90%
active UID dust share = 10% split across eligible recipients

If there are no dust recipients, BeamCore returns a UID 0 burn-only vector.

Validator consumption

Validators fetch the materialized vector:

GET /Validator/epoch-summary/latest-epoch

The response includes matching uids and weights arrays:

{
	"epoch": 17925,
	"current_epoch": 17926,
	"uids": [12, 47, 52],
	"weights": [0.8, 0.075, 0.05],
	"uint16_weights": [52428, 4915, 3276],
	"formula_version": "tiered_weight_verified_uploaded_mib_x_penalty_based",
	"all_weights_zero": false
}

When current_epoch differs from epoch, validators are applying the latest valid historical vector because the current PRISM evidence window has no usable production weights.

Improving weight share

  • Graduate to the qualified pool by completing calibration work reliably.
  • Complete enough penalty-adjusted uploaded production MiB inside the PRISM evidence window to rank into a higher emission tier.
  • Keep your orchestrator connected and ready so it can receive production assignments.
  • Maintain strong PRISM performance so routing gives you more opportunities to complete production work.

Decentralized distributed bandwidth infrastructure.

On this page