# (Based)  Preconfirmations

*Do they really live up the hyope or yet another nerd snipe? *

By [nikos](https://paragraph.com/@0xniko0x) · 2024-10-31

---

**Status quo**  
Preconfs are a daily routine of our interactions with L2 before they settle on the L1, in the form of _soft confirmations_. The certainty of inclusion and settlement of the transaction on the L1 is provided by **_reputational collateral_** of the L2 & its sequencer.  
  
**Preconfs TLDR;**  
Preconfs serve as early guarantees for transaction inclusion in a block, giving users rapid feedback and securing their inclusion via staked collateral. The sub millisecond latency in inclusion confirmation, aims to enhance UX by clearly defining and reducing execution risk.  
  
**Based Sequencing**  
Based Sequencing provides a neutral, reliable shared sequencing layer designed to enable asynchronous composability both among rollups and between rollups and the Ethereum L1. Additionally, Based preconfirmations offer enhanced user experience by delivering preconfirmations that significantly improve transaction responsiveness. Usually provided by the L1 proposer, the preconf. supply - chain setup looks like the following:  
  
_In a leader - based setup, the L1 proposer handles two endpoints_  

1.  Request endpoint: For users and searchers to request preconfirmations
    
2.  Promise Endpoint: Enables real-time streaming of preconfirmation results to the public. This allows the requester (user/searcher) to instantly receive their result while simultaneously sharing the latest state updates with other users, even before they submit their own preconfirmation requests.
    

2.  Similar to priority fees or tips, users can include a 'tip' with their preconfirmation request to incentivize the proposer (preconfirmer) to provide a preconfirmation, operating on a first-come, first-served (FCFS) basis  
    
    ![](https://storage.googleapis.com/papyrus_images/99023fa3e2bb12d485af4725054c28a1.png)
    
    [https://ethresear.ch/t/strawmanning-based-preconfirmations/19695](https://ethresear.ch/t/strawmanning-based-preconfirmations/19695)
    
      
    **However, this monopolistic design brings several important trade-offs**  
      
    **Latency games - the centralization trap, all over again**  
    The single entity with the most sophisticated infra and lowest latency, gains the majority of the MEV backrunning profit. As we've seen in other prorpoerties within the transaction supply chain, participants were always incentivized to minimize latency to the limit.  
    An example here is, a searcher could vertically integrate with preconfers to have a constant advantage among other searchers and users in the space.  
      
    Now imagine this integration string_: searcher - builder - proposer/validator_  
    Sounds familiar? _more on that later on_  
      
    **Congestion**  
    As L2 fees approach near zero, searchers aiming to avoid costly latency games may flood the network with probabilistic arbitrage attempts. This strategy involves repeatedly submitting arbitrage contracts that execute attempts and roll back if they fail. Such a scenario could echo the pre-priority gas auction days, where intense competition among searchers congested block space with unsuccessful arbitrage transactions, ultimately increasing gas fees for regular users.  
      
    **Tip pricing**  
    In a profit-seeking, profit-maximizing environment, preconfirmers may receive requests anytime before their slot, often without knowing all transactions that will be in their block (partial requests). Additional requests and non-preconfirmed transactions could arrive before their proposal deadline, requiring preconfirmers to decide whether to confirm a request based on an incomplete view of the potential value/MEV opportunity. This means that if a preconfirmer receives a request with a 'tip' of X amount, they may not be able to determine if this tip is appropriately priced relative to the value of the rest of the block  
      
    **Fair trade**  
    Preconfers have the ability to delay preconfirmation promises, potentially failing to return them to users in a reasonable time. It's important to note that preconfermers are motivated to withhold these promises as much as possible to maximize their chances of reordering and inserting transactions or prioritise transactions from vertically integrated users, thereby increasing their MEV.  
      
    **Principle agent risk**  
    When a proposer delegates the preconfirmation rights to an external entity or marketplace, the liveness and censorship resistance of the preconfirmations depend entirely on that single external entity for the duration of the preconfer's slot(s), potentially introducing a single point of failure.
    
    **Access is key**  
    Any system with L1 preconfirmations will likely cause the preconfirmer and block builder to merge into a single entity. This is because most MEV (like CEX-DEX arbitrage) is captured in preconfirmed transactions, reducing the profitability of building non-preconfirmed blocks.  
    Since preconfirmed transactions must be placed at head of block to avoid disrupting the expected transaction order, builders must constantly update blocks to include the latest preconfirmed transactions, making it nearly impossible to separate the two roles.  
    This integration would shift block-building from the current JIT - auction model to an early selection process, where proposers delegate both preconfirmation and building rights to a single external entity in advance, offering limited control over centralization risk and fair execution in those off-chain environments.  
    

**Inclusion List**  
Since the Merge, validators have largely outsourced block production to builders, who control transaction inclusion, leaving proposers to accept this or miss out on MEV. Inclusion Lists aim to shift some decision-making power back to proposers, balancing incentives and data availability. While PBS promotes competitive block creation through mev-boost, it gives builders full control over transactions. Inclusion Lists allow proposers to ensure important transactions are included in the next block, maintaining proposer involvement and fair block production while preserving PBS's competitive environment.  
  
**Out of protocol designs**  
Out-of-protocol designs are solutions from third-party companies like Espresso, Chainbound, and Primev, using low-latency consensus, off-chain P2P environments, or proposer sidecars.  
  
**MEV-commit by** [@primev\_xyz](https://x.com/primev_xyz)  
MEV-commit is p2p coordination layer for all transaction supply chain & MEV participants. Bidders submit encrypted bids onto a mempool, where execution providers like builders, rollups and sequencers evaluate those submissions, bid on them and issue commitments to those transactions, submitted on chain. The system rewards these providers based on their execution performance and slashes them if confirmed transactions are not executed.[https://x.com/primev\_xyz/status/1813264680724668905…](https://x.com/primev_xyz/status/1813264680724668905…)  
  
**In protocol designs** Protocol-based pre confirmations aim to deliver an enhanced UX with sub-millisecond latencies. These preconfs create an in-protocol standard for immediate inclusion guarantees in the next block. As preconfirmers, L1 proposers generate "signed promises" and earn tips from users by economically guaranteeing block inclusion. To enable this in-protocol, we must assume that proposers are willing to • opt into additional slashing (via third party protocol s.a Eigenlayer) • have the ability to force inclusion of transactions/blobs via inclusion lists This method leverages L1’s decentralization and liveness for efficient sequencing, potentially channeling MEV back into L1. However, giving proposers the right to include and settle transactions allows them to exploit a larger design space for potential value extraction due to their centralized nature (in this case). This incentivizes proposers to vertically integrate with resource-rich entities (like builders), essentially controlling the entire transaction supply chain and potentially creating new monopolies.  
  
**PP & BFT by** [@EspressoSys](https://x.com/EspressoSys)  
PP preconfirmations aim to provide fast preconfirmations by having preconfers act as a slashable centralized sequencers during their preconfer slot. Similar to in protocol solutions of based preconfs, they opt into an externally-managed protocol and can be slashed for not executing their commitments. Preconfers are ranked by their next proposer slot and can offer anything from really plain inclusion/execution confirmations to more specified preconfirmation types. • **BFT consenus** Unlike PP preconfirmations, which rely on a single entity's honesty, BFT consensus protocols offer different guarantees for preconfirmations due to their internal designs. This low-latency consensus approach aims to speed up rollup pipelines, as BFT rollups begin settlement immediately after receiving the committed protocol output. In contrast, PP preconfirmations require rollups to wait until the preconfirmer's block is proposed and finalized, before settlement on the L1. Both BFT and PP preconfirmations are fully composable, allowing them to run together and provide a variety of preconfirmations [https://hackmd.io/@EspressoSystems/bft-and-proposer-promised-preconfirmations…](https://hackmd.io/@EspressoSystems/bft-and-proposer-promised-preconfirmations…)  
  
**Bolt by Chainbound**  
Bolt is an out-of-protocol sidecar for Ethereum block proposers, enabling them to credibly commit to a set of which will be included in a block. Using innovations like preconfirmations and inclusion lists, Bolt aimsto increase block-space value and yields for stakers via inclusion and confirmation tips. It integrates seamlessly with the current block production pipeline and uses an external-managed protocol (symbiotic) for economic security. Key features of Bolt include:  
• Trustlessness, new trusted entities; commitments are backed by economic assurances.  
• Proposers are fully accountable for their commitments with penalties for breaches.  
• A permissionless system, where any proposer can opt in, and any user can request commitments without a central authority.  
  
**Conclusion & personal thoughts**  
I appreciate the innovation behind preconfirmations, as well as the aim to enhance user experience and alter on-chain behavior. However, they currently seem more focused on constructing narratives around technical jargon, building infrastructure around those narratives, and marketing operations that may ultimately increase centralization in transaction execution. At the current point of time, they feel more like a 'nice-to-have' feature rather than an essential development, especially since ongoing discussions around shortening L1 block times could make preconfirmations unnecessary.

However, if preconfirmations indeed represent a meaningful intellectual advancement, we should carefully weigh the associated trade-offs in their design:

*   In-protocol implementations risk overloading L1, requiring extensive testing before integration and potentially imposing restrictive design limits.
    
*   Out-of-protocol designs, while quicker to deploy, could introduce challenges, such as reduced credible neutrality, hardware demands for low-latency consensus (which may centralize control), and dependency on external protocols for liveness guarantee

---

*Originally published on [nikos](https://paragraph.com/@0xniko0x/based-preconfirmations)*