Introducing the APM Framework: Mechanisms, Protocols, and Sidecars

Department of Decentralisation
1

Overview

Auxiliary Proposer Mechanisms (APMs) provide a structured framework for evaluating and reason about the role of mechanisms, protocols, and sidecars that operate alongside Ethereum validators in its evolving consensus environment.

For Lido, Node Operators and stakers need a way to assess how these emerging tools can impact the security, economics, and operations of the protocol. With developments like Proposer-Builder Separation, preconfirmations, and advanced block markets, decentralized block production is becoming more complex, and staking protocols face new challanges to carefully adapt while maintaining high standards.

Developed through engagements with multiple Ethereum R&D teams, APMs build on the PERCH proposal. The goal is to establish a robust process so those who interact with the Lido protocol can reason about advanced block proposal activities on Ethereum, ensuring benefits for both the Lido protocol and the largerEthereum community. Strong interest from teams and operators highlights the need for an open, structured approach to vetting these protocols.

Motivation

Ethereum’s block proposal landscape has undergone significant transformation over the years. With developments like PBS or proposer-builder separation (up until now in an out-of-protocol manner by way of the mev-boost protocol), giving rise to increasingly competitive MEV markets, validator duties have continued to evolve rapidly, with novel inclusion preconfirmation protocols and Native Rollup-services quickly accelerating the space.

While these changes create new opportunities, they also introduce challenges for validators, who must balance decentralization, efficiency, and profitability. APMs provide a structured approach to help proposers navigate these trade-offs while aligning with network incentives.

For large-size staking protocols like Lido, however, new proposer-side infrastructure must be introduced carefully. An overly permissive system risks market fragmentation, benefiting neither Lido, users, nor Ethereum. Additionally, because of the significant commercial value of Lido’s Node Operator set, if sidecars introduce incentives, Lido must ensure it captures this value to maintain sustainability.

For these reasons, APMs must undergo rigorous evaluation to protect stakeholders and preserve a cohesive, high-quality proposer ecosystem.

Auxiliary Proposer Mechanisms

At the core of the APM framework are three main components: Mechanisms, Protocols, and Sidecars, that together enable enhanced functionality compared to the default block proposal process in Ethereum.

  • Mechanisms define an objective and a method to achieve it within the Ethereum block proposal process. They establish the fundamental logic guiding proposer behavior.
    • PBS (Proposer-Builder Separation) is a mechanism.
    • Preconfirmations are a mechanism.
  • Protocols are structured specifications of the standards, rules, and configurations for a given mechanism. They can exist in-protocol, out-of-protocol, or as hybrids (within the Ethereum ecosystem), shaping how mechanisms operate in practice.
    • MEV-Boost is an out-of-protocol specification for the PBS mechanism.
    • Bolt is a protocol.
  • Sidecars are services or software components that support Protocols, acting alongside validator software to enable their functionality.
    • MEV-Boost is a Sidecar, as is Commit-Boost (PBS module).
    • Bolt is a Sidecar, as is Commit-Boost (Preconfirmations module).

Protocols may also introduce additional client software or require modifications to existing node software. While these aren’t strictly classified as sidecars, they function similarly within the APM framework. Examples include mev-geth and the MEV Boost Relay client.

A single mechanism can be implemented by multiple protocols, which in turn may rely on various sidecars. This generally follows a 1 : n : n relationship—one mechanism can have multiple protocols, and each protocol can be enabled by multiple sidecars. In some cases, a sidecar may even support multiple protocols.

image
image1688Ă—932 36.8 KB

For more information:
[Node Operator Portal for APMs]

Validation Process for Use With the Lido Protocol

To ensure security, alignment, and value capture, APMs undergo a structured vetting process before adoption. This process mitigates risks, assesses benefits, and sets protocol standards for their integration into Lido’s Node Operator set.

Before formal DAO consideration, an APM must meet key prerequisites:

  • Comprehensive, publicly accessible documentation.
  • A monitoring path with defined performance metrics.
  • Clearly established incentives, including their distribution paths.
  • A third-party security audit (when applicable).

In order to enshrine a vetting process for APMs, it is proposed that during the consideration phase, a few items should be completed at minimum by Protocols interested in undergoing an APM assessment:

  • Engaging the Lido community and node operators (NOs):
    • Submit a PERCH proposal with demonstrated interest from a sufficient number of NOs,
    • Ideally, testing occurs outside Lido infrastructure before formal consideration,
    • NOs report no significant operational, technical, or security issues.
  • APMs must undergo testing on an Ethereum testnet (Hoodi or the available network) with interested NOs for at least one month:
    • A minimum of 5000 validator keys must participate (at least 1000 per NO),
    • Success is determined based on pre-defined performance metrics.
  • Determining security and operational readiness:
    • Community members, including Lido DAO contributors, perform a security review of the APM, documenting best practices for NOs, etc.,
    • Dedicated operational channels are set up for troubleshooting and incident response.
  • Conditions are met for mainnet rollout:
    • The APM Committee is established to oversee the vetting process and maintain the Allowed List of approved APMs ,
    • APMs are adopted in controlled cohorts, starting with interested NOs,
    • Participation remains open for additional teams following standard testnet validation procedures.

