Every block reward is split fairly by accepted work.

The cyan curve is Kernel-PPLNS. The dashed amber line is fixed-count PPLNS-N. Same hashrate, same time in pool — but the smooth kernel spreads the transition over the window length L instead of snapping. No cliff at join, no cliff at leave.

The cyan curve is the production kernel k_τ,L(x). Roughly 63% of the kernel mass sits inside the first τ of work — meaning the most recent block-time of work earns the bulk of the reward. At L = 4τ the remaining weight is only about 1.8% of the peak, then the bounded-support kernel cuts to zero.

A single miner joins at day 0 and leaves at day 10. The target is 99.9% coverage (N ≈ 6.9 expected blocks), but the published max ramp is 3 days. A 1-block/day scope is therefore capped at L = 3.0, giving about 95% effective coverage and a 3-day full-tail ramp. Faster scopes keep the full target: 10 blocks/day ramps in 16.6 hours, and 100 blocks/day in 1.7 hours. This is the fair tradeoff: shorter ramp, higher variance, disclosed up front. The cap is a fixed public policy, not a round-timing signal.

Both lines converge to 1.00 — exactly the fair reward. Each seed batch is one independent 30-day Monte Carlo run. The whale stays essentially flat from day one; the tiny miner may finish a little above or below fair, which is normal variance over 28,800 pool blocks.

The tiny miner wobbles more during week one because they have only a handful of shares inside the kernel window at any moment, so each block's small reward allocation is bumpier. The whale has thousands of shares in-window so each block's reward allocation is essentially deterministic. Both effects average out over thousands of blocks — and crucially, both miners converge to the same expected reward per unit of work, regardless of scale or share difficulty.

All three lines target 1.00× fair in expectation — Kernel-PPLNS credits the same expected rate regardless of pool cadence. The miner earns a smooth fraction of every block via the kernel; what changes between pools is how many blocks the pool finds during the window. Over 30 days that's ~30 pool blocks on a 1-block/day chain (few events to average over — the line still moves visibly), ~300 on a 10-block/day chain (settles near fair over the month), and ~3,000 on a 100-block/day chain (effectively flat from hour two). The same wobble applies whether you're 1% or 25% of the pool — bumpiness is set by event count, not your hashrate. Slow chains mean fewer pool blocks per month; fast chains mean smoother realized rewards. Plan for the cadence you're mining.

Each curve shows the typical swing in your reward vs fair — about two out of three months will land inside that ± band, half over and half under. On a 100-block/day pool, a typical month is within ±2% of fair — reward flow is rock steady. On a 1-block/day chain it's ±18%, so some months you'll come in well over fair and some well under (it averages out, but month-to-month is bumpy).

Two practical takeaways: (1) the swing is the same whether you're 1% or 25% of the pool — every miner gets a smooth fraction of every block, so size doesn't change your variance; and (2) mining longer always smooths things out — three months on a 10-block/day pool feels as steady as one month on a 100-block/day pool.

Four miners with the same 5%-of-pool hashrate when present, but very different schedules: a steady miner (28 days), early-shift hopper (mornings only, 14 days), late-shift hopper (evenings only, 14 days), and a weekend-only hopper (8 days). Each line is the average of 40 independent simulations — a single seed shows ±10% noise from block luck (see Chart 06), so we average across many to isolate the hopping effect from variance.

Across 8 independent pre-rendered seed batches (try the Next seed batch button above), every schedule's mean lands within about 1% of fair — no systematic edge for any hopping pattern. The simulation runs from steady-state prehistory and backfills the aggregate background when a hopper is off, so the pool's expected hashrate stays constant. Fair is computed as the kernel-weighted expected payout given each miner's actual on/off schedule, so ramp-tail rewards are attributed to the right shift.

Per-trial spread differs by schedule — the weekend hopper shows ±4% per single batch vs ±2% for steady — exactly as Chart 06's variance formula predicts: fewer mining days equals fewer pool blocks to average over. That's not a hopping penalty; it's the same luck-variance every miner faces. Fixed schedules do not show a systematic payout edge here.

/// Allocation result for one block. Conservation MUST hold:
/// `Σ miner_atomic + Σ fee_atomic + dust_atomic == actual_reward_atomic`.
pub struct BlockAllocation {
    pub dust_atomic: u128,
    pub total_miner_atomic: u128,
    pub total_fee_atomic: u128,
}

// For every payout key K, before integer-atom flooring:
//
//   exact_gross_K = actual_reward_atomic * G_K / G_b
//   exact_fee_K   = actual_reward_atomic * F_K / (G_b * 10_000)
//
// The helper returns floor(exact) and the exact U256 remainder in one
// stack-only U512/U256 division. The remainder is the payout ranking key.
//
for (key, agg) in per_key {
    let (gross_atomic_u256, gross_remainder) =
        u256_mul_div_floor_rem(&reward_atomic_u256, &agg.g_k_q128, &g_b)?;
    let gross_atomic = u256_to_u128_saturating(&gross_atomic_u256);

    let (fee_atomic_u256, fee_remainder) =
        u256_mul_div_floor_rem(&reward_atomic_u256, &agg.f_k_q128, &denom_g_b_times_10000)?;
    let fee_atomic = u256_to_u128_saturating(&fee_atomic_u256);

    payouts.push(SettlementScratch {
        key,
        gross_atomic,
        fee_atomic,
        gross_remainder,
        fee_remainder,
        gross_incremented: false,
    });
}

// Floor residuals are whole atoms still owed by this block:
//
//   actual_reward_atomic == Σ floor(exact_gross_K) + gross_residual
//   0 <= gross_residual < payout_key_count
//
// With 10,000 payout keys there can be up to 9,999 residual atoms, but
// they are paid out here, not left as block dust.
let fee_residual = fee_target - total_fee_floor;
distribute_fee_remainder(&mut payouts, fee_residual);

let gross_residual = actual_reward_atomic - total_gross_floor;
distribute_gross_remainder(&mut payouts, gross_residual);

// After redistribution, each key's miner+fee equals its final gross.
for p in payouts {
    if p.fee_atomic > p.gross_atomic {
        return Err(AllocatorError::ConservationViolated {
            got: p.fee_atomic,
            expected: p.gross_atomic,
        });
    }
    let miner_atomic = p.gross_atomic - p.fee_atomic;
    total_miner = total_miner.saturating_add(miner_atomic);
    total_fee = total_fee.saturating_add(p.fee_atomic);
}

let distributed = total_miner.saturating_add(total_fee);
if distributed != actual_reward_atomic {
    return Err(AllocatorError::ConservationViolated {
        got: distributed,
        expected: actual_reward_atomic,
    });
}

// What this guarantees:
//
//   Σ miner_atomic + Σ fee_atomic == actual_reward_atomic
//   dust_atomic == 0
//
// The residual bound still scales with payout-key count, but residual
// atoms are deterministically assigned instead of being swept as dust.
let dust_atomic = 0;

One confirmed block, expanded as an atom-level ledger. The matured block reward is exactly 1,000,000,000 atoms: miner reward allocations (cyan, 990,000,000 atoms) plus the 1% pool fee (green, 10,000,000 atoms). Deterministic largest-remainder rounding pays the whole residual atoms to payout keys, so normal allocation dust is 0 atoms. The closure error is 0 atoms, bit-exact.

The important distinction is residual versus dust. With 10,000 distinct payout keys, the initial gross floors can leave as many as 9,999 whole atoms unresolved. This allocator does not leave those atoms in dust: it ranks the exact remainders and assigns each residual atom once, then requires the final distributed total to equal the daemon-credited reward exactly.