This research is in active development and changing.

We suggest a preconfirmation network design that allows multiple parties to run sidecars on the validator. This prevents one party having monopoly power over preconfirmations on the network. Imagine a situation where one preconfirmation network becomes dominant and all validators run this software (like flashbots today is run by 90% of validators). Unlike PBS which is a competitive process which requires a sophisticated block builder involved in the process, the preconfirmation network has monopoly over block sale rights, they can block off certain parties from being able send a preconfirmation, or even have state locks for multiple blocks on Ethereum state as a whole.

In order to prevent this kind of cabal formation, we suggest that validators run multiple sidecars, allowing multiple parties to auction none, some, or all of the block.

We will further decentralize the gateway access. Gateway is the entity that processes transactions before the sidecar gets access, acting as a load balancer to prevent spam attacks. This is another source of centralization as the gateways are permissioned entities.

The second issue is the potential for gateway centralization. If the same gateway is elected every time, it gives it extraordinary powers over ethereum block building. Unlike the block builders which must compete for this right, gateway earns this right via agreement with the proposer.

Allowing multiple gateways to at least submit inclusion preconfirmations, is in a way implementing multiproposer, allowing multiple parties to submit constraints into the block at once.

More to be added here soon!

This post assumes familiarity with preconfirmations. If you aren't familiar here's a few resources:

• https://docs.interstate.so/research/proposer-commitment-network-explained-5
• https://github.com/NethermindEth/awesome-preconfirmations

This research is in active development and changing.

Open Questions in Preconfirmations​

1. What will be the pricing of a preconfirmation?
2. Will one preconfirmation relay be dominant or will multiple?
3. How should a wallet send a preconfirmation request?

Pricing a Preconf​

There are two types of preconfirmations: Just-In-Time, which is buying space in the current block (less than 12 seconds from now) and Ahead-Of-Time, which is buying space in a future block (>12s from now). We will cover Just-In-Time.

The validator has a monopoly on transaction inclusion, so they will attempt to max rewards per block. When the validator issues a preconfirmation, their gain is:

Profit_To_Validator = Preconf_Fee + MEV_Extractable_From_Preconfirmed_Tx  - MEV_Extractable_From_Excluded_Transaction

Thus the validator can maximize profits by excluding transactions that were not mev-extractable and replacing them with preconfirmationed transactions.

We believe the amount of non-mev-extractable transactions per block will depend mainly on the number of waiting transactions in the mempool. There needs to be a data science/ML pricing model on the proposer or relay side, that handles pricing of a preconfirmation.

Pricing Model​

We believe the inputs to this model would be (1) number of waiting transactions in the mempool (2) source of incoming transactions, dex transactions would be more valuable for MEV vs nft mints. Other variables could be considered like (3) time of day (4) impending high traffic events, and more.

To make money, the preconfirmation price should be higher than the lowest mev-extractable transaction

Valuable Use Case Only Preconfirmations​

A proposer can either give a preconfirmation cheaply to many people or at a high price to only a few.

For valuable use case preconfirmations, the user only sends a preconfirmation when there is a critical event for which they need inclusion rights. For example, for an upcoming hot NFT mint, the user would send out a preconfirmation. These use cases would be fewer in between and the bidder for these types of preconfirmations would pay a premium. If you're able to buy a bored ape during mint time, and then sell in the next block, you could guarantee yourself a strong profit.

For everyday-use preconfirmations, the fee would be so low that users send most of their transactions preconfirmed. Preconfirmations would be the default path for sending most transactions on Ethereum for convenience reasons.

While we'd prefer for everyone to experience instant confirmations while using Ethereum, validators need to price carefully to ensure they are profitable.

Validator Operator Behavior

If you are a node operator, your best outcome is done by:

1. integrating multiple preconfirmation protocols so that the relay doesn't have monopoly power. This is also positive to decentralization, since the relay could be censoring.
2. charge a uniform price across preconfirmations via the pricing model (or accept the relay that offers the highest). You need to keep track of profits over time (or run your own model) to confirm that the relay bid is higher than your opportunity cost. A bad preconfirmation protocol regularly prices the preconfirmation at below your opportunity cost, causing you to lose money over time.

It would be preferable for ethereum to encourage everyday-use preconfirmations to allow the average user to experience instant confirmation.

For the initial rollout of preconfirmations, we suggest that the validator operator price at a bit higher than expected, measure per block earnings then slowly reduce the price to meet demand, constantly checking to ensure the preconfirmation integration is net profitable.

How should a wallet send a preconfirmation request?​

We believe the best UX is for the user to be provided a price for a preconfirmation upfront (instead of having to bid and await acceptance). User would check a box on their wallet and receive a preconf for gas + preconf_fee. The wallet provider should provide updated fees from a few preconfirmation relays, taking the fee that is cheapest.

Multi-Relay Integration​

As preconfirmations become costlier the less space is in the block, every preconfirmation relay needs to know how many preconfirmations the validator has given out (via the other relays). Thus the validator should report to each preconfirmation protocol the number of total preconfirmations that have been given out.

This research is in active development and changing.

Interstate network allows validators to batch and run generic sidecars in order to earn additional fees. This is most useful for use cases that touch ethereum state, such as preconfirmations and sequencing use cases.

This also opens up the design space to allow validators to run external coprocessors that run outside of the validator. Effectively you can run logic outside of the validator and have it touch the state inside of the validator.

A version of this is implemented by reth execution extensions and a geth version has been implemented by Peter S.

While this is useful for ultrafast block times, and decentralized sequencing, it can be extended by off-chain coprocessors who can make commitments based on the state of the chain.

In fact this can be further extended to coprocessors who do not rely the chain's upcoming state but on attestations made by ethereum validators.

Attestations​

Ethereum validators can be used to execute the current state, but also attest to the correctness of the truth of a certain statement. Eigenlayer and Karak implement this by having operators run computation, backed by the slashable stake adding weight to their claims.

However an alternative way to achieve the state attestation is to have the physical validators attest the correctness of an off-chain claim. One way to borrow security is from physical stake, which may be controlled by one or a few parties.

Another way is to use attestations by the physical validators themselves, which are a larger more decentralized party. This has a benefit of being more capital efficient, claims can be trusted even without a large amount of capital.

Example Use Cases​

These are some use cases that we are working on and some we are thinking through.

• Preconf-Boost module, which allows users to get transaction inclusion confirmations ahead of an upcoming block (we are developing this).

• Layer-2-Boost, allows the rollup to gain access to TEE based off-chain computation and reduces the L1 slot times for L2s to a few 100 ms (we are working on a version).

• Attestation-Boost, allows an external protocol to borrow from the physical and geographic security of ethereum. Takes ethereum's attestation ability and applies it to the truth of an external claim, for example the output of a prediction market. To determine who won the presidential election, we could require at least 20% of ethereum nodes with no dissenters to attest to the truth of that claim.

• TEE-Boost, this would allow the protocol to request special computation that occurs inside of the validator, in a trusted execution environment.

• Sequencing-Boost, perhaps combined with TEEs, you could use a centralized sequencer and then attest to the correctness of the sequencer's claims on a decentralized validator set.

• Economic-Claims-Boost, validators can supply their economic value as collateral for a claim without a governing party. Allowing them to earn more rewards.

References

• Geth ExEx, Peter Szilagyi / Ethereum Foundation, https://x.com/peter_szilagyi?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor
• Reth ExEx, Paradigm, https://github.com/paradigmxyz/reth-exex-examples
• Commit Boost, Drew Van Der Werf, https://commit-boost.github.io/

This research is in active development and changing, not every line here gospel.

Summary​

