The Primal Problem (Phase 1)

The time has come now to formulate and visualize our primal problem. The general idea is to maximize the qualified volume, T, we defined previously for epoch i. The more high signal volume that prediction markets receives the better.

Where:

• V_i^prev is the rolling array of qualified volume wagers made by miner i

• x_i is the allocation fraction for the miner i. It represents how much qualified volume we will fund

• n is the number of total miners competing

The optimizer continuously maximizes qualified volume by setting allocations x_i. Miners influence these allocations indirectly: by plugging in possible eligible volume and achieving a positive ROI over time, they increase the likelihood of a more favourable x_i in the next epoch, and vice versa. A more favourable x_i can be seen as a promise of opportunity for the current epoch which the miner can capitalize on and earn alpha tokens as a reward.

Budget Constraints

The x_i is controlled by various constraints of which the first is the maximum budget allocation we can reward the miners. To express this constraint we write:

Where B is the total budget of emissions for this epoch and c_i is a payout weight understood as the token cost of rewarding miner i for one unit of allocation. If a miner had big volume over the past n epochs and good ROI, then c_i is large. Funding them (turning up x_i) makes total payouts jump quickly. If a miner had low volume or tiny ROI, then c_i is small. Funding them costs very little. If a miner had negative ROI, then c_i = 0 and eligibility will cut them off from emissions rewards. In this primal, the cost function serves to ensure our rewards summed over the miners do not exceed the budget.

Although this constraint is powerful, it’s not enough because the case might emerge when a big budget is set, but no positive ROI action occurs. Miners don’t get paid out just for existing. So we set a κ cap constraint that throttles rewards so they only scale with eligible volume, and the extra budget is not paid out this epoch and remains available in the emission schedule if the miners do not perform over a period of time.

κ is the global cap on payouts per unit of qualified volume. It is understood as a system wide ratio that keeps total payouts proportional to total qualified volume. If the network has been producing a lot of qualified volume over recent epochs, then κ shrinks so we don’t overpay per dollar of flow. If the network has been producing very little, then κ rises and the system automatically offers a higher rate per dollar to attract miners back. Now our budget constraints forbid wasteful emissions to globally underperformant periods of mining.

There is one final consideration in the budgetary constraints. There could be a case where an individual miner is so dominant that they consume all of the rewards, making the tournament’s supplied inference fragile and discouraging participation from miners who might be valuable in the future. To prevent this, we impose a diversity constraint which limits any one miner’s share of the total budget.

Formally, for each miner i:

where ρ is a fraction of the epoch’s total qualified volume T. This ensures no single miner can capture more than ρ of the pie, keeping the feasible set well-balanced and avoiding overfitting to one signal. In total, the budget cap, the κ cap, and the diversity constraint together ensure a broad distribution of rewards that sustains a steady flow of competitive qualified volume and inference signal to prediction markets.

Eligibility

Of concern is the ability to qualify useful inference. We generally don’t want random guessing or subjective heuristics to have any influence on the collective signal, and so we introduce the concept of eligibility by proof of skilled wagering. To do this, we propose disqualification constraints on winning volumes:

Any of these constraints, if broken, will disqualify winning volume for the epoch. We want the potential volume to be qualified only if it generates ROI at least greater than or equal to a positive threshold. This is straightforward. Furthermore, we want the miners to trade some minimum volume so they don’t try to collect rewards on micro-trades, so we enforce that the trailing volume over n epochs is at least above a lower bound. Last of all, we want to ensure that the miner is staking rationally. We do this by invoking the Kelly Criterion and define f_i as the median of the trailing position’s stake size divided by the implied bankroll. If f_i falls between something rational like 1% to 10% of the implied bankroll size, we can assume there is a good chance the miner is rational and not trying to make outrageous hail mary trades or minuscule trades which imply no kind of sustainable inference with value.

Ramp Constraint

The last constraint for our primal optimization problem is designed to squash any kind of whipsawing effect in the optimization output from epoch to epoch. We call this the ramp constraint and it governs how much the allocation knob x_i for each miner can change between epochs.

Formally, for each miner i:

Without a ramp constraint, allocations could jump wildly. One epoch a miner could get nothing and the next epoch they suddenly could get everything. This would create “bursty” or unstable routed volume into prediction markets, which is undesirable for market stability. The ramp ensures miners aren’t whipsawed by sudden, extreme allocation changes just because of short term noise in ROI or volume. Miners can adapt, but the system only shifts gradually. By forcing allocations to move at a desired rate, the optimizer is implicitly filtering out high-frequency noise and only sustained performance leads to steadily increasing allocations.

Full Primal Problem

Stated thusly the primal problem in its entirety is:

This program answers the question: “What is the most volume we can route, given the rules?”. It formally returns two optimal values. First, T* which is the largest feasible flow of qualified volume that can be routed to prediction markets this epoch while respecting all the guardrails (budget, κ cap, diversity, ramp, eligibility). The second return is an allocation vector where each x_i*​ tells us what fraction of miner i’s past eligible volume is being “funded” this epoch. Note, if:

• x_i* = 0: miner is excluded.

• 0 < x_i* < 1: miner is partially funded.

• X_i* = 1: miner is fully funded (within eligibility and diversity limits).

And the outputs In plain english:

• “How much of each miner’s slice is included in making that pie?” (that’s the vector x∗)

• “What’s the biggest pie of qualified volume we can route this epoch?” (that’s T∗)