Auston Sterling Thank you to Max/KuDeTa and Ladislaus for review In this document we describe the Aestus Relay's approach to MEV-Boost timing games as a service (TGaaS). In short: Block proposal timing games are unavoidable; at this point the best approach is ensuring democratized access to high-quality timing management tools. Aestus will apply a safe delay to all getHeader requests coming from validators identified by user agent. See below. Aestus's default timing games implementation results in a median delay of 735 ms. Validators looking to be more conservative or more aggressive may customize parameters by appending ?headerDelay={ms}&headerCutoff={ms} to the Aestus listing in their mev-boost relay list. See below. We encourage staking pools and relays to be transparent about timing games.

MEV-Boost relays deliver blocks from block builders to proposing validators, each block having an ETH value which is delivered to the proposer. Some relays have proposed forming a "guild" of sorts, charging builders a small fee, formulated as a small % (e.g. 0.5% of the block value). While naively this could be accomplished by requiring each builder to create one additional transaction every block to pay the guild, blockchain transaction fees make this infeasible. Instead, the contract designed here is intended to handle upfront deposits from builders, with a requirement to provide at least X ETH before relays will accept their blocks. A separate, off-chain accounting service monitors the block-to-block changes in current value (deposited collateral minus accumulated fees). On a regular schedule (weekly), the guild reconciles the on-chain balances, moving the correct amount of accumulated fees from each builders' deposits to the guild's multisig. Notes Lots of interesting places to take this in terms of automation, governance, etc. This iteration is intended to be a minimum viable solution. Builder interaction should be largely permissionless. However, we're willing to accept that the owner (relay guild multisig) has a lot of power and has to be trusted to not e.g. steal excessive builder deposits. Preferably upgradable to be able to iterate further on design. Builder pubkeys are BLS12-381, 48 bytes, no simple way to verify them or their signatures on-chain, but it is in a builder's interest for them to be accurate. Builders should be able to withdraw funds, but being able to do so at any time could be open to attacks, e.g. withdraw all value right before reconciliation. Instead: a builder marks their account for withdrawal, and after the next reconciliation after fees are taken, any excess is safely withdrawn.