Proposal: Onboard Bolt to the Lido Alliance

BOLT: MEV-boost Compatible Proposer-Commitments Enabling Trustless Preconfirmations

Proposal

  • Bolt allows proposers to make credible commitments, starting from preconfirmations. This new feature enhances network censorship resistance and user experience, aiming to increase Ethereum usage.
  • Bolt will be open-source and PBS compatible, with permissionless access on both the demand and supply side. Most importantly, it will be trustless, primarily relying on staked capital as economic collateral for commitments.
  • Bolt protocol is built by Chainbound, a research and development organization specializing in optimized infrastructure and networking solutions on Ethereum.
  • Chainbound is proposing to consider Bolt for the Lido Alliance. The team believes that the software aligns with Lido’s values and requirements. In addition, the Alliance will support the bootstrapping stages of the new primitive enabled by Bolt, retaining the vision and alignment with Ethereum, Lido, and the community.

Protocol Overview

Bolt Protocol enables Ethereum block proposers to provide credible commitments about their block contents. The system aims to improve Ethereum’s UX and censorship resistance by unlocking new primitives such as preconfirmations and inclusion lists. Ultimately, this will increase block-space value and yield for stakers, resulting in a more resilient Ethereum.

Bolt is implemented out-of-protocol, leveraging staked collateral for economic assurances. It is compatible with the existing block production pipeline, making it easy to integrate with existing systems.

Bolt will come to market via the phased approach outlined below:

Bolt Design Principles:

  1. Trust-minimized: No new trusted entities are introduced. Commitments are backed by economic assurances, not by trusted intermediaries.
  2. Credible: Because Bolt is proposer-centric, they can be fully held accountable for their commitments. In case of breaches, proposers can be penalized, which ensures the credibility of the commitments.
  3. Permissionless: Any proposer can opt-in to the protocol, and any user can request commitments from them. No central authority is needed.
  4. Compatible: Bolt is designed to be compatible with the existing PBS pipeline, and eventually ePBS. From the proposer’s perspective, the only change needed is an additional sidecar.

Guided by these principles, we believe Bolt is an effective preconf solution for Lido Node Operators and Ethereum as a whole.

For Ethereum:

  1. Bolt accelerates Ethereum’s roadmap towards stronger censorship resistance properties (Inclusion Lists, PEPC), de-fragmentation (based sequencing), and fast UX (preconfs), without relying on trusted intermediaries.
  2. Bolt’s permissionless nature makes it unopinionated in the current relay and builder market competition. Having an opinionated solution that could potentially favor specific relays or builders is fundamentally unhealthy for Ethereum.
  3. Bolt’s proposer-centric credibility ensures Ethereum does not increase its reliance on trusted entities within the block-production pipeline. This is important so as not to add to existing centralizing pressures.

For Lido Node Operators:

  1. Bolt is economical and easy to integrate for node operators. Bolt is implemented out-of-protocol and is compatible with the existing block production pipeline.
  2. Bolt is expressive and future-proof. Bolt is designed to cover multiple block-space use-cases, while also remaining compatible with the potential transition towards ePBS.
  3. Bolt is fault-tolerant. Bolt has an embedded fallback block building mechanism as a last resort to ensure that relays and builders aren’t critical to the proposers’ operation.
  4. Validators do not need to rely on trusted relationships to make commitments to further monetize their blockspace.

Bolt V1

Bolt V1 will support inclusion preconfirmations. Inclusion preconfirmations are commitments about the inclusion in a certain slot.

Architecture

By default, the software stack for proposers will be extended with a new component called bolt-sidecar that implements the default builder-API. The bolt-sidecar will serve like a proxy for the modified mev-boost client, which implements the constraints-API. Users interact with the bolt-sidecar, turning commitments into constraints and communicating them to the PBS pipeline through the constraints-API

Component Table

Component Placement Description
Bolt RPC Off-chain RPC proxy server that propagates preconfirmation requests to opted-in proposers in the lookahead
Bolt sidecar Off-chain The entrypoint for Bolt. Implements the commitments-API and turns commitments into constraints
MEV-Boost Off-chain Modified MEV-Boost client that implements the constraints-API and verifies constraint proofs
Registry On-chain The registry smart contract that keeps track of the opted-in proposer set and their associated stake

Proposer Software Stack

Untitled (3)

bolt-sidecar

The Bolt sidecar is the off-chain entrypoint for Bolt. To enable it, proposers must point their beacon node builder-api to the sidecar’s endpoint. From the perspective of the beacon node, the sidecar will look like a regular external block builder.

The sidecar is responsible for the following tasks:

  • Receiving & validating commitment requests from users through the commitments-API
  • Turning commitments into constraints and communicating them downstream
  • Proposing a safe fallback block in case of any faults

Modified mev-boost

The modified mev-boost client will implement the constraints-API and verify those constraints against incoming builder bids, which will have proofs attached. For more information on how proofs and verification will work, see the proofs section.

Registry

The Bolt Registry is the smart contract that keeps track of opted-in proposers and their associated stake. The responsibilities of the registry include:

  • Registering new proposers via an EOA, verifying their authenticity cryptographically (see the unfinalized opt-in procedure below)
  • Accounting for the proposer’s stake/collateral, potentially including restaked capital
  • Removing proposers that no longer wish to participate in Bolt (with a cooldown period)
  • Providing read access to the proposer set (useful for the Bolt RPC and Challenger components)

Bolt RPC

