Initializing the Problem

We require a few pieces of data to incentivize the miners

Bittensor, like any blockchain, works by validating all the inputs in a block and for Almanac, our blocks of routed unqualified volume must be initialized by passing in initial conditions so the validators can compose the problem and solve the optimization. We offer a convenient table of python native variables and explain them in the context of the initialization.

Variable	Data Type	Example	Explanation
n	Integer	100	Number of miners providing signals/volume.
B	Float (tokens)	1000.0	Total token budget available to allocate this epoch.
Vᵢ	Array[Float], length = n × k	[1200, 980, 1040, …] for each miner	Rolling qualified volumes (net of 1% fee) over the last k epochs. Captures scale of flow.
ROIᵢ	Array[Float], length = n × k	[0.04, 0.06, 0.05, …] for each miner	Rolling ROIs (fractions, not %). Captures profitability/adverse selection ability over the last k epochs.
x_prev	Array[Float], length = n	[0.10, 0.00, 0.05, …]	Allocation fractions from the previous epoch (carried forward for ramp).
v_prev	Array[Float], length = n	[5000, 4800, 5100, …]	Aggregate volumes across miners (used to compute HHI for ramp constraint).
v_total	Float	100000.0	Total market volume across all miners last epoch (normalizes HHI).
ROI_min	Float (threshold)	0.02	Minimum rolling ROI required for miner eligibility.
V_min	Float (threshold)	100.0	Minimum trailing qualified volume required for eligibility.
ρ_cap	Float (share cap)	0.10	Maximum share of routed volume any single miner can receive (e.g., 10%).
κ̄	Float (ratio)	B / Volume_prev = 0.9	Payout-to-volume cap: ensures total payouts don’t exceed sustainable ratio.
ε	Float	1e-4	Tolerance for Phase 2: ensures (T ≥ (1−ε) T_1).
ramp	Float	0.01	Smoothness parameter derived from HHI: limits how much allocations can shift epoch to epoch.

This comprises the data we use to score the miners in the epoch by validators as the initial conditions.