Systematization of Knowledge on Preconfirmations

• The paper establishes a comprehensive framework for preconfirmation protocols by formalizing definitions, the protocol lifecycle, and enforcement mechanisms.
• It details a six-stage preconfirmation pipeline, examining methodology and simulation-based economic models to assess inclusion and execution preconfs.
• Practical insights include analysis of real-world deployments like Optimism and Taiko, offering guidelines for risk management and design optimization.

Preconfirmation protocols address the persistent delay between transaction issuance and final confirmation in blockchain ledgers by providing users with early—yet enforceable—guarantees of eventual confirmation. This Systematization of Knowledge (SoK) establishes a rigorous framework for understanding preconfirmations, formalizes terminology and the protocol lifecycle, analyzes economic and risk dimensions, and surveys representative real-world deployments. Preconfirmations are formalized as structured commitments by entities with enforcement and penalty mechanisms baked into protocol design, aligning user needs for transaction certainty with incentives and constraints faced by block proposers or their delegates.

1. Formal Terminology and Definitions

The foundational concept in this space is the preconfirmation or preconf: a commitment by an entity (preconfer) that a specified predicate over the blockchain ledger will become true at some future moment. If $f: \text{Ledger} \to \{\text{true}, \text{false}\}$ represents a predicate, a preconfirmation is a promise that $f(L) = \text{true}$ for some future ledger $L$. This abstraction captures several concrete cases:

• Inclusion preconfs: $f$ encodes eventual inclusion of a transaction $tx_0$.
• Execution preconfs: $f$ specifies additional ordering constraints, e.g., $tx_0$ must immediately follow a sequence $stx_1$ in the ledger.

Conditional preconfs refine this by making $f$'s guarantee contingent on a secondary predicate $c$; that is, if $c(L) = \text{true}$ at some point, then $f(L)$ must also be satisfied.

Entities issuing such commitments are termed preconfers. In many protocol variants, block proposers themselves serve as preconfers, though responsibilities can be delegated to specialized entities labeled gateways, which issue commitments on a proposer's behalf. The term preconfing denotes the act of issuing a preconfirmation.

2. Protocol Architecture: The Preconfirmation Pipeline

Preconfirmation protocol implementations converge on a canonical six-stage pipeline, each stage regulating responsibility allocation, interaction, and accountability within the system:

1. Preconfer Registration: Entities seeking to act as preconfers must satisfy eligibility constraints—authorization as a proposer or governance approval—typically enforced via the deposit of slashable collateral into a registry contract (e.g., the Universal Registry Contract).
2. Preconfer Election: For each slot or time interval, specific preconfers are selected. Computational mechanisms for election often exploit the blockchain’s proposer lookahead feature (notably detailed in Ethereum’s EIP-7917). Variants distinguish between L1 chains, based L2s (which follow L1 selection logic), or non-based L2s with their own mechanisms. Builder-based models require preconfirmations to be explicitly conditional on winning the relevant slot auction.
3. Preconf Request: Users transmit requests designating the transaction(s) to be preconfirmed. Requests encapsulate the desired preconf type, deadlines, preconf tip (a direct incentive), and, where supported, extended parameters such as tip decay schedules or custom penalty specifications.
4. Preconf Response: The designated preconfer or gateway issues a signed commitment in response, specifying transaction identifiers, targeted block/slot, and optional contextual state. This step is underpinned by the fair exchange problem: ensuring mutual satisfaction for both preconfer and user and conditioning tip disbursal on actual fulfiLLMent.
5. FulfiLLMent: Realization of the preconfirmation occurs as the preconfer (or the responsible builder/proposer) constructs and publishes a block meeting the promised criteria. The commitment can be formalized mathematically, e.g., $\exists p$ such that $tx_i = B[p]$ or that $f(B) = \text{true}$ for block $B$. Distinctions arise between full block preconfs (entire block reserved for preconf requests) and partial block preconfs (remaining space filled conventionally).
6. Enforcement and Punishment: Failure to honor preconfirmations triggers penalty mechanisms—collateral slashing, blacklisting, freezing of stake, or loss of reputation. Precise fault categories are introduced: safety faults (predicate $f$ violated), liveness faults (missed slots), and idleness faults (no response to requests). Some protocols define an overseer entity to monitor compliance and initiate penalties.

Step	Entity Involved	Mechanism/Contract
1	Candidate (preconfer)	Preconf Registry/Collateral Deposit
2	Scheduler	Proposer Lookahead/Election Mechanism
3	User	Request w/ Tip & Metadata
4	Preconfer/Gateway	Signed Commitment
5	Proposer/Builder	Block Inclusion/Ordering
6	Overseer/Contract	Slashing/Enforcement

3. Economic Models and Risk Considerations

User-Proposer Incentive Dynamics

