A Market Mechanism for Rollout
Selection in Group-Relative RL

Romain Fanucci, Malik El — Reliquary

Technical report · September 2026 · Not peer reviewed

Abstract

We present Reliquary, a permissionless market for reinforcement-learning rollouts, and demonstrate it by training a 4B model on math and code. Anyone can participate by choosing prompts and generating groups of completions on their own hardware. Participants compete to supply verified groups that meet the trainer’s reward-variance criterion, with freedom to optimize inference and develop their own prompt-selection strategies, including prediction before generation. A validator verifies and scores submissions; selected groups receive payment and supply the trainer’s updates.

Group-relative RL depends on groups with differing rewards. Over a 12,852-update run from Qwen3-4B-Base, uniform sampling produces progressively fewer such groups: the estimated generation multiplier of a reactive filter rises from 1.1× to 1.9× in math and 2.4× in code. The increase comes from groups with sixteen successful answers, whose zero reward variance is discovered only after generating all sixteen. Reliquary opens the search for eligible groups to independent participants. Its reward integrity design target combines a prescribed public sampling stream with validator-computed rewards; tolerance-based verification approximates this target.

The network supplied approximately 6.6 million training rollouts. The released Reliquary-4B checkpoint gains 31.1 percentage points of held-out math pass@1 and 20.1 points in code on exact-content-disjoint subsets, with transfer to AMC23, AIME, HumanEval+ and MBPP+. The trainer performs no rollout generation. The run demonstrates end-to-end feasibility of market-supplied RL training; generation-cost savings from predictive selection and comparative learning efficiency remain to be measured.

Updated public checkpoint PERMISSIONLESS PARTICIPATION Independent miners Prompt selection · In-zone prediction Inference optimization · Own hardware Generate 16 completions per group CENTRALIZED IN THIS RUN Validator Verify samples Compute rewards · Apply gate Rank and select groups CENTRALIZED IN THIS RUN Trainer Update the policy Publish checkpoints No rollout generation Submit groups Selected groups Payment for selected groups
Figure 1 — System overview. Participation is open: miners independently choose prompts and optimize generation under the protocol’s sampling contract. The validator selects and rewards eligible groups, and the trainer publishes updated weights. Prompt prediction is an available strategy; its generation-cost benefit is not measured in this run.

1. Introduction

Reinforcement learning from verifiable rewards has converged on group-relative methods — GRPO and its descendants[2] — in which a batch consists of groups: G completions sampled from one prompt, whose rewards are normalized against each other to form advantages. The method has a structural dependency that the loss does not reveal: it can only learn from prompts the policy sometimes solves. A group in which every completion earns the same reward has advantages identically zero. It contributes no gradient and has already cost G forward passes.

As a policy improves, some prompts yield increasingly frequent all-correct groups, so whoever supplies rollouts to a GRPO trainer is searching for a frontier that moves under them at every update.

Two families of response exist. Reactive filtering generates first and discards degenerate groups: DAPO’s Dynamic Sampling[1], the largest single contributor in its ablation. It pays for every discarded group. Predicting difficulty before generating — cheap probes, learned predictors, curricula — replaces that waste with an estimate, drawn from the trainer’s own history of reward vectors, of which prompts are worth a group. Either way the trainer pays to find out, and the decision stays with the trainer (§2). A third line moves the compute without moving the decision: decentralized generation on untrusted machines, with the prompts still chosen centrally; we build on it, and compare against it in Appendix D.

This paper describes and measures something else: a market that pays only for variance. Participants spend their own compute choosing prompts and generating groups against a public checkpoint. A validator admits a group only if its reward vector passes a variance gate, pays only for admitted groups, and trains on them. The protocol does not say how to choose prompts. Payment for selected, verified groups lets participants compete on selection and delivery.

Two design objectives motivate the mechanism. Ideally, a participant must be unable to change a single reward-bearing token, since the reward vector is what is paid on — and verified inference in the TOPLOC sense[12] is not enough, because a participant could run the right model twenty times and submit the best group. We therefore fix the sample, not just the model, with a public forced sampling stream, and recompute every reward on the validator. This is intended to make prompt choice the main selection lever, subject to the numerical tolerance and threat-model limits in §4.2. A flat payment for eligible groups removes the earlier payout peak at a particular reward count; generation costs and the tie-break still influence which prompts are profitable (§4.5).

Contributions.

C1. The cost of Dynamic Sampling, measured over a complete run, and its composition. The trainer’s cost of a reactive filter is T = 1/nondeg(θ) for a fixed prompt distribution and sampling contract with no control run; it rose from 1.1× to 1.9× (math) and 2.4× (code), accounted for by the rising k = 16 mass, partly offset by declining k = 0 mass (§3.1–3.3). The selected math batch also shows increasing reference contestation, motivating reference-quality auditing (§3.4).

C2. A mechanism for buying rollout selection from a market, and what it delivered. A market that pays only for groups with variance, with a public sampling stream, approximate sample verification, and validator-computed rewards (§4). Over the run it supplied training groups and, on math, a submitted pool harder than uniform before any ranking (§5). The contribution is an operational mechanism through which miners can compete on predicting in-zone prompts and reducing wasted generation. Section 5.3 separates observed market behavior from the economic benefit that remains to be measured.

As an end-to-end feasibility test, the run also trained a model: with zero generation compute on the trainer’s side, a 4B base gained 31 and 20 points of paired held-out pass@1 on exact-content-disjoint subsets and transferred to external benchmarks (§6). The released-model evaluation also shows a sampled-versus-greedy discrepancy (§6.4). One sentence summarizes the mechanism: participants choose prompts and compete to deliver verified groups that pass the trainer’s variance gate.

1.1 What this paper does not claim


2. The problem and the existing responses

2.1 GRPO groups and degeneracy

For a prompt q, sample G completions from policy θ, score each with a verifier, and form advantages by normalizing within the group: A_i = (r_i − mean(r)) / std(r). When std(r) = 0 every advantage is zero. For binary rewards with k of G correct, this occurs at k = 0 and k = G; the group’s signal √(p(1−p)) peaks at k = G/2. A prompt is in-zone for θ if 0 < k < G; the training signal lives entirely in the in-zone prompts.

2.2 Reactive filtering: DAPO’s Dynamic Sampling

configuration AIME24 avg@32
Naive GRPO 30
+ Overlong Filtering 36
+ Clip-Higher 38
+ Soft Overlong Punishment 41
+ Token-level Loss 42
+ Dynamic Sampling (= DAPO) 50

Dynamic Sampling adds 8 points, the largest single contribution of the five (the others add 6, 2, 3 and 1) and the only one that is a data-selection change rather than a loss change.[1] The procedure discards degenerate groups and resamples until the batch is full. DAPO acknowledges the cost without quantifying how it evolves; §3 does.

2.3 Predicting difficulty before generating

The cost of reactive filtering is well understood, and a line of work removes it by deciding before the rollouts are spent. Its empirical foundation is that a prompt’s value is temporally predictable: prompts that are zero-variance in one epoch are overwhelmingly zero-variance in the next, and the effective prompt ratio can fall to around 20% late in training. GRESO[4] turns that into a probabilistic pre-rollout filter — each prompt is skipped with a probability that rises with its recent run of zero-variance epochs, with a self-adjusting exploration rate so skipped prompts are revisited — and reports up to 2.4× wall-clock speedup in rollout and 2.0× in total training time without accuracy loss.

Three other families attack the same estimate. Cheap probes: SPEED-RL proposed screening with 4–8 responses before committing to a full group, but its authors later withdrew the preprint because of experimental bugs; we cite it as a proposal, not as evidence. [5] Learned predictors: MoPPS[6] models each prompt’s success rate as a latent variable, updates a streaming Bayesian posterior and selects by posterior sampling in a bandit; Prompt Curriculum Learning[7] uses a light on-policy value model to pick prompts near a 50% success rate without rollout evaluation. Adaptive group construction: Reinforce-Ada[8] varies the number of responses per prompt instead of the set of prompts. A contrarian strand argues the discarded prompts are not worthless and can be exploited rather than filtered.[9]