• A proposer commitment network is a set of validators (aka block proposers) that sell space in a future block via slot auctions
• A preconfirmation is a promise of tx inclusion by a validator in a future block.
• A slot auction turns Ethereum from a discrete 12 second block time into a continuous transactions stream -- like Solana, where Ethereum user transactions are confirmed nearly instantly. This is facilitated by an off-chain agreement between the validator and the user where the validator agrees to include the upcoming transaction in a current or future block.
• Wallets will integrate preconfirmations directly, allowing the user to receive instant confirmations with the check of a box.
• Apps can purchase space in an upcoming block, allowing them to self sequence and profit from the orderflow they generate, without having to move to an L2 (losing access to L1 interoperability & decentralization)
• The proposer commitment design space is large and is a building block that opens up a lot of Ethereum utility; we explore more interesting use cases of proposer commitment networks such as user mev rebates, liquidation auctions for lending borrowing protocols, and more.

Example Use Cases​

• Irfan wants to buy coffee, using a preconfirmation the merchant receives the Etherscan receipt instantly instead of having to wait up to a minute.
• Danny sends a transaction on Uniswap, a few seconds later he gets a bonus from Uniswap, which has rebated him some of the MEV captured by the app via the trade.

Introduction​

We introduce Interstate, a credible proposer commitment network, which will enable users to receive a transaction receipt on the Ethereum base blockchain on the order of a 100 milliseconds. We define a preconfirmation as an out of protocol proposer given guarantee that a transaction will be included within the next block. If this mechanism is successful, we expect the majority of transactions on Ethereum mainnet to occur through a preconfirmation network. Interstate is an out of protocol proposer commitment protocol, which allows proposer validators to issue generic commitments of future transaction inclusion to users and protocols including layer two blockchains (L2s). Our network is a relay which connects users seeking fast transaction inclusion with our network of validators which are willing to offer preconfirmations. We introduce a built in auction mechanism, which will dynamically price the preconfirmation fee to be valuable to both the proposer validator and economical for the user. Our intended users are wallets and protocols including layer twos. We further solve novel problems that arise from proposer commitments, and extend functionality beyond preconfirmations into generic proposer commitments.

Mechanism​

A transaction is submitted directly to the proposer, and received by the preconfirmation relay, the relay routes the message to the next in-network proposer, and issues a preconfirmation receipt given the next proposer that is willing to accept a preconfirmation request (Note: over time we expect nearly all validators to accept preconfirmations just as 90%+ of all validators now run mev-boost, there is additional discussion around enforcing this in-protocol). The transaction is then included in the inclusion list submitted to the third party mev-boost relay. Professional centralized block builders order transactions and insert some of their own to maximize MEV profit. Each block builder sends a proposal to the relay containing their bid, the proposer accepts the most valuable block and submits it to the Ethereum network.

If the proposer accepts the preconfirmation request but fails to include the transaction, the proposer validator may be slashed. We can slash the validator either directly or via a restaking protocol.

Introduction​

Every twelve seconds on Ethereum, you have a validator selected as a block proposer, which has full control over which transactions are included in the block.

Proposer-builder separation is where the block builder outsources the work of picking and ordering transactions in the mempool to a third party entity: a professional block builder. Block building is highly competitive, with a few entities producing most of the blocks.

Block builders bid compete to bid the most for an upcoming block. Thus the primary beneficiary of MEV is the block proposer.

The pbs relay network is a type of blockspace auction, where the proposer gives up the entire block to a block builder. It is an entirely offchain agreement between the block builders and the block proposers.

The idea is to extend this off-chain agreement to build utility for the Ethereum blockchain and create a general purpose proposer commitment network.

Proposers can commit to nearly anything regarding the state of an upcoming block.

Types of Slot Auctions​

• This is split into an inclusion vs execution commitments. Execution preconfirmations are a stronger guarantee that the transaction won't revert or fail and will be executed successfully. This can be provided by an off-chain actor that maintains a fork of the chain or by the Block builder
• Slot auctions can support blob and regular transaction types.