The Bolt RPC will be a public RPC endpoint that will proxy requests from users to opted in proposers according to the lookahead and provide additional functionality like DoS protection and rate limiting. The Bolt RPC will be a separate process from the proposer, and anyone can run one. Proposers can configure the Bolt sidecar to point to their preferred Bolt RPC

Please refer to our technical documentation for more details about Bolt’s architecture, commitment types, use cases, and more!

Delegation

Bolt’s architecture allows proposers to delegate the task of providing commitments to a trusted third party. This can be achieved by signing a permit message that allows the third party to submit commitments on their behalf. They then have to point their builder-API to the third party’s bolt-sidecar endpoint.

We defer to individual validators, larger node operators, and staking pools on their own policies towards delegation. For example, the allowance of delegation can be addressed within Lido’s Ethereum Block Proposer Reward Policy. It should be noted that delegation leads to a fully trusted relationship. If the operator commits a fault, the proposerr will get penalized.

Onboarding Process

The onboarding process requires proposers to opt-into the Bolt protocol. This has two parts:

  1. Off-chain Validator signature Authentication

    Validators need a signature to validate preconfirmation requests. The exact authentication method is still an open research topic, but Bolt plans to support a variety of signing methods, such as the Commit Boost signing manager. Proposers, and their respective key managers, will interact with a commit-boost’s signing manager and proxy key scheme to both authorize respective validators and authenticate commitments.

  2. Opt-in Procedure

    Once registered, proposers must post some form of collateral to guarantee economic credibility behind their preconfirmations. The specific method in which this is achieved is left as an open point for now.

We are actively looking for validators to take part in Cohort 1 for testing and demoing Bolt. We believe Lido node operators would make ideal partners here. Please reach out if you would like to participate.

Side-note: An experimental (not part of the poc) on-chain registration process could work as follows:

  1. The Proposer signs a message with their withdrawal address private key to signify that they are requesting to opt-in. The message will need to contain the Ethereum address that the proposer intends to use as signer to authenticate individual preconfirmation requests. This way, proposers in Bolt will have a separate identity from their validators private key.
  2. The Proposer sends a transaction to the Registry, requesting to opt-in to Bolt. The transaction must be sent from the same address that was specified in the signed message, which must be passed in the transaction’s data. This way, the ownership of this new ECDSA key-pair is proven on-chain.

Security Culture

The Bolt protocol will be open-sourced and audited allowing for rigorous internal and external examination of all Bolt components. Bolt is designed to be simple and minimal. Along with a modified mev-boost client, Bolt only introduces 2 additional off-chain components: a sidecar and an RPC.

Chainbound will collaborate with external parties for both on-chain and off-chain components. For example, Bolt can utilize existing battle-tested restaking modules.

Additionally, Bolt’s interface and standards will be a collaborative output from many teams thinking about similar solutions. Chainbound will provide maintenance, monitoring and, analytics for continued transparency, integrity, and security of Bolt.

Lido Alliance <> Chainbound

Lido’s reGOOSE states:

Internalize validator services that align with Ethereum’s roadmap, starting with preconfirmations, without exposing stakers to additional risk

Bolt is not only: (1) a generalized proposer commitments protocol that can facilitate a variety of potential validator services, but also (2) designed with preconfirmations as the primary use case, and (3) aligned with Ethereum’s roadmap towards stronger censorship resistance guarantees, better UX, and defragmentation.

Bolt does, however, rely on economic security, placing additional slashing risk on proposers. We find this path necessary when introducing proposer-centric commitments so as not to rely on trusted intermediaries. With that said, there are ways to either reduce proposer risk (which can come in the form of insurance funds) or increase rewards (yield) to compensate for said risk.

Lido Alliance Support for Chainbound

Acceptance into the Lido alliance would be a direct endorsement for Chainbound and Bolt. With this endorsement, Chainbound would appreciate the convergence from Lido stakeholders around Bolt as one of the preconfirmation solutions to test and iterate over. For the Lido working group, Chainbound would appreciate direct collaboration and feedback on Bolt’s design choices, suggestions around auditors and firms, and continuous testing of the software.

Helping bootstrap Validator Cohort 1, in particular with Lido Node Operators, would be an incredible help, along with ongoing assistance around validator adoption down the line.

Lido Alliance Alignment Collateral

We at Chainbound are open to discussing the possibilities here.

Towards a Proposer-centric Future

We hope the design decisions around our protocol reflect our desire to support and grow Ethereum, and therefore, help support Lido, a key steward of the Ethereum community. Proposer agency and trustless proposer commitments are core towards making Ethereum more censorship-resistant and usable.

We are excited for Ethereum and Lido’s future and hope Bolt can play a part in that!

8 Likes

Thank you for your proposal! Preconfirmations were the first item in the Alliance wishlist and we’re happy to see some interest.

With preconfirmations there is a lot that needs to be tested and a lot of designs that need to be finalized before we can recommend endorsing anything to token holders. It’s also an occasion for Lido DAO to propose standards for outputs so that, in the long-run, multiple preconfirmation protocols can participate.

To move forward on preconfirmations, we will source advice on how to structure a process with clear requirements for Chainbound and any other project to apply and move to testnet.

5 Likes

Thank you for your proposal! As one of the supporters of the pre-confirmations experiment within the Lido protocol timeline, I am very excited about having you as a member of the Lido Alliance. As a member of the working group focused on pre-confirmations, I would be delighted to collaborate on refining the preconfirmation setup for Lido Node Operators.

2 Likes

UPDATED Proposal: Onboard bolt to the Lido Alliance