Two things about this literature matter here. First, it confirms the problem this paper measures: the interesting question is not whether to filter but who pays to find out, and every method above is an attempt to make the trainer pay less. Second, all of them estimate difficulty centrally, from the trainer’s own history or its own probes, and so remain bounded by what the trainer has already generated. The strategy suggested by the archive (§5.3) is consistent with using past reward vectors to select prompts. The archive does not establish that participants predict in-zone status before generation, or quantify the generation cost they avoid.

2.4 What they have in common

Both families decide which prompts get a group from one point — the trainer — using information that is either after the fact (reactive filtering) or a prediction from the trainer’s own history and probes. Either way the trainer pays to find out, in discarded generation or in the probes and predictors that replace it. None of them makes the party generating the rollouts bear the cost of a wasted group, and none of them lets that party profit from choosing better. The mechanism of §4 does both.


3. How large is the cost, and how does it grow?

3.1 The reactive-filter cost in closed form

Define nondeg(θ) as the probability that a prompt drawn from the training distribution produces a group with 0 < k < G under policy θ at the training sampling protocol. A reactive filter’s expected generation multiplier is

    T(θ) = 1 / nondeg(θ)

T is conditional on the policy, prompt distribution and sampling contract. The identity assumes repeated independent draws with unchanged acceptance probability. It counts complete generated groups, not tokens or GPU time, and does not cover predictive selection or early stopping. No control training run is needed to estimate this checkpoint-level quantity. Three properties matter:

  1. T ≥ 1, with equality if every sampled group is accepted.
  2. T need not increase with policy quality. It rises when mixed-outcome groups become less frequent overall; improvement on previously unsolved prompts can instead increase their frequency.
  3. T diverges. As nondeg → 0, T → ∞. This is conditional on nondeg approaching zero, not a general prediction for every training trajectory.

§3.4 examines reference contestation in the selected batch separately from this cost identity.

3.2 Method

Every published checkpoint of one continuous run is evaluated on a fixed held-out suite: 500 prompts per environment, k = 16 rollouts each (8,000 graded rollouts per cell), under the training contract exactly — T = 1.0, top_p = 1.0, top_k = 0, raw prompt encoding, 8,192-token cap, production grader. The same prompts are used at every checkpoint, so every comparison in this paper is paired at the prompt level. nondeg at each checkpoint is the fraction of prompts with 0 < k < 16.

The suite must be offline and fixed. Any distributional statistic read from live production traffic is confounded by participant prompt selection: what arrives in the archive is what participants chose to send, not what the policy does on a uniform draw. §5 compares the two directly, and they differ at every checkpoint.

The suite is held out by index, not by content, and that was not enough. Nothing in the market excludes the held-out indices, and OpenMathInstruct-2 repeats each problem under ~23 row indices. Checked after the run against every trained content: 218 of the 500 math prompts (43.6%) and 49–65 of the 500 code prompts (10–13%) were trained on — in math almost all under another row index of the same problem, in code 41 at the held-out index itself. Every held-out figure in this paper includes them. Where it matters the original run analysis reported both: the base → update 12,842 pass@1 gain was +34.3 / +20.7 on the full suite and +31.0 / +19.6 on the uncontaminated prompts. These historical figures are retained for the original series; §6.2 separately reports the released weights using an exact-content-only exclusion. The in-zone k-distributions move by at most 0.44 k when contaminated prompts are removed. “Uncontaminated” means no trained content matches by exact hash or by 8-gram Jaccard ≥ 0.8 — in math the two criteria flag the same 218 prompts, every near-duplicate being an exact duplicate under another row index; an embedding-based check was started and not completed, so paraphrase-level leakage below that threshold is not excluded. The transfer benchmarks are unaffected. The next run excludes the held-out set by content hash on the validator and checks the archive afterwards (§7.3).

Checkpoints are named throughout by their update count (windows since the base reset). The published checkpoint identifiers are not update counts — the counter is inherited across weight resets and jumped 712 → 1084 on 2026-08-27 — and are given only in Appendix A, where they are needed to fetch the weights.

3.3 Result

math base math u8,800 math u12,842 code base code u8,800 code u12,842
nondeg 0.900 0.568 0.526 0.882 0.428 0.414
T = 1/nondeg 1.11× 1.76× 1.90× 1.13× 2.34× 2.42×
k = 16 share 0.2% 37.6% 40.8% 1.2% 47.2% 49.0%
k = 0 share 9.8% 5.6% 6.6% 10.6% 10.0% 9.6%
Figure 1
Figure 2 — The reactive-filter cost over the run. (a) Share of the 500 held-out prompts per environment that are in-zone (1 ≤ k ≤ 15), 16/16 observed successes (k = 16) and 0/16 (k = 0) at each evaluated checkpoint (81 math, 79 code, one every ~160 updates). (b) T = 1/nondeg, the groups a reactive filter generates per group it keeps. Pointwise binomial standard error for an estimated proportion p is √(p(1−p)/500), approximately 2.2 percentage points at p = 0.5; the series is not step-monotone at that level (no dip larger than 0.16 in T). Dashed vertical line: 2026-08-29 15:22 UTC, admission budget 64 → 96. Data: 01-nondeg.csv.

At the end of the run a reactive filter discards 47% of math groups and 59% of code groups under this uniform-draw estimate. The decomposition matters: the increase is accounted for by the growing k = 16 mass — 16/16 observed successes — which rises from 0.2% to 41% (math) and 1.2% to 49% (code), while k = 0 declines (9.8 → 6.6%, 10.6 → 9.6%), partly offsetting the increase. The filter increasingly discards what the model solves on every one of the sixteen attempts, and discovers this by solving it sixteen times. It is the growth of these all-success groups, rather than of all-failure groups, that makes in-zone groups rarer in the observed run. With 500 prompts per point the series has a binomial standard error of about 2.2 points at nondeg ≈ 0.5 and T is not step-monotone (no dip larger than 0.16); it is monotone at the scale of 50 checkpoints. Between updates 8,800 and 12,842 math nondeg still falls (0.568 → 0.526) while pass@1 moves 0.7 points: the estimated filtering cost continues to rise while the measured math improvement is small.

Post-trained checkpoints remain a separate test. This run starts from a pretrained base and observes a multiplier of up to about 2.4×. A stronger checkpoint may yield fewer in-zone groups on a saturated corpus, but that depends on the model, corpus and sampling contract. No post-trained-checkpoint result is reported here.

3.4 Reference-quality warning near the math plateau

Math performance largely plateaued while code continued to improve. We therefore record one diagnostic signal that could make reference quality more influential near the plateau. The two environments differ in corpus and reward function, so this comparison does not identify a cause.

A group is informative about reference quality only when the model and the grader disagree systematically; convergence alone does not show that the reference is wrong. We therefore treat the statistic below as a warning signal, not as a label-error measurement.

Across all 202,873 trained math groups, we call a group contested when at least 8 of its 16 rollouts agree on one final answer but every rollout carrying that answer is graded wrong against the reference. The rate rises from 1.8% over the first ten checkpoints to 11.1% over the last ten (Spearman ρ = 0.44; the series is autocorrelated). Contestation is 11.2% for model-voted references versus 5.1% for human-written references, while the model-voted share of trained groups rises from 86.5% to 98.5%.

This is a warning, not a causal result. A contested group may reflect a wrong model answer, an incorrect or ambiguous reference, or a grader failure; the 8/16 threshold also becomes easier to satisfy as the policy learns to converge. Only 6.2% of contested groups were identified as math_verify false negatives, and the available manual sample is too small to estimate the prevalence of wrong references. The pattern is therefore consistent with reference-quality problems becoming more important near the math plateau, but does not show that they caused it. Auditing and correcting a stratified sample of references is the next experiment.

The composition shift can also reflect source difficulty, availability and depletion. Neither statistic independently identifies label errors as the cause of the plateau.

Figure 4
Figure 3 — Reference contestation in the trained math batch. A group is contested when ≥ 8 (or ≥ 11) of its 16 rollouts agree on a final answer that the grader marks wrong; grader false negatives are contested groups where math_verify judges the modal answer equal to the reference. Per checkpoint, 20-checkpoint rolling mean (raw in grey). Right axis: share of trained groups whose reference was model-voted during corpus synthesis. Black bars: means over the first and last ten checkpoints. Data: 05-contestation.csv.

