Guide to preconfirmations in Ethereum: What they are, how they work, and why they matter

Preconfirmations (preconfs) are an emerging innovation in Ethereum that allow committing to include a transaction in a block even before the block exists.

Stick around to learn more about what preconfirmations are in Ethereum, how they work, and why they’re key to the future of the ecosystem.

A preconfirmation is essentially a signed commitment: someone with the ability to propose a block guarantees that your transaction will be included at the agreed moment.

So, what problems does this solution aim to address? Currently, Ethereum faces several issues:

• Transactions can be reordered or “sandwiched” by MEV, directly affecting users.
• The lack of predictability makes costs unreliable: extremely high during congestion peaks, very low during off-peak periods.
• Certain issuers or specific transactions may be systematically excluded by some builders.

Preconfirmations aim to tackle these issues by providing a prior guarantee of inclusion.

What’s more, this promise can come with an economic counterpart. For example, if the block proposer fails, they can be penalized via a smart contract using collateral from the block creator. That makes the commitment far more credible than a mere intention.

Although the concept isn’t entirely new—in fact, Bitcoin introduced a similar version called 0conf, which allowed payments without waiting for a block—there were no penalties if the miner failed. Ethereum aims to fix that problem by adding financial accountability.

Preconfs pave the way for several improvements and help solve multiple Ethereum issues:

• Faster confirmations: near-instant confirmations (hundreds of milliseconds instead of seconds).
• Fewer failed transactions: especially useful in markets where state changes rapidly.
• Greater censorship resistance: if the validator themselves commits, it ensures the transaction is included even if some builders reject it.
• Cost predictability: by securing prior inclusion, users can anticipate the gas they’ll pay and avoid surprises during network congestion spikes.
• MEV mitigation: by locking in inclusion and the order of certain operations, the risk of them being reordered or “sandwiched” is reduced.

Anything else?

They could even open the door to new use cases:

• Based rollups: rollups that delegate transaction ordering to Ethereum and could use these fast confirmations to improve user experience.
• Preparation for encrypted mempools: in the future, these encrypted transaction mempools will offer privacy, and preconfs could guarantee inclusion without publicly exposing transaction data.

In Ethereum, three main actors are involved in block building:

• Builders: prepare blocks with the most profitable transactions.
• Proposers: validators who, in their turn, decide which block gets published.
• Relays: messengers that connect builders and proposers.

Today, just a dozen authorized relayers handle nearly all traffic between builders and validators. While this means relying on relayer centralization, it currently keeps the ecosystem running—without them, users would face much more severe MEV extraction.

Preconfs will pave the way for PBS, enabling a decentralized and secure separation of these roles.

and relay

In Ethereum, there are two key moments before a block is published:

1. When the block is prepared by a builder.
2. When the block is signed and published by a validator (proposer).

Depending on who makes the promise, the strength of the preconfirmation varies:

Builder preconfirmation: the builder says, “your transaction will be in the block I’m preparing.”

• It’s very fast, because it arrives even before the validator sees the block.
• But it’s not 100% secure, as the validator might end up choosing a different block.

Proposer preconfirmation: the validator who will sign the block says, “I commit to including your transaction in my block.”

• This one is much more secure, as the validator has the final say over what goes into their block.
• It’s a bit “later” than the builder’s, but more reliable.

Today, preconfs are not part of the official protocol. They’re still in the research and testing phase within the Ethereum community.

• Several designs have been proposed in Ethereum Research forums.
• Some teams are already experimenting with “preconf markets” and compatible relays.
• Their adoption depends on integrating economic mechanisms (slashing/restaking) that are still under development.
• There’s no fixed launch date yet, but the expectation is they will roll out in test environments first and gradually integrate into the mainnet.

In other words: it’s not something you’ll use today when sending an Ethereum transaction, but it is one of the key features shaping the future of the network’s user experience.

At Stakely, we’re already preparing our infrastructure to support this future. We’ve done so by adapting our infrastructure for Commit-Boost, the evolution of MEV-Boost designed to enable preconfirmations, inclusion lists, and more. Discover [here] how Commit-Boost works and why we’ve adopted it!