bolt – Enabling Preconfirmations with Proposer Commitments


Proposal TLDR


  • With bolt, users can receive near-instant confirmation on non-contentious transactions through inclusion preconfirmations. Actions like transfers, approvals, and mints, which previously took an average of 7 seconds, can now be preconfirmed in approximately 250ms. Users can be confident in these ‘promises of inclusion’, as they are backed by economic collateral and enforced by slashing conditions.
  • Starting with inclusion preconfirmations on Ethereum, bolt enables validators to further monetize their blockspace. Bolt leverages proposer commitments—a novel primitive that allows proposers (validators) to make credible commitments on the blocks they produce—to achieve this. Bolt is fully PBS-compatible, allowing validators to access ancillary revenue streams without giving up MEV rewards.
  • Bolt starts with inclusion pre-confirmations but is designed to be flexible to unlock a variety of use cases. Promising applications include encrypted transaction inclusion, event-driven promises, settlement guarantees for dApps and rollups—and most notably, based sequencing. In future iterations, bolt plans to expand to other commitment types, such as blockspace claims, to potentially enable execution preconfirmations and blockspace futures.
  • Bolt protocol is built by Chainbound, a research and development organization specializing in optimized infrastructure and networking solutions on Ethereum. Bolt is fully open-sourced and built with an Ethereum-first mentality. We understand the negative externalities and centralizing forces at play, and therefore, we have designed bolt with proposer-centricity at its core.
  • In this updated proposal, Chainbound is proposing that bolt be considered for acceptance in the Lido Alliance. The team believes that the protocol aligns with Lido’s values and requirements. Additionally, the Alliance’s support for the adoption of bolt will bring preconfirmations to Ethereum while retaining alignment with the visions of Ethereum, Lido, and the broader community.

Protocol Overview


Bolt enables sub-second inclusion preconfirmations on Ethereum through the use of proposer commitments. Users can interact with Ethereum proposers in real time, allowing transactions to be confirmed instantly. By engaging with proposers within the proposal interval, bolt bypasses consensus in the hot path, resulting in significant speed benefits for users. Instead of relying on consensus, bolt leverages crypto-economic collateral to ensure the credibility of inclusion pre-confirmations.

For Ethereum validators, bolt allows proposers to take on additional duties (and risk) to access ancillary rewards in a MEV-Boost compatible and safe manner. By opting into the bolt protocol, proposers can make commitments with users and relay these commitments as constraints to MEV-Boost builders. This opens the door to a variety of potential use cases, including encrypted transaction inclusion, settlement guarantees for dApps and rollups, and based sequencing.

While developing bolt, we have built with these design principles in mind:

  1. Permissionless: Any proposer can opt in to the protocol, and any user can request commitments from them.
  2. Proposer-centric: Because bolt is proposer-centric, proposers can be fully held accountable for their commitments.
  3. Simple: A simple schema is implemented to facilitate integration for users and proposers.
  4. Trust Minimized: Bolt does not rely on delegation of duties to centralized third parties. The protocol aims to introduce no new trusted intermediaries.*
  5. Compatible: bolt is designed to be compatible with the existing PBS pipeline and eventually ePBS.

*For bolt v1, we aim to address the fair-exchange problem by implementing dedicated RPCs. Bolt intends to deploy the initial RPC during the protocol’s market launch. The main role of the RPC will be limited to protecting validators from spam, and time-stamping both commitment requests and responses.

Guided by these principles, we believe bolt is an effective preconf solution for Lido and Ethereum as a whole.

For Ethereum:

  1. Bolt ultimately accelerates Ethereum’s roadmap towards stronger censorship resistance properties (Inclusion Lists, PEPC), de-fragmentation (based sequencing), and fast UX (preconfs), without relying on trusted intermediaries.
  2. Bolt’s permissionless nature makes it unopinionated in the current relay and builder market competition. We believe that having an opinionated solution that could potentially favor specific relays or builders is fundamentally unhealthy for Ethereum.
  3. Bolt’s proposer-centric design ensures Ethereum doesn’t increase its reliance on trusted entities within the block-production pipeline. This is crucial to avoid adding to existing centralizing pressures and allows validators to directly issue commitments simply by running the bolt-sidecar (more on this below).

For Lido:

  1. Bolt is economical and easy to integrate for node operators. Bolt allows proposers to further increase their rewards in a MEV-boost compatible manner.
  2. Bolt is expressive and future-proof. It is designed to unlock a variety of use-cases through the support of diverse commitment types, while also remaining compatible with the potential transition towards ePBS.
  3. Bolt is fault-tolerant. Bolt has an embedded fallback block building mechanism as a last resort to ensure that relays and builders aren’t critical to the proposers’ operation.
  4. Bolt is proposer-centric. Validators do not need to delegate responsibilities to sophisticated and centralized third-parties when issuing commitments.

bolt v1


Bolt V1 will support inclusion preconfirmations. Inclusion preconfirmations are commitments about the inclusion in a certain slot.

Architecture

Bolt’s architecture is designed to be simple, consisting of both off-chain and on-chain components. It is best to view bolt as a an extension to Mev-Boost. From a node operators perspective, validators run our modified MEV-boost client + sidecar, and opt-in to the bolt protocol through a registration process.

Component Placement Description
bolt sidecar Off-chain The entrypoint for bolt. Implements the commitments-API and turns commitments into constraints.
MEV-Boost Off-chain Modified MEV-Boost client that implements the constraints-API and verifies contraint proofs
bolt RPC Off-chain RPC proxy server that propagates preconfirmation requests to opted-in proposers
Registry On-chain The registry smart contract that keeps track of the opted-in proposer set and their associated stake
Challenger On-chain The challenger smart contract that verifies inclusion proofs and slashes the appropriate stake
Observer Off-chain A server that receives and stores global preconfirmation state