The observed increase motivates auditing reference quality in both the market selection and reactive-filtering pipelines. It is not a general property of temperature, and this run does not establish that reference quality was the binding constraint on learning.


4. The mechanism, decision by decision

Reliquary is an open protocol and reference implementation running as Bittensor subnet 81. Independent participants (“miners”) spend their own GPU time generating rollout groups against a public checkpoint. A validator admits, grades, ranks, verifies, pays, and trains on the best groups, then publishes a new checkpoint. Instead of the trainer deciding which prompts get a group, anyone may generate a group for any prompt, and the trainer pays only for groups it can learn from. The protocol specifies the checkpoint, the sampling stream, the reward functions, the gate, and the payment rule. It does not specify how a participant chooses prompts; selection and delivery are left open to competition.

Why one property governs every decision below. In group-relative RL the reward vector of a group is the entire training signal: it sets every advantage, decides admission, and — in any mechanism that pays on usefulness — decides payment. A participant who can move one reward by one token can move all three. Proving that the participant ran the announced model is not sufficient: a participant who runs the right model twenty times and submits the group whose reward vector wins has forged nothing and has still chosen the reward. The verification decisions target reward integrity: under exact sampling and verification, the prompt, checkpoint and public randomness would determine the group and its validator-computed rewards. The implementation approximates this objective with tolerance-based sample checks (§4.2). It does not prove that all accepted groups for the same inputs have identical rewards. Payment is restricted to selected groups passing the variance gate. Each decision is given with the measurement that justifies it — what it cost, what it caught, or what it was replaced after.

4.1 One window is one optimizer update

Decision. Each environment collects a pending population for a fixed interval, freezes, admits, ranks, verifies the candidates that can still win, pays, and hands exactly 16 groups per environment to one GRPO update; a checkpoint change discards pending samples, so no update mixes declared generation checkpoints; every 16 windows the model is published and signed. Participants poll the current window and checkpoint, pick a prompt not in cooldown, generate exactly 16 rollouts under the forced stream of §4.2, sign and submit. A common generation checkpoint within a batch does not imply that it equals the optimizer’s current weights. The 16-window publication cadence and pipeline can introduce behavior-policy lag; its exact distribution requires the run’s checkpoint-to-update trace. We therefore claim single-use rollouts, not zero policy lag.

Why. It gives the market a clock, makes nondeg(θ) well-defined per update, and makes updates per day the training budget. The three phases of a window are pipelined: while window i collects, window i−1 is verified and window i−2 is trained, so after the first two windows every lane is busy on every window and the cycle is the longest of the three phases plus handoff, not their sum. Verification and training both take under ~30 s of wall-clock on one H100 each; the cycle is therefore whatever the collection interval is set to, and the collection interval is a choice, not a limit.

Figure 7
Figure 4 — One window loop in cross-section, at two collection intervals. Collection, verification and training are pipelined: while window i collects, window i−1 is verified and window i−2 is trained, so the cycle is the longest phase plus handoff. Top: as run — collection fixed at 100 s so that long rollouts could still arrive and win; verification (under ~30 s) and training (~30 s) wait on it, and the cycle is 102 s. Bottom: the same infrastructure with collection set to the training step, ~32 s per update, about three times the run’s rate. Schematic; verification and training at their run durations.

Measured. Over the run, 12,852 windows over 15.2 days. For two days (08-27 and 08-28) the collection interval was ~70 s and the system ran 1,136 and 1,077 updates a day, the fastest it went; from 08-30 to the end it was fixed at 100 s, giving 825–921 updates a day at a median cycle of 102 s. The 100 s was deliberate: longer than the phases it feeds so that long rollouts could still arrive and win (§4.5). Had the interval been set to the training step — ~32 s including handoff — the same infrastructure would have run ~2,700 updates a day, three times the run’s rate; that is the setting of the next run. The validator’s binding cost is the re-forward of §4.2: 226 hours of proof-process time over the run (proofs run concurrently on the one H100; wall-clock verification per window stays under ~30 s), a median of 33 proofs per window, against zero generation. Reaching a pipelined loop took three weeks of throughput work on an unchanged GPU count — the levers, their measured rather than predicted effects, and two throughput predictions that were announced and measured false are in Appendix C.

4.2 Fix the sample, not the model

Decision. Every decode step is forced onto the token selected by a uniform variate u derived from window randomness, prompt, checkpoint, rollout index and token position — and deliberately not from participant identity. The prescribed stream is shared by all participants for a given prompt and window. The validator re-derives, under the published checkpoint, the chosen-token probability at every position (token authenticity) and the probability the model assigned to EOS where it was emitted (p_stop); a group whose match rate falls below the floor is rejected.

Intended protection. Binding generation to public randomness removes participant-selected seeds from the specified sampling contract; changing identity does not change that stream. This targets sampling choice as well as forward-pass correctness. In exact arithmetic with exact verification, fixed inputs would determine the group. With tolerance-based verification, however, a different sequence or model may still pass. A high match rate alone is not a proof of model identity or of an unchanged reward vector.

Threat model. The validator, published checkpoint, randomness derivation and grader are trusted. Participants may choose prompts, withhold outputs, repeat computation, vary execution settings, coordinate identities, and submit altered sequences. The measurements below show honest numerical variation and observed rejections; they do not bound an adaptive attacker’s probability of acceptance or reward manipulation.

Measured. Forced sampling is not batch-invariant — regenerating the same groups on the same machine with only the launch batch size changed left 0 of 32 rollouts byte-identical, and 4.78% of stochastic positions change their legal token — so honest participants match at ~0.95 and the floors sit at 0.80 per group and 0.70 per rollout; tightening them rejects honest participants before dishonest ones. Any protocol that treats “same seed → same reward” as an invariant is building on sand. The layer is load-bearing: over the run the validator rejected some 16,000 submissions under token-mismatch rejection rules, at a steady rate every day. These counts do not identify every rejection as malicious or measure the number of successful undetected manipulations. Token-level verification constrains submitted sequences but, because numerical tolerances are required across hardware and batching configurations, it does not constitute a complete proof of model identity.

Remaining validation. A targeted audit must test whether reward-bearing token edits, alternative execution configurations, or repeated generation can change rewards while satisfying every verifier check. It should report honest rejection rates and adversarial acceptance rates, including accepted changes to k, gate eligibility and payment, across sequence lengths and hardware configurations. This is a proposed test, not a result of the present run. Until it is completed, reward integrity remains an objective supported by partial checks rather than an established invariance guarantee.

4.3 The validator writes every reward

Decision. Math answers are regraded and code tests executed only by the validator, in a sandbox, overwriting any participant-supplied value. The reward a participant reports is never read.

Why. Recomputing rewards prevents a participant-supplied score from determining payment. It does not by itself prevent manipulation of the submitted text or exploitation of a grader; those risks depend on the checks and limitations in §4.2.

Measured. 844 math submissions rejected for a tampered boxed answer and 879 code submissions for a reward mismatch over the run. And a limit that is not about forgery: the extraction rule is part of the reward function. After a protocol revision asking for step-by-step reasoning, the grader extracted the last fenced block, so a rollout that reasons, implements, then appends an example was graded on the example; the 1.7% of rollouts with more than one block and no function in the last earned zero in 99.4% of cases and carried 75% of all negative advantage pressure on the “reasons first” behaviour, and the fraction of code rollouts containing prose decayed from 80.9% to 15.6% — the policy, not curation, by binomial test. Grading the correct span: 374 improved, 0 regressions over 2,560 rollouts, +10.8 points. In RL from verifiable rewards a bug in the extraction rule does not produce noise; it produces a trained behaviour.

4.4 Pay only for variance: the gate is DAPO’s criterion, made a parameter

Decision. σ is the population standard deviation of the 16 recomputed rewards; a group is admitted only if σ ≥ 0.24. For binary rewards σ = √(p(1−p)) with p = k/16, and σ(k = 1 or 15) ≈ 0.242, so the gate admits exactly k = 1…15 — DAPO’s 0 < |{correct}| < G — in a form that also works for the code environment’s fractional test-pass rewards.

