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 capture from the mempool at a given moment. True MMEV cannot be measured directly in real time, so SLICE scores each slice against the highest-fee template actually observed in it — an empirical proxy for MMEV within that slice.
- SRI — Stratum Reference Implementation
- The FOSS reference implementation of Stratum V2.
Introduction
DMND Pool mined the first Stratum V2 block a miner built themselves, end to end — block 955,318, on 25 June 2026. Stratum V2 is a protocol developed over the past five years by FOSS developers in the Bitcoin space, primarily the Stratum Reference Implementation (SRI) team. Its 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 — technical and economic. Stratum V2 addresses the technical front by handing template creation back to miners. It does not touch the economic front. Full Pay Per Share (FPPS) has quietly centralized the network at the economic layer: because the pool must estimate fees and pay a fixed rate per share, it absorbs all the variance — which is expensive to run and pushes hashrate toward the few pools large enough to bankroll it. The result is that 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. That cost difference matters beyond the balance sheet: because SLICE never has to bankroll variance the way an FPPS pool does, DMND isn't pushed onto the grow-or-die treadmill that FPPS economics create. The pool's incentives stay aligned with paying miners fairly, not with getting large enough to absorb risk.
PPLNS assumes every miner is working on the same block template. If two miners submit equal work, they earn equal reward — because they had the same opportunity to collect transaction fees. Once miners build their own blocks, that assumption no longer holds: two miners contributing identical hashrate may be building different blocks with different fee values, and classic PPLNS has no mechanism to tell them apart. 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 block it was building.
Because the fee portion uses Stratum V2's Job Declarator, SLICE is also called PPLNS+JD.
Why building your own block requires template-aware payouts
Building your own block doesn't just give you control — it makes a new payout system necessary. The logic is short:
- Classical PPLNS assumes every miner is building the same block.
- When miners build their own blocks, that assumption breaks — different miners build blocks of different fee value.
- Therefore a payout system must distinguish between equally difficult work done on blocks of different value — or it systematically underpays the miners building the most valuable blocks.
None of those premises names a specific design. They only establish that template awareness is now required. SLICE is our answer to that requirement.
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 transactions that had not yet entered the mempool. In effect, it would ask miners to compete against a future they could not observe. 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 observed 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 (our observed proxy for 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.
X is set by the pool. 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
Pool difficulty exists solely to regulate how often miners submit proofs of work. It's a measurement tool, not a measure of value. 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. Say network difficulty is around 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.
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.
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. (Figures illustrative.)
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 — your work keeps paying
When you stop mining, your earnings don't stop with you. The shares you already contributed keep paying out as they age out of the window — you're compensated for hashrate you actually delivered, not cut off the instant you disconnect.
SLICE vs FPPS vs PPLNS
| FPPS | PPLNS | SLICE | |
|---|---|---|---|
| Rewards template quality | No | No | Yes |
| Independently verifiable | No (opaque fee assumptions) | Not typically (trust the pool's share count) | Yes — shares and scoring are published |
| Payout basis | Insurance (fixed rate per share) | Rolling hashrate window | Rolling window + fee-weighted scoring |
| Miner variance | Very low | Moderate | Comparable to PPLNS |
| Cost to pool | High (pool absorbs variance) | Low | Low |
| 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 — that's your earlier work still earning, not a delay. And when you build your own block — a better template, on your own node — your fee-portion payout goes up directly. That's the incentive SLICE is built to preserve.
Underneath all of it is one thing FPPS pools can't offer: building your own block gives you real control — on your own node, within Bitcoin's existing consensus rules. No protocol changes, no asking permission. Block construction goes back into miners' hands, and SLICE makes sure you're paid for the value you put into it.