Skip to main content

Introduction

Bolt enables Ethereum block proposers to provide credible commitments about the contents of their blocks. The system aims to improve Ethereum's UX and censorship resistance, by unlocking new out-of-protocol primitives such as preconfirmations and inclusion lists. Ultimately, this will increase the value of differentiated blockspace for users and applications, and generate more yield for validators.

Bolt v1 (first version) enables sub-second pre-confirmations on Ethereum through the use of proposer commitments. Users can interact with proposers in real time, enabling transactions to be confirmed instantly. The goal is to revolutionize the Ethereum user experience and unlock a new spectrum of possibilities for its applications.

Bolt is implemented out-of-protocol, leveraging restaking for economic assurances. Due to its out-of-protocol nature, it operates in an optimistic failure mode: proposers can breach any commitments they make, but will be penalized when they do. The system is compatible with the existing block production pipeline, making it easy to integrate with existing systems.

Design Principles​

Bolt's uniqueness lies in the following principles:

  1. Permissionless: Any proposer can opt-in to the protocol, and any user can request commitments from them. No central authority is needed.
  2. Trustless: No new trusted entities are introduced. Commitments are backed by economic assurances, not by trusted intermediaries.
  3. Proposer-centric: Because Bolt is proposer-centric, they can be fully held accountable for their commitments. Bolt does not rely on delegation of duties to sophisticated 3rd parties.
  4. Simple: A simple schema is implemented to facilitate easy integration for users and proposers.
  5. Compatible: Bolt is designed to be compatible with the existing PBS pipeline, and eventually ePBS.

Core Interfaces​

info

These interfaces are still under development and subject to change. We are collaborating with different teams on standardization efforts.

Bolt introduces 2 new interfaces: the commitments-API and the constraints-API. These APIs are documented in the API section. The commitments-API is concerned with the interaction between users and proposers, while the constraints-API is an extension of the existing builder & relay APIs:

Bolt interfaces

Commitments API​

The commitments API is the way for users to interact with proposers to request commitments from them. The commitments API will be subject to a lot of changes based on which commitments proposers can and want to support throughout different versions of Bolt.

Constraints API​

The main functionality of the constraints API is to allow proposers to communicate constraints to builders, and to allow them to trustlessly verify the validity of those constraints without needing to know the contents of the block.

The constraints API is an extension of the builder & relay APIs to allow for 2 things:

  • Constraint communication from proposers to builders
  • Constraint validity proofs from builders to proposers

This is a necessary change to the existing block production pipeline for it to be compatible with proposer commitments. It can also be used for other standalone use cases such as out-of-protocol spot inclusion lists.

The constraints API is implemented by the Relay and Builder and is described in more detail in the builder API and relay API sections.