Why. The gate uses validator-computed rewards, whose resistance to output manipulation depends on §4.2. It is also a configurable eligibility threshold: DAPO’s criterion is binary and fixed; here the trainer states what difficulty it wants and the market supplies it — a higher threshold buys groups closer to p = 0.5, an environment-specific threshold a different mix per environment.

Run configuration. The threshold was held at 0.24 throughout, so the demand curve is a capability of the design, not a result we demonstrate (§7.2).

4.5 A flat valuation and one uniform slot

Decision. At most 16 content-distinct groups win per environment per window; each winner earns one uniform slot; there is no runner-up share; unfilled slots burn. Every admitted group has the same value; ordering among them is a tie-break.

Why. this run pays for membership in the zone, not for variance at the margin. Every group with σ ≥ 0.24 is worth the same slot, and among members the order is a tie-break that turned out to be arrival. Pricing variance at the margin is the open design problem of §7.3. A participant’s expected margin per submitted prompt is E[margin] = P(in-zone | prompt) · P(win | in-zone) · v_slot − c_gen, where c_gen is the cost of one forced 16-rollout group and v_slot the slot’s emission value. Under a flat valuation P(win | in-zone) is set by the tie-break, which the participant does not control through the prompt’s content, so the term a participant controls is P(in-zone | prompt): a uniform draw earns at the policy’s natural rate, falling toward 0.41 (§3); a predictor of precision ρ increases the expected in-zone yield to ρ. At equal winning probabilities, this can improve margin if avoided generation costs exceed prediction costs; prompt-dependent generation time and the tie-break also affect realized returns. The margin of the uniform strategy falls with every update — the reactive-filter tax seen from the participant’s side. And a flat valuation has no interior optimum to farm.

Measured — why flat. The earlier auction ranked by std · (1 − mean), which for binary rewards peaks at exactly k = 2. Within weeks six operators were submitting k = 2 groups 80–100% of the time and one window paid all sixteen slots to k = 2 groups at the identical float value; a GPU replay against the forced stream found no token forgery — the suspects matched the canonical stream slightly worse than controls. The peak, not fraud, was the bug. Flattening the valuation dropped the k = 2 share from 95% to 15% on code and 52% to 27% on math within ten windows and roughly doubled mean winner reward. Sampling checks do not eliminate selection incentives: a participant can target a payout peak through prompt choice without forging tokens. Flattening removes this particular peak; it does not prove incentive compatibility or optimal selection.

Flat valuation was a saturation safeguard, not a claim that all in-zone groups have equal training value. Under heavy oversupply relative to the 16 available slots, participants supplied enough score-maximizing k = 2 groups for the previous quality score to become an effective hard filter on the trained batch. Once effective supply is controlled relative to training demand, quality-sensitive ranking can be reintroduced and evaluated without allowing a single farmable target to dominate the batch. Reducing participant count alone is not sufficient: a small number of high-throughput operators can create the same oversupply, and any replacement metric must be tested for concentration at its optimum.

Measured — what orders the members. With every admitted group at the same value, the ordering is entirely the tie-break, and the tie-break ranks by throughput: tokens produced per unit of time, the time being counted in drand rounds since the window opened, so that a public clock rather than network latency sets the denominator. Throughput is the deliberate choice between two failures. Ranking by tokens is what the previous tie-break did, and it selected rumination — late winners carried a median 3,448 tokens per rollout against 880 for early ones. Ranking in a way that ignores length favours short rollouts, which are cheaper to produce at equal probability of admission. Throughput is neutral between the two, and on this run it was: the rank correlation between selection and rollout length is +0.05 (math) and +0.04 (code) — essentially nil, which is what the criterion was for.

What it does not separate is generation speed from arrival. A participant whose infrastructure is fast both produces more tokens per round and submits earlier, so the two move together: selection by arrival tercile is 53 / 14 / 2% (math) and 64 / 10 / 0.2% (code), and the rank correlation between selection and arrival age is −0.50 / −0.59. The ranking is not arrival order — it prices output per round, and a slower, longer group can outrank a fast short one — but on this run the two are hard to tell apart, and the probability of winning falls from 27% at k = 1 to 20% at k = 15 (§5.2). Measuring throughput against generation time rather than window time would separate them; that is open (§7.3), as is the concentration it interacts with: a purely random ticket would hand the highest-volume operator 55% of slots, so any replacement key needs a per-operator cap.

4.6 Prompt reuse is controlled by cooldown

Decision. Prompt reuse is governed globally by a configurable cooldown, enforced by dataset index and canonical rendered-prompt hash. In this run the cooldown was set to one million updates—far beyond the 12,852-update run—so every prompt entering a winning batch was effectively single-use. This setting was practical because the available corpora were large; it is not a requirement of the mechanism. Windows carrying poison signatures are archived and credited but skipped by the optimizer.

Why. The cooldown prevents participants from repeatedly farming a prompt whose current reward distribution is already known, and prevents the trainer from resampling nearly identical experience before the policy has materially changed. With smaller or specialized corpora, prompts can become eligible again after a sufficient policy change. A fixed update count is only a proxy for that change; future versions could condition reuse on measured policy divergence or on a change in the prompt’s rollout distribution. This is a sample-reuse restriction, not a guarantee of zero behavior-policy lag (§4.1).

Measured. The market consumed 33% of the distinct math corpus in sixteen days (63% of the human-labelled math source), participants learned to avoid consumed prompts locally (near-cooldown skips fell 4.8 → 1.4 per window) and then collided on what remained: prompts submitted by two or more operators in the same window rose ×8 and identical-token rejections rose from 0.3 to 8.1 per window over the last three days (§5.1). The effectively permanent cooldown was an anti-exploit choice with a learning cost—each prompt was trained on exactly once during this run—that §7.2 leaves unmeasured.

The gate threshold, the value function, the cooldown and the collection interval are validator-side parameters; two changed during the protocol’s history above, making this a two-level optimization: participants search locally for in-zone prompts while the protocol adjusts what counts as in-zone. Together the decisions turn a population of self-interested participants into a search process over the frontier — the search that §2.3 says a static dataset cannot perform.


5. What the market delivered

5.1 What arrives at the door — the whole run

12,702 production windows (32,791 → 45,492). The run continued to 45,643 (last paid window 45,641); the whole-run series of §5.2–6.4 cover it, the per-window series below stop at the archive collection of 2026-09-09.

Math Code
reactive filter’s multiplier on the same policy 1.1× → 1.9× 1.1× → 2.4×
admitted per window (median) / selected 64–72 / 16 64–66 / 16
groups admitted / rejected out-of-zone 878,917 / 8,749 834,388 / 121,726
Figure 2
Figure 5 — What the policy offers and what the market delivers. Black step: the natural in-zone rate of the policy on a uniform draw (Figure 2a). Coloured line: the in-zone share of groups arriving at the validator, 50-window rolling mean (raw per-window series in grey). Shaded: the gap. The delivered series covers windows 32,791–45,492; the code annotation gives daily means. Aggregate submitted-group in-zone rates are 99.0% (math) and 87.3% (code), computed as admitted / (admitted + out-of-zone). These rates exclude locally discarded generations and do not measure miners’ predictive accuracy or generation efficiency. Data: 02-delivered-inzone.csv, 01-nondeg.csv.

The gap in Figure 5 describes the composition of submitted groups. Local generation followed by filtering can produce a high submitted in-zone rate without reducing generation costs. The run does not distinguish this strategy from prediction before generation (§5.3). Supply exceeded demand roughly fourfold throughout (admission budget 64 per environment per window until 2026-08-29, 96 afterwards, for 16 selected).

