mev-share

This repository stores the technical specifications for the MEV-share protocol, which is described in this design doc. It is intended to host discussion, development, and release notes for the protocol. Find the current specifications in /specs and see issues for active discussions around design tradeoffs and features.

Coordinating on one interface for orderflow auctions will reduce switching costs, increase competition, and create a more fair and efficient market.

Motivations

Today, orderflow originators like wallets and dapps do not actively participate in MEV. Their users generate MEV when transacting, but this value is captured by builders, searchers, and validators – not users, wallets, or dapps.

MEV-Share enables MEV redistribution whereby MEV generated by transactions can be redistributed to the initiating user, orderflow provider, and any other destination.

Importantly, MEV-Share is an open-source protocol, not a product or company. MEV-share uses commitments and privacy to facilitate permissionless collaboration between orderflow originators and searchers, similarly to what MEV-Boost did for builders and validators. It is credibly neutral, permissionless for searchers, and does not enshrine a single block builder. Aggregating order flow to MEV-Share will greatly reduce proprietary order flow as a centralizing force on Ethereum while enabling orderflow originators to participate in the MEV supply chain.

Note: The MEV-Share Matchmaker was renamed to the MEV-Share Node. This change is reflected in the specifications after June 2023.

Minimum standardizable interfaces

There are many parties that may interact as part of the MEV-share protocol:

1. Orderflow providers / sources (users, wallets, dapps)
2. Searchers
3. MEV-Share Nodes
4. Blockspace providers / proxies (builders, sequencers, validators, bundlers)

A minimum set of interfaces includes:

1. How orderflow providers send orderflow and preferences (eg. privacy, redistribution) to MEV-Share Nodes
2. How MEV-Share Nodes share information about orderflow with searchers
3. How searchers send bids, orderflow, and preferences (eg. validity conditions) to MEV-Share Nodes
4. How MEV-Share Nodes send orderflow and preferences to blockspace providers
5. How value is redistributed to orderflow providers, blockspace providers, and MEV-Share Nodes

Current architecture and APIs

The MEV-share design is actively being developed. You can find the latest architecture diagram in ./architecture.md and individual API specifications can be found in the /specs folder. See /bundles for bundle APIs and /events for event streaming APIs (each version has its own file).

Concretely, MEV-share extends the bundle API to support privacy settings, validity conditions, and complex bundle bodies. This API is used for interfaces (1), (3), and (4) above. (2) is handled by a new streaming endpoint and (5) is at the discretion of the block builder, but must fulfill the validity conditions.

Open Questions and Contributions

There are several questions around design tradeoffs and feature support. You can find existing conversations in the issues of this repo, or add your own issue to suggest a change or request a feature.