Bitcoin Magazine
SLICE: Making PPLNS Work for Demand Response
Bitcoin mining has come a long way since the days of GPUs and basement set ups. In that time, miners have advanced in countless ways. For example, ASICs are now the standard, not GPUs. Furthermore, enterprise grade players have entered the field, opening new frontiers and bringing with them the size and institutional recognition that opens the doors to otherwise unreachable places for smaller miners. Nowadays, the mining landscape is one where grid services, curtailment strategies, and energy market participation are no longer edge cases but core strategies. As the world around it has moved forward, there’s one question we keep hearing from miners: can PPLNS adapt?
Many miners, particularly those working closely with energy providers or integrating Demand Response mechanisms, have come to view PPLNS with suspicion. They worry that it penalizes downtime and rewards only uninterrupted hashrate—a bad deal for those who routinely curtail machines to support the grid or provide other services.
This fear isn’t baseless. It traces back to a pivotal moment in the mining industry’s recent past, one that apparently sealed the deal for many on PPLNS style payouts: the fallout between RIOT and Braiins Pool.
At the time, Braiins was using the Score payout system. Designed in 2011 by Slush himself, Score was engineered to solve the problem of pool hopping—when miners would jump between pools to exploit reward systems. There’s also been a misconception that Score is a PPLNS style payment system, but as Rosenfeld’s bible on pool payout systems describes, Score and PPLNS are distinctly different payout methods. The main difference is how they account for shares, specifically, Score implemented a rolling window with exponential decay function, this effectively made the lookback window very short. On the other hand, PPLNS is a family of payout systems with various types of fixed length lookback windows.
As shown on this archived website of how Score worked, you can see that after 90 minutes your hashrate had no more presence on the pool. This means that the moment a miner starts mining, their share of rewards fairly quickly reaches the fair value of the hashrate. On the other hand, when a miner stops mining, it drops equally fast, as shown on the gif below.
This might have worked well in the era of cowboys and hackers, but it was never designed with today’s complex mining environments in mind. Certainly not with Demand Response, where miners intentionally and profitably take machines offline to stabilize energy grids or bid into ancillary markets. To Score, that kind of behavior looks no different than a pool hopper—someone attempting to cheat the system.
So when RIOT left Braiins, citing concerns about payout mechanics, it sent a shockwave through the mining world. Due to the aforementioned misconception, Score system’s flaws got unfairly projected onto a broader category of payouts, PPLNS got caught in the fray, catching a stray bullet in the process, and the industry collectively threw the baby out with the bathwater.
But the mining world has changed, and it’s time for the phoenix to rise from his ashes.
SLICE: A Payout Mechanism for the 21st Century Grid
Enter SLICE, a modern, open-source Stratum-V2-ready payout system created by the DMND team. It’s an improvement and evolution of PPLNS, that rethinks how miners get paid, rewards are calculated, and —most importantly— how downtime is treated respect
to Score. All while preserving miner’s right to build their own block templates with SV2.
At its core, SLICE is about fairness and transparency. It preserves the foundational idea of PPLNS—paying miners in proportion to their actual contribution to solving blocks—while modernizing it for today’s decentralized mining landscape.
The key innovation lies in how SLICE structures reward calculation, and on how the lookback window works. Rather than treating the entire pool as a monolith, SLICE breaks time into smaller, dynamic “slices” of work to properly distribute the fee component. These slices represent batches of shares submitted over a specific period, where we control for the amount of fees in the mempool, and compare and score different job templates for the financial value they represent. When a block is found, SLICE distributes the block subsidy and transaction fees separately. The subsidy is allocated proportionally by hashrate, while the fees are distributed based on hashrate and financial value.
This is particularly relevant in a world where miners can choose their own transaction sets. Some miners may prioritize high-fee MEV-style bundles; others may exclude certain types of transactions for ideological, political or technical reasons. SLICE ensures that, within each slice, miners are rewarded according to both the quantity and quality of their work—without punishing them for downtime or strategic energy decisions. For those curious to learn more, this article can prove helpful.
Demand Response Without Penalty
What makes SLICE especially attractive for miners participating in Demand Response or curtailment programs is that it doesn’t penalize you for being offline.
That’s because SLICE doesn’t decay your payout just because you took a break. Your shares remain in the PPLNS window—the rolling window of recent work that is eligible for payouts—as long as they’re recent enough. In this way, each share is treated independently, and is expected to get 8 payouts, since SLICE uses an 8-block rolling window, each valid share remains eligible for payout across the next 8 blocks on average. This means that regardless of how big or small the pool is, you will never have the abysmal luck of eating up bad luck days without a block, disconnecting, having the pool find a block, and not get paid.
That means miners can power down during peak demand hours, support their regional grid, and still collect their fair cut from blocks found after they resume operations, most importantly, even while they’re offline, if their shares are still in the window. In other words, if the pool has a streak of bad luck, and then the miner is called to perform demand response and shuts off, even if the pool finds a block during their down time, that miner will get paid their fair share for all the time they were online. That’s because each share generated during that time will be active and getting paid for 8 blocks on average.
This is not a workaround. This is the feature. It makes SLICE fully compatible with modern energy strategies that require flexibility, whether you’re participating in frequency regulation markets, ramping down during grid emergencies, or simply optimizing for off-peak pricing.
For example, let’s say that a miner is mining at a pool, and the pool hasn’t found that day’s block yet. This means that the pool hasn’t found the block yet, and thus the miners hasn’t gotten paid for that day yet. Now, the miner shuts off to provide ancillary services during peak summer load for a few hours, during that time, the pool finds the block. In a Score based pool, the miner would not see a single Sat of that after 90 minutes, when the decay has had full effect. But even if the pool found a block 30 minutes later, due to the exponential decay, the miner would barely see anything. On the other hand, the miner would have all of the shares they mined over the day receive a payment, since each share receives on average 8 payments. Thus, the miner would benefit in the good times, and not be penalized in the bad times.
Payment Transparency and Auditability
Furthermore, SLICE doesn’t just modernize payout fairness—it does so in a way that minimizes trust in the pool operator. Every slice is fully auditable. Each share is tracked, indexed, and publicly verifiable by any miner, so miners can independently verify their share of the block reward. There’s no black box, no “trust me bro.”
And if the pool operator attempts to cheat—say, by injecting fake shares to dilute payouts—miners can challenge the integrity of the slice. The Job Declaration extension to Stratum V2, which SLICE relies on, includes mechanisms for publishing share data, verifying Merkle roots, and ensuring that each share corresponds to real computational work.
For miners who care about decentralization, SLICE isn’t just a payment scheme—it’s an accountability tool.
From Defensive to Strategic
The shift from Score to SLICE represents more than a technical upgrade. It’s a mental shift. Mining pools no longer need to defend against bad actors by penalizing everyone. Instead, they can structure payouts in a way that reflects reality: that miners are sophisticated participants working not only in the Bitcoin blockchain, but also the energy ecosystem.
With SLICE, PPLNS stops being a liability and becomes a strategic advantage. It enables better revenue capture, more transparency and auditability, and smoother integration with grid services.
And in a world where uptime is optional, but fairness is non-negotiable, that’s exactly what enterprise-grade miners need, a strategic pool partner that pushes forward and innovates, bringing the future today and enabling miners to make more money with the same hardware.
This is a guest post by General Kenobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
This post SLICE: Making PPLNS Work for Demand Response first appeared on Bitcoin Magazine and is written by General Kenobi Nakamoto.