Prompt collisions increase under the run’s cooldown. Submitted code in-zone yield declines from 2026-08-29 (daily mean 0.946 → 0.809 on 09-09; −1.5 points per 1,000 windows after 08-29), while submitted math yield stays in 0.966–0.997. The market used 33% of the distinct math corpus in sixteen days (63% of the human-labelled math source, 35% of augmented_math), making those contents unavailable under the run’s effectively permanent cooldown. Near-cooldown skips fell from 4.8 to 1.4 per window. Prompts submitted by two or more operators in the same window rose ×8, and identical-token rejections rose from 0.3 to 8.1 per window over the last three days. These are per-window counts, not collision rates normalized by submission volume. They document increasing overlap in submissions, but do not establish corpus exhaustion: submission volume, concentration of miner strategies and the cooldown can all influence the pattern.

Figure 5
Figure 6 — Prompt collisions under the run’s cooldown. Left axis, per window (50-window mean), math: identical-token rejections (two participants submitting the same forced group), prompts submitted by two or more operators in the same window, and pool candidates skipped for a content already used. Right axis: share of the distinct math corpus not yet excluded by the run’s cooldown. Counts are not normalized by submission volume; the figure does not establish corpus exhaustion. Data: 13-depletion.csv.

5.2 What the delivered distribution shows, and who shaped it

Three comparisons, kept apart because they answer different questions.

Figure 3
Figure 7 — Distribution of k for the admitted pool (before ranking, light), the paid groups (dark) and the natural in-zone draw (black outline) at the base, update 1,439 and update 12,682. Math: pool k is an exact count. Code: the archived pool carries only a per-group mean, so its bars are 16 × mean test-pass fraction and the natural outline is computed the same way; exact-count code comparisons are inconclusive (§5.2). n = admitted pool / paid groups / natural in-zone prompts. Data: 14-pool-vs-natural-hist.csv, 03-k-distributions.csv.

Paid groups vs the natural draw — least informative. At every checkpoint the paid groups sit lower in k than the natural in-zone distribution and over-represent k ≤ 2 (math 14–21% vs 9–16%; code 15–18% vs 6–7%). This describes a distributional shift. Selective local filtering can also produce such a shift, and the paid set reflects participant choices, admission rules and validator ranking together.

Admitted pool vs the natural draw — differences before ranking. The admitted pool includes every group that passed admission before final ranking. It reflects participant choices together with cooldown eligibility, arrival-ordered admission and early close. For math, where rewards are binary and the pool’s k is a count, it is harder than a uniform draw at 70 of 81 evaluated checkpoints and easier at none (bootstrap 95% CI on the difference in mean k; 8.92 vs 9.97 at update 12,682, 9.28 vs 10.26 at update 12,842; 26–28% at k ≥ 14 against 37–38% natural). These are comparisons with the recorded uniform in-zone baseline. Isolating participant selection would additionally require matching the eligible prompt set and admission conditions; the observed differences alone do not isolate its contribution. For code the archived pool carries per-group means, not counts; the fractional comparison points the same way (43 of 79 checkpoints, never above) but the exact-count comparison on the 31% of code groups with binary rewards is inconclusive, and we do not claim it. “Participant choice” here covers both which prompts were attempted and which in-zone groups were kept after generating; the archive cannot separate the two (§5.3).

Ranking — observed selection differences within the pool. Among admitted candidates the throughput tie-break (§4.5) correlates strongly with arrival — selection is 53 / 14 / 2% by arrival tercile in math and 64 / 10 / 0.2% in code — and the probability of winning is not flat in k: it falls from 27% at k = 1 to 20% at k = 15 in math (lift 1.16 at k ≤ 2, 0.88 at k ≥ 14, each window’s selection rate held fixed). The marginal rank correlation between selection and length is small (ρ = +0.05); this does not establish independence from length after accounting for other variables. The tie-break ranks output per round, so throughput and arrival are coupled in the selection rule.

The consequence for the trainer holds regardless of which party did the shaping: the trained batch carries more training signal per group than a uniform in-zone draw, as measured by reward and advantage proxies — 3–4% higher group reward standard deviation, 3–10% higher mean absolute advantage on raw rewards, and 18–44% more groups in the central band 5 ≤ k ≤ 11. The measured ratios exceed 1 on 91–95% of checkpoints and rise over the run. Here “training signal” denotes these group-level proxies; it is not a measurement of the optimizer’s gradient norm after normalization and clipping. Whether more signal per group yields faster learning is unmeasured, and references may be wrong (§3.4).

5.3 What we can and cannot conclude — stated plainly

What we observe. The admitted pool differs from the recorded uniform in-zone baseline (§5.2). The archive does not distinguish prediction before generation from generating several groups and submitting those expected to win, or isolate these choices from eligibility and admission effects. Participants choose their own selection procedure; the run records no local-attempt telemetry that would separate these strategies.

Generation volume and cost. The mechanism lets participants choose prompts, bear generation costs and compete for payment on usable groups. The archive records 1.88 M graded groups, 30.2 M rollouts and approximately 18.5 B submitted tokens for 6.5 M rollouts trained on: about 4.6 times the trained rollout volume. Oversupply contributes to this volume, and locally discarded generations are unobserved. Submitted volume is therefore only a lower bound on generated volume, not a measurement of total compute or a cost comparison with a centralized pipeline. A generation-cost advantage remains to be measured.

An observable overlap with public history. Paid prompts are locked by cooldown, while admitted-but-unpaid groups are archived with their mean reward and their prompts remain eligible. Contents in this record over the preceding 200 / 800 / 3,200 windows account for 11 / 27 / 48% of admitted math contents and 10 / 24 / 39% of code contents, compared with 1.8 / 6.2 / 18% and 0.4 / 1.3 / 3.8% under the recorded uniform-choice baseline. This is consistent with miners consulting the record, but also with repeatedly selecting the same prompts for other reasons; it does not identify their strategy or remove eligibility and admission effects. Centralized trainers can also maintain reward histories. Here the public record additionally includes outcomes from groups that received no slot payment. Appendix G reports offline strategy estimates and their transfer assumptions. Testing the economic benefit requires predictions recorded before generation and measurement of prediction and generation costs (§7.2).

5.4 Market structure

Over the run 55 operators and 100 hotkeys were paid, a median of 19 operators per window; over the last 100 windows the top operator held 11.2% of slots and the top ten 72%. Submitted yield is associated with slot share: across operators with at least 20 submissions, in-zone rate correlates with slot share (Spearman ρ = 0.52 across 53 operators) and with tenure (ρ = 0.37). The median operator delivers 95% in-zone, the top decile 99.9%; three operators at ~44% survive on volume and hold 3–4% of slots each. This is §4.5 seen from outside: the participants who deliver more in-zone hold more of the market and stay longer.

These associations do not separate the effects of prompt selection, local filtering, infrastructure speed and submission volume. The distributional shift is already visible before final ranking (§5.2), but eligibility and admission rules also shape that pool. Likewise, the correlation between submitted in-zone rate and slot share does not control for throughput or arrival. Their respective contributions remain unmeasured (§7.3).

Figure 6
Figure 8 — In-zone rate at arrival against share of paid slots, one point per operator with ≥ 20 submissions; point size is tenure in windows. Data: 04-operators.csv.

6. The run: does the mechanism train a model?

6.1 Setup

Numbers are for the complete v5 run: windows 32,791 → 45,643 (2026-08-25 21:17 → 2026-09-09 23:41 UTC; last paid window 45,641). Checkpoints are named by update count (update 0 = base, 12,852 = end of run; published identifiers in Appendix A). Per-window market series end at window 45,492; whole-run series cover the run. The evaluation curve ends at update 12,842. Sections 6.2–6.4 report the evaluation of the released Reliquary-4B weights at update 12,842; historical analyses are labeled separately.

Continuous run from Qwen3-4B-Base: 12,852 windows = 12,852 updates over 15.2 days (~850/day, median cycle 102 s), 512 fresh rollouts per update (16 math + 16 code groups × 16), ~6.6 M rollouts trained on, never reused. DAPO loss with the constants of Appendix B; pure RL from the base — no SFT, no distillation, no chat template. Trainer: one H100 PCIe, under ~30 s per update. Validator: one H100, 226 hours of proof-process time over the 351 wall-clock hours archived (§4.1). Generation compute on our side: zero. Evaluation as in §3.2, including its contamination.

6.2 Results

