[ACP-208] Adopt Mev Zone as Standard Mev Solution for the C chain.#208
[ACP-208] Adopt Mev Zone as Standard Mev Solution for the C chain.#2080x7183 wants to merge 10 commits intoavalanche-foundation:mainfrom
Conversation
0x7183
changed the title
michaelkaplan13
left a comment
michaelkaplan13
left a comment
There was a problem hiding this comment.
Thanks for writing up this proposal. I left a few high-level comments.
We can certainly proceed with merging and making this a proposed ACP regardless, but my personal opinion is that while MEV is currently unavoidable, AvalancheGo is not the place to enshrine a specific proposer-builder separation implementation. PBS formalizes a market for MEV, but comes with its own set of protocol complexity and various risks. Nodes that want to opt in to this can certainly do so by running modified clients (as I believe currently occurs on Ethereum, etc), and I would recommend following a similar pattern here. A forked version of AvalancheGo could be maintained separately to support this functionality, while allowing the standard AvalancheGo implementation to focus solely on network level improvements.
|
|
||
| ## Specification | ||
|
|
||
| Here’s an overview of the entities in the MEV context. |
There was a problem hiding this comment.
In addition to listing the entities, I think it'd be good to include more detail on how the end-to-end system operates.
- How do validators find/know of specific builders to connect to?
- How do validators choose which bid to use?
- How are bids ensured to be paid by builders if selected by a validator?
There was a problem hiding this comment.
@michaelkaplan13 we just modified the proposal to include more technical details.
Just for reference: Mev Zone implementation doesn't follow Ethereum’s PBS design but extend the validator’s functionality: receive blocks from block builders, check them, and, if they pass a set of predefined rules add them to the chain.
| MEV Zone offers a fundamentally different approach. It introduces a transparent and inclusive infrastructure designed to align MEV extraction with the interests of the Avalanche network and its users. Instead of relying on closed-door deals and informal coordination, MEV Zone brings MEV into the open, creating a framework where validators, searchers, users, and block builders interact under publicly verifiable rules. | ||
| By formalizing private transaction support, enabling sealed-bid auctions, and redistributing part of the extracted value, MEV Zone turns a previously extractable mechanism into a source of shared value. | ||
|
|
||
| This Avalanche Community Proposal (ACP) seeks formal community endorsement to recognize MEV Zone as the canonical MEV infrastructure on Avalanche. By integrating it into the base client, we ensure that the value inevitably extracted from transaction ordering is not lost to third parties, but instead returned to the chain and its stakeholders. Validators receive fair MEV rewards, users benefit from reduced manipulation and $AVAX burning, and the ecosystem gains visibility into a once obscure topic. Ultimately, this shift lays the groundwork for a more democratic and transparent MEV landscape, where value flows through open mechanisms, opportunities are accessible to all actors—not just a privileged few—and protocol-level incentives reinforce trust, efficiency, and long-term sustainability for the Avalanche network. |
There was a problem hiding this comment.
users benefit from reduced manipulation and $AVAX burning
Is this true? My understanding is that more widely adopted proposer builder separation would lead to more transaction ordering manipulation, not less. It's just that the market for the value extracted via transaction ordering is formalized.
There was a problem hiding this comment.
While PBS doesn’t directly reduce transactions ordering manipulation, private transaction endpoints limit mempool exposure and mitigate it. We'll update the proposal to clarify this and better reflect the intended meaning.
Co-authored-by: Michael Kaplan <55204436+michaelkaplan13@users.noreply.github.com>
Co-authored-by: Michael Kaplan <55204436+michaelkaplan13@users.noreply.github.com>
Co-authored-by: Michael Kaplan <55204436+michaelkaplan13@users.noreply.github.com>
2 participants
This ACP seeks formal community endorsement to recognize MEV Zone as the canonical MEV infrastructure on Avalanche by integrating it into the base client.