This is a calendar reminder, not a design task. It is the minimal one-line mitigation for #202, deliberately kept separate from #203 (deriving the subsidy from chain height), which stays parked with the rest of the whitepaper work.
Deadline
Measured live on 2026-09-12: tip 2942208, target 3,071,200 → 128992 blocks ≈ 44.9 days.
Flux is a 30-second chain (measured at 30.05 s over 100,000 blocks, 2,842,031 → 2,942,031), not the 2-minute target some docs imply — about 2,874 blocks/day. Re-derive from the live tip rather than trusting a stale date here.
What happens if this is missed
At block 3,071,200 the block subsidy drops 14 → 12.6 FLUX. Nothing in the app reads the chain for this, so every earnings figure on the site — per-tier daily payment, APY, the whole projection — silently reads 11.1% high until the constant is edited. No error, no warning; the numbers just quietly become wrong.
#244's countdown makes the event visible to users, but it does not correct the figures.
What to change
Both copies, or the edit is worse than useless:
client/public/runtime/app-content.js — the production constant.client/src/setupTests.js — the test double.
client/src/audit/constantsParity.test.js fails if the two disagree, which is the safety net. But note the trap it protects against: apidata.test.js derives its expectations from those constants, so editing production alone would leave the suite green while certifying wrong arithmetic. The audit harness has the same blind spot — app and reference would agree perfectly, both reading the same stale value.
Verify after the change
cd client && CI=true npx react-scripts test --watchAll=false
python tools/audit/capture.py
cd client && CI=true npx react-scripts test --watchAll=false d1AppSide && cd ..
python tools/audit/reference/d1_earnings.py
python tools/audit/compare.py
compare.py should report the subsidy as 12.6 and still exit 0. The nine subsidy-dependent figures will all move; pay_frequency should not — it depends on node count, not subsidy. That asymmetry is the signal the change landed correctly and is exactly how the harness was mutation-tested.
Related
This is a calendar reminder, not a design task. It is the minimal one-line mitigation for #202, deliberately kept separate from #203 (deriving the subsidy from chain height), which stays parked with the rest of the whitepaper work.
Deadline
Measured live on 2026-09-12: tip 2942208, target 3,071,200 → 128992 blocks ≈ 44.9 days.
Flux is a 30-second chain (measured at 30.05 s over 100,000 blocks, 2,842,031 → 2,942,031), not the 2-minute target some docs imply — about 2,874 blocks/day. Re-derive from the live tip rather than trusting a stale date here.
What happens if this is missed
At block 3,071,200 the block subsidy drops 14 → 12.6 FLUX. Nothing in the app reads the chain for this, so every earnings figure on the site — per-tier daily payment, APY, the whole projection — silently reads 11.1% high until the constant is edited. No error, no warning; the numbers just quietly become wrong.
#244's countdown makes the event visible to users, but it does not correct the figures.
What to change
Both copies, or the edit is worse than useless:
client/public/runtime/app-content.js— the production constant.client/src/setupTests.js— the test double.client/src/audit/constantsParity.test.jsfails if the two disagree, which is the safety net. But note the trap it protects against:apidata.test.jsderives its expectations from those constants, so editing production alone would leave the suite green while certifying wrong arithmetic. The audit harness has the same blind spot — app and reference would agree perfectly, both reading the same stale value.Verify after the change
compare.pyshould report the subsidy as 12.6 and still exit 0. The nine subsidy-dependent figures will all move;pay_frequencyshould not — it depends on node count, not subsidy. That asymmetry is the signal the change landed correctly and is exactly how the harness was mutation-tested.Related