The final column evaluates the released weights, ReliquaryForge/Reliquary-4B, at update 12,842. Earlier columns and the original learning curves retain their original evaluation source. The author identifies the evaluated release as 01d004d86aa683b1bdd47dabf31cd1a06b7634b9; no byte-identity with a historical Hub revision is asserted.

math basemath u8,800math u12,842code basecode u8,800code u12,842
pass@1, exact-content-disjoint (282 / 450 prompts)0.4830.7940.5750.776
Δ exact-content-disjoint (points; 95% CI)+31.1 (28.5, 33.8)+20.1 (18.6, 21.6)
pass@1, full suite0.4020.7380.7510.5620.7550.768
pass@16, full suite0.9020.9440.9420.8940.9000.910

The exact-content-disjoint subset excludes 218 math and 50 code prompts whose content hashes match trained prompts. It does not exclude near-duplicates. In particular, its 450 code prompts and +20.1-point gain are not interchangeable with the original exact-or-8-gram-Jaccard exclusion in §3.2 (435 code prompts, +19.6 points). The original run figures and filtering-cost series are unchanged.

Benchmark evaluation contract. Base and released model are evaluated with vLLM on identical raw prompts: eight samples per problem, T = 1.0, top_p = 1.0, top_k = 0, and an 8,192-token cap, plus a separate greedy pass. Math is graded with math-verify on the last \boxed{}. Code is graded with EvalPlus base and plus tests on the last fenced block defining the entry function. HumanEval+ has 164 tasks; MBPP+ uses v0.2.0 with 378 tasks, not the historical 399-task set. Exact package versions, the full base-model revision and weight-file hashes remain release-manifest requirements (Appendix A).

Scores are percentages. The Qwen3-4B (base) and Reliquary-4B columns give sampled pass@1, with greedy in parentheses. Δ is the mean per-problem paired difference in percentage points, followed by its t-statistic—not a confidence interval. Differences are computed before rounding and can differ by 0.1 from subtraction of displayed scores. Pass@8 is the fraction of problems solved by at least one of the eight samples.

benchmarkNQwen3-4B (base)
pass@1 (greedy)
Reliquary-4B
pass@1 (greedy)
Δ (paired t)pass@8
Qwen3-4B (base) → Reliquary-4B
GSM8K (near-domain)1,31955.9 (72.5)90.3 (91.9)+34.5 (53.9)95.0 → 97.1
MATH-500 (near-domain)50037.2 (52.8)72.6 (77.8)+35.4 (28.8)80.4 → 90.2
AMC234015.6 (25.0)47.5 (55.0)+31.9 (6.6)55.0 → 80.0
AIME 2024302.5 (3.3)10.8 (10.0)+8.3 (2.1)10.0 → 23.3
AIME 2025300.8 (0.0)9.2 (13.3)+8.3 (2.4)3.3 → 20.0
HumanEval+16452.1 (78.7)72.9 (76.8)+20.9 (11.4)88.4 → 93.9
MBPP+37843.7 (68.0)67.6 (70.6)+23.9 (19.6)79.4 → 82.8

GSM8K and MATH-500 are near-domain—the math corpus is synthesized from their train splits—so AMC23, AIME, HumanEval+ and MBPP+ carry the transfer claim. Each AIME set has only 30 problems; eight samples per problem do not turn it into 240 independent problems. Its gains and paired t-statistics should therefore be interpreted cautiously. These comparisons concern one decoding contract, not a matched centralized training control.

In the original learning-curve analysis, 94% of the math gain and 72% of the code gain were acquired in the first ~800 updates. The remainder is a long marginal climb—and on math it stopped (flat from ~update 4,600, +0.7 over the last 236 checkpoints) while code continued; §3.4 investigates a possible contributor.

6.3 What the gain is made of

On the full held-out suite, pass@16 moves much less than pass@1: math 0.902 → 0.942 and code 0.894 → 0.910, versus pass@1 0.402 → 0.751 and 0.562 → 0.768. This is consistent with increased reliability on problems the base could already occasionally solve, the pattern Yue et al. report for RLVR at small scale.[10] It does not imply that the set of solvable problems is unchanged. On the released weights, benchmark pass@8 rises from 80.4 to 90.2 on MATH-500, 55.0 to 80.0 on AMC23, 10.0 to 23.3 on AIME 2024, and 3.3 to 20.0 on AIME 2025.

Formatting versus answer accuracy. Under these graders, a response without the required answer channel scores zero, so pass@1 factors into channel rate times accuracy conditional on that channel. Channel rates rise from 90.0 to 99.7% on MATH-500, 84.3 to 100% on GSM8K, and 86.3 to 100% on MBPP+. An arithmetic decomposition attributes the following share of the pass@1 gain to changing the channel rate; the range reflects the two orders of changing channel rate and conditional accuracy. This is descriptive accounting, not a causal attribution.

benchmarkchannel-rate share of gain
GSM8K30–41%
MATH-50011–20%
AMC235–15%
AIME 20243–13%
AIME 20251–12%
HumanEval+15–19%
MBPP+29–39%

Gains also persist on the subset of problems where the base produced the required channel in all eight observed samples: +32.1 points on MATH-500 (222 problems, paired t = 18.0), +18.5 on HumanEval+ (106, t = 7.5), and +19.5 on MBPP+ (115, t = 8.7). Within these observations the base has no missing-channel failures to recover, so correcting those failures alone cannot explain the gains. The subset is defined by eight observed base samples, not by a guarantee of perfect formatting on future samples; it does not isolate a causal improvement in reasoning.

The original run analysis found no emergence of long chain-of-thought: accuracy fell with length at every checkpoint (MATH-500 at update 8,800: 95% below 300 tokens, 0% above 4k). This association is descriptive, not a causal effect of response length. The original coherence checks reported held-out NLL drift under 0.15% and MMLU / ARC / TruthfulQA / IFEval confidence intervals crossing zero; these checks are not new measurements of the released weights.

6.4 Greedy decoding captures less of the math gain and little of the code gain

The matched evaluation of the released weights in §6.2 shows a strong dependence on decoding. On MATH-500, greedy accuracy rises from 52.8 to 77.8% (+25.0 points), against +35.4 sampled; on GSM8K it rises from 72.5 to 91.9% (+19.4), against +34.5 sampled.

On code, greedy changes are small and mixed: HumanEval+ falls from 78.7 to 76.8% (−1.9 points), while MBPP+ rises from 68.0 to 70.6% (+2.6). Sampled pass@1 nevertheless rises by 20.9 and 23.9 points. Thus a greedy-only evaluation would miss most of the sampled improvement and would show a decline on HumanEval+. We do not call this a statistical null result: uncertainty estimates for the greedy differences are not reported. The pattern is consistent with probability mass shifting toward correct responses without a comparable improvement in the greedy output, but does not by itself identify the mechanism.

Evaluation of RL post-training should report its sampling contract and include greedy results where relevant to intended use. Improvement under one decoding contract does not imply improvement under another.


7. Limitations and open problems

7.1 Trust boundary

The system is auditable, not trustless. A single production trainer owns checkpoint publication and is authoritative for reward computation, selection, quarantine and optimizer execution; the verification stack evidences that selected rollouts match their announced checkpoint, not that the validator’s policy is correct. Labels and tests for both environments are public or reconstructable — validator authority prevents participants from writing rewards, but secrecy is not the moat; §3.4 motivates reference-quality auditing. The verification limitations in §4.2 apply even with an honest validator. Multi-trainer consensus is not implemented.

7.2 What this run could not measure

Predictive selection and generation cost. The intended efficiency gain is fewer unusable groups generated through miners’ ex-ante prediction of in-zone prompts. It does not require greater learning gains per trained group. This run neither controlled emissions nor observed all local attempts, so it cannot measure miners’ prediction accuracy, avoided generation, or cost per usable group. A future study will control the payment budget and measure predictions committed before generation, their realized outcomes, and generation and prediction costs, including discarded work. Controlled payments alone would not identify prediction accuracy; prospective prediction records are also needed.