Preconfirmation protocols alter the payment landscape by introducing preconf tips—economic inducements paid by users to secure early guarantees. For inclusion preconfs, fee allocation conforms to observed fee distributions (lognormal/logarithmic) within a block; block positions later in the list receive lower tips due to diminished economic value.

Execution preconfs, imposing deterministic ordering, add complexity. The paper distinguishes between:

• Independent Sub-Slot Auctions (ISSAs): The block is partitioned into sub-slots, each auctioned independently. With, for example, eight equal sub-slots, ISSAs can reduce the expected proposer revenue by up to 50% relative to a single full-block auction (not including tips); as sub-slot granularity increases, revenue reductions may reach 74%.
• Dependent Sub-Slot Auctions (DSSAs): Slot revenue is jointly optimized, in which expected revenue is maintained or even increased over delayed (single-lot) auctions.

Risk Analysis

Risks arise both from protocol design complexity and operation:

• Implementation risk includes the likelihood of software bugs or misconfiguration as preconfirmation modules are integrated into existing block production infrastructure.
• Slashing and legal risk result from violations of preconf commitments, particularly safety faults, triggering monetary or legal penalties.
• Reputation risk accrues if missed or incorrectly executed preconfs undermine user trust.
• Liveness loss can occur if downtime or missed slots result in preconf request expiration and loss of fees or status.
• Centralization and congestion risk: Only technologically and financially capable entities may persist as preconfers, introducing centralization. High demand may also result in request spam, elevated tip competition, congestion, and increased protocol latency.

These economic dynamics and risk dimensions are examined through both theoretical models and simulation-based revenue estimates.

4. Case Studies in Protocol Implementations

Several real-world protocol deployments demonstrate the practical translation of the preconfirmation framework:

• Optimism: Implements an implicit preconf regime via a centralized sequencer, which orders and temporarily confirms transactions in "unsafe" blocks before batch compression and settlement to L1. No explicit registry exists, and enforcement occurs through indirect means such as reputational consequences.
• Taiko’s Permissionless Preconfs: Utilizes the Universal Registry Contract for open preconfer registration and employs a lookahead mechanism for election. Standardized L2 transactions serve as preconf requests; preconfer commitments must be fulfilled by committing to L1 within an expiration window, with direct slashing enforcement for mismatches.
• Primev’s mev-commit Protocol: Enables L1 builders to publish cryptographic, conditional preconfirmations to a mev-commit chain. FulfiLLMent depends on builder success in slot auctions, and a tip decay mechanism incentivizes early issuance. User guarantees are in place for unfulfilled preconfs.
• ETHGas: Integrates proposer–builder separation by adapting MEV-Boost ("Commit-Boost"). Proposers register, post collateral, and auction off block-space commitments (inclusion, execution, or full-block). A relay verifies compliance, triggering automatic slashing and penalty if a commitment is not met.

Protocol	Registry	Enforcement	Preconf Type
Optimism	No	Reputational	Implicit (via sequencer)
Taiko	Universal Reg.	Slashing	Execution/Inclusion
Primev	Mev-commit chain	User guarantees	Conditional
ETHGas	Commit-Boost	Relay + Slashing	Inclusion/Execution

5. Bridging Formalism and Deployment

The paper exhibits a tight correspondence between abstract theoretical definitions—commitments to predicate $f$, categorization (inclusion vs. execution preconfs), and specification of fault types—and instantiated protocol mechanisms. The structured preconfirmation pipeline functions as a universal model, facilitating direct protocol comparison across deployments and informing the design of fair exchange, pricing, and enforcement machinery.

• Economic models such as ISSA and DSSA, and protocol innovations like tip decay, are mapped to concrete pricing and incentive schemas used in fielded systems.
• Risk investigations elucidate operational hazards, including those due to slashing mechanisms and centralization, visible in real-world deployments like ETHGas and Primev.
• Modular theoretical constructs allow for adaptation to diverse consensus and block-building environments, with trade-offs between decentralization (e.g., Taiko’s open registration) and efficiency (e.g., Optimism’s centralized sequencer).
• The presence or absence of roles such as overseers and relays reflects practical considerations in liveness, enforcement, and dispute resolution.

6. Conclusion and Prospects for Research

Formalizing preconfirmations as predicate-commitment mechanisms, this SoK provides a comprehensive taxonomy and analysis—articulating protocol mechanics, economic and risk dimensions, and representative system deployments. The taxonomy and preconfirmation pipeline facilitate systematic comparison and illuminate the trade-offs inherent in protocol design and deployment.

A plausible implication is that continued evolution of preconfirmation protocols will focus on optimizing incentive compatibility, expanding fair exchange mechanisms, and mitigating centralization pressure, while preserving or enhancing user experience and blockchain security. The surveyed frameworks and practical cases furnish a blueprint for the development and analysis of novel preconfirmation mechanisms in both L1 and L2, as well as emerging multi-chain and cross-domain settings.