Skip to main content

Bolt V1

Here is a high-level overview of the transaction flow to obtain an inclusion preconfirmation with Bolt:

Bolt transaction flow

The specific steps are described as follows (from top to bottom):

  1. The User sends a preconfirmation request to the Bolt RPC 1.
  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.

Footnotes​

  1. The Bolt RPC does not need to be a single server, as it falls under the same conditions as regular Ethereum RPCs: anyone can run one. It's just a proxy server that implements the Commitments API. ↩