An objective case against the smoothing pool for node operators

Here I’d like to make a case for why I think the smoothing pool idea is a negative for all market participants, likely not economically viable anyway, and objectively not the best use of dev time.

First, I want to acknowledge the positive. Smoothing rewards greatly reduces the variance for any single NO. This leads to predictable rewards, which is particularly great for small operators. These are generally the NOs we should be building for.

Now, a few reasons against:

1. Node operators are less accountable for their performance.

Post-merge, it’s likely that the bulk of rewards will be coming from proposals and MEV, not from attestations. As a result, there will be much less incentive to maintain high uptime since NOs in the smoothing pool will have most of their rewards socialized. This could negatively affect rETH yield.

Severity: Low-medium, node operators are still fairly well incentivized to keep high uptime.

2. Smoothing will greatly increase the profitability of potential tip/MEV thefts.

Because smoothing pool NOs are only entitled to a tiny percentage of any rewards (vs. non-smoothing pool NOs who are entitled to half), the cost to forfeit their collateral and steal tips/MEV is effectively cut in half.

This is perhaps best illustrated with an example. Imagine a NO with 1 minipool and a 10% RPL collateral who proposes a block with a 3 ETH block reward. The cost to steal this block is 1.6 ETH (their RPL collateral), whereas the profit to do so is 1.5 ETH (the other half the block reward), thus not economically viable. If that same NO has opted into the smoothing pool, the cost is still 1.6 ETH, but the reward is approximately 3 ETH since they wouldn’t otherwise be entitled to much of the reward. Ergo, the cost to steal this block has been reduced by half, and the profit went from -0.1 ETH to +1.5 ETH by enabling the smoothing pool.

Severity: High, this reduces the cost of a known economic attack by half.

3. Smart contract risk, gas costs, technical overhead.

Smoothing would add technical complexity, smart contract risk and additional gas spent. This is probably fairly small, but still a consideration.

Severity: Low, likely not a meaningful negative.

4. Economical viability re: MEV

Smoothing would not offer a competitive APR compared to non-smoothing. The reason for this is that MEV would be an option for NOs to enable or not, meaning that those who don’t enable MEV would act as a drag on the performance of the pool.

Again, an example. Let’s imagine that post-merge APR is 10%, MEV APR is an additional 5%, and 80% of NOs enable MEV. Then your options as a NO are as follows:

  • Non-smoothing, no MEV enabled: 10% APR.
  • Smoothing pool: 14% APR (10% base APR + 80% * 5% MEV APR).
  • Non-smoothing, MEV enabled: 15% APR.

How many rational NOs would accept a lower APR just to smooth their rewards? Also, there are many reasons not to enable MEV, including legal, moral, technical.

Severity: High, economic activity would limit the efficacy of smoothing, heavily limiting adoption.

5. Opportunity cost re: dev time

Even absent these concerns, smoothing adds little value to the protocol in my opinion. Dev time could arguably be used in more productive ways.


Smoothing is a great idea and beautifully caters to what Rocket Pool can offer, but I’m afraid it would be ineffective and unused, and ultimately a net-negative for the protocol in general.

5 Likes