Skip to content

Conversation

@0x7183
Copy link

@0x7183 0x7183 commented Jun 12, 2025

This ACP seeks formal community endorsement to recognize MEV Zone as the canonical MEV infrastructure on Avalanche by integrating it into the base client.

@0x7183 0x7183 changed the title [ACP-205] Adopt Mev Zone as Standard Mev Solution for the C chain. [ACP-208] Adopt Mev Zone as Standard Mev Solution for the C chain. Jun 12, 2025
Copy link
Contributor

@michaelkaplan13 michaelkaplan13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.
Copy link
Contributor

@michaelkaplan13 michaelkaplan13 Jul 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants