Introducing SLICE: A Payout Mechanism for the 21st Century Grid

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.

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 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