# Retroactive proposer rewards ### Motivation The goal is to incentivize timely block releasing, i.e. beginning of slot. Currently the block proposer is rewarded in proportion to the profitability of the attestations they include in their block. Instead let's try to also account for the proposer's timeliness using some heuristic. ### High level idea One heuristic could be to scale the current proposer's reward by the **share of same-slot committee votes that the block receives and are included in the subsequent block.** Consider the following example:  Block `n+1` was released slightly late such that 10% of the committee in slot `n+1` are attesting before they received block `n+1` and thus vote for block `n`. However, the great majority of the committee (90%) hears block `n+1` before they attest and so they vote for it. The block proposer of slot `n+2` includes all attestations in their block `n+2`. The idea now is that the rewards of the block proposer of slot `n+1` are scaled with a factor of `0.9`. This punishes the proposer for being slightly late such that 10% of the committee didn't hear the block in time. Note that all committee members are incentivized to vote for block `n+1` (if they hear it in time) and therefore griefing the proposer of block `n+1` is costly and not incentive compatible. Further note that it is not incentive-compatible for the proposer of block `n+2` to grief the attesters of slot `n+1` by not including attestations, since they also get rewareded based on those attestations (which are the most profitable ones to include as well). ### Discussion This scheme incentivizes early enough block releasing such that all validators hear the block in time to vote for it. This idea does not manage to perfectly discriminate between a block that is perfectly on time (released at beginning of slot) and a block that is slightly late, say 1s. The reason is that a block which is only slightly late (e.g. 1s) will likely be heard by all attesters before the 4s attestation deadline and thus accumulate very similar levels of votes. However, it should definitely create incentives to release blocks rather earlier than later. This incentive scheme does not hold if MEV gains due to late-releasing (say 10s into block) dominate the timeliness rewards in itself. However, in combination with proposer boost it may be sufficient to make sure the equilibrium of when to attest stays around the 4s deadline (if no block has been seen yet). Releasing blocks late is in the interest of builder/proposer because they get more tx mempool listening time and can thus extract more MEV. The only thing potentially stopping builders/proposers from converging towards releasing very late in the slot (say 11s in) is that proposer boosting enables the next proposer to reorg late blocks out because they won't be able to accumulate enough LMD GHOST weight to withstand the boost.