Dappnode Smooth Vanilla Block Analysis

Objective

• The goal of this study is to quantify the extent to which vanilla blocks are negatively impacting the pool and its rule-abiding participants.

• Comments

  • The goal is NOT to recreate the functionality of the Smooth Oracle, which is responsible for proper accounting of ALL interactions with the pool.
  • The focus is solely on successful proposals to the pool, not missed proposals or proposals with an incorrect fee recipient address.
  • There are a handful of edge cases where MEV blocks are paid out to the pool in a non-standard manner—those blocks are not accounted for in the results.
  • There are a number of vanilla blocks where the lost MEV is unavailable, causing the accounts for those blocks to have an inaccurately low (LostETH/VanillaETH) ratio.

Results

• Pool Summary Stats - all accounts sorted by average contribution to the pool
• Lost MEV Stats - all accounts that have cost the pool lost MEV, sorted highest to lowest by amount lost
• High Vanilla Accounts - all accounts above a 5% vanilla block threshold, sorted highest to lowest by percentage
• Pool Block History (4.4MB) - a visualization of the pool's entire block history

• Comments

  • Vanilla blocks have cost the pool more than 10 ETH(!) of lost MEV. Given the pool's 7% fee and high (>6%) vanilla block rate, honest participants within range of the pool's average, and especially those well above the pool's average, are likely incentivized to leave the pool.
  • L1 fees are lower than ever and maximizing MEV contributions is imperative, regardless of how little MEV there is relative to the vanilla block.
  • MEV smoothing pools only work when ALL participants carry their weight by submitting 100% MEV blocks—there is no gray area here. It's easy to hand-wave small amounts lost sporadically to vanilla blocks, but the results of this analysis prove that it quickly adds up to a significant amount.
  • The only reason a vanilla block should ever be submitted to a MEV smoothing pool is because of a rare technical issue with MEV-boost, or the ultra-rare case where a vanilla block is actually worth more than the MEV for that slot. Numerous accounts in the pool with high three-digit and even four-digit block contributions with <1% vanilla rates prove that minimizing vanilla blocks is achievable and a choice.
  • Intentional vanilla blocks—either by running without MEV-boost or by setting a non-zero min-bid—equate to theft from the pool and its honest participants. Vanilla blocks lower the pool's average reward and APR, while the accounts submitting them unfairly extract payouts from the pool in exchange for essentially nothing—i.e. those accounts are stealing from the pool.

Proposal

• The simplest, fairest, and most effective solution is to update the Terms of Use (ToU) to stipulate that ALL vanilla blocks submitted to the pool will be treated as donations:
  • A validator proposing a vanilla block will NOT receive credit (Pending → Claimable) for the proposal
  • A validator proposing a vanilla block will NOT have its Pending amount credited with any portion of the vanilla block
  • Put another way—a validator will not accrue any earnings from its own vanilla blocks, and it can only collect its earnings by proposing a bona fide MEV block

• Comments

  • This proposal protects the pool and its honest participants from losses caused by dishonest participants. It also eliminates the need to ban accounts, and supersedes more complex schemes that attempt to coerce participants to run MEV-boost, or subscribe to n-number of relays, or set min-bid to zero, etc.
  • The primary objection to this proposal is the pool's Oracle sometimes misidentifies MEV blocks as vanilla blocks. However, MEV block detection has improved significantly and this analysis uses, with a high success rate, a different method than the pool's Oracle. The two methods combined would make false-positives almost nonexistent. In the rare case of a false-positive, the Oracle can be updated to account for the new edge case and re-run, thus mitigating concerns over vanilla false-positives.
  • On November 2, 2024 pool participants approved a new ToU that bans participants who submit three consecutive vanilla blocks. Given the results of this study, it's clear the new ToU is an insufficient deterrent, as accounts can still get away with a 70% vanilla block rate — e.g. V-V-M-V-V-M-V-V-M-V.