Preconfirmation Flow

  1. The User sends a preconfirmation request to the bolt RPC .
  2. The bolt RPC server (which implements the Commitments API) forwards the request to the bolt opted-in Proposer next in line (according to the beacon lookahead window).
  3. The Proposer simulates the transaction and validates that it satisfies the protocol validity rules, such as the base-fee and nonce requirements. If the transaction is valid, the Proposer sends a signed preconfirmation back to the bolt RPC to be relayed back to the User.
  4. The Proposer also shares the signed preconfirmation with the Relay, by calling its /constraints endpoint.
  5. All Block builders subscribed to the Relay constraints SSE stream will receive the preconfirmation as an event.
  6. All Block builders build a payload which includes the preconfirmations and other transactions, as well as the constraint validity proofs. Then they submit the payloads to the Relay, along with these proofs.
  7. The Relay validates each bid along with its inclusion proofs (this step could also be skipped if running in optimistic mode).
  8. When it’s time to propose, the Proposer calls the Relay’s /header_with_proofs endpoint to fetch the most profitable valid header.
  9. Finally, the proposer also checks the validity of the header and its proofs, and if everything is correct, it signs it and sends it to the Relay via the /blinded_blocks endpoint.
  10. At this point the relay has all the necessary information to submit the signed payload to the beacon chain.

For full information on bolt’s design and code, please refer to the below. Everything is open-source.

Roadmap


Mid-October ‘24 Mid-November ‘24 December ‘24 January ‘25
Deployments Holesky v1 (testnet) Holesky v2 (testnet) Mainnet v1
Collaborations Lido Alliance (TBD)
Working Groups Cohort 1 - validator onboarding Cohort 2 - validator onboarding
Security Audit 1 & 2 Audit 3

Security Culture


The bolt protocol is open-sourced and will be audited allowing for rigorous internal and external examination of all bolt components. Bolt is designed to be simple and minimal. Along with a modified mev-boost client, bolt only introduces 3 additional off-chain components: a sidecar, an RPC, and observer. Bolt will abide by any formal security analysis and procedure enacted by the Lido Alliance.

Chainbound has and will continue to collaborate with external parties for both on-chain and off-chain components. For example, bolt is fully integrated with audited battle-tested restaking solutions.

Additionally, bolt’s interface and standards have been and continue to be a collaborative output from many teams thinking about similar solutions. Chainbound will provide maintenance, monitoring and, analytics for continued transparency, integrity, and the security of bolt.

Lido Alliance <> Chainbound


Lido’s reGOOSE states:

Internalize validator services that align with Ethereum’s roadmap, starting with preconfirmations, without exposing stakers to additional risk

Bolt is not only: (1) a generalized proposer commitments protocol that can facilitate a variety of potential validator services, but also (2) designed with preconfirmations as the primary use case, and (3) aligned with Ethereum’s roadmap towards stronger censorship resistance guarantees, better UX, and defragmentation.

With the additional duties placed on proposers, bolt naturally introduces new risks. Bolt relies on economic security, adding slashing conditions on proposers. However, we believe the added rewards through bolt compensate for this risk. There are additional methods, such as insurance funds, that protocols can use to minimize risk for stakers.

Lido Alliance Support for Chainbound

Acceptance into the Lido alliance would be a direct endorsement for Chainbound and bolt. With this endorsement, Chainbound would appreciate the convergence from Lido stakeholders around bolt as one of the preconfirmation solutions to test and iterate over. From the Lido Alliance, Chainbound would appreciate direct collaboration and feedback on bolt’s design choices, suggestions around auditors, continuous testing of the software, and ongoing assistance around validator adoption.

In the near-term, as bolt approaches Holesky, we would appreciate the Lido Alliance to actively help bootstrap Cohort 1 of our Proposer Working Group with key Lido Node Operators. This can come in the form of introductions, education, and integration-assistance.

Next Steps

With the acceptance into the Lido Alliance, bolt would immediately recognize Lido as a key steward of the bolt protocol, and the Lido alliance would recognize itself as a key contributor to the bolt protocol. As a result, we feel it is appropriate to allocate governance power to the Lido Alliance to align incentives going forward; this will come in the form of bolt token grants.

Lido Alliance Alignment Collateral

We have structured a ‘Lido Alliance - bolt Token Allocation’ document that describes bolt’s alignment collateral. As a summary:

Total Allocation (6.5%)

Bolt plans to allocate 6.5% of its total token supply to the Lido Alliance. The total allocation consists of two components:

  • Strategic Allocation: 3.5%
  • KPI-Based Allocation: 3%

Strategic Allocation (3.5%)

  • Direct Grant: The Strategic Allocation in an unconditional direct grant to the Lido Alliance. This 3.5% represents the minimum number of tokens that the Lido Alliance will receive.
  • Unlock Schedule: Tokens will follow the same unlock schedule as early contributors to bolt.

