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.

1. 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
   

   

   
   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.

   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
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…

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.

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
  
  

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.

1. 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
   

   

   
   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.

   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
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…

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.

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