# Relay Funding Working Group: Initial ROUGH Brainstorming/Inventory of Concepts to Consider
Version: 0.1
Includes input from: Blocknative team + Auston Sterling's comments in TG Group

## Top-Level Metrics
* Ethereum Mainnet Block Volume
* 7,200 blocks per day
* 2,629,800 blocks per year
* ~85% relayed via MEV-Boost (per MEVboost.org 24 hour data)
* 6,120 Relayed block per day
* 2,235,330 Relayed blocks per year
* 100% of these blocks require Relays
* Impact of MEV-Boost Economy (per [Rated.Network](https://www.rated.network/?network=mainnet&view=pool&timeWindow=1d&page=1) all-time data)
* 3.2x increase in average block value delivered to the Proposer
* +0.0871 ETH additional value per Relayed block
* +36 transactions per Relayed block (30.25% more transactions/block)
* Active Relays (per relayscan.io)
* 10 total relays
* 8 unique relay operators (as one provider currently operates multiple relays)
* USD/ETH: $1,874
* +$163.225 added value per Relayed block
* +$998,946 added validator value per day
* +$364,865,092 added validator value per year
* SIMPLE MATH:
* The MEV-Boost ecosystem currently adds ~$1.0MM of validator economic value per day or ~$365MM of additional validator economic value per year
* Searchers have built-in economics that are independent (??) of this result
* Builders have built-in economics that are independent (??) of this result
* Relays are essential to this outcome but do not currently have any built-in economics

## Stakeholders
* Primary
* Relay Operators
* Builders
* Searchers
* Validators
* Staking Pools
* Self-Stakers
* Secondary
* L2's
* Protocols
* Users
* Researchers

## Inventory of Potential Funding Sources / Aligned Economic Approaches

* **Public Goods / Foundation Grants**
* *Description / Example*: Public good funding by EF for multiple consensus layer client teams to promote and maintain client diversity
* *Pros*
* *Cons*
* **In-line Incentives**
* *Description / Example*: Some form of flat fee for each each relayed block
* *Pros*
* *Cons*
* **In-protocol Incentives**
* *Description / Example*: Some variable fee based on Relayed block value
* *Pros*
* *Cons*
* **Transaction Fee Based**
* *Description / Example*: Either a component of the Gas Fee (base or priority fee) or a fee based on the number of transactions included in the Relayed block
* *Pros*
* *Cons*
* **SaaS**
* *Description / Example*: Builders pay a recurring subscription fee to the Relay for access. Or Validators pay a recurring subscription fee to the Relay to connect. [Note: this breaks the permissionlessness nature of the MEV-Boost network?]
* *Pros*
* *Cons*

* **Vertical Integration**
* *Description / Example*: Relay, builder, searcher all from the same entity
* *Pros*
* *Cons*
* **RelayDAO**
* *Description / Example*:
* *Pros*
* *Cons*

## Inventory of Potential Funding Sources
* **Protocol Guild**
* *Pros*
* *Cons*
* **Ethereum Foundation**
* *Pros*
* *Cons*
* **Large treasuries** (Coinbase, Optimism, Arbitrum, Polygon, etc)
* *Pros*
* *Cons*
* **Proposer**: the current proposer pays some form of fee to the Relay Network in aggregate and/or the 'winning' Relay individually
* *Pros*
* *Cons*
* **Staking Pools**: the staking pools in aggregate fund the Relay Network in aggregate
* *Pros*
* *Cons*
* **Validators**
* *Pros*
* *Cons*
* **Block Builders**
* *Pros*
* *Cons*
* **MEV Searchers**
* *Pros*
* *Cons*
* **Users / Wallets**
* *Pros*
* *Cons*
* **ETH Holders**
* *Pros*
* MEV-Boost blocks contain more transactions per block vs 'vanilla' blocks and therefore increase EIP-1559 Burn (that is, more transactions per block = more aggregate Base Fee ETH per block = more burn = benefits all ETH holders)
* *Cons*
* To date, the Base Fee has been sacrosanct...difficult to determine a 'fair' or defensible way to redistribute some portion of the Burn

## Inventory of Potential Policies / Requirements to Consider
* Economics by entity vs individual operating relay: might this incentivize operating multiple relays per entity? Is that desirable?
* SLA’s
* Geographic diversity: do we want US-based entities to operate Relays?
* Regulated vs. Non-Regulated
* Censoring vs. Non-Censoring
* Builder Permissioned (allow lists) vs. Permissionless
* Optimistic vs. Simulating
* Missed Slot Assurances / Refunds

## Top Level Questions / Concerns
* Weakest link?
* Single vs. multiple code-bases
* Collaboration vs. collusion
* Centralizing forces (of which there are many)
* Validators striking off-chain deals with Builders to avoid paying Relay fees
* Timing considerations for ePBS
* Jurisdiction concerns: some Relay operators are based in jurisdictions that ‘require’ specific policies…

## APPENDIX: WIP Rational
* MEV-Boost Relays provide a critical role to the orderly economic operation of the Etheruem concensus layer.
* Relays increasingly provide backstops / protection from various attack vectors, consensus instability (equivocation), etc.
* Relays are expensive to operate in terms of engineering staff, devops staff, and hosting services (network, storage, CPU, redundancy, load balancing, etc.)
* Relays are targets for hackers and malicious relay operators and need a security budget to defend themselves.
* Relays carry multiple forms of liability, including missed slots, regulatory enforcement, brand reputation, and more.
* Many large Staking pools impose strict rating criteria on Relays (uptime, response time, compliance policies and track record, missed slot refunds, etc.)
* While Relays are view as a 'temporary' trusted solution, the current timeline to enshrined PBS (ePBS) is indeterminate – but generally assumed to be measured in years.