KPI-Based Allocation (3%)*

  • KPI Definition: The KPI is defined as the percentage of Ethereum delegated to validators part of the Lido on Ethereum Curated Module who have opted in and are running the bolt protocol, out of the total amount of Ethereum delegated to all validators part of the Lido on Ethereum Curated Module. More information on the Curated Module, which is formerly known as the NodeOperatorsRegistry, can be found here.
  • KPI Threshold: bolt is targeting a 90% adoption rate among the validators part of the Lido on Ethereum Curated Module as the threshold for 100% KPI achievement.
  • Vesting Schedule: The tokens will vest over the pre-approved vesting schedule attributable to the “Ecosystem Incentive” stakeholders category, which is tentatively, a 4-year vest with a 1- year cliff.

*More details can be found on the IPFS document

The token allocation process is as follows:

  1. Vote: Lido DAO votes on the acceptance of bolt into the Lido Alliance
  2. Sign: Necessary legal documents are signed by the Lido Alliance
  3. bolt launch: Following the initial mainnet launch of Bolt, expected in early Q1 2025, Chainbound, or a bolt foundation/DAO, will calculate the Lido KPI allocation amounts on a monthly basis, inform the Lido DAO, and adjust the respective allocations accordingly.
  4. TGE: The unlock and vesting schedules for both the Strategic Allocation and KPI-based Allocation commence on the TGE date.
  5. Distribution: The Strategic Allocation and the KPI-based Allocation are distributed on unlock and vesting dates. The total amount is conditional on the KPI value, which is also measured on vesting dates.

Why Us?


Chainbound is the research and development organization spearheading bolt, and we believe we are the correct team to help bring preconfirmations to Ethereum.

We have:

  1. The track record in building safe, performant, low-level Ethereum infrastructure. Our products, Fiber and Echo, are utilized by the top block-builders and applications (telegram bots).
  2. We build with an open development and open innovation ethos. Bolt is fully open-source, and from the start, we have collaborated closely with node operators and external researchers to ensure bolt’s design is both optimal and secure.
  3. We build with an Ethereum-first mentality. We understand the negative externalities and centralizing forces at play, and therefore, we have designed bolt with proposer-centricity at its core.
  4. We pride ourselves on the reputation we have built, represented through our products and research. Most notably, our latest research for the Ethereum Foundation on geographic validator decentralization.

From the entire Chainbound and bolt team - thank you for the consideration!

3 Likes

Bolt - Alliance Workgroup Review

Key Terms


Ethereum-alignment and commitment to decentralize validation

Bolt has been designed with an Ethereum-first and proposer-centric approach. There are economies of scale pushing Ethereum towards centralized block production, and Bolt attempts to push back on this. Bolt does not rely on delegation, as it allows validators to directly issue commitments simply by running the Bolt sidecar. Bolt is a lightweight solution that does not significantly increase validator requirements. Its permissionless nature makes it unopinionated in the current relay and builder market competition, and therefore it does not favor specific relays or builders—an unhealthy outcome for Ethereum. Lastly, Bolt accelerates Ethereum’s roadmap towards stronger censorship resistance properties (Inclusion Lists, PEPC), defragmentation (based sequencing), and fast user experience (preconfirmations).

Use-cases for stETH adoption and integration

The benefits and use cases for stETH are twofold.

Firstly, Lido Node Operators (stETH validators) can access ancillary rewards in addition to the MEV-Boost auction. This leads to downstream benefits for stETH holders in the form of increased rewards.

Secondly, Bolt requires economic collateral to back commitments. Given that stETH is both highly liquid and has a high market capitalization, it stands as one of the few appropriate assets for collateral on Bolt. This use case induces additional demand for stETH.

Opportunities for node operators

Bolt enables proposers to deliver preconfirmations, thereby increasing validator rewards in a MEV-Boost compatible and safe manner. It leverages proposer commitments—a novel primitive that allows proposers (validators) to make credible commitments on the blocks they produce—to achieve this. Bolt plans to start with inclusion preconfirmations and progressively expand to different commitment types, further adding additional revenue streams for validators.

Security Review

Please see “Security Culture” section here for further detail

What are the processes for putting code into production? (Skip answer this is just subheading)

What is the release flow from the security perspective?

  1. Write and document code in open-source
  2. Internal review + implement changes
  3. External review by partners engineering teams + implement changes
  4. Devnet v1 deployment (after every deployment and audit, repeat steps 1-3)
  5. Devnet v2 deployment
  6. Testnet v1 deployment
  7. External audits by 1-3 teams
  8. Testnet v2 deployment
  9. External audits by 1-3 teams
  10. Mainnet v1 deployment

How does the team decide the code is ready for mainnet?

  1. Fully open-source to ensure a large review surface area
  2. Strong documentation to ensure a low barrier for reviewability
  3. HIgh code standards and expectations demanded by the team
  4. Rigorous internal review process
  5. Multi-party external review process
  6. Audits
  7. Multiple devnet and testnet deployments
  8. Testnets are participated and reviewed by many parties

Does the protocol have public audits? What parties conducted the audits?

  • In the process of finalizing audit partners

What’s the issue summary (total issues / total fixed / crits and highs / crits and highs fixed)

  • NA

How is the deployment verified against the audit?

  • NA

What are the processes for managing security through TVL growth?

Is there a bug bounty? if yes — which and where

  • Not yet announced, but Chainbound plans to implement a bug-bounty for v2 of bolt’s testnet and mainnet

Are there limits / thresholds on the project / TVL? Who controls those?

  • There are no hard-coded limits, but as of now, there is a 1 ETH collateral target for validators
  • There will be whitelists for collateral types
  • TBD on who controls these. If these are upgradeable parameters, a multi-sig, which Lido can have seats on, will be the initial controlling party.

Are there any user funds on a multisig?

  • No