Multislot MEV opportunities

How Slot Auctions Work​

Just In Time auctions are bids for inclusion within a block within 12 seconds from now.

The proposer has an incentive to delay as long as possible before accepting the preconfirmation, thus the preconfirmation protocol must enforce a time window within which the preconfirmation will be accepted.

Lifecycle of a slot auction:

1. Wallet requests slot pricing from a few relays
   • Each proposer commitment relay will have some subset of Eth validators, so the preconf request will be conducted between a different set of providers each time
   • This request can happen through an external rpc or this logic can be written into the wallet itself
2. Proposer commitment relays responds with a bid and a minimum confirmation window
   • Without a minimum confirmation window promised by the relay, the proposer would be incented to wait until the end of the block anyways, minimzing the utility of the preconfirmation
3. User selects the cheapest & fastest proposer commitment relay and submits their request through them

Edge cases:

1. The upcoming validator has not opted into any preconfirmation network. Proposers are select 32 blocks in advance, the preconfirmation requester would then submit their request to the next upcoming block in the lookahead.
   • This affects time to finality for the preconfirmation request, a block preconferred later in the lookahead means longer until the transaction is actually written to Ethereum, requiring greater trust in the preconfirmation relay
   • The upper bound of a transaction that can be preconfirmed is the upper bound of stake bonded by the validator. I.E if the stake offered by the preconfer relay isn't enough to compensate for an unincluded transaction, the preconf requester should not proceed. For this reason, restaking networks are used, which typically have a few billion in stake.
2. None of the 32 blocks proposers are opted in. Assuming 20% of the network opts in, calculating the occurrence of this:

At 10% of the network, there's a 27.8% chance none of the lookahead can offer a preconfirmation

At 50% of the network, there's a 2.33E-10 probability that no existing proposer can offer a slot, which is close to zero.

At 50% of the network, there's only a 3.25% chance that the first five validators have not opted in.

90% of validators today run flashbots, so we find it likely a similar number will run a slot auction network, should it be net profitable.

At enough validators, we can usually guarantee a slot that resolves within the first minute and its close to impossible that can we not guarantee a slot at all.

Pricing of A Slot Auction

Now, we ask ourselves at what price can the buyer of a preconfirmation and a seller of advanced blockspace come to a conclusion on the value of a future block.

The concern from the blockspace seller's side is that the price paid for a preconfirmation is almost certainly less than the value that could be extracted from running MEV on the transaction.

In order to be willing to grant a preconfirmation, the slot must be worth more than a

The conditions for when the slot auction is worth less a typical transaction is:

1. When lots of non-mev extractable transactions are slot auctioned. This means the block must be filled with lots of low value transactions for the MEV searcher, which must drop high value transactions in favor of lower value ones

   • We expect auctioned transactions to exist at the end of a block: see XGA's A/B block auctions [1]

2. When the network becomes more active than expected, causing the block builder to lose out on profitable transactions

   • This is a problem faced by any seller of a futures contract, and is acceptable
   • This may however cause slot auctions to be differentially accepted based on time of day

In Protocol Changes Supporting Slot Auctions

We expect enshrined proposer builder separation to support the movement towards slot auctions. Ethereum is facing stiff competition from alternative L1s, which offer near instant confirmations and scale.

As such, we expect Ethereum foundation to encourage out of protocol changes that enable a user experience improvement with in protocol changes that do the same.

Enshrined proposer builder separation and similar changes can force the proposer to take lower fees and accept slot auctions.

Note, while in-protocol changes can force the proposer to earn less, our protocol is opt-in by proposers, thus cannot cause the proposer to net lose over time else they would stop opting in.

Use Cases​

