# Relay Guild and Funding Proposal

## Preamble

Since *The Merge*, adoption of MEV-Boost has grown such that block auctions now deliver around 95% of Ethereum mainnet blocks. Annualised--hundreds of millions in USD of profit from MEV flows from searchers to builders and validators through this system. At the time of writing, less than 10 entities are operating relays at the centre of this architecture. Their role is to both conduct the auction and provide an escrow service--protecting builders' bids and ensuring validator payment.

Relays currently have no sustainable source of funding, despite this critical role in the operation and economics of the Ethereum network. Yet, they are expected to provide enterprise class services and assume financial liability for any faults. This position is not sustainable and several relays have already privately signalled their intent to wind down operations.

One core objective of the MEV-Boost architecture is to provide equitable access to MEV for the entire validator set. A collapse in the relay set increases the chance of builders and staking pools opting to work directly with one another--in turn creating disparity in staking returns for smaller and solostaking operations. This would be a dangerous economic centralising force.

Finally, because validators and builders must place their trust in relays to automate the auction, relays have themselves become powerful entities. This should be a concern - if exploited, a relay with a significant validator adoption could cause significant economic damage with much broader ecosystem consequences. It is therefore important that we develop healthy incentives and governance structures that can serve as a signal to the validator set on safety, standards, and best practice.

# A Relay Guild

The _relay guild_ was founded for the following purposes:

* To pursue sustainable relay funding mechanisms,
* To foster a diverse and independent relay ecosystem,
* To signal good relay practice and set standards,
* To ensure validators enjoy equal access to MEV profits.

_Relay guild members_ agree to upholding the following core set of behaviour:
* Relays publish clear policies for builders, treating all bids that meet these criteria equally and confidentially,
* Relays publish open endpoints and accept registrations from all validators,
* Relays are responsible for ensuring validators recieve payments for block proposals.

The _relay guild_ commits to the following principles:
* Collecting service fees using transparent policies published on this website,
* Distributing those services fees equitably, taking into account metrics on performance, ecosystem alignment and validator signalling,
* Devolving core financial, membership and other governance responsibilities to an _independent_ "relay inclusion comittee",
* Developing and upholding standards on relay availability, uptime, missed slots and compensation (etc).

## Relay Guild

### Initial Guild Membership Criteria

* Processed > 1% of winning bids in the proceeding 1 week (av.) via relayscan.io:

This qualifies the following relays:

* Aestus
* Agnostic
* Bloxroute
* Blocknative
* Eden
* Flashbots
* Ultra sound

### Independent Governance

* The relay guild will nominate an independent committee of credibly neutral individuals from ecosystem organisations (EF, EthStaker, client teams ... etc).
* Existing relays will each nominate one member. Any relay entity may veto a nomination so that in effect, the committee is unanimously agreed.
* Once formed, this independent committee will establish it's own internal process, but commits to fulfilling its role at least once per calendar month.
* The relay guild will compensate commitee members for this work at an agreed rate.

### Governance Structure

The relay guild membership will work in conjuction with the independent committee to fulfill the following functions:

1. Adding a relay to the guild
2. Removing a relay from the guild
3. Adjusting service fees and distribution weights
4. Distributing collected service fees and other income

Governance functions of the relay guild by members from either relay or the independent commitee can be balanced and may evolve over time. We highlight two options to provoke further discussion:

"Active" management by the independent committee: the commitee fulfills all governance functions, and the relay membership plays no role.

"Passive" management by the independent commitee: relays self-administer the guild, with oversight from the independent committee who have the ability to lock funds and remove members.

## Raising Funds

### In-Protocol Fees

The relay guild will seek to implement enforced per-block relay service fees over time. These should be targeted to compensate costs including infrastructure, operational, human and administrative expenses. A small profit margin which serves as additional buffer against ETH price fluctations will be incorporated.

To set the initial service-fee relays will submit cost estimates to the independent commitee who will determine the target price in % terms by averaging these across the relay set.