About the Block Proposer Rewards Policy

It’s important to note that the Block Proposer Rewards Policy, which currently guides Node Operators using the Lido protocol regarding their responsibilities and expectations as block proposers acting in lieu of stakers, will need to be updated to accommodate APMs. This policy update aims to ensure that the use of APMs aligns with network principles and that any strategies employed remain transparent and community-oriented. Lido DAO contributors are preparing a proposal for this policy update, which will be presented to the community for feedback.

Conclusion

Ethereum’s block proposal landscape is evolving, and the Lido protocol must adapt while upholding its high standards of security and decentralization. APMs provide a structured way to assess and integrate new proposer-side mechanisms responsibly, ensuring they align with the interests of Node Operators, stakers, and the broader Ethereum ecosystem.

Experts, security-focused community members, active Node Operators, and anyone passionate about decentralized block proposal systems are invited to join the conversation and contribute to the evaluation and refinement of the APM framework.

Your insights and feedback are crucial in strengthening the resilience and effectiveness of these mechanisms.

14 Likes
2

Hey Gabriella and the Lido Community, Drew here from the Commit-Boost effort. Thank you very much for putting this together and for the Lido Community accelerating Proposer Commitments and services that will support based rollups, among other use cases. Wanted to post some clarifications and ideas / comments on the policy below. I hope these considerations help strengthen what you all are trying to push forward!

Most of below is framed from the ideas in this post as well as practical considerations when personally thinking about going through this policy / framework. There are three sections of this comment 1) Confirming details about the framework 2) Some items to consider and 3) Confirming Commit-Boost readiness / anything else we need to do to be approved for Lido NOs to run Commit-Boost + PBS.

Confirming Details About the Framework
Is the following breakdown of mechanism, sidecar, and protocol aligned with how the framework is being defined? I’ve included two case studies below for reference:

  1. Proposer-Builder Separation (PBS)
  • Mechanism: PBS
  • Sidecar: Commit-Boost, MEV-Boost
  • Protocol: PBS Module (used with Commit-Boost; Commit-Boost can operate without it), and MEV-Boost protocol (implemented with MEV-Boost sidecar)
  1. Preconfirmations
  • Mechanism: Preconfs
  • Sidecar: Commit-Boost
  • Protocols: Puffer Module, ETHGas Module, or Interstate Module (all using Commit-Boost sidecar)

Considerations for the Framework

  • Grandfathering existing infrastructure:
    How is the team thinking about incorporating existing infrastructure, especially in the context of policy changes going forward?
  • Onboarding process:
    The framework seems focused on protocols. Does a different process apply to sidecars or new mechanisms? For example, with IL-Boost—being both a new mechanism and a protocol using the Commit-Boost sidecar—would onboarding involve proposing IL-Boost as a new protocol via the APM process, or is there a broader review for the mechanism itself?
  • Committee structure & conflicts of interest:
    Who will serve on the Committee, and is there a defined process for identifying and addressing conflicts of interest?
  • Transparency in decision-making:
    Will meeting notes or recordings be made available? Will teams present directly to the Committee, or will someone represent them?
  • DAO voting requirements:
    Is a formal DAO vote required for each protocol, or can NOs proceed with a protocol in production once the process has been followed and the Committee gives the go-ahead?
  • DAO vs NOs:
    Are there any safeguards in place to manage potential conflicts between DAO voters and NOs, particularly when incentives or perspectives might diverge?
  • Fast-tracking live protocols:
    Is there a path for expediting approval of protocols already running in production (e.g., Commit-Boost + PBS, which has been active for over a month and responsible for a decent amount of blocks being stacked, with no reported issues across multiple validators)?
  • Timeline clarity:
    I see a month allocated for testing—do we have an estimated timeline for the full process? Some clarity and goal-setting around this would be really helpful.
  • 1000-key requirement:
    Do all Lido NOs have access to more than 1000 keys for testing? Where did this number originate, and what’s the reasoning behind it? The rationale for more than 1000 is I have personally found NOs like to test various concepts and ideas so having more than the minimum to test multiple items is key. It seams reasonable but just some clarity and ensuring all NOs can participate if they want to seems important.
  • Where the testing takes place:
    There’s been some discussion around testnets—how does that impact onboarding? For instance, Commit-Boost + PBS and Other Commit-Boost Modules have had extensive testing in Holesky. Now that Hoodi is live, does that change anything? Also, if something has been running on mainnet already, can that be used as part of the testing validation?
  • Metrics framework:
    While this will naturally evolve, having some initial guidelines or expectations would be helpful. Not necessarily a strict list, but broad principles. For example, IL-Boost may not increase yield and might even slightly reduce it—yet it could still provide enough value to be worth supporting.

