Bolt
- Name: Bolt
- URL: https://docs.boltprotocol.xyz/
- Category: out-of-protocol proposer-commitment infrastructure / Ethereum preconfirmation protocol / PBS constraints-and-proof extension
- Tags: ethereum-ecosystem
- Summary: Bolt is proposer-commitment plumbing for Ethereum’s PBS supply chain. Users ask proposers for commitments, proposers turn those promises into constraints, builders return proof-carrying bids, and enforcement stays optimistic rather than protocol-native. Useful mechanism note, not a category anchor for based rollups.
- What it does:
- Lets users request commitments such as preconfirmations from Ethereum block proposers
- Adds a commitments API for user-to-proposer interaction and a constraints API that extends builder / relay communication in the PBS pipeline
- Allows proposers or delegated entities to submit signed transaction constraints for specific slots, including top-of-block or atomic-bundle style requirements
- Requires builders to produce bids with inclusion proofs so proposers can verify that committed transactions are present before signing the block header
- Provides a sidecar / mev-boost style integration path plus contracts for proposer registration and permissionless dispute resolution around attributable faults
- Includes fallback logic where proposers can self-build if relay responses do not satisfy the committed constraints
- Key claims:
- Bolt’s introduction page says the protocol enables Ethereum block proposers to provide credible commitments about block contents and explicitly frames preconfirmations and inclusion lists as the motivating primitives
- The docs say Bolt v1 enables sub-second preconfirmations on Ethereum through proposer commitments, which makes it a useful comparison class for any system trying to sell faster confirmation without waiting for protocol-native changes
- Bolt’s docs say the system is out-of-protocol and leverages restaking for economic assurances, operating in an optimistic failure mode where proposers can breach commitments but are penalized when they do
- The repository README says Bolt is fully compatible with PBS and is implemented as a forked / extended MEV-Boost stack, which is analytically important because Bolt is trying to change the execution supply chain without replacing it wholesale
- The technical flow says proposers forward committed transactions to relays as constraints, builders subscribe to those constraints and return bids with inclusion proofs, and proposers locally verify proofs before signing; this turns “preconfirmation” into a pipeline redesign rather than a simple promise message
- The builder API docs show Bolt also standardizes delegation and revocation of constraint-submission rights, which means authority over commitments can be reassigned instead of remaining hardwired to one validator key path
- The fallback-to-self-build path matters because it reveals where ultimate execution authority still sits: proposers can reject invalid relay proofs and build directly, preserving proposer accountability at the edge of the PBS market
- The strongest comparison frame is not generic fast-confirmation UX; it is “an out-of-protocol constraints market layered on top of PBS, with proposer accountability backed by economic penalties and proof-carrying bids”
- Whitepaper: No canonical standalone Bolt whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the official docs, the repository README, and the builder-API specification pages; see
../whitepapers/bolt-primary-sources-2026-05-10.md. - Sources:
Internal linkages
- Strongest upward comparison points: puffer-preconf and spire.
Control surface
-
Authority sits in who can sell commitments, who can submit or delegate constraints, which relays and builders support proof-carrying bids, and what penalty path actually matters when a promise breaks.
-
Read Bolt as Ethereum supply-chain middleware, not as a based-rollup center.
-
Last reviewed: 2026-06-16 UTC