From 186f51841c096bfe59c395d39f0b5e5277ecae0b Mon Sep 17 00:00:00 2001 From: 0x7183 <0x7183@gmail.com> Date: Thu, 12 Jun 2025 10:21:02 +0200 Subject: [PATCH 01/10] Struct for mev zone ACP --- ACPs/205-mev-client-c-chain/README.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 ACPs/205-mev-client-c-chain/README.md diff --git a/ACPs/205-mev-client-c-chain/README.md b/ACPs/205-mev-client-c-chain/README.md new file mode 100644 index 00000000..e69de29b From 82d5ec1f2799066b3a453b5914a6a998b7d582d4 Mon Sep 17 00:00:00 2001 From: 0x7183 <75803943+0x7183@users.noreply.github.com> Date: Thu, 12 Jun 2025 10:49:35 +0200 Subject: [PATCH 02/10] Created ACP for mev zone --- ACPs/205-mev-client-c-chain/README.md | 105 ++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) diff --git a/ACPs/205-mev-client-c-chain/README.md b/ACPs/205-mev-client-c-chain/README.md index e69de29b..b9aa0cf7 100644 --- a/ACPs/205-mev-client-c-chain/README.md +++ b/ACPs/205-mev-client-c-chain/README.md @@ -0,0 +1,105 @@ +| ACP | 205 | +| :------------ | :------------------------------------------------------------------------------------ | +| **Title** | MEV Zone as Canonical MEV Infrastructure in AvalancheGo | +| **Author(s)** | [0x7183](http://github.com/0x7183) [toran777](http://github.com/toran777) | +| **Status** | | +| **Track** | Standards + + +## Abstract +This ACP introduces MEV Zone, a framework for managing and democratizing Maximal Extractable Value (MEV) on Avalanche. +MEV Zone provides an open and transparent infrastructure where all participants—validators, searchers, users, and block builders—can interact under clear and public rules. It enables private transactions, protects users from frontrunning, and introduces sealed-bid auctions where searchers compete fairly. A portion of extracted value is redistributed to the Avalanche community: validators receive MEV rewards and users benefit from reduced manipulation and $AVAX burning. + +## Motivation +Every year, over $3.5 million is extracted through MEV on Avalanche, with little to no competition. None of this value currently flows back to the chain. As Avalanche continues to grow, this number is expected to rise significantly. +Now is the time to act to ensure Avalanche is properly positioned for the future. + +Maximal Extractable Value (MEV) is an unavoidable dynamic present in all decentralized networks where the ordering of transactions directly impacts the outcome of the system. +Avalanche is no exception: MEV already occurs on-chain, but the value it generates is currently being siphoned off by a small number of centralized actors operating through opaque, private arrangements. This creates an imbalanced and exclusionary ecosystem, where the benefits of MEV are not shared with the broader community and are instead concentrated in the hands of a few. + +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 Change 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. + +#### Required Changes +- Integration of MEV Zone in the AvalancheGo Base Client + +Integrating MEV Zone directly into the AvalancheGo base client means that every validator running the official Avalanche node software will have MEV Zone functionality available but disabled by default. Validators can choose to activate it by updating their configuration file. +By being part of the base client, MEV Zone becomes immediately available to all validators, making participation seamless and increasing adoption across the network. +It ensures there’s one shared MEV framework, rather than fragmented solutions. This is critical for transparency and coordination. +Since AvalancheGo is maintained by the core protocol team, any MEV-related changes go through the same rigorous testing, versioning, and auditing pipeline as the rest of the code. + +## Specification + +Here’s an overview of the entities in the MEV context. + + +#### Validator +Role: Validators are responsible for creating and publishing blocks in the Avalanche network. +Interactions: +Receives bids from the Builder for the right to include specific transactions in the block. +Publishes the final block to the network based on the highest bids. + + +#### Avalanche Network & Mempool +Role: Acts as the communication hub where all transactions are broadcasted and temporarily stored in the mempool until included in a block. +Interactions: +Searchers and Builders listen to the mempool for pending transactions to identify profitable opportunities for MEV extraction. +Validators publish finalized blocks back to the network after including selected transactions. + +#### Searchers +Role: Searchers are specialized participants that monitor the mempool for profitable opportunities, such as arbitrage or liquidations, by analyzing pending transactions. +Interactions: +Listen to pending transactions: Continuously scan the mempool to identify MEV opportunities. +Send bundles: Once an opportunity is identified, searchers create optimized bundles of transactions and send them to the Builder for inclusion in the next block. + + +#### Builder +Role: Builders aggregate transaction bundles from Searchers and construct the most profitable block possible. They then bid on validators to include their block in the blockchain. +Interactions: +Receive bundles: Accepts bundles from searchers that are designed to extract MEV. +Send bids: Proposes blocks to the Validator, offering payment (bids) in exchange for the right to have their block included. + + +## Backwards Compatibility +The implementation of this proposal will not introduce any backwards compatibility issues. It extends functionality for those who want to participate without impacting those who don’t. + +## Reference Implementation +RawBid represents a raw bid from builder directly. +``` +type RawBid struct { + BlockNumber uint64 `json:"blockNumber"` + ParentHash common.Hash `json:"parentHash"` + Txs []hexutil.Bytes `json:"txs"` + UnRevertible []common.Hash `json:"unRevertible"` + GasUsed uint64 `json:"gasUsed"` + GasFee *big.Int `json:"gasFee"` + MevRewards *big.Int `json:"mevRewards"` + MevBurnShare *big.Int `json:"mevBurnShare"` + MevValidatorShare *big.Int `json:"mevValidatorShare"` + hash atomic.Value +} +``` + +BidArgs represents the arguments to submit a bid. +``` +type BidArgs struct { + // RawBid from builder directly + RawBid *RawBid + // Signature of the bid from builder + Signature hexutil.Bytes `json:"signature"` + // PayBidTx is a payment tx to builder from sentry, which is optional + PayBidTx hexutil.Bytes `json:"payBidTx"` + PayBidTxGasUsed uint64 `json:"payBidTxGasUsed"` + BurnTx hexutil.Bytes `json:"burnTx"` +} +``` +For more details, refer to the mev.zone [documentation](https://mevzone.gitbook.io/mevzone) + +## Security Considerations +MEV Zone integrates with AvalancheGo through minimal, isolated modifications that do not affect core consensus or block production. Validators remain fully functional regardless of MEV Zone status. If builders fail or behave incorrectly, validators default to standard block construction using internal logic. + + + + From 2103415b86c09f8064197a9929b04e21d7c71831 Mon Sep 17 00:00:00 2001 From: 0x7183 <0x7183@gmail.com> Date: Thu, 12 Jun 2025 14:43:34 +0200 Subject: [PATCH 03/10] Added correct acp number --- .../README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename ACPs/{205-mev-client-c-chain => 208-mev-client-c-chain}/README.md (97%) diff --git a/ACPs/205-mev-client-c-chain/README.md b/ACPs/208-mev-client-c-chain/README.md similarity index 97% rename from ACPs/205-mev-client-c-chain/README.md rename to ACPs/208-mev-client-c-chain/README.md index b9aa0cf7..beeab335 100644 --- a/ACPs/205-mev-client-c-chain/README.md +++ b/ACPs/208-mev-client-c-chain/README.md @@ -1,4 +1,4 @@ -| ACP | 205 | +| ACP | 208 | | :------------ | :------------------------------------------------------------------------------------ | | **Title** | MEV Zone as Canonical MEV Infrastructure in AvalancheGo | | **Author(s)** | [0x7183](http://github.com/0x7183) [toran777](http://github.com/toran777) | From 579c6dae2ce3179e1eb0601314ae8562e57fb21c Mon Sep 17 00:00:00 2001 From: 0x7183 <75803943+0x7183@users.noreply.github.com> Date: Thu, 12 Jun 2025 21:32:32 +0200 Subject: [PATCH 04/10] fix typo --- ACPs/208-mev-client-c-chain/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ACPs/208-mev-client-c-chain/README.md b/ACPs/208-mev-client-c-chain/README.md index beeab335..268214db 100644 --- a/ACPs/208-mev-client-c-chain/README.md +++ b/ACPs/208-mev-client-c-chain/README.md @@ -20,7 +20,7 @@ Avalanche is no exception: MEV already occurs on-chain, but the value it generat 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 Change 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. +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. #### Required Changes - Integration of MEV Zone in the AvalancheGo Base Client From 9f1968e0f66d25c1e77b7d8136d47773a857f03c Mon Sep 17 00:00:00 2001 From: 0x7183 <75803943+0x7183@users.noreply.github.com> Date: Tue, 8 Jul 2025 09:35:48 +0200 Subject: [PATCH 05/10] Change Track from Standards to Best Practices Co-authored-by: Michael Kaplan <55204436+michaelkaplan13@users.noreply.github.com> --- ACPs/208-mev-client-c-chain/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ACPs/208-mev-client-c-chain/README.md b/ACPs/208-mev-client-c-chain/README.md index 268214db..3dfdf302 100644 --- a/ACPs/208-mev-client-c-chain/README.md +++ b/ACPs/208-mev-client-c-chain/README.md @@ -3,7 +3,7 @@ | **Title** | MEV Zone as Canonical MEV Infrastructure in AvalancheGo | | **Author(s)** | [0x7183](http://github.com/0x7183) [toran777](http://github.com/toran777) | | **Status** | | -| **Track** | Standards +| **Track** | Best Practices | ## Abstract From 78b68881acface0e6b584e8c230a26177da43bef Mon Sep 17 00:00:00 2001 From: 0x7183 <75803943+0x7183@users.noreply.github.com> Date: Tue, 8 Jul 2025 09:36:09 +0200 Subject: [PATCH 06/10] Update ACPs/208-mev-client-c-chain/README.md Co-authored-by: Michael Kaplan <55204436+michaelkaplan13@users.noreply.github.com> --- ACPs/208-mev-client-c-chain/README.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/ACPs/208-mev-client-c-chain/README.md b/ACPs/208-mev-client-c-chain/README.md index 3dfdf302..9d7bf82c 100644 --- a/ACPs/208-mev-client-c-chain/README.md +++ b/ACPs/208-mev-client-c-chain/README.md @@ -99,7 +99,3 @@ For more details, refer to the mev.zone [documentation](https://mevzone.gitbook. ## Security Considerations MEV Zone integrates with AvalancheGo through minimal, isolated modifications that do not affect core consensus or block production. Validators remain fully functional regardless of MEV Zone status. If builders fail or behave incorrectly, validators default to standard block construction using internal logic. - - - - From 713c8930be5fbfec046692070e1895b25bb3048c Mon Sep 17 00:00:00 2001 From: 0x7183 <75803943+0x7183@users.noreply.github.com> Date: Tue, 8 Jul 2025 09:36:18 +0200 Subject: [PATCH 07/10] Update ACPs/208-mev-client-c-chain/README.md Co-authored-by: Michael Kaplan <55204436+michaelkaplan13@users.noreply.github.com> --- ACPs/208-mev-client-c-chain/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ACPs/208-mev-client-c-chain/README.md b/ACPs/208-mev-client-c-chain/README.md index 9d7bf82c..a4388569 100644 --- a/ACPs/208-mev-client-c-chain/README.md +++ b/ACPs/208-mev-client-c-chain/README.md @@ -95,7 +95,8 @@ type BidArgs struct { BurnTx hexutil.Bytes `json:"burnTx"` } ``` -For more details, refer to the mev.zone [documentation](https://mevzone.gitbook.io/mevzone) +For more details, refer to the mev.zone [documentation](https://mevzone.gitbook.io/mevzone). + ## Security Considerations MEV Zone integrates with AvalancheGo through minimal, isolated modifications that do not affect core consensus or block production. Validators remain fully functional regardless of MEV Zone status. If builders fail or behave incorrectly, validators default to standard block construction using internal logic. From 331a2566fe054248fe04441d489eeb7423af40f6 Mon Sep 17 00:00:00 2001 From: 0x7183 <75803943+0x7183@users.noreply.github.com> Date: Thu, 10 Jul 2025 09:37:57 +0200 Subject: [PATCH 08/10] Added technical details to mev zone acp --- ACPs/208-mev-client-c-chain/README.md | 354 +++++++++++++++++++++----- 1 file changed, 287 insertions(+), 67 deletions(-) diff --git a/ACPs/208-mev-client-c-chain/README.md b/ACPs/208-mev-client-c-chain/README.md index a4388569..a0308cc1 100644 --- a/ACPs/208-mev-client-c-chain/README.md +++ b/ACPs/208-mev-client-c-chain/README.md @@ -1,102 +1,322 @@ -| ACP | 208 | -| :------------ | :------------------------------------------------------------------------------------ | -| **Title** | MEV Zone as Canonical MEV Infrastructure in AvalancheGo | -| **Author(s)** | [0x7183](http://github.com/0x7183) [toran777](http://github.com/toran777) | -| **Status** | | -| **Track** | Best Practices | - +| ACP | 208 | +| :------------ | :------------------------------------------------------------------------ | +| **Title** | MEV Zone as Canonical MEV Infrastructure in AvalancheGo | +| **Author(s)** | [0x7183](http://github.com/0x7183) [toran777](http://github.com/toran777) | +| **Status** | | +| **Track** | Best Practices | ## Abstract -This ACP introduces MEV Zone, a framework for managing and democratizing Maximal Extractable Value (MEV) on Avalanche. -MEV Zone provides an open and transparent infrastructure where all participants—validators, searchers, users, and block builders—can interact under clear and public rules. It enables private transactions, protects users from frontrunning, and introduces sealed-bid auctions where searchers compete fairly. A portion of extracted value is redistributed to the Avalanche community: validators receive MEV rewards and users benefit from reduced manipulation and $AVAX burning. + +This ACP introduces MEV Zone, a standard interface for managing Maximal Extractable Value (MEV) on Avalanche. It enables private transactions, protects users from frontrunning, and introduces sealed-bid auctions where searchers compete fairly. A portion of generated value is redistributed to the Avalanche community: validators receive MEV rewards and users benefit from private transactions and $AVAX burning. ## Motivation -Every year, over $3.5 million is extracted through MEV on Avalanche, with little to no competition. None of this value currently flows back to the chain. As Avalanche continues to grow, this number is expected to rise significantly. -Now is the time to act to ensure Avalanche is properly positioned for the future. -Maximal Extractable Value (MEV) is an unavoidable dynamic present in all decentralized networks where the ordering of transactions directly impacts the outcome of the system. -Avalanche is no exception: MEV already occurs on-chain, but the value it generates is currently being siphoned off by a small number of centralized actors operating through opaque, private arrangements. This creates an imbalanced and exclusionary ecosystem, where the benefits of MEV are not shared with the broader community and are instead concentrated in the hands of a few. +#### Intro + +Every year, over $3.5 million is generated through MEV on Avalanche, with little to no competition. None of this value currently flows back to the chain. As Avalanche continues to grow, this number is expected to rise significantly. + +#### Core + +- **Secure, zero-risk standard for validators** + Validators should face no downtime or performance penalties. + +- **Implemented as an AvalancheGo dependency** + The solution lives in a library imported by AvalancheGo rather than inside the node itself, keeping the repository untouched. -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. +- **Unified interface for searchers** + A single API for submitting MEV bundles eliminates the need for multiple implementations. -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. +- **Simplified development for searchers and block builders** + One common interface reduces integration effort and resources. + +- **Maintained solution** + Validators running custom MEV-enabled clients can adopt this implementation directly, which is also maintained by the node core developers, instead of running a third part implementation. #### Required Changes -- Integration of MEV Zone in the AvalancheGo Base Client -Integrating MEV Zone directly into the AvalancheGo base client means that every validator running the official Avalanche node software will have MEV Zone functionality available but disabled by default. Validators can choose to activate it by updating their configuration file. -By being part of the base client, MEV Zone becomes immediately available to all validators, making participation seamless and increasing adoption across the network. -It ensures there’s one shared MEV framework, rather than fragmented solutions. This is critical for transparency and coordination. -Since AvalancheGo is maintained by the core protocol team, any MEV-related changes go through the same rigorous testing, versioning, and auditing pipeline as the rest of the code. +- Integrate MEV Zone into the [coreth library](https://github.com/ava-labs/coreth). + +All updates are limited to Coreth, a dependency of AvalancheGo, so the node’s own repository remains completely untouched. This isolation eliminates the risk of conflicts with ongoing work on the core node. + +Integrating MEV Zone directly into the library means that every validator running the official AvalancheGo node software will have MEV Zone functionality available but disabled by default. Validators can choose to activate it by updating their configuration file. + +Since this library is maintained by the core team, any changes should go through the same process as the rest of the code. + +## Description + +This implementation doesn't follow Ethereum’s PBS design. +Mev Zone's goal is to extend the validator’s functionality: receive blocks from block builders, check them, and, if they pass a set of predefined rules (see more below), add them to the chain. + +We chose this approach primarily because Avalanche’s rapid block time (≈ 1.7 s at the time of this proposal) benefits from a low-latency solution. + +Introducing an external relay would add unnecessary delay to the process. The proposed adjustment, however, keeps intact the security and trust assumptions that underlie the MEV market between builders and validators. ## Specification -Here’s an overview of the entities in the MEV context. +Below are the specifications on what Mev Zone brings to the validator. +### Definitions -#### Validator -Role: Validators are responsible for creating and publishing blocks in the Avalanche network. -Interactions: -Receives bids from the Builder for the right to include specific transactions in the block. -Publishes the final block to the network based on the highest bids. +**Builder:** The party that gathers transaction bundles from searchers, packs them into the most profitable block it can and bids the validator to add that block to the chain in return for a fee. +**Validator (Proposer):** The node that signs and pushes a new block on chain. It reviews bids from builders, picks the best-paying block, and broadcasts it to the network. -#### Avalanche Network & Mempool -Role: Acts as the communication hub where all transactions are broadcasted and temporarily stored in the mempool until included in a block. -Interactions: -Searchers and Builders listen to the mempool for pending transactions to identify profitable opportunities for MEV extraction. -Validators publish finalized blocks back to the network after including selected transactions. +**Searcher:** Watches the mempool for profit chances (like arbitrage or liquidations), packs the right transactions into a bundle, and sends it to a builder for the next block. -#### Searchers -Role: Searchers are specialized participants that monitor the mempool for profitable opportunities, such as arbitrage or liquidations, by analyzing pending transactions. -Interactions: -Listen to pending transactions: Continuously scan the mempool to identify MEV opportunities. -Send bundles: Once an opportunity is identified, searchers create optimized bundles of transactions and send them to the Builder for inclusion in the next block. +**Bid:** A builder’s offer for block space. A bid should include the following fields: +- **blockNumber** – height of the block +- **parentHash** – hash of the parent block +- **txs** – transactions to include in the bid +- **unRevertible** – tx hashes that must not be reverted (optional) +- **gasUsed** – total gas the block will consume +- **gasFee** – total gas fee that was burned +- **mevRewards** – total MEV captured in the block +- **mevBurnShare** – portion of MEV that will be burned +- **mevValidatorShare** – portion of MEV paid to the validator -#### Builder -Role: Builders aggregate transaction bundles from Searchers and construct the most profitable block possible. They then bid on validators to include their block in the blockchain. -Interactions: -Receive bundles: Accepts bundles from searchers that are designed to extract MEV. -Send bids: Proposes blocks to the Validator, offering payment (bids) in exchange for the right to have their block included. +- **packedBlockReward** – the total gas fees that the block builder's block would send to the coinbase address. +- **packedValidatorReward** – the validator’s payout. + We take the validator's wallet balance after the bid, subtract what it held beforehand, and the difference is the reward. -## Backwards Compatibility -The implementation of this proposal will not introduce any backwards compatibility issues. It extends functionality for those who want to participate without impacting those who don’t. +- **packedBurnShare** – the total mev share sent to the burn address. + We do the same delta calculation on the network’s burn address: balance after execution minus balance before. + +- **currentBurn** – the total gas fees that the validator’s self-built block would send to the coinbase address. + +### Bid acceptance rules + +A bid is kept only if it passes **all** the checks below: + +1. **Gas safety** + + - `gasUsed` in the bid must be **≤ the block gas limit** once the built-in gas reserves for the pay-bid and burn txs are deducted. + +2. **Transaction validity** + + - Every tx in `txs` must execute without error. + - Any hash listed in `unRevertible` must stay in the final block. + +3. **Price floor** -## Reference Implementation -RawBid represents a raw bid from builder directly. + - For txs that are _not_ already in the mempool, the **average gas price** must be **≥ `minGasPrice`**. + +4. **Reward correctness** + + - The builder reward, validator reward, and burn share must match the numbers declared in the bid (`mevRewards`, `mevValidatorShare`, `mevBurnShare`). + - Both the **burnTx** and **payBidTx** must execute successfully. + +5. **Burn-share correctness** + + - The balance increase at the burn address, **packedBurnShare**, must equal `mevBurnShare`. + +6. **Block size** + + - The total encoded size of all bid-txs must stay **≤ `targetTxsSize`**. + +7. **Outbid every other builder** + + - For the same parent hash, the bid’s **packedBlockReward** must be **no smaller** than any competing bid. + +8. **Be more profitable than the validator’s own block** + - The validator compares + - `packedBlockReward + packedValidatorReward` **vs.** `currentBurn` (what its fallback block would earn). + - The bid wins only if it pays **more** than the fallback. + +If any of these checks fail, the validator drops the bid and reverts to its own block. + +### Implementation + +In our setup, builders and validators work together in a single step: during each block interval, the builder sends a bid that already contains the full list of transactions. The validator can then seal and publish the block right away. + +```mermaid +sequenceDiagram + participant Builder + participant Validator + + Builder->>+Validator: Submit bid with transactions + Validator->>+Validator: Select the most profitable bid + Validator->>+Validator: Executes bid with transactions + + alt Bid has error + Validator->>+Builder: Notify builder about error + else Bid ok + Validator->>+Validator: Seal block + end ``` -type RawBid struct { - BlockNumber uint64 `json:"blockNumber"` - ParentHash common.Hash `json:"parentHash"` - Txs []hexutil.Bytes `json:"txs"` - UnRevertible []common.Hash `json:"unRevertible"` - GasUsed uint64 `json:"gasUsed"` - GasFee *big.Int `json:"gasFee"` - MevRewards *big.Int `json:"mevRewards"` - MevBurnShare *big.Int `json:"mevBurnShare"` - MevValidatorShare *big.Int `json:"mevValidatorShare"` - hash atomic.Value + +- The builder sends its bid with transactions to the next proposer. +- When the validator is the proposer, it picks the bid worth the most if it has any. +- The validator runs every transaction to make sure the set of rules match what the bid promised. +- If the bid is wrong, the validator falls back to the block it built earlier and tells the builder what went wrong. +- Once it has a valid bid, or uses its own block, the validator seals and broadcasts the block. + +## Appendix + +#### JSON-RPC APIs & Configuration + +This part describes how builders interact with a validator that has **MEV functionality** enabled and how a validator can configure that functionality. + +### 1. JSON-RPC Endpoints + +#### 1.1 mev_sendBid + +Submit a MEV bid to the validator. + +```jsonc +{ + "jsonrpc": "2.0", + "id": 1, + "method": "mev_sendBid", + "params": [ + { + "rawBid": { + "blockNumber": , // Target block height + "parentHash": "", // Hash of the parent block + "txs": [ "", ... ], // Raw transactions included in the bid + "unRevertible": [ "", ... ],// (Optional) Tx hashes that MUST NOT fail + "gasUsed": , // Gas consumed by the block + "gasFee": "", // How much gas gets sent to the coinbase address + "mevRewards": "", // Total MEV extracted by builder + "mevBurnShare": "", // Portion of MEV burned + "mevValidatorShare": "" // Portion of MEV paid to validator + }, + "signature": "", // ECDSA-sign over rawBid + "payBidTx": "", // Tx that transfers mevRewards to validator + "payBidTxGasUsed": , // Gas used by payBidTx + "burnTx": "" // Tx that burns mevBurnShare + } + ] +} +``` + +#### Response + +```jsonc +{ + "jsonrpc": "2.0", + "id": 1, + "result": "" // Hash of the accepted bid +} +``` + +#### 1.2 mev_params + +Query the MEV info of the validator + +``` +{ + "jsonrpc": "2.0", + "id": 1, + "method": "mev_params" +} +``` + +#### Response + +```jsonc +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "ValidatorCommission": , // Commission in basis points (1 bp = 0.01 %) + "ValidatorWallet": "
", // Address receiving the validator share + "Version": "" // Validator software version + } +} + +``` + +### 2. Validator Configuration + +MEV functionality is **disabled by default**. +To enable it, validators need edit the chain-config file following the official configuration (see the [official docs](https://build.avax.network/docs/nodes/chain-configs)): + +```jsonc +{ + "eth-apis": [ + "internal-mev" // Expose MEV-specific RPC endpoints + ], + + "mev": { + "enabled": true, // Switch for the MEV module + + "builders": [ // List of trusted builders + { + "address": "", // EOAs allowed to submit bids + "url": "" // Builder RPC endpoint to send notifications + } + ], + + "validatorCommission": , // Commission in basis points (e.g. 500 = 5 %) + "validatorWallet": "" // Validator reward address + } } ``` -BidArgs represents the arguments to submit a bid. +### Field Reference + +| Field | Description | +| ------------------------- | ----------------------------------------------------------------------------------------------- | +| `eth-apis` | Extra API namespaces exposed by the node. Must include `internal-mev` for any MEV RPCs to work. | +| `mev.enabled` | Global on/off toggle for the MEV module. | +| `mev.builders[].address` | EOA of an authorized builder. Only these addresses can call `mev_sendBid`. | +| `mev.builders[].url` | Builder’s public RPC endpoint . | +| `mev.validatorCommission` | Validator commission expressed in basis points (1 bp = 0.01 %). | +| `mev.validatorWallet` | Address that receives the validator’s commission share. | + +### 3. Reference Go Types + +This is the **common interface** that every block-builder must implement if they want to interact with Avalanche validators. + +### 3.1 RawBid + +Represents the **canonical bid payload** sent from a builder to the validator. + +```go +type RawBid struct { + BlockNumber uint64 `json:"blockNumber"` // Target block height + ParentHash common.Hash `json:"parentHash"` // Hash of the parent block + Txs []hexutil.Bytes`json:"txs"` // Raw signed txs to include + UnRevertible []common.Hash `json:"unRevertible"` // (Optional) tx hashes that must not fail + GasUsed uint64 `json:"gasUsed"` // Gas consumed by the block + GasFee *big.Int `json:"gasFee"` // Total gas fee burned + MevRewards *big.Int `json:"mevRewards"` // Total MEV captured + MevBurnShare *big.Int `json:"mevBurnShare"` // Portion of MEV burned + MevValidatorShare *big.Int `json:"mevValidatorShare"` // Portion of MEV paid to validator + + hash atomic.Value // Lazily-cached hash of the bid +} ``` + +### 3.2 BidArgs + +Wrapper that carries a signed RawBid plus the auxiliary transactions used to pay rewards and burn fees. + +```go type BidArgs struct { - // RawBid from builder directly - RawBid *RawBid - // Signature of the bid from builder - Signature hexutil.Bytes `json:"signature"` - // PayBidTx is a payment tx to builder from sentry, which is optional - PayBidTx hexutil.Bytes `json:"payBidTx"` - PayBidTxGasUsed uint64 `json:"payBidTxGasUsed"` - BurnTx hexutil.Bytes `json:"burnTx"` + RawBid *RawBid `json:"rawBid"` // Embedded RawBid + Signature hexutil.Bytes`json:"signature"` // Builder’s ECDSA signature over RawBid + PayBidTx hexutil.Bytes`json:"payBidTx"` // Tx that transfers mevRewards to validator + PayBidTxGasUsed uint64 `json:"payBidTxGasUsed"` // Gas used by payBidTx + BurnTx hexutil.Bytes`json:"burnTx"` // Tx that transfers mevBurnShare to burn addr } + ``` -For more details, refer to the mev.zone [documentation](https://mevzone.gitbook.io/mevzone). +## Backwards Compatibility + +The implementation of this proposal will not introduce any backwards compatibility issues. It extends functionality for those who want to participate without impacting those who don’t. ## Security Considerations + MEV Zone integrates with AvalancheGo through minimal, isolated modifications that do not affect core consensus or block production. Validators remain fully functional regardless of MEV Zone status. If builders fail or behave incorrectly, validators default to standard block construction using internal logic. + +## External Resources + +- [Mev Explorer](https://explorer.mev.zone) +- [Documentation](https://mevzone.gitbook.io/mevzone) + + + From f5c5846037e0c83972a90ccc9b11cc19b8ea77fd Mon Sep 17 00:00:00 2001 From: 0x7183 <75803943+0x7183@users.noreply.github.com> Date: Thu, 2 Oct 2025 18:07:48 +0200 Subject: [PATCH 09/10] Update docs --- ACPs/208-mev-client-c-chain/README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ACPs/208-mev-client-c-chain/README.md b/ACPs/208-mev-client-c-chain/README.md index a0308cc1..2d9a988a 100644 --- a/ACPs/208-mev-client-c-chain/README.md +++ b/ACPs/208-mev-client-c-chain/README.md @@ -135,6 +135,7 @@ sequenceDiagram participant Builder participant Validator + Validator->>+Builder: Get bid with transactions Builder->>+Validator: Submit bid with transactions Validator->>+Validator: Select the most profitable bid Validator->>+Validator: Executes bid with transactions @@ -145,7 +146,7 @@ sequenceDiagram Validator->>+Validator: Seal block end ``` - +- The next proposer asks the builder its bid with transactions transactions - The builder sends its bid with transactions to the next proposer. - When the validator is the proposer, it picks the bid worth the most if it has any. - The validator runs every transaction to make sure the set of rules match what the bid promised. @@ -320,3 +321,4 @@ MEV Zone integrates with AvalancheGo through minimal, isolated modifications tha + From c2eef6cae9517adfe6068d65d7edc6e4579275b7 Mon Sep 17 00:00:00 2001 From: 0x7183 <75803943+0x7183@users.noreply.github.com> Date: Thu, 2 Oct 2025 19:19:17 +0200 Subject: [PATCH 10/10] Update docs --- ACPs/208-mev-client-c-chain/README.md | 79 +++++---------------------- 1 file changed, 13 insertions(+), 66 deletions(-) diff --git a/ACPs/208-mev-client-c-chain/README.md b/ACPs/208-mev-client-c-chain/README.md index 2d9a988a..dea9f5bc 100644 --- a/ACPs/208-mev-client-c-chain/README.md +++ b/ACPs/208-mev-client-c-chain/README.md @@ -128,7 +128,7 @@ If any of these checks fail, the validator drops the bid and reverts to its own ### Implementation -In our setup, builders and validators work together in a single step: during each block interval, the builder sends a bid that already contains the full list of transactions. The validator can then seal and publish the block right away. +In our setup, builders and validators work together in a double steps: during each block interval, the validator request information to the block builder. The builder sends a bid that already contains the full list of transactions. The validator can then seal and publish the block right away. ```mermaid sequenceDiagram @@ -159,49 +159,6 @@ sequenceDiagram This part describes how builders interact with a validator that has **MEV functionality** enabled and how a validator can configure that functionality. -### 1. JSON-RPC Endpoints - -#### 1.1 mev_sendBid - -Submit a MEV bid to the validator. - -```jsonc -{ - "jsonrpc": "2.0", - "id": 1, - "method": "mev_sendBid", - "params": [ - { - "rawBid": { - "blockNumber": , // Target block height - "parentHash": "", // Hash of the parent block - "txs": [ "", ... ], // Raw transactions included in the bid - "unRevertible": [ "", ... ],// (Optional) Tx hashes that MUST NOT fail - "gasUsed": , // Gas consumed by the block - "gasFee": "", // How much gas gets sent to the coinbase address - "mevRewards": "", // Total MEV extracted by builder - "mevBurnShare": "", // Portion of MEV burned - "mevValidatorShare": "" // Portion of MEV paid to validator - }, - "signature": "", // ECDSA-sign over rawBid - "payBidTx": "", // Tx that transfers mevRewards to validator - "payBidTxGasUsed": , // Gas used by payBidTx - "burnTx": "" // Tx that burns mevBurnShare - } - ] -} -``` - -#### Response - -```jsonc -{ - "jsonrpc": "2.0", - "id": 1, - "result": "" // Hash of the accepted bid -} -``` - #### 1.2 mev_params Query the MEV info of the validator @@ -236,36 +193,25 @@ To enable it, validators need edit the chain-config file following the official ```jsonc { - "eth-apis": [ - "internal-mev" // Expose MEV-specific RPC endpoints - ], - + // Turns the MEV auction logic on for this validator. + "mev-api-enabled": true, + // MEV parameters "mev": { - "enabled": true, // Switch for the MEV module - - "builders": [ // List of trusted builders + // Whitelisted builder relay(s) – address must match the signer of the bundles it relays. + "builders": [ { - "address": "", // EOAs allowed to submit bids - "url": "" // Builder RPC endpoint to send notifications + "address": "0x00B22a6A183DdBefe7B515A73eC2Dc7C39bf82cE", + "url": "https://builder.mev.zone/ext/bc/C/rpc" } ], - - "validatorCommission": , // Commission in basis points (e.g. 500 = 5 %) - "validatorWallet": "" // Validator reward address + // Commission the validator keeps from every winning bundle (basis-points). + "validatorCommission": 500, + // Address that actually receives the commission. + "validatorWallet": "0x00..." } } ``` -### Field Reference - -| Field | Description | -| ------------------------- | ----------------------------------------------------------------------------------------------- | -| `eth-apis` | Extra API namespaces exposed by the node. Must include `internal-mev` for any MEV RPCs to work. | -| `mev.enabled` | Global on/off toggle for the MEV module. | -| `mev.builders[].address` | EOA of an authorized builder. Only these addresses can call `mev_sendBid`. | -| `mev.builders[].url` | Builder’s public RPC endpoint . | -| `mev.validatorCommission` | Validator commission expressed in basis points (1 bp = 0.01 %). | -| `mev.validatorWallet` | Address that receives the validator’s commission share. | ### 3. Reference Go Types @@ -322,3 +268,4 @@ MEV Zone integrates with AvalancheGo through minimal, isolated modifications tha +