Preconfirmations in the Based Stack

At Spire, we believe that preconfirmations (abbr. preconfs) are a helpful technology for improving user experience on based rollups.

Spire's integration of preconfs is agnostic to preconfirmation protocols.

We are partnering and working with some of the major preconfirmation protocols in an attempt to unify them permissionlessly and encourage the market to decide which is the best option. Below, you'll read more about The Preconfirmation Registry and The Preconfirmation Gateway, which are two ways we're more involved in preconf research and implementation.

To learn more about the basics of sequencing and preconfirmations check out Ethereum L2 Based Rollups and Sequencing on Ethereum L1

The Based Stack does not include specific preconfirmation support (i.e. support for slashing, collateral, or delegation.) The important exception is Spire’s sequencer election, which intentionally only chooses proposers that have some predetermined minimum amount of preconfirmation collateral. This is important because it indicates that users will be able to access preconfs more often, even if not all Ethereum validators are opted-in to preconfs.

We also attempt to make the Based Stack helpful and friendly to preconfs in other ways (like making L2 blocks easy to access from the L1 execution environment for things like preconf penalties).

Why preconfirmations?

Aside from extremely fast “soft confirmations” for users, some designs for preconfs (execution preconfs to be specific) also enable toxic MEV protection, an important part of improving user experience when interacting with applications.

Preconf flow from user -> RPC -> Gateway and back to the user

Spire is also actively contributing to preconf research as we believe that getting this right is important to the effective functioning of based rollups in the near future. Ultimately, we believe that faster block times on Ethereum make based rollups (aka “fast based rollups”) even more powerful.

To this end, we fully support Ethereum research being done to reduce the block time from 12 seconds down to 2-4 seconds. We also understand that such a change requires significant changes to Ethereum's consensus and therefore would not like to be dependent on such an upgrade soon.