This document outlines a design specification for a proof of concept (POC) that enables preconfirmations (preconfs for short) on Ethereum. It focuses on how the existing PBS (Proposer-Builder Separation) infrastructure stack—comprising the MEV-boost client, builders, and relays—can be adjusted to support preconfirmations. The goal is to unify and align different preconfirmation protocols, such as Bolt by Chainbound, to be supported by the existing PBS infrastructure stack.

Goals

• Enable the issuance of L1 preconfirmations, providing users with swift confirmations of transaction inclusion with economic guarantees.
• Create an additional revenue stream for proposers, increasing staking yield and
• Build the foundations for infrastructure to support rollups, where L2 transactions are sequenced by the L1.
• Ensure maximal compatibility with existing preconfirmation protocols. With the current version specifically Bolt by Chainbound

Terminology

• Preconfer: The entity that issues preconfirmations. This can be either the Proposer or a Gateway to which the proposer delegated its preconf rights to.
• Gateway: A sophisticated entity capable of pricing and issuing preconfirmations.
• Elected Gateway: The Gateway that has been designated as the Preconfer for a given slot.

Interfaces

• Commitments API: new API used in the User/Preconfer communication
• Constraints API: extension of the Builder API with support for preconfs, used in the Preconfer/Relay and Builder/Relay communication

High-Level flow for delegated Preconfer

• Early in the epoch (e.g. during RegisterValidator), the Proposer signals to relays its preference to delegate its preconf rights to a gateway. The Proposer elects a Gateway directly via the elect_gateway endpoint of the Constraints API
• Gateways and users/RPCs poll relays to know the Elected Gateway via the preconfer endpoint of the Constraints API
• Users/RPCs submit preconfirmation requests via the preconf endpoint of the commitments API