Commit-Boost Readiness
Based on what’s outlined, is there anything missing for Commit-Boost + PBS Module to be considered ready? Here is the original PERCH post and I believe NOs have been directly speaking with the Lido team. Is there anything else needed on our side? Here are a few key items I’ve identified so far:

  • A security assessment by Lido/DAO members (which I understand is already underway).
  • Formation of the AMP Committee (not something we can control, but noted in this post it needs to be in place).
  • Metrics collection—do we need to track anything specific, or are validator posts and the NO presentations from Commit-Boost calls and other forums sufficient? NOs have posted about performance, no issues, operational efficiencies among other items of note.

Thank you again for pushing this forward and please let me know if there are any questions or we can help in any way around this!

6 Likes
3

Hey Drew, thanks for putting together such a thoughtful response. Wanted to share a few thoughts based on my experience working with Node Operators and supporting the DAO–NO relationship over the past couple years.

1) Confirming Details About the Framework

In general the order goes Mechanism → Protocol → Sidecar, but it’s possible for sidecars to support multiple protocols (and thus possibly also multiple mechanisms).

In the case of PBS — which is also outlined in the example here — the structure is as follows:

Mechanism: PBS
Protocol: Out of Protocol PBS (specifically the MEV Boost specification)
Sidecars:

  • Flashbots MEV Boost
  • Vouch (has block relay services)
  • Commit Boost PBS module

Mechanism: Preconfirmations
Protocol: EthGas
Sidecars: EthGas commit boost module

2) Considerations for the Framework

It’s important that the policy fits what operators are already doing infra-wise but also has room to grow with the protocol. Ideally, it should be flexible enough to accommodate different types of mechanisms, and it should be something we revisit regularly — not just a one-and-done.

While it’s crucial to define the “what” of the policy, I think it’s also worth considering how the policy would actually work day-to-day. This includes things like:

  • What are the anticipated and possible effects, risks, and impacts of different possible activities?
  • Are the activities in question or their effects monitorable?
  • What restrictions of activities, or monitoring and enforcement are possible at a technical and/or automatic level?
  • How might enforcement be operationalized in practice, e.g. clearly setting expectations for Node Operators and defining pathways for accordance with expectations, both for current mechanisms and new ones introduced over time.

On the review side, it might make sense to tailor the scope depending on what’s being proposed.

  • If it’s a brand new mechanism, a broader, more in-depth review makes sense.

  • But if it’s an existing piece of the stack that’s already been tested or reviewed before, we might be able to streamline that process a bit and avoid redoing work.

Besides the base one-month processing time, it’s probably worth budgeting some buffer for reviewing outcomes, having discussion, and going through governance. It’s hard to give precise timelines, but in a best-case scenario where everything lines up, I’d say an extra 1.5–2 months is a reasonable ballpark.

There’s no issue with Node Operators running more than 1,000 validators on testnet — in fact, that can be helpful — as long as those validators are maintained through the full lifecycle. That helps avoid any unexpected impact and keeps things stable.

Earlier test results (like from Holesky or even mainnet) can still be useful for evaluations. No need to throw that data out if it’s still relevant.

In terms of what we’re actually measuring, I think we want to focus on a mix of (but not limit to):

  • Core validator duties (attestations, proposals, etc.)

  • Any mechanism-specific metrics

  • UX-level considerations (like whether the mechanism improves or degrades user experience)

  • Assessing mechanism / protocol / sidecar “compatibility” / integration with other APMs (i.e. does it override, does it augment, does it supplant,etc.) and the overall effects on things like protocol rewards effectivness.

That should give a good picture of how a mechanism performs both technically and from a user perspective.

As for the other points related to committee, things are still in progress, we hope to be able to share more information soon.

3) Commit-Boost Readiness

a few things are already in motion, as you also mentioned:

  • A security assessment is currently underway, which is a critical step before broader adoption.

  • The formation of the AMP Committee is also in progress, which will oversee the vetting procedure and maintain the Allowed List of approved APMs.

  • For metrics, having a dashboard or explorer would be ideal for tracking performance and behavior. Curious — what metrics are currently being collected or monitored today? Presentations on community calls are great resources and can definitely be referenced; however, for clearer communication and discussion, it’s preferable to have structured information written down.

  • From the Node Operator side, we definitely don’t want to make the process overly burdensome, but it would be great to define a lightweight structure that helps surface the right information. I’ll follow up soon with more concrete thoughts on that.

Hope that’s helpful — appreciate all the thought and energy you’re putting into this, looking forward to iterating more.

3 Likes