The use case for preconfirmations is the ability to send multiple transactions that depend on the last finalizing in batch in between Ethereum blocks. This is especially useful for Layer Two customers that seek to batch multiple transactions and borrow L1 finality quickly. It is useful for intent centric rollup protocols that seek to insert multiple transactions in between a block to fulfill a user intent. It is useful for wallet users who seek to get faster first confirmation. It is useful for lending borrowing protocols who seek to guarantee liquidations, or process multistep liquidations. The use case is near instant transaction confirmation, in singular or batch on Ethereum L1.

Integrating as a Validator Operator​

Our value add to validator operators is that we strictly increase the value of validator rewards on top of mev-boost. We expect our validator operators to already be running the mev-boost sidecar. We offer the Interstate sidecar which has the right to add to the inclusion list of the mev-boost sidecar, and offer a bid to the validator for this inclusion right. Our relay connects protocols, wallets, and L2s seeking to make preconfirmations requests to our network of validators willing to accept requests. Validator operators collect the additional rewards generated from preconfirmation requests, and based on our testing stand to gain significant rewards on top of vanilla mev-boost. Please reach out to join our testnet.

Integrating as an L2​

Preconfirmations are a valuable use case for a layer two protocol seeking to give immediate layer one finality to its users, this allows the L2 protocol to absorb near instant finality from the L1. These preconfirmation requests can be priced in stream or in batch and then submitted to the L1. A lookahead can be used to check the next available proposer that can accept the preconfirmation transaction. A particular type of rollup called a based rollup [6], pushes the work of the L2 sequencer into the L1. The L1 builder do the work of the L2 block builder, ordering transactions submitted into L2. Integrating as an L2 requires exposing a smart contract endpoint to the user to allow them to make a preconfirmation request and route the preconfirmation request into our network.

The Problem​

In our view, in order to be useful as a global payments and state machine, the Ethereum blockchain needs to have subsecond transaction confirmations. Modern payment mechanisms, trading systems, and beyond require fast changes of state. Currently, this is achieved on the Ethereum blockchain using layer two blockchains. While incredibly useful for many applications, layer twos have several major shortcomings:

• Weak Censorship Resistance Guarantees: Censorship resistance is entirely based on trust on a centralized sequencer. The sequencers of major L2s can censor transactions with network participants being unaware. Note, forced transaction inclusion from the L1 prevents funds from being locked in the L2 but does not enforce transaction inclusion.

• Centralized Bridging: Due to needing time for watchers to submit challenge proofs to avoid invalid state transitions, optimistic rollups have a seven day challenge period before transactions are written to the L1. This means bridging takes seven days on optimistic rollups and requires trust on a centralized bridge provider.

• L1 Offers Strictly Better Decentralization Guarantees: Decentralized applicaitons ("Dapps") built on L2s acquire trust assumptions of the L1 in a weaker manner than DApps directly on the L1.

• Minimizes L1 Value Accrual: It moves profitable MEV & transaction value away from the L1, reducing its economic value, educing the security of assets on the L1 and its value as a DA layer.

With many of the L2s being directly competitive with the L1, there's less opportunity for value capture on the L1 as MEV value moves to the L2, which means block proposers earn less. While the above security guarantees are offered by the most decentralized L2s, many L2s don't reach these guarantees. Transactions sent on the L1 directly on the other hand benefit from all of these guarantees and are preferable where possible.

Additionally, bringing transactions back to the L1 allows the L1 token, Ethereum, to capture greater value. As of EIP-4844, Ethereum has at times been earning as little as $1 per week from fees from L2s posting blobs [5]. Meanwhile sequencer fees for the major L2s has been significant, allowing the valuable user transactions to be captured by the L2 while Ethereum gets very little in batched blob fees. Moving transaction volume back to the L1 via based sequencers and preconfirmations allows Ethereum recapture the value lost.

Alternative L1s have been proposed as a solution to slow transaction times on Ethereum. Solana and the other alternative layer ones offer fast finality with several tradeoffs. Some issues with existing alternative L1s are:

• Validator Operators Limited to Professionals: In some systems like Solana, the validator hardware requirements are too expensive for the average user. This requires professional validator operators to run validators for the network. This means that the average user cannot verify the state of the network locally, requiring trust in a professional node operator. Additionally, the cost of running node operations must be subsidized by delegation, often from the foundation of the L1 as is the case for several alt L1s, centralizing control of validators around the L1. In some cases, the validator set is limited in protocol, allowing only validator operators with explicit legal agreements with the foundation to run validators, as is the case for Aptos.% expand on what trust assumptions are lost when a user can't run a validator themselves. %
• Insider Majority Token Ownership: As is the case for most of the major alt L1, the foundation and early investors typically controls 40%-60%+ of the token. Insufficient distribution of token ownership allows the foundation to exert control over the validator set, and exert excess implicit control over the applications that can be built on top of the L1, often picking winners and losers.
• Bridging Risk: Bridging transactions from an alternative L1 and Ethereum requires the use of a bridge, which are centralized nodes. This adds centralization to transactions moving to and from different layer 1s. Additionally bridges inherit the security guarantees of the weakest chain they support, meaning if any one chain on a bridge is exploited, all assets of the bridge are exposed.
• Ecosystem Fragmentation: Decentralized Applications on one chain cannot access the state of the other chain, thus there is liquidity fragmentation, lack of interoperability, and language barrier on executing on one chain to the next.

Today, to receive fast transaction confirmation and borrow Ethereum's security, the user must bridge to an alternative L1 or L2, execute the transaction, and then bridge back. This requires the user to take on the weakest trust assumption, which is usually in the bridge itself. By enabling faster finality directly on Ethereum mainnet, we avoid the need to bridge and execute on an alternative L1 or L2, and we solve the fragmentation issue significantly.

Interstate Network​

Our network allows transaction volume to occur on the Ethereum Layer 1 and benefit from the greater composability and decentralization guarantees that the Ethereum Layer 1 has. Our network allows the block builders to build a block and insert our transactions at the end of the block created by block builders.

Proposer Builder Separation​

Proposer builder separation is the way blocks are built on Ethereum, with 9/10ths of all blocks on Ethereum built using mev-boost.

Inclusion Lists​

Inclusion lists [2] force the inclusion of a certain transaction into a current or future block. They are a mechanism to force proposers and builders to include a pending transaction and not censor. In some cases the major block builders in Ethereum have censored transactions, based on sanctions [3]. This mechanism is useful when proposers consistently ignore certain transactions in the mempool. As our protocol is a layer on top of the mev-commit relay, our protocol takes advantage of the inclusion list that can be enforced on block builders. An inclusion list is a list of transactions that a block proposer can include into the next incoming block. Inclusion list design is an area of active research[8]. Ethereum has 12 second slot times while block builders have 8 seconds to prepare the next slots blocks, and it takes 4 seconds to propogate the block through the network. Inclusion lists need to operate under these constraints.

The actor responsible for distributing the inclusion list to the network can be a single entity (like the proposer) or a committee. The inclusion list can comprise the aggregate of inclusion lists from comittee members, which represents the IL committee's vote.

The inclusion list's gas limit has an implication on the size of the inclusion list, which affects the network propogation and node verification time. The inclusion list could potentially assert an order requirement on the block, requiring the transaction to be placed at the top, bottom, and anywhere in the block.

The inclusion list must be made available to the block builders to avoid stalling block construction. The delivery method of the inclusion list relies on the trust model, if a single person constructs the inclusion list, stricter requirements might be used such as additional attestors along the block.

Users may attempt to use the inclusion list as a data store. There need to be measures in place to assure there's a charge for storing the inclusion list or the data is stored impermanently. The actor tasked with fulfilling the IL and broadcasting the resulting product over the network. If the proposer is using mev-commit relay, the relay itself needs to enforce block inclusion as the proposer can't enforce fulfillment of the inclusion list when singing the header request. We can further insert transactions at the end of the block built by block builders.

