SLICE is a mining pool payout system built for Stratum V2. It splits each block reward into two parts: the subsidy is paid by classic PPLNS on hashrate alone, while the fees are paid by PPLNS with Job Declaration scoring — so miners are compensated for the value of the block they built, not just the work. Slicing the lookback window into short time-boxed slices removes the unfairness of comparing shares submitted hours apart.
Glossary
- PPLNS — Pay Per Last N Shares
- A payout method where the pool pays miners based on their share of hashrate contributed inside a rolling lookback window of the last N shares.
- FPPS — Full Pay Per Share
- A payout method where the pool pays each share at a fixed rate (subsidy + expected fees), acting as an insurer that absorbs variance. Expensive to operate and centralizing.
- JD — Job Declaration
- A Stratum V2 feature that lets miners construct their own block templates using their own node, instead of accepting a template pushed by the pool.
- MMEV — Maximum Mempool Extractable Value
- The highest total fee value a block could possibly capture from the mempool at a given moment.
- SRI — Stratum Reference Implementation
- The FOSS reference implementation of Stratum V2.
Introduction
DMND Pool is the first pool to use Stratum V2, a protocol developed over the past five years by FOSS developers in the Bitcoin space, primarily the Stratum Reference Implementation (SRI) team. Stratum V2's goal is to decentralize Bitcoin — specifically mining and pooled mining — by fixing the wrong turn Stratum V1 took when it shifted block template creation from miners to pool operators.
But decentralizing pooled mining is a two-front problem. Full Pay Per Share (FPPS) has quietly centralized the network at the economic layer: today a handful of pools decide which transactions get mined. Even with universal Stratum V2 adoption, FPPS-style incentives would still push the industry toward centralization.
SLICE is a mining pool payment system designed to close the economic gap. It's engineered to work alongside Stratum V2's technical design, so both centralization vectors — technical and economic — are addressed together. Fair, transparent, low variance, and aligned with decentralization.
SLICE: adapting PPLNS to Stratum V2
For a pool trying to decentralize, PPLNS is one of the best options available. It's transparent, easy to verify, cheap to operate — it's an actual payout, not an insurance product like FPPS — and it distributes rewards proportionally to hashrate contributed.
But PPLNS wasn't built for Stratum V2. It assumes every miner is working on the same block template, so it has no way to reward a miner who chose to build a better block than their neighbour. That's the Achilles heel, and it gets worse as fees become a larger share of block revenue.
SLICE fixes this by splitting each block reward in two:
- Block subsidy — distributed by classic PPLNS, based purely on hashrate contributed inside the lookback window.
- Transaction fees — distributed by PPLNS plus Job Declaration scoring, so each share is weighted by both its hashrate and the fee value of the template it was mining against.
Because the fee portion uses Stratum V2's Job Declarator, SLICE is also called PPLNS+JD.
Creating fair slices
Splitting the reward isn't enough on its own. If we scored every share inside the lookback window against the same fee benchmark, we'd punish earlier shares for something they had no control over: fewer transactions in the mempool when they were submitted.
The mempool is not static. New transactions arrive constantly, often at higher fee rates than the ones already there. A share submitted at 10:00 has access to a mempool that literally could not have existed at 09:55. Scoring both against the same maximum-fee benchmark would penalise the 09:55 share for time travel it couldn't do. This is the same failure mode that sank older systems like SCORE.
The fix is to divide the lookback window into short slices of time. Inside each slice, every share is scored against the highest-value share in that slice — the assumption being that within a short enough window, everyone had roughly the same opportunity to build a valuable template. The benchmark (MMEV) keeps climbing as new high-fee transactions land, so the incentive to construct the best possible block is continuous.
Within any single slice, that scoring looks like this — the best share sets the benchmark at 1.0 and every other share is graded against it:
This is what makes SLICE fair not just across miners, but across time. It's the ingredient that lets Job Declaration work without punishing anyone for the clock.
The size of a slice
A slice ends and a new one begins when either of the following happens:
- A new block is found — the current slice closes.
- MMEV increases by a threshold X — the current slice closes and a new one waits until MMEV rises by another X.
The pool chooses X. Smaller X means more slices, which means finer-grained fairness. Slice length is dynamic and driven by real mempool activity, not a fixed clock.
Each slice contains all the shares submitted during that period. Every share has a difficulty attached, which tells the pool how much work it represents. The total difficulty across all shares is the "size" of the slice.
A note on measuring hashrate
How SLICE treats shares
DMND Pool targets 6 shares per minute per client and adjusts each miner's pool difficulty dynamically to hit that rate.
When a miner submits a share above their pool difficulty, it's added to the current slice — but every share is valued at the pool difficulty, not at the actual difficulty of the specific share it happened to be. This matters for fairness.
Consider a miner who gets lucky and finds a block. The current network difficulty is above 110T, and DMND's lookback window covers 8× the network difficulty of work. If we counted the lucky share at its true difficulty, that single share would occupy an eighth of the entire window and vacuum up an eighth of all rewards — including rewards owed to other miners who did the same amount of actual work.
That's a windfall for one miner and a rip-off for everyone else. Valuing all shares at pool difficulty — including the winning one — keeps the system balanced.
Payouts in SLICE
DMND's lookback window is 8× the current network difficulty of work. When a block is found, the pool walks back through recent slices until the accumulated difficulty reaches that threshold. If the boundary lands mid-slice, the whole slice is included — no share gets orphaned by rounding.
Inside the window, shares pay out under the two-track rule: subsidy by hashrate, fees by hashrate weighted by fee score within the share's slice.
A worked example
Payout math in one slice
Say a miner submits 100 shares at their assigned pool difficulty during one slice. The slice contains 1,000 shares total from all miners. The highest-fee share in the slice was built against a template worth 0.5 BTC in fees. Our miner's shares were built against templates worth 0.4 BTC on average.
Both allocations are then scaled by the slice's weight in the overall lookback window. That's the mechanic in a nutshell: subsidy rewards work, fees reward valuable work.
Life of a share
Because the lookback window is 8× network difficulty, an average share stays in the window for roughly eight payout rounds before ageing out. It's not that a share is paid eight separate times — it's that the sliding window keeps including that share until enough newer work has been submitted to push it out.
Ramp-up
When you start mining, your first payouts are smaller than the steady-state rate. It takes about eight rounds before your full contribution is reflected.
Ramp-down
When you stop mining, your payouts don't stop immediately. Your shares continue to earn until they age out of the window.
SLICE vs FPPS vs PPLNS
| FPPS | PPLNS | SLICE | |
|---|---|---|---|
| Payout basis | Insurance (fixed rate per share) | Rolling hashrate window | Rolling window + fee-weighted scoring |
| Miner variance | Very low | Moderate | Low–moderate |
| Cost to pool | High (pool absorbs variance) | Low | Low |
| Compatible with Job Declaration | No | Partially | Yes |
| Transparency | Opaque fee assumptions | Fully verifiable | Fully verifiable |
| Centralization pressure | High | Low | Low |
What this means if you're mining with DMND
Your first few payout rounds are a ramp-up — don't panic. When you disconnect, your payouts continue for another few rounds as your shares age out — don't panic then either. And building better templates using your own node via Job Declaration directly increases your fee-portion payout. That's the incentive SLICE is built to preserve.