Relays will enforce this service fee by ensuring a transaction exists that credits the relayguild.eth account for every block that the relay validates. PRs to block validation logic will follow.

The relay governance structure commits to a monthly review of service fees to ensure fees denominated in ETH are targeted appropriately in USD. The relay guild will update this ETH denominated service fee on-chain, specifying the block number from which the new fee applies.

Additional technical work that may enhance this further includes:

* Allowing fees to accumulate against a builder's balance (similar to optimistic relay deposits) to avoid per-block transactions
* Adjusting service fees based on targets and ETH price fluctations automatically.

### Public Goods Funding

The relay guild commits to exploring avenues for collective fundraising via grants and public goods funding rounds from across the broader ethereum ecosystem. These may be used to incentivise commissioning new relays or specific enhancement to relay operations. Public goods funding may serve to bootstrap the guild or play a role in long-term funding, but the guild should be prepared to pursue in-protocol fees as needed.

### Distribution

Service fees will initially be distributed equally amongst relay guild member entities.

Over time, the guild will move towards distributing rewards in proportion to validator registrations per relay (see FAQ for discussion).

Additional technical work that may enhance this further includes:
* A modification to Beacon Node API Specs + MEV-Boost clients to make validator registrations robust,
* Storing validator registrations on-chain (e.g. post EIP-4844),
* Consideration of additional metrics to affect and inform distribution.

----

# Additional Notes

### Funding targets

To set the service-fee targets denominated in ETH, relays will submit cost estimates to the independent commitee in USD. Once these have been processed and accepted, the ETH target will be set at average relay costs + a 25% buffer.

`ETH target = (av. relay costs + 25% / ETH price) * number of relay`

To calculate the service fee charged by relays to validators, the commitee will use averaged data from independent sources (e.g. rated + eigenphi) to calculate this as a percentage in terms of relayed ETH for the participating relays.

### Alternative funding options

While we acknowledge the challenges in pursuing in-protocol service fees, we argue that it is the most viable option for maintaining the health of the relay ecosystem over a multi-year horizon while the pathway towards ePBS is determined. Service fees collected by a guild ensure all validators are treated equally, is technically elegant when fully realized, and uses self-governance to incentivise high standards for participating relay operators. In other words, we prefer to rely on ethereum.

**Under the status quo**, at least 4 relays have privately confirmed that current funds will not last through the year and/or that they may have to consider ceasing operations. This will likely result in relays that are run by builders or staking pools, which may threaten smaller stakers' access to MEV opportuties.

**Direct competition between relays through variable fee mechanisms** drives innovation around minimising latency, but relays become dependent on the quality of bids for earnings and direct competition encourages market capture and operation of relays by builders. This removes putative intra-block redundancy from the MEV network--where a proposer may query multiple relays for the same bid--and more generally discourages open development and collaboration on relay infrastructure and tooling.

**Long-term public goods funding** reinforces that relays are public goods, to be operated for the benefit of--and to be judged and governed by--the broader Ethereum community. However, it may be inconsistent, time-intensive and there is little evidence yet to suggest that sufficient funds can be raised sustainable. Furthermore, it does not target those making profit (validators) effectively or equitably.

### Validator registration count as funding distribution weights

There are some advantages to using weighted validator registrations to dictate funding distribution amongst guild members in terms of economic dynamics it creates:

1) Funds relays based on adoption, rather than competition
2) Shifts influence over relay economics from the builders to the validators
3) Validators can signal relay support on a range of non-economic preferences

There are of course also challenges that come with prefering validator signalling over builder signalling, and staking pools will be in a powerful position to influence relay operations. Generally, however, the validator set is better aligned to the long term interests and core values of the broader ecosystem than builders.

Looking towards verifiable counting of registrations, with the current data API relays could access the validator registrations of other relays, and copy those registrations to their own relay to spoof a higher registration count. A simple solution would have relays keep the signatures private, providing them only to the inclusion committee for verification. Longer-term, an update to the builder API specs could have validators specify their desired relays in their signed registration request. Either way, additional research would be needed to analyze potential issues surrounding bribes or other gameable elements.