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.


I think 1. and 4. are fair criticisms of a bad implementation of the smoothing pool, but not arguments against it in general. You 100% should be required to do MEV to join the pool (this might be necessary to reasonably control MEV stealing in general, independent of the smoothing pool), and likely some kind of offline penalty needs to be there as well.

1 Like

Agreed re: MEV being required. Although that would force a NO to trade off their reasons for not wanting to enable MEV against the higher APR they would receive.

Also IIRC the team wants MEV to be optional for everyone, and not force it for the same reasons (legal, moral, etc.).

I agree that value-adds for small operators is a worthy goal. However, there’s an element of luck/lottery (plus uptime and performance) that leans towards avoiding the smoothing pool. If you hit the lottery, you keep it.

Also, I agree that MEV has some alignment issues with Ethereum generally and RP specifically, and perhaps we don’t want to entrench it as a core part of the RP project. MEV resistance or mitigation could be a future initiative for the Ethereum protocol.

Maybe continue to focus on RPL tokenomics, ecosystem, and distribution (e.g. Garlic Bread reforms) rather than MEV and smoothing pools?

1 Like

Point 2, the MEV theft profitability, is the most valid argument of these against the smoothing pool, I think.

Your example isn’t entirely accurate though, as you assume only staked RPL is at risk. But in the currently proposed design, up to 75% of the NO’s 16 ETH can also be penalized for MEV theft. This shifts the window of attractiveness up considerably, to ‘hail mary’ blocks worth more than 13.6 ETH. These do still happen though, and the smoothing pool still cuts the cost in half once your reach that treshold.
But tbh, every NO ‘defection’ is one too many as once they do, they will just keep misbehaving/stealing from then on without protocol recourse. In the end we might need something like the proposed 0x03 (contract-enforceable validator exits) to safeguard against this, regardless of whether the smoothing pool is implemented or not.

In the mean time, we could:

  • gather data on historical ‘hail mary’ blocks to quantify the size of the problem and the impact of halving the cost of a MEV stealing attack
  • solicit feedback from NOs whether they’d use the smoothing pool in the first place (also ask for their # of minipools to test the hypothesis it’d be mostly small NOs using it.)
1 Like