Partially Prebuild Blocks​

The auction for the preconfirmation mechanism occurs separately from the auction for block building. Preconfirmations are allocated in a separate way from traditional MEV-boost auction. Traditional builders can operate on the block without adjustments. The auction for the transaction inclusion happen separately. Preconfirmations are allocated separately from the traditional MEV-boost auction, allowing them to coexist without disrupting the ecosystem. Block building, in the case of XGA preconfirmations is handled by multiple parties. \newline

This mechanism has some similarities to Solana's single leader validator system, where Solana has a stream of transactions, confirmed by a single leader, which broadcasts transactions continuously to the network, rather than blocks.

Simulation testing has been done on the value of the preconfirmation transactions on the block. Based on testnet simulations, preconfirmation fees materially outpace priority fees, and increase the value of each block.

Batchable Preconfirmations​

We propose composable preconfirmations, which are a form of execution preconfirmation, that allow a user to send multiple preconfirmation requests that depend on the state induced by the prior preconfirmation. Execution preconfirmations guarantee successful execution of the created block while inclusion preconfirmations only guarantee the proposer will include the transaction, which may fail (i.e if your transaction depends on a Uniswap pool having 100 usdc, and a higher prority transaction in the same block modifies this state, your transaction will fail).

Risks​

There are centralization risks associated with submitting transactions into a single leader. The single leader has the power to refuse preconfirmations from certain parties and view all incoming preconfirmation requests. This introduces some of the centralization problems seen in alternative L1s. While this fast path adds some centralization, users can get their transactions included by taking the slow submission path. Additionally, we are exploring the use of Trusted Execution Environments (TEE) in order to keep the incoming preconfirmation requests into our private mempool private [8], though this is lower priority than getting a working auction mechanism.

Multiproposer​

There has been discussion around multiple proposers, which would remove the single slot monopoly given to the active proposer and allow multiple proposer to concurrently propose a block. The ordering of the block would be merged, either via a randomized amongst the multiple proposers or by priority fee. This would remove the ability of a single proposer to decide the entire ordering of the next block. While multiproposer, is still being worked on and if it becomes adopted in protocol, we roughly expect it to be implemented end of 2025.

Preconfirmation Registry​

One issue with preconfirmations is lack of standardization around transactions sent and received. There's additional issues The preconfirmation registry contract allows validators to opt into receiving preconfirmations. There's also the option to accept multiple preconfirmations from multiple networks in order to increase the likely hood of preconfirmation acceptance from the user.

Other Proposer Commitments​

We have primarily discussed preconfirmations as the primary utility of out of protocol proposer commitments. However proposer commitments are essentially partial block auctions, and there are several ways to increase the value of a block by auctioning off transaction order and inclusion rights.

References​

1. Multiple Concurrent Block Proposers, https://ethresear.ch/t/concurrent-block-proposers-in-ethereum/18777

2. EIP-7547, Mike Neuder, Vitalik Buterin, https://eips.ethereum.org/EIPS/eip-7547

3. https://medium.com/coinmonks/understanding-the-impact-of-the-ofac-sanctions-on-block-builders-9c0e02b7e450

4. 20Squares.xyz Team, https://ethresear.ch/t/preconfirmations-on-splitting-the-block-mev-boost-compatibility-and-relays/19837

5. Ethereum Protocol Research, https://www.eip4844.com/

6. Taiko & Nethermind Team, https://ethresear.ch/t/based-preconfirmations-with-multi-round-mev-boost/20091

7. DBA, https://dba.xyz/were-all-building-the-same-thing/

8. Flasbots Team, https://collective.flashbots.net/t/tee-boost/3741

9. Inclusion List Timing Constraints, https://ethresear.ch/t/inclusion-list-timing-constraints/20198