# Initializing the Problem

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.

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

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