Is the code upgradable? How and who controls upgradability?

  • TBD (as bolt is in testnet)
  • If there are any upgradeable contracts, a multi-sig, which Lido can have seats on, will be the initial controlling party.

What is the likelihood that the project will endure?

Is the project incorporated? How the legal structure looks like?

  • Chainbound Inc is a Delaware C Corp
  • A foundation will be set up for bolt

What’s the funding situation?

  • Seed Round (2024): led by cyber.Fund, with participation from Maven 11, Semantic, Robot Ventures, Bankless Ventures, Anagram, and Chorus One
  • Pre-Seed (2023): led by Delphi Ventures and cyber.Fund, with participation from SCP

What is the team size?

  • Team of 7
  • Expanding soon

Is the code open source? What’s the license?

Executive Summary

Dimension Conclusion
Security Evaluation Commitment to run testnet launch, as well as having the public audit report and bug bounty upon any launch
Ethereum Decentralization Direct, very positive
stETH Adoption Direct, very positive
Benefits to Node Operators Direct, very positive

Recommendation: Accept

The Alliance Workgroup recommends accepting Bolt and endorsing it for the Lido Alliance.

2 Likes

Snapshot vote started

We’re starting the Lido Alliance application: Bolt Snapshot, active till Thu, 24 Oct 2024 16:00:00 GMT . Please don’t forget to cast your vote!

1 Like

Hi Bolt team and Alliance,

Thanks for the proposal and apologies for the somewhat late feedback. Sounds like a positive step for and in alignment with Lido goals. We just a few follow up questions around transparency and feedback on success metrics that would be helpful to hear back on ahead of the governance deadline -

  1. (Alliance) Are there any relevant peer or competing solutions that were compared / considered with regards to the proposal and the various parameters (allocation, KPI, security)?
  2. On your KPI threshold and success metric: How is this going to be measured? Might have missed something on the technical side here but naively seems this can be gamed / end up with scenarios where if MEV reward >> Bolt collateral a operator might choose to get collateral slashed but end up in profit from rewards, and still maintain KPI ratio as it seems to just be the % of who opted in?
  3. Other than Chorus One, are there any other validators that are on both the Ethereum Curated Module (Node operators registry) list as well as in any of your funding rounds? Declaration around this would further add transparency towards incentive alignment and monitoring.
5 Likes

Hi, Nemo here, Lido Alliance contributor, let me try to cover answers to the questions bellow.

Are there any relevant peer or competing solutions that were compared / considered with regards to the proposal and the various parameters (allocation, KPI, security)?

  • When Lido contributors first started exploring preconf this spring/summer, only bolt and commit-boost were actively building in the space (or at least on the radar)

  • Lido DAO also gave a grant to commit boost, more details here: Commit-Boost Grant Proposal for Lido Community

  • During Zuberin, Bolt was the only team with ready-to-show prototypes. During & after the conference, they proved very cooperative and aligned with the Ethereum ethos + super receptive on feedback and design implementation suggestions

  • Lido Alliance is open to anyone that demonstrates Ethereum and Lido alignment (from the perspective of both code security and security practices overall), as well as GOOSE alignment in particular. Given a high degree of collaboration with the Bolt team early on, as well as their development and security processes proving to be satisfactory by Lido’s standards, we didn’t approach other teams that started building in pre-confs in the meantime.

  • No, allocation was not explored with other projects as we didnt have other applicants.

  • The KPI metric was made based on a discussion with the Bolt team, where we attempted to find a fair middle ground for both sides and strive for the win-win scenario. If Bolt is successful in their work, the assumption is that a lot of validators will be happy to opt-in.

  • Also, the Bolt team will be next to fill this out: [Proposal] PERCH: Protocol Evaluation and Request Coordination Hub for coordination for testnet colab

  • There will be one more proposal in the future to endorse Bolt tech, assuming everything goes as planned/agreed upon during the testnet period

On your KPI threshold and success metric: How is this going to be measured? Might have missed something on the technical side here but naively seems this can be gamed / end up with scenarios where if MEV reward >> Bolt collateral a operator might choose to get collateral slashed but end up in profit from rewards, and still maintain KPI ratio as it seems to just be the % of who opted in?

Interesting note, but such behaviour doesn’t seem reasonable:

  1. Even in status quo, a Node operator may attempt to «steal» huge MEV, but we can detect these actions and impose strict consequences (up to and excluding the NO from the operator set)

  2. With preconf software installed the proposed scenario may occur, however such significant MEV would either end up in Withdrawal credentials and be distributed among holders, DAO and NO’s (so no economic rationale to do so) or NO’s might also try to «steal» MEV, except in this case along with the existing reputational harm, they would also lose Bolt collateral.

Generally we assume that NO’s acting in such a manner is not economically rational (longterm, even exorbitant MEV < daily rewards from Lido), not to mention the reputational harm NOs would face as legal entities.

more details about calculation you can also find here

1. Other than Chorus One, are there any other validators that are on both the Ethereum Curated Module (Node operators registry) list as well as in any of your funding rounds? Declaration around this would further add transparency towards incentive alignment and monitoring.

Nope, only Chorus One

Hope this helps :saluting_face:

6 Likes

Much appreciated, Nemo - both the depth and speed of your response :slight_smile: We’ll be voting today as well.

4 Likes

@Chainbound , seems that there is potential for helping with censorship resistance, but v1 depends on Bolt RPC, which can be forced to censor IPs.

Where is the Chainbound entity based? What are some measures you plan to take to avoid being subject to a legal requirement to geoblock participants?

