Introducing the APM Framework: Mechanisms, Protocols, and Sidecars

Department of Decentralisation
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