Pre-Confirmation

A soft commitment is a signed promise from a block builder or validator about a transaction's inclusion and ordering in the next block. It provides a probabilistic guarantee, as it relies on the signer's reputation and economic stake. If the signer reneges, they face slashing penalties or loss of future revenue. This is the most common and lightweight form of pre-confirmation.

A hard commitment provides a cryptographic guarantee of execution. It often involves the block builder posting a bond or collateral that is automatically slashed if the promised outcome is not delivered. This creates a strong cryptoeconomic security model, making the pre-confirmation as secure as the underlying blockchain's consensus for finalizing the slashing condition.

This advanced feature allows a user to receive not just a promise of inclusion, but a cryptographic proof (like a state root or a Merkle proof) that their transaction will result in a specific state change. This proves the transaction's deterministic outcome given the current mempool and pending block, protecting against maximal extractable value (MEV) theft and failed transactions.

Pre-confirmations can guarantee that a bundle of transactions is executed atomically (all-or-nothing) and in a specific order. This is critical for:

• DeFi arbitrage: Protecting multi-step trades from being front-run.
• Liquidations: Ensuring a liquidation transaction and its profit-taking follow-on trade are inseparable.
• Bridge operations: Securing the sequence of lock-and-mint or burn-and-release actions.

The most secure type of pre-confirmation, where a zero-knowledge proof (ZK-proof) is generated to attest to a transaction's validity and its resulting state change. This allows users to trust the outcome without trusting the prover. The proof can be verified on-chain later, ensuring the builder cannot lie without detection. This is a frontier research area combining ZK-Rollup technology with pre-confirmation services.

A core feature is the maximum latency guarantee, which promises the transaction will be included on-chain within a specified time window (e.g., "next block" or "within 2 seconds"). This transforms the user experience from uncertain waiting to predictable settlement, enabling real-time applications. Failure to meet the deadline typically triggers a refund of any pre-confirmation fee or a slashing penalty.

Pre-confirmations are used to protect users from Maximum Extractable Value (MEV) attacks like front-running and sandwich attacks. A service provider (e.g., a builder or searcher) can cryptographically guarantee a user's transaction will be included in a specific position within a block, shielding them from predatory bots. This is critical for DEX swaps and large liquidations.

• Example: A trader swapping ETH for USDC receives a signed promise their swap will not be front-run, ensuring a predictable price.

Applications requiring sub-second finality, such as perpetual futures exchanges or on-chain gaming, use pre-confirmations to simulate and lock in a transaction's outcome instantly. This creates a user experience comparable to centralized systems while maintaining blockchain settlement.

• Example: A trading dApp shows a "trade confirmed" message the moment the user clicks, using a pre-confirmation from a trusted builder, with on-chain settlement following seconds later.

Searchers and block builders use pre-confirmations to coordinate atomic arbitrage opportunities across multiple decentralized exchanges. They bundle several transactions into a single, profitable unit and obtain a pre-confirmation from a validator to guarantee the entire bundle is executed atomically (all succeed or all fail).

• Mechanism: The builder signs a commitment to include the profitable bundle, allowing the searcher to execute the complex trade without risk of partial failure.

Pre-confirmations enhance the security of fast withdrawal bridges and cross-chain messaging. A relayer can provide a signed attestation that funds are locked on the source chain, allowing the destination chain to release funds immediately, with the full settlement finalized later. This reduces the custodial risk window.

• Example: A user bridging USDC from Ethereum to Arbitrum receives funds in seconds based on a validator's pre-confirmation, rather than waiting for the full challenge period.

Wallets and RPC providers integrate pre-confirmation services to give users immediate feedback. When a user submits a transaction, the provider can return a simulation result and a soft guarantee of inclusion, reducing uncertainty and failed transaction fees.

• Key Feature: Shows users an accurate gas estimate and likelihood of success before they sign, based on real-time mempool data and builder commitments.

Pre-confirmations are a key component of order flow auctions. Users or wallets sell their transaction order flow to a builder network. The winning builder pays for the right to execute the transaction and provides a pre-confirmation back to the user, sharing the MEV profits.

• Economic Model: This creates a market where users are compensated for their order flow, and builders compete to provide the best execution and guarantees.

A decentralized, challenge-based model that uses economic security instead of a central operator.

• How it works: A network of attesters signs promises. If they renege, their staked bond is slashed.
• Key Guarantee: Security derives from the cryptoeconomic cost of breaking the promise.
• Trade-off: Introduces a challenge period (e.g., 5 minutes) before the pre-confirmation is final, making it slower than fast lanes but more decentralized.

Pre-confirmations are natively integrated into the role of the block builder, especially in Proposer-Builder Separation (PBS) architectures.