3 Likes

Hey Lanski! Thank you for the response. The RPC topic is something we have thought about extensively, and we appreciate you bringing this up. Here are answers to your questions/points:

  1. Seems that there is potential for helping with censorship resistance, but v1 depends on Bolt RPC, which can be forced to censor IPs.

    First, let’s describe the responsibility of the RPC. The RPC is a public endpoint that proxies requests from users to opted-in proposers according to the lookahead and provides additional functionality like DoS protection, rate limiting, and ensuring fair exchange.

    We want to emphasize that the bolt RPC serves as an intermediary to enhance the user experience for both users and validators, but it holds no monopolistic or exclusive rights within the system.

    Let’s break down (1) the extent of an RPC’s role in bolt v1 and (2) our path towards decentralization—two aspects we do not take lightly.

    (1) On the extent of an RPC’s role:

    Running an RPC is permissionless. Any team can develop their own RPC that interacts with opted-in validators, reads the registry, and forwards transactions to validators in the lookahead. This approach effectively opens new communication channels and ensures no exclusive control. For example, Spire Labs is developing a dedicated RPC for Based Rollups on bolt (more info here). Any user or proposer is free to exit from any RPC.

    The RPC is fully separated from the block-building process. The RPC is distinctly different from a gateway or relay, as it does not run an auction nor does it directly build a proposer’s block. The RPC purely acts as a request and response message feed. Node operators retain full agency on how they build their block.

    (2) On our path towards decentralization:

    For preconfirmations to grow, we strongly believe that the system should provide immediate value, and this can come with some near-term sacrifices on the decentralization spectrum. We are a team of seven, and we take an iterative approach to building and made a decision to ship v1 with a dedicated RPC. Decentralizing remains a top priority for us, and we have already researched and designed a quick proof of concept to tackle this issue. Please see our implementation of DATO here.

  2. Where is the Chainbound entity based? What are some measures you plan to take to avoid being subject to a legal requirement to geoblock participants?

    The Chainbound entity is a Delaware C Corp with headquarters in New York. While the bolt RPC will initially be operated by Chainbound, the development team is actively working on establishing the bolt DAO, planned to be structured under a Cayman Islands foundation. Concrete updates on this transition process will be shared on the Lido forum in due course. We believe this approach and our path towards decentralization are promising steps to reduce the possibility of enforced RPC censorship.

2 Likes

Hey @Chainbound - I appreciate your answer!

I fully agree with providing immediate value and have often used the motto “Decentralize until it hurts, centralize until it works, then decentralize again”.

The fact that RPCs are permissionless can provide resistance to a type of censorship I was referring to. If the organisation is forced by law or government order to restrict business with particular IPs or wallets, then other actors - free from such constraints - can spin up an instance and offer their service to those who the first provider wouldn’t give access to.

I’ve voted yes to onboarding and here is my rationale: Pol Lanski Delegate Thread - #7 by Lanski

4 Likes

Snapshot vote ended

Thank you all who participated in Lido Alliance application: Bolt Snapshot, we reached a quorum! :pray:
The results are:
Onboard Bolt to Lido Alliance: 61.0M LDO
No Action: 199.7k LDO

Nice to see such progress on the pre-confirmation landscape, congrats!

TL;DR: is there a reason why you plan to go both via a custom sidecar, and a commit-boost module?

As an operator managing a large number of keys/setups (Kiln), going through the commit-boost path and have a well maintained Bolt commit-boost module rather than implementing a Bolt-specific sidecar/custom mev-boost seems desirable.

Pre-confirmation will be exclusive at least at the beginning (i.e: validation keys going through pre-conf system A will be restricted to only go through the PBS builder of the pre-conf A, or it would be slashed). In the case of a custom Bolt-specifc sidecar, an operator who wants to use Bolt on a subset of their infrastructure would need to duplicate beacons so that part of their infra goes via a classic mev-boost, and the other part via bolt-mev-boost + bolt sidecar. Then accordingly spread validation keys on dedicated validator clients, each targeting the wanted beacon.

This complexity will also surface on the human/maintenance side: if an mev-boost bug arises during a protocol upgrade (historically happened), operator now needs to: ping Bolt, have Bolt patch bolt-mev-boost and the sidecar, then do the same with flashbots & mev-boost.

Such diversity in setups will happen within Lido (with SSV & Obol which I guess would have a different timeline regarding pre-confs), and at the end of the journey, it will be more likely to be complexe/brittle/unstable. It defeats a bit one of the goal of pre-confirmations: be easy to adopt on the staking side with little risk.

Commit-boost has work in progress to handle PBS routing (i.e: be able to tell, this series of public keys from this set would use the PBS module with relayers A,B,C ; these public keys from this other set would use Bolt for instance, this other series to this other module). A Bolt module here would be a nice addition, and would pave the way for a wider adoption of pre-confirmations.

It sounds to me to be the right approach for pre-confirmations sidecars if we want an ecosystem with a lot of possible flavors while being simple to opt-in/manage/maintain :slight_smile:

1 Like

Hey mxs!

First, we just wanted to say we greatly appreciate the Kiln team’s interest in preconfirmations and proposer commitments, and thank you for your contributions to the space through your work on commit-boost.

We would love to address your concerns about us building both a custom bolt sidecar and a commit-boost module.

As we respond, please let us know if we’ve misunderstood any part of your perspective. Our shared goal is to bring preconfirmations and proposer commitments to Ethereum in the safest and most effective way possible.

Let’s start by looking at your concerns:


Concern (1)

