Summary
This issue is the discussion and review venue for the Customized Halving (CH) schedule — "Scenario II" — specified in RIP-0002 (Active), as consolidated for the upcoming Core v1.1.0 release. CH is the baseline emission schedule already committed to the Rincoin mainnet chainparams from genesis. This thread exists so that node operators, miners, and the community can review the schedule, its rationale, and its verification status, and coordinate around the next consensus-critical transition ahead — the Phase 3→4 dilation at block 840,000.
References: RIP-0002 (Active), Aevust/rincoin-rips, GPG-attributed to key 8B6E 3BF4 5C71 4ECA. Economic model: Whitepaper v1.6.4 §3.4, §3.6 (DOI: 10.5281/zenodo.17141922).
BVA validation results & logs: doi.org/10.5281/zenodo.20745260.
The schedule (normative)
| Phase |
Block Range |
Reward (RIN) |
Subsidy (sat) |
Duration (blocks) |
| 0 |
[0, 210000) |
50.00 |
5,000,000,000 |
210,000 |
| 1 |
[210000, 420000) |
25.00 |
2,500,000,000 |
210,000 |
| 2 |
[420000, 630000) |
12.50 |
1,250,000,000 |
210,000 |
| 3 |
[630000, 840000) |
6.25 |
625,000,000 |
210,000 |
| 4 |
[840000, 2100000) |
4.00 |
400,000,000 |
1,260,000 |
| 5 |
[2100000, 4200000) |
2.00 |
200,000,000 |
2,100,000 |
| 6 |
[4200000, 6300000) |
1.00 |
100,000,000 |
2,100,000 |
| Terminal |
[6300000, ∞) |
0.60 |
60,000,000 |
perpetual |
Key invariants: 60 s target block time; COIN = 100,000,000 sat (1 RIN = 10⁸ sat); cumulative issuance over [0, 6300000) = 31,027,500 RIN; a 168,000,000 RIN macro-cap that is a combined-system property (maintained via PoR recycling, not by the schedule alone — see below); perpetual terminal reward 0.60 RIN/block. Phases 0–3 preserve Bitcoin-standard 210,000-block intervals; the dilation begins at Phase 4.
Why CH?
At 60-second blocks, Rincoin issues ten times faster than Bitcoin. Under an unmodified 210,000-block halving interval, block-subsidy issuance would fall below Bitcoin's initial generation rate at block 840,000 (~583 days post-genesis) — i.e., the security budget would contract roughly ten times faster than Bitcoin's, while the fee market is unlikely to mature on that accelerated timeline (Whitepaper §1.2). CH resolves this by dilating the halving interval from block 840,000 onward: Phases 4–6 span 1,260,000 / 2,100,000 / 2,100,000 blocks instead of 210,000, restoring multi-year economic cycles (Phase 4 ≈ 2.4 years; Phases 5–6 ≈ 4.0 years, matching Bitcoin's cadence) while remaining compatible with the 168M macro-cap design.
The perpetual terminal reward of 0.60 RIN/block is a deliberate parametric choice. It yields fixed annual issuance r_f = 525,600 × 0.6 = 315,360 RIN/yr, which at a continuous loss rate γ = −ln(D) ≈ 0.01511364 (D = 0.985, i.e., a 1.5% annual retention loss) corresponds to a steady-state circulating supply C^ss = r_f / γ ≈ 20.87M RIN — near-coincident with the ~21M "Nakamoto target" inherited from Bitcoin. (Scenario I's 0.5 RIN settles below 21M; a 1.0 RIN terminal would delay convergence to the cap.) This steady-state figure concerns only the terminal-subsidy contribution; the full long-run equilibrium also depends on RIP-0005 (PoR) / RIP-0006 / RIP-0007, and the 168M cap is maintained via PoR reincarnation of dormant coins (Whitepaper §3), not by unbounded issuance.
Deployment model and current status
- Chainparams from genesis, not signaling. Unlike a BIP9 soft fork, CH is not "activated" by miner signaling — the schedule has been fixed since genesis: a single chainparams field (
nSubsidyHalvingInterval = 210000) determines every phase boundary — Phases 0–3 via the standard halving formula, Phases 4–6 and the terminal phase via explicit thresholds at 4× / 10× / 20× / 30× the interval in GetBlockSubsidy (src/validation.cpp) — and each boundary takes effect at its height. There is no activation vote; the only requirement is that every consensus node runs software enforcing the correct schedule.
- RIP-0002 is Active. The schedule has been embedded in mainnet chainparams since genesis (first shipped in Core v1.0.6). The Phase 0→1 (block 210,000), Phase 1→2 (block 420,000), and Phase 2→3 (block 630,000) boundaries are now historical events on the Rincoin mainchain, validated in production by Core v1.0.6 nodes on the official SEED servers without consensus deviation.
- v1.1.0 consolidates the finalized implementation. Because the block-840,000 dilation is a protocol-major consensus change, the release carrying the finalized, sim-verified CH implementation is versioned v1.1.0 (per RIP-0001's protocol-major criterion) rather than a minor bump.
- The pending transition. The Phase 3→4 boundary at block 840,000 (6.25 → 4.00 RIN) is the most consequential transition still ahead. RIP-0002 becomes eligible for
Final status after that boundary is traversed without controversy.
Verification status
CH has been validated on rincoin-sim at 1/1000 scale (nSubsidyHalvingInterval = 210, Phase 4 activation at block 840). All boundary-value cases pass, including the four CH-specific boundaries:
| Boundary (sim / mainnet) |
Transition |
Result |
| 839–840 / 839,999–840,000 |
Phase 3 → 4 (CH dilation) |
PASS |
| 2,099–2,100 / 2,099,999–2,100,000 |
Phase 4 → 5 |
PASS |
| 4,199–4,200 / 4,199,999–4,200,000 |
Phase 5 → 6 |
PASS |
| 6,299–6,300 / 6,299,999–6,300,000 |
Terminal entry |
PASS |
Both sides of every boundary are tested to catch off-by-one errors (half-open [start, end) intervals). Conforming implementations MUST also satisfy the cumulative-supply identity:
sum(GetBlockSubsidy(h) for h in 0..6,299,999) == 31,027,500 × COIN
The schedule logic has additionally been cross-checked against the Core implementation (GetBlockSubsidy, src/validation.cpp): all 15 RIP-0002 test vectors reproduce under both the sim interval (210) and the mainnet interval (210000), and the identity above holds exactly.
What v1.1.0 requires of node operators and miners
Because CH is committed in chainparams and the 840,000 dilation is a hard fork, a node still enforcing the legacy Bitcoin-standard schedule would expect a 3.125 RIN subsidy at block 840,000 and would reject the 4.00 RIN block as an excessive coinbase — partitioning itself from the network. Therefore:
- All full nodes and miners MUST run CH-aware software (Core v1.0.6+ / v1.1.0) before block 840,000 is mined.
- There is nothing to signal or vote on for CH itself — the schedule is deterministic. The action required is to keep the node software current.
Discussion points
This venue is open for review, questions, and objections. Some areas worth discussing:
- Hash-rate behavior at the 840,000 dilation. RIP-0002 §Security notes hash rate "may still contract sharply" at this step. Two things are worth weighing honestly: (a) the cut is 6.25 → 4.00 RIN (36%), which is gentler than the 50% cut (6.25 → 3.125) the unmodified Bitcoin schedule would impose at the same height — so CH softens this transition; but (b) it occurs at ~1.6 years post-genesis, when the fee market is least mature. Unlike the later Phase 6 → Terminal transition, the 840,000 dilation has no conditional valve (RIP-0003 addresses only the 6,300,000 boundary). Is any monitoring or contingency warranted for 840,000, or is the softened cut sufficient?
- Node-operator / miner readiness and timeline. How do we best ensure an ecosystem-wide upgrade well ahead of block 840,000 — exchanges, pools, explorers, SEED operators? What lead time and communication plan should accompany the v1.1.0 rollout?
- Economic-parameter basis. The chain of reasoning behind the terminal 0.60 RIN /
γ = −ln(0.985) ≈ 0.01511364 / C^ss ≈ 20.87M (Whitepaper §3.4, §3.6) is the load-bearing assumption for long-run supply. Review and challenge of the γ assumption and the Scenario I vs II selection (0.5 vs 0.6 RIN terminal) are welcome here.
- Relationship to RIP-0003. RIP-0002 is the deterministic baseline; RIP-0003 (Draft) is the conditional valve for the far-future 6.3M transition. Whether the baseline alone is the right scope for v1.1.0 (with RIP-0003 deferred) can be discussed here.
Process
RIP-0002 is Active and the schedule is already live in chainparams; this thread is the community / node-operator / miner review-and-consensus venue for the v1.1.0 consolidation of that consensus change. The change is protocol-major under RIP-0001 and follows the standard governance process (reviewed PR; unanimous 2/2 Core approval, with the Founder holding final approval). This issue is a discussion venue — not a merge, a vote, or an approval.
How to weigh in
Reviews, questions, and objections are welcome from node operators, miners, and the community.
Full text: RIP-0002, Aevust/rincoin-rips. Economic basis: Whitepaper v1.6.4 §3.4, §3.6.
Summary
This issue is the discussion and review venue for the Customized Halving (CH) schedule — "Scenario II" — specified in RIP-0002 (Active), as consolidated for the upcoming Core v1.1.0 release. CH is the baseline emission schedule already committed to the Rincoin mainnet chainparams from genesis. This thread exists so that node operators, miners, and the community can review the schedule, its rationale, and its verification status, and coordinate around the next consensus-critical transition ahead — the Phase 3→4 dilation at block 840,000.
References: RIP-0002 (Active),
Aevust/rincoin-rips, GPG-attributed to key8B6E 3BF4 5C71 4ECA. Economic model: Whitepaper v1.6.4 §3.4, §3.6 (DOI: 10.5281/zenodo.17141922).BVA validation results & logs: doi.org/10.5281/zenodo.20745260.
The schedule (normative)
[0, 210000)[210000, 420000)[420000, 630000)[630000, 840000)[840000, 2100000)[2100000, 4200000)[4200000, 6300000)[6300000, ∞)Key invariants: 60 s target block time;
COIN = 100,000,000sat (1 RIN = 10⁸ sat); cumulative issuance over[0, 6300000)= 31,027,500 RIN; a 168,000,000 RIN macro-cap that is a combined-system property (maintained via PoR recycling, not by the schedule alone — see below); perpetual terminal reward 0.60 RIN/block. Phases 0–3 preserve Bitcoin-standard 210,000-block intervals; the dilation begins at Phase 4.Why CH?
At 60-second blocks, Rincoin issues ten times faster than Bitcoin. Under an unmodified 210,000-block halving interval, block-subsidy issuance would fall below Bitcoin's initial generation rate at block 840,000 (~583 days post-genesis) — i.e., the security budget would contract roughly ten times faster than Bitcoin's, while the fee market is unlikely to mature on that accelerated timeline (Whitepaper §1.2). CH resolves this by dilating the halving interval from block 840,000 onward: Phases 4–6 span 1,260,000 / 2,100,000 / 2,100,000 blocks instead of 210,000, restoring multi-year economic cycles (Phase 4 ≈ 2.4 years; Phases 5–6 ≈ 4.0 years, matching Bitcoin's cadence) while remaining compatible with the 168M macro-cap design.
The perpetual terminal reward of 0.60 RIN/block is a deliberate parametric choice. It yields fixed annual issuance
r_f = 525,600 × 0.6 = 315,360 RIN/yr, which at a continuous loss rateγ = −ln(D) ≈ 0.01511364(D = 0.985, i.e., a 1.5% annual retention loss) corresponds to a steady-state circulating supplyC^ss = r_f / γ ≈ 20.87M RIN— near-coincident with the ~21M "Nakamoto target" inherited from Bitcoin. (Scenario I's 0.5 RIN settles below 21M; a 1.0 RIN terminal would delay convergence to the cap.) This steady-state figure concerns only the terminal-subsidy contribution; the full long-run equilibrium also depends on RIP-0005 (PoR) / RIP-0006 / RIP-0007, and the 168M cap is maintained via PoR reincarnation of dormant coins (Whitepaper §3), not by unbounded issuance.Deployment model and current status
nSubsidyHalvingInterval = 210000) determines every phase boundary — Phases 0–3 via the standard halving formula, Phases 4–6 and the terminal phase via explicit thresholds at 4× / 10× / 20× / 30× the interval inGetBlockSubsidy(src/validation.cpp) — and each boundary takes effect at its height. There is no activation vote; the only requirement is that every consensus node runs software enforcing the correct schedule.Finalstatus after that boundary is traversed without controversy.Verification status
CH has been validated on
rincoin-simat 1/1000 scale (nSubsidyHalvingInterval = 210, Phase 4 activation at block 840). All boundary-value cases pass, including the four CH-specific boundaries:Both sides of every boundary are tested to catch off-by-one errors (half-open
[start, end)intervals). Conforming implementations MUST also satisfy the cumulative-supply identity:The schedule logic has additionally been cross-checked against the Core implementation (
GetBlockSubsidy,src/validation.cpp): all 15 RIP-0002 test vectors reproduce under both the sim interval (210) and the mainnet interval (210000), and the identity above holds exactly.What v1.1.0 requires of node operators and miners
Because CH is committed in chainparams and the 840,000 dilation is a hard fork, a node still enforcing the legacy Bitcoin-standard schedule would expect a 3.125 RIN subsidy at block 840,000 and would reject the 4.00 RIN block as an excessive coinbase — partitioning itself from the network. Therefore:
Discussion points
This venue is open for review, questions, and objections. Some areas worth discussing:
γ = −ln(0.985) ≈ 0.01511364/C^ss ≈ 20.87M(Whitepaper §3.4, §3.6) is the load-bearing assumption for long-run supply. Review and challenge of theγassumption and the Scenario I vs II selection (0.5 vs 0.6 RIN terminal) are welcome here.Process
RIP-0002 is Active and the schedule is already live in chainparams; this thread is the community / node-operator / miner review-and-consensus venue for the v1.1.0 consolidation of that consensus change. The change is protocol-major under RIP-0001 and follows the standard governance process (reviewed PR; unanimous 2/2 Core approval, with the Founder holding final approval). This issue is a discussion venue — not a merge, a vote, or an approval.
How to weigh in
Reviews, questions, and objections are welcome from node operators, miners, and the community.
Full text: RIP-0002,
Aevust/rincoin-rips. Economic basis: Whitepaper v1.6.4 §3.4, §3.6.