The effect of selection on the learning curve. No matched centralized run (same base, corpus, contract and update count) was made, so whether the market’s harder-than-uniform, noise-concentrated, one-shot batch learns faster or slower than a uniform dynamic sample per unit of total compute is unmeasured. The statistics in §5.2 and §3.4 describe the batch but do not bound comparative learning efficiency. Supply elasticity. The market ran at four admitted groups per slot throughout, so a tighter gate would have absorbed slack rather than tested whether participants can follow a moving demand; the demand curve of §4.4 is a capability, not a result. The intervention on reference noise. §3.4 motivates a controlled test of audited reference corrections or exclusions. Model consensus alone is not ground truth. These are separate follow-up questions; the primary efficiency test will concern predictive selection and generation cost under controlled payments. Starting from a post-trained checkpoint is a proposed test of a lower-yield regime, not evidence of an established advantage. The transfer scores in §6.2 are reported separately from historical analyses and do not establish a matched comparison with other post-trained models.

7.3 What this run did not control

The price of the market. The run paid participants the full emission the subnet allocated to it, with no reserve price, no bid, and no cost control; a per-rollout figure would be a fact about the emission schedule during those sixteen days, not an estimate of an efficient market price, and we report none. This design tests whether the system operates, not whether miners predict efficiently under a controlled budget. The held-out suite. It was contaminated by content (§3.2); the next run excludes by content hash on the validator and checks the archive afterwards. The tie-break. Flat valuation (§4.5) leaves ordering to throughput, which does what it was meant to do on length (ρ = +0.05) but does not separate generation speed from arrival on a window clock (ρ = −0.50 / −0.59 with arrival age; r = +0.74 between arrival and rollout length among winners). Counting throughput against generation time, and capping any one operator’s share, are the two changes the next run needs; what the current key costs in the batch is small by the signal ratio of §5.2. The corpus. Code yield ended at 81% and falling, a third of the math corpus was consumed, and participants had begun colliding on what remained; harder or procedurally generated prompts and executable references for math are what comes next, and the procedurally generated environments are implemented and dormant.


8. Related work

§2 places this work against the two literatures it speaks to directly — DAPO’s reactive filtering (§2.2) and pre-rollout difficulty prediction (§2.3). What remains is the rest of the neighbourhood.

References

  1. Yu, Q. et al. (2025). “DAPO: An Open-Source LLM Reinforcement Learning System at Scale.” arXiv:2503.14476.
  2. Shao, Z. et al. (2024). “DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models.” arXiv:2402.03300.
  3. DeepSeek-AI et al. (2025). “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning.” arXiv:2501.12948.
  4. Zheng, H. et al. (2025). “Act Only When It Pays: Efficient Reinforcement Learning for LLM Reasoning via Selective Rollouts.” arXiv:2506.02177.
  5. Zhang, R. et al. (2025). “SPEED-RL: Faster Training of Reasoning Models via Online Curriculum Learning.” arXiv:2506.09016. Withdrawn by the authors in March 2026 because of experimental bugs.
  6. Qu, Y. et al. (2026). “Can Prompt Difficulty be Online Predicted for Accelerating RL Finetuning of Reasoning Models?” arXiv:2507.04632.
  7. Gao, Z. et al. (2026). “Prompt Curriculum Learning for Efficient LLM Post-Training.” arXiv:2510.01135; ICLR 2026.
  8. Xiong, W. et al. (2025). “Reinforce-Ada: An Adaptive Sampling Framework under Non-linear RL Objectives.” arXiv:2510.04996.
  9. Le, T.-L. V. et al. (2026). “No Prompt Left Behind: Exploiting Zero-Variance Prompts in LLM Reinforcement Learning via Entropy-Guided Advantage Shaping.” arXiv:2509.21880.
  10. Yue, Y. et al. (2025). “Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?” arXiv:2504.13837.
  11. Prime Intellect Team et al. (2025). “INTELLECT-2: A Reasoning Model Trained Through Globally Decentralized Reinforcement Learning.” arXiv:2505.07291.
  12. Ong, J. M. et al. (2025). “TOPLOC: A Locality Sensitive Hashing Scheme for Trustless Verifiable Inference.” ICML 2025. PMLR 267:47196–47211.

9. Conclusion

Group-relative RL learns only from prompts the policy sometimes solves, and training success removes them. Over a complete run we measured what that costs a reactive filter: a generation multiplier rising from 1.1× to 1.9× on math and 2.4× on code, accounted for by increasing 16/16-success groups, partly offset by declining 0/16 groups. We also observed increasing reference contestation in the selected math batch, which coincides with math learning stopping while code, graded by execution, continued (§3.4).

Reliquary moves the decision to a market whose participants have prompt choice and delivery decisions under a prescribed sampling stream. They are paid for selected, verified groups passing the variance gate, subject to the verification limits in §4.2. Across the archived windows, the batch had 3–4% higher group reward standard deviation and 3–10% higher mean absolute advantage on raw rewards than a uniform in-zone draw; on math the admitted pool was harder than uniform before any ranking. Overlap with public-record contents motivates testing history-based predictive selection (§5.3 and Appendix G). The observed prompt collisions and cooldown exclusions motivate studying how prompt reuse and submission concentration affect available supply.

With zero generation compute of its own, the trainer took a 4B base up 31.1 points on held-out math and 20.1 on code (48.3 → 79.4% and 57.5 → 77.6% on exact-content-disjoint subsets), with transfer to AMC, AIME, HumanEval+ and MBPP+. The matched evaluation of the released weights shows decoding-dependent gains (§§6.2–6.4). The run demonstrates end-to-end feasibility of market-supplied RL training. It does not establish a learning-efficiency advantage over centralized rollout selection. The system enables competition on predicting in-zone prompts; whether this reduces generation costs is the question for a future experiment with controlled emissions and prospective measurement of miners’ predictions and compute.


Appendix A — Reproducibility status and release requirements

Status at publication: partial. The public materials listed below allow a reader to inspect the model family, the current runtime, and the protocol. They do not currently permit an exact reproduction of the v5 experiment reported here. In particular, the run archive, the paired evaluation matrices, the corpus manifests, and the source commit that produced the run are not yet public. We therefore do not describe this report as fully reproducible until the release bundle specified below is published.

The following table maps the update counts used in this report to production windows and checkpoint identifiers. The evaluated model release is pinned to commit 01d004d86aa683b1bdd47dabf31cd1a06b7634b9 in ReliquaryForge/Reliquary-4B, as listed below.

name in text update first window published id
base 0 32,791 ck660
update 1,439 1,439 34,229 ck1100
update 4,641 4,641 37,431 ck1320
update 8,800 ~8,800 41,604 ck1574
update 12,682 12,682 45,472 ck1800
update 12,842 12,842 45,632 ck1810
end of run 12,852 ck1811 (published, never served)

Publicly inspectable artifacts

artifactpublic locatorrelation to this run
Base modelQwen/Qwen3-4B-BaseRevision 906bfd4b reported in the model card; the full commit hash and file hashes remain to be included in the release manifest.
Released modelReliquaryForge/Reliquary-4BAuthor-specified release commit: 01d004d86aa683b1bdd47dabf31cd1a06b7634b9, for the weights evaluated at update 12,842. Repository private at preparation time; public access and SHA-256 weight-file hashes remain release requirements.
Runtime sourcegithub.com/reliquadotai/reliquaryCurrent source only; it is not a substitute for the run’s pinned commit and dependency lockfile.
Operational protocol documentationReliquary validator documentationLive documentation; it may differ from the v5 contract and must not be used to infer v5 settings.
Window archive and receiptsNot yet publicBlocks exact reconstruction of the market series and participant-pool analyses.
Paired evaluation matricesNot yet publicBlocks independent recomputation of every reported confidence interval and distributional comparison.
Corpus/content manifests and contamination matchesNot yet publicBlocks audit of one-shot exclusion and the contamination analysis.

