-
Notifications
You must be signed in to change notification settings - Fork 41
[ACP-208] Adopt Mev Zone as Standard Mev Solution for the C chain. #208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Michael Kaplan <[email protected]>
Co-authored-by: Michael Kaplan <[email protected]>
Co-authored-by: Michael Kaplan <[email protected]>
This ACP seeks formal community endorsement to recognize MEV Zone as the canonical MEV infrastructure on Avalanche by integrating it into the base client.