• Direct Relationship: The entity providing the pre-confirmation is the same entity building the next block, eliminating intermediary risk.
• Efficiency: Allows for optimal order flow auction (OFA) mechanics, where users can bid for priority directly with the builder.
• Ecosystem Impact: This model aligns incentives and is a core component of MEV supply chain redesign.

DApps and protocols implement their own pre-confirmation logic for critical user actions, often using a combination of the above models.

• Use Case: A decentralized exchange (DEX) guaranteeing a user's swap execution at a quoted price before the transaction is mined.
• Mechanism: The DEX's backend may interact with a fast lane service on behalf of the user or run its own attester network.
• Example: A lending protocol providing an instant, pre-confirmed liquidation to protect solvency.

The core risk is the potential for a searcher (who provides the pre-confirmation) and a block builder (who creates the block) to collude. If they are not the same entity, the builder could ignore the searcher's promised transaction, causing the pre-confirmation to fail. This risk is mitigated by reputation systems and financial penalties (slashing) for dishonest actors.

• Example: A searcher guarantees inclusion, but the builder is bribed by a competing transaction and omits it, causing a front-running or sandwich attack on the user.

Pre-confirmations have a strict time-to-live (TTL). An attacker can exploit network latency or launch a liveness attack against the searcher or relay to delay block propagation, causing the guaranteed transaction to expire before it can be included. This is a form of Denial-of-Service (DoS) against the pre-confirmation service itself.

• Result: The user's transaction fails, potentially missing a critical DeFi deadline or losing a profitable arbitrage opportunity, despite having a prior guarantee.

Most pre-confirmation models rely on the searcher posting a bond or stake that can be slashed for misbehavior. The security of the guarantee is only as strong as the economic backing.

• Key Questions: Is the bond sufficient to cover all outstanding guarantees? Can the searcher's capital be liquidated quickly in case of default? A solvency crisis in the searcher network would render all pre-confirmations worthless, similar to risks in some cross-chain bridges.

Pre-confirmations for complex DeFi transactions (e.g., liquidations, arbitrage) often depend on external price oracles and state data. An attacker could manipulate these data feeds after the pre-confirmation is signed but before on-chain execution.

• Scenario: A pre-confirmed liquidation becomes unprofitable due to a manipulated price, but the searcher is forced to execute it anyway to avoid slashing, incurring a loss. This transfers oracle risk to the service provider.

While blockchains are decentralized, pre-confirmation services often centralize trust in a small set of high-reputation searchers or a specific relay network. Users must trust these intermediaries, creating a trusted third-party risk that contradicts blockchain's permissionless ethos.

• Systemic Risk: The failure or censorship by a dominant pre-confirmation provider could fragment liquidity and user experience, similar to reliance on major MEV relays.

A critical distinction is the type of guarantee. Most pre-confirmations are cryptoeconomic contracts enforced by slashing, not cryptographic proofs.

• Cryptoeconomic: Violation leads to penalty claims, which require dispute resolution and claim periods. Funds may not be recoverable instantly.
• Cryptographic: (e.g., using ZK proofs of transaction inclusion) would be unconditional but is currently impractical. Users must audit the smart contracts and governance managing the searcher bonds.

The mempool (memory pool) is a network node's holding area for broadcasted transactions that are pending confirmation. It is the source from which builders select transactions for block inclusion. Pre-confirmation services often monitor and interact directly with private or public mempools to assess transaction priority and potential front-running risks.

A block builder is an entity that constructs a block's contents by selecting and ordering transactions from the mempool. In Proposer-Builder Separation (PBS) architectures, builders compete to create the most valuable block for validators. Pre-confirmation services often establish direct relationships with builders to secure a guaranteed slot for a transaction, providing a stronger commitment than the public mempool.

MEV refers to the profit that can be extracted by reordering, including, or censoring transactions within a block. Pre-confirmations are a critical tool for MEV protection, offering users a cryptographic guarantee that their transaction will be included as-is, shielding them from harmful sandwich attacks or arbitrage extraction that occurs during public mempool latency.

The Flashbots Auction is a sealed-bid, first-price auction mechanism designed to democratize access to MEV. Builders submit bundles of transactions directly to validators via a private channel. This system creates a private mempool, which is the foundational infrastructure many pre-confirmation services use to offer enforceable commitments, moving transactions away from the vulnerable public domain.

Time-boost is a specific pre-confirmation mechanism, notably implemented by EigenLayer, that uses a cryptographic commit-reveal scheme. Users commit to a transaction with a fee, and builders compete to include it. If the builder wins the block auction, the transaction is revealed and executed. This prevents transaction theft while still allowing for efficient MEV market competition.

A soft confirmation is a probabilistic guarantee of inclusion, often based on a high likelihood from a reputable builder or a staked bond. It is less cryptographically secure than a hard confirmation backed by signed commitments or ZK proofs. The distinction lies in the enforceability; a soft confirmation may offer a refund if it fails, but cannot prove malicious exclusion on-chain.