Release bundle required for exact reproduction

  1. A signed, immutable manifest naming the source commit, dependency lockfile, container digest, base-model revision, every checkpoint’s full Hub commit hash, and SHA-256 hashes of all files.
  2. The complete per-window archive (accepted, rejected, admitted, and selected groups), with rewards, timestamps, checkpoint identifier, and a schema version; secrets and operator identifiers may be redacted only if the aggregate claims remain recomputable.
  3. The two fixed 500 × 16 reward matrices for every evaluated checkpoint, the contamination-match table, and the exact evaluation harness. Include the released-model benchmark sample-level outcomes for base and model (eight samples plus greedy), the per-problem paired matrices, both contamination exclusion masks, grader/package versions, and the scripts defining confidence intervals and t-statistics.
  4. Immutable corpus manifests for Math and Code, including rendered-prompt hashes, content hashes, source provenance, and the cooldown/one-shot state needed to replay selection.
  5. Scripts that regenerate every table and figure from those artifacts, plus a command that verifies all published SHA-256 hashes before analysis.
  6. A versioned license and a permanent archive (for example, a Zenodo DOI) for the manifest, data schemas, and analysis code.

Appendix B — Production constants and training hyperparameters

Run configuration (reported, not independently executable until the pinned source commit is released). Loss: GRPO group-relative advantage, token-level, per-environment normalized; Clip-Higher 0.2 / 0.28; dual clip 10; KL β = 0; soft overlong punishment (factor 0.5 over the last 4,096 tokens); AdamW fp32; LR 1e-6, 10-window warmup then flat; π_old = validator’s own logprobs. Sampling contract: raw prompt with the signed step-by-step template, T = 1.0, top_p = 1.0, top_k = 0, cap 8,192 tokens, 16 rollouts per group. Gate σ ≥ 0.24; admission budget 64 then 96 per environment; content cooldown 1,000,000 updates (therefore effectively permanent within this run). The release manifest in Appendix A must additionally pin the prompt template, reward/grader versions, optimizer implementation, randomness derivation, dataset revisions, and all hardware-sensitive generation settings.

Appendix C — Throughput: how the window cycle was paid for

date windows/day median cycle
2026-08-04 106 815 s
2026-08-18 152 568 s
2026-08-22 434 199 s
2026-08-25 771 112 s
2026-08-27 1,136 76 s

Levers, with measured rather than predicted effects: deriving the old policy’s log-probabilities from the verification pass (~3–4%, against 12–15% predicted — the cost model was wrong); memoizing an attention unpadding computation containing a hidden host-device synchronization (−21%); detaching the trainer behind an object-store journal (−57%); isolating the proof plane in its own process (−44% per proof).

The root cause worth reporting. Profiling showed the verification forward at 161 ms in production against 28.7 ms alone on the same stack — a healthy 122–199 effective TFLOPS. The discrepancy was a GIL convoy: the proof thread releases the interpreter lock on every CUDA operation, hundreds of times per forward, and each time re-queues behind a CPU-bound thread holding it for 5 ms. One CPU-bound Python thread slows an otherwise idle proof thread by ×1031. The fix was isolation, not parallelism: two proof threads are worse (×0.87) and two processes without MPS gain nothing (×1.04).

Two failed predictions, reported as such. Isolating the proof plane was announced at +40% throughput and delivered ~0 extra updates: at 100 s of collection and ~64 s of proof, collection binds. An adaptive collection close was announced at +25% and measured over 26 hours at 81 → 102 s per cycle, i.e. 17–20% fewer updates per day; it was reverted. A lever chain reported only through its successes is not a measurement.

Appendix D — Comparison with decentralized generation (Prime Intellect)

INTELLECT-2[11] trains a 32B reasoning model with GRPO-style RL whose rollouts are generated by a permissionless, heterogeneous swarm: workers pull the current policy through SHARDCAST, generate rollouts with vLLM, and submit them with a TOPLOC proof; PRIME-RL keeps inference, verification and training asynchronous. TOPLOC commits to the hidden states of a generation with a locality-sensitive hash that a validator can check by prefill, reported at up to two orders of magnitude cheaper than regenerating, robust to GPU non-determinism and tensor-parallel layout, and able to detect a wrong or quantized model; the validator also applies sanity checks on sequence length and end-of-sequence probability. The verification overhead is reported at about 1% of worker throughput.[11][12]

Two things distinguish that setting from ours, and neither is a criticism of it. First, what the proof establishes. TOPLOC attests that the forward pass over a submitted sequence was computed correctly by the announced model, and it does so well: a sequence edited after generation no longer matches its commitment. What it does not attest is that the sequence was sampled from the model — Prime Intellect say as much of the original scheme, which verifies the computation up to the last hidden state but does not detect changes in sampling behaviour such as speculative decoding or arbitrary token sequences fed through the forward pass. A participant who alters one reward-bearing token and re-runs the forward pass on the altered sequence therefore holds a valid proof of a sequence the model would rarely have produced; so does a participant who generates a prompt’s group twenty times and submits the one it prefers. INTELLECT-2 covers part of this with sampling checks — terminations must reach the cap or emit EOS with probability above 0.1, and the logit distribution is inspected. Payment for assigned work creates different incentives from payment conditional on rewards, but does not establish that sampling deviations are harmless. Reward-dependent payment motivates the sampling checks in §4.2 and recomputation in §4.3, subject to the stated limits. The properties are complementary rather than alternative: model attestation and sample-fixing address different parts of the verification problem, while TOPLOC’s robustness to hardware non-determinism highlights a limitation of our forced stream (§4.2).

Second, who chooses the prompts. Selection stays with the orchestrator, which applies its own offline and online data filtering and samples the questions under a deterministic seed precisely so that workers cannot pick easy ones; the swarm supplies generation capacity, not decisions about what is worth generating. Our mechanism moves that decision, and only that decision, to the participants — which is what makes prompt choice an economic object and what the rest of this paper measures.

Appendix E — A further episode from protocol history: two identities starved an environment

A per-window admission budget of 64 receipts, first-come and never refunded on rejection, combined with a per-identity cap of 32, means two identities consume the budget. Two did, for 199 windows, at a 100% failure rate. Honest miners were left with exactly as many receipts as slots; redundancy was zero. Separation was perfect: 184 flooded windows averaged 15.8 candidates and 14.51/16 slots filled; 15 clean windows averaged 63.1 and 16.00/16. Cost: 4.3% of emission burned continuously, and honest participants refused silently, before any archived reason.

Appendix F — Supplementary figures

Figure S1-signal
Figure S1-signal — Reward and advantage statistics per group, paid groups relative to a uniform in-zone draw at the same checkpoint: group standard deviation σ = √(p(1−p)), mean absolute advantage on the raw rewards, and share of groups in the central band 5 ≤ k ≤ 11. Line at 1 = no difference. Data: 11-signal-per-group.csv.
Figure S2-strategies
Figure S2-strategies — Two participant strategies evaluated on the run’s own record (§6.3). Left: rollouts spent per in-zone group for early abandonment after m identical rewards on the forced prefix, exact from the held-out reward matrices, at the base, update 8,749 and update 12,842; thin horizontal lines are uniform sampling at the same checkpoint; the oracle floor is 16. Right: expected in-zone precision of prompts taken from the admitted-but-unpaid public record of the previous H windows, for two archived-k rules. Data: 15-strategies.csv.

Appendix G — Offline estimates for history-based selection

The public archive contains admitted-but-unpaid groups and their mean rewards. Their prompts remain eligible until selected or otherwise excluded. A candidate strategy selects prompts from the previous 200 windows whose archived k lies in [3, 13]. Transferring the measured persistence of in-zone status between checkpoints on held-out prompts to these archive candidates gives estimated end-of-run generation requirements of approximately 17 rollouts per in-zone group in math and 19 in code, compared with 30 and 39 for uniform sampling. Figure S2-strategies also reports an early-abandon probe on the forced prefix, estimated at 26 / 29 rollouts per in-zone group; at the base it costs more than uniform sampling.

These are offline estimates. The transfer assumes that persistence on held-out prompts represents persistence among archive candidates, despite differences in prompt composition and selection. Eligibility, cooldown, policy changes and submission competition can affect deployment. The quoted rollout counts do not establish total economic cost: lookup or prediction overhead, token lengths, hardware costs, discarded local attempts and the probability of receiving payment also matter. The archive does not show that miners implemented these strategies or achieved these costs. A prospective test should record predictions before generation and measure their outcomes and costs (§7.2).