This is the first in a series of post-Merge methodology introductions and upgrades that we plan at Rated, in order to more accurately express the realities of this new landscape.
Context
The concept of missed rewards attempts to capture the other half of “opportunity cost”, that penalties accrued does not. In the pre-Merge era of the Beacon Chain, missed rewards are a little more straightforward to calculate, as there is an objective, spec-based standard to measure against. In the post-Merge era, however, the introduction of priority fees and MEV to the mix, complicates things as semantics influence methodology and so on.
Proposed methodology
We believe missed rewards should be viewed in two separate tracks; Consensus and Execution layer missed rewards. The two tracks are really the heart of the methodology/calculation, such that :
total_missed_rewards == consesus_missed_rewards + execution_missed_rewards
While the high level aspect of the methodology is straightforward, the component pieces are less so. We have developed two separate sections in our methodology that discuss the approaches we are proposing in detail.
Consensus layer missed rewards
This section is more straightforward, as there is an objective standard (the Beacon Chain spec) by which we can build back up to rewards left on the table for less than perfect performance.
We think the crucial element here is correct interpretation of the spec.
Execution layer missed rewards
This section is a lot less straightforward, as there is a lot of subjectivity involved in setting the bar for what constitutes opportunity cost. For example, when a proposer misses a block should the value that they missed be judged by the value of the next block? Or should it be judged by the maximum bid seen in a MEV Relay for that specific slot? Or perhaps the average?
We have outlined what we think are 4 distinct approaches in the documentation.
Call to action
We’d like to invite the community to participate in helping guide and hardening the methodology before we freeze and deploy. The end result will power features in the front-end and most likely, modulate the outputs of downstream integrations––like Nexus Mutual’s slashing and downtme insurance policy.