As an operator managing a large number of keys/setups (Kiln), going through the Commit-Boost path and having a well-maintained Bolt Commit-Boost module rather than implementing a Bolt-specific sidecar/custom MEV-Boost seems desirable.

Response (1)

We understand your perspective. However, based on our discussions with other partners, we do not want to constrain their choices to just commit-boost. We aim to remain neutral and agnostic, leaving the decision open to each respective node operator.

The main differences between using bolt as a commit-boost module or using bolt’s full stack is whether you choose to (1) use commit-boost’s signer or not, (2) your choice to run commit-boost’s PBS module, and (3) use commit-boost’s telemetry.

Having two bolt implementation options is beneficial on a few dimensions: (1) Diversity and safety—if a bug appears in one setup, the other might remain unaffected; and (2) Retaining agency over design decisions—since we have no control over the commit-boost codebase, having agency over signing, telemetry, and PBS flows, is advantageous from a dependency perspective.

We believe it is important from a safety perspective to build bolt without default external dependencies like commit-boost. However, we are open to revisiting this once commit-boost has been sufficiently battle-tested in production. There are potential areas for bugs—such as the PBS module, telemetry, and signing—that we do not have control over. For example, if a bug arises in the PBS module of commit-boost, bolt’s lightweight MEV-Boost fork remains unaffected, and vice versa.

At this stage, we consider it too early to decide on using only one implementation. Therefore, promoting sidecar diversity is the right approach. Introducing a single point of failure does not offer outsized benefits. We want validators to freely test different options and determine what works best for them. By requesting support exclusively for commit-boost, you take a strongly opinionated stance in favor of one software and design over another, which we do not believe to be the right approach when not enough testing has been conducted. We prefer to remain neutral by building both options and offering the choice to node operators.


Concern (2)

Pre-confirmation will be exclusive at least at the beginning. In the case of a custom Bolt-specific sidecar, an operator who wants to use Bolt on a subset of their infrastructure would need to duplicate beacons so that part of their infrastructure goes via a classic MEV-Boost, and the other part via Bolt-MEV-Boost + Bolt sidecar. Then accordingly spread validation keys on dedicated validator clients, each targeting the wanted beacon.

Response (2)

We plan to add a solution here, and so thankfully, this should not be a concern for node operators running bolt. Even today, when starting up bolt, you can define which validator keys you want to provide inclusion preconfs with. The other validator keys will just use the regular PBS flow proxied through the sidecar.


Concern (3)

This complexity will also surface on the human/maintenance side: if an MEV-Boost bug arises during a protocol upgrade (historically happened), operators now need to: ping Bolt, have Bolt patch Bolt-MEV-Boost and the sidecar, then do the same with Flashbots & MEV-Boost.

Response (3)

First, we understand your concern with Chainbound maintaining multiple implementations of bolt. With that said, we feel the benefits on a client diversity and redundancy perspective, is net beneficial for operators. At the end of the day, we understand that this is more work on us, but we are happy to take this on.

Secondly, we want to highlight under the commit-boost module design in general, operators would need to interface with as many teams as modules they decide to run. The issue you mention is magnified in this case, as node operator teams need to interface with more teams. In our opinion, this also may increase the frequency of bugs with modules being less battle-tested.

Third, we have implemented very little changes to MEV-Boost; you can see a fork diff here. We have everything open-source for anyone to review.


Concern (4)

And at the end of the journey, it will be more likely to be complex/brittle/unstable. It defeats a bit one of the goals of pre-confirmations: be easy to adopt on the staking side with little risk.

Response (4)

Sorry if we are misunderstanding your point, but to suggest supporting both a custom bolt sidecar and a commit-boost module will “more likely to be complex/brittle/unstable” over just supporting a bolt commit-boost module does not fit with our perspective.

Your argue for less optionality and diversity at this stage as it leads to less risk, but this seems to directly contradict the very premise of the commit-boost model, which is predicated on module optionality and diversity. Additionally, echoing what we stated above in Responses (1) and (3), we firmly believe that having optionality at this stage is actually critical from both a diversity and safety perspective.

From our perspective, at this stage, shoehorning bolt into commit-boost’s module model has some distinct risks: (1) bolt is fully reliant on the external dependencies of commit-boost, (2) the module model increases the complexity on a human/maintenance level with the requirement to interface with many module teams and with each team having to coordinate with commit-boost (single point of failure), and (3) on a codebase level with many modules potentially reducing the robustness of validator software—it’s important that validator software coalesces around a few battle-tested options.

Lastly, If your concern is having to potentially run both commit-boost and bolt standalone, you don’t need to worry, you are free to run everything via a bolt commit-boost module.


Concern (5)

Commit-Boost has work in progress to handle PBS routing (i.e., be able to tell, this series of public keys from this set would use the PBS module with relayers A, B, C; these public keys from this other set would use Bolt, for instance, this other series to this other module). A Bolt module here would be a nice addition and would pave the way for wider adoption of pre-confirmations.

Response (5)

Since we offer the option to run bolt with commit-boost, node operators who want to express more granular preferences over their validators—even when connected to a single builder API—can leverage this functionality by simply running bolt with commit-boost.

Alternatively, you can achieve this using bolt standalone by choosing not to opt some of your validators into Bolt’s registry contract.


We genuinely appreciate your feedback and recognize your deep understanding of node operator needs. We truly believe in our approach and would welcome the opportunity to discuss it further if you’re interested. Your insights are valuable, and we’d be grateful to consider any more suggestions you might have.

2 Likes