Context
Companion to the tier-multiplier issue. Fred publicly committed on 2026-05-27:
"...the hardest challenges should accrue a big jackpot, I'm not sure how to solve that."
A flat multiplier per tier (1×, 3×, 10×) is the easy part. Jackpot semantics are open: we want hardest-tier wins to pay disproportionately more than even an aggressive linear multiplier would allocate, so a tier-3 solve is a recognizable event in a miner's PnL — not just "tier-1 × 10."
This issue is for design + decision, not implementation. Once a pattern is picked, implementation slots on top of the per-tier multiplier issue.
Design space
A. Progressive multiplier (super-linear)
score_multiplier per row, but the operator picks super-linear values:
- T1: 0.05
- T2: 1.0
- T3: 50.0
Pros: zero new schema, slots into the multiplier issue. Cons: still flat per tier — every tier-3 win pays the same; no scarcity premium.
B. First-mover bonus per challenge_id
On top of the per-tier multiplier, the FIRST winner of any tier-3 challenge_id gets a one-time bonus (e.g., 100× the normal score weight) in the policy aggregation window. Subsequent wins at the same tier on different challenge_ids pay just the multiplier.
Pros: literally a jackpot per challenge — "first to solve THIS specific tier-3" is the event. Cons: needs a new column / flag tracking "first-mover bonus claimed" so the aggregator doesn't double-pay across windows. Operator must decide bonus magnitude.
C. Time-since-active decay
Reward scales with how long a challenge sat unsolved. A tier-3 that took 5 days to crack pays more than one solved in 5 minutes — captures genuine difficulty as the network sees it. Requires capturing activated_at per row (currently we have created_at_iso and updated_at_iso, neither precisely the "active since" timestamp).
Pros: market-revealed difficulty. Cons: needs schema add; encourages operator to stage hard tier-3s and not rotate them, which is fine but creates a perverse incentive to delay rotation.
D. Hybrid (most likely "right" answer)
Progressive multiplier (A) + first-mover bonus (B) + soft decay (C). Each piece adjustable independently. Most flexible, most surface area.
Decision needed
Pick one of A/B/C/D. Each has different implementation cost:
- A: trivial, ~5 LOC change on the multiplier issue, done as one PR
- B: medium, new
first_mover_bonus_claimed flag + aggregator change + tests
- C: medium, needs
activated_at timestamp added + careful migration of existing rows
- D: union of the above, biggest PR
References
Context
Companion to the tier-multiplier issue. Fred publicly committed on 2026-05-27:
A flat multiplier per tier (1×, 3×, 10×) is the easy part. Jackpot semantics are open: we want hardest-tier wins to pay disproportionately more than even an aggressive linear multiplier would allocate, so a tier-3 solve is a recognizable event in a miner's PnL — not just "tier-1 × 10."
This issue is for design + decision, not implementation. Once a pattern is picked, implementation slots on top of the per-tier multiplier issue.
Design space
A. Progressive multiplier (super-linear)
score_multiplierper row, but the operator picks super-linear values:Pros: zero new schema, slots into the multiplier issue. Cons: still flat per tier — every tier-3 win pays the same; no scarcity premium.
B. First-mover bonus per challenge_id
On top of the per-tier multiplier, the FIRST winner of any tier-3 challenge_id gets a one-time bonus (e.g., 100× the normal score weight) in the policy aggregation window. Subsequent wins at the same tier on different challenge_ids pay just the multiplier.
Pros: literally a jackpot per challenge — "first to solve THIS specific tier-3" is the event. Cons: needs a new column / flag tracking "first-mover bonus claimed" so the aggregator doesn't double-pay across windows. Operator must decide bonus magnitude.
C. Time-since-active decay
Reward scales with how long a challenge sat unsolved. A tier-3 that took 5 days to crack pays more than one solved in 5 minutes — captures genuine difficulty as the network sees it. Requires capturing
activated_atper row (currently we havecreated_at_isoandupdated_at_iso, neither precisely the "active since" timestamp).Pros: market-revealed difficulty. Cons: needs schema add; encourages operator to stage hard tier-3s and not rotate them, which is fine but creates a perverse incentive to delay rotation.
D. Hybrid (most likely "right" answer)
Progressive multiplier (A) + first-mover bonus (B) + soft decay (C). Each piece adjustable independently. Most flexible, most surface area.
Decision needed
Pick one of A/B/C/D. Each has different implementation cost:
first_mover_bonus_claimedflag + aggregator change + testsactivated_attimestamp added + careful migration of existing rowsReferences
project_cathedral_tier_jackpot_commitment.md