Summary

Pre-confirmations (preconfs) allow proposers to commit to specific execution outcomes before the block is produced, giving users near-instant confirmation of transaction results. Two distinct approaches exist: inclusion preconfs (commit to including a transaction) and outcome preconfs (commit to a specific execution result). The BAL-based (Block-Level Access List) approach enables outcome preconfs that can be verified without downloading the full block, using BAL witnesses as compact proofs.

Pre-Confirmation Types

Inclusion Pre-Confirmations

  • Proposer commits: “I will include transaction T in my block”
  • User gets certainty their transaction will be executed, but not what the execution result will be
  • Simpler to implement; suitable for simple transfers
  • Used by: mev-commit (ETHGas), relay-based preconf systems

Outcome Pre-Confirmations

  • Proposer commits: “Transaction T will execute and produce result R in my block”
  • User gets certainty about the final state change (token balance, contract state, etc.)
  • More complex: requires the proposer to commit to a full execution trace
  • Suitable for: DeFi trades, complex contract interactions where the outcome (not just inclusion) matters

BAL-Based Outcome Pre-Confirmations

The key insight from the 2026 research: Block-Level Access Lists (BALs) provide a compact representation of all state changes in a block. An outcome preconf can be expressed as:

Preconf commitment: "Transaction T will execute with 
  reads: {state_key_A: value_X, state_key_B: value_Y}
  writes: {state_key_C: value_Z}"

This commitment can be verified without downloading the full block by:

  1. Proposer commits to a BAL Merkle root
  2. User queries for a BAL witness — a Merkle proof of the specific transaction’s reads/writes in the BAL
  3. User verifies: does the committed BAL root match the claimed reads/writes for transaction T?

This makes outcome preconf verification gas-efficient and light-client compatible.

FOL: First-Order Logic for Preconf Conditions

The research introduces FOL (First-Order Logic) constraint language for expressing preconf conditions:

PreconfCondition = {
  tx_hash: Hash,
  block_constraint: Formula,  // FOL formula over block properties
  validity: ValidationFn      // how to verify the condition was met
}

// Example: "My tx is included AND the ETH price oracle is above $2000"
condition = (included(tx) AND oracle_price("ETH/USD") > 2000)

Uniform verifier: a single on-chain contract that can verify any FOL condition against a committed BAL root. This enables:

  • Proposers to commit to any condition expressible in FOL
  • Anyone to verify the condition was met using BAL witnesses
  • No per-condition smart contract deployment needed

The BAL + ePBS Integration

Under ePBS (EIP-7732):

  1. The builder commits to a payload hash at ~4s into the slot
  2. The BAL (attached to the block) is part of the committed payload
  3. The proposer can verify the BAL commitment without seeing the full payload
  4. Pre-confirmations can reference the BAL root rather than requiring full block download

No relay needed post-ePBS: today, preconfs require relay integration because the relay holds the block body. Under ePBS, the protocol-level commit-reveal makes relay preconf integration unnecessary.

Relay-Based Inclusion Preconfs (Current)

Before ePBS, the cleanest path for preconfs:

mev-commit (ETHGas):

  • Proposers opt in to the mev-commit network
  • Users submit transactions to mev-commit nodes
  • mev-commit relays process the transactions and provide inclusion commitments
  • If the commitment is violated, collateral is slashed

Relay block merging path (discussed at Cannes workshop):

  • Relay can append pre-confirmed transactions to the winning block
  • If the winning builder didn’t include the pre-confirmed tx, relay appends it
  • Cold-start problem eliminated: 3-5 relays adopting merging → all their blocks support preconfs
  • No builder integration required

Preconf Use Cases

Use casePreconf typeLatency needWhy it matters
L1→L2 bridge depositInclusion~13 seconds (FCR)Reduce bridge wait from 20 min
DeFi trade executionOutcome~1 secondCertainty on trade result for complex strategies
Game state updateOutcome<1 secondInteractive applications
Payment confirmationInclusion~1 secondMerchant payment UX
Liquidation botsOutcome~100msNeed to know if liquidation succeeds before gas cost

Constraint Sharing for Pre-Confirmations

At the Cannes workshop (Apr 2026), constraint sharing was identified as something relays can safely share:

  • Pre-confirmation commitments are constraints on block content
  • Relays can share constraints with each other at slot start without affecting auction dynamics (the constraint doesn’t reveal MEV-sensitive information)
  • This allows multiple relays to honor the same preconf commitment even if the winning block comes from one relay and the pre-confirmed tx was submitted via another

Open Questions

  • Should the BAL root be included in the ePBS commitment? (Currently the commitment is just to payload_hash, not BAL root)
  • How does FOL constraint verification interact with the gas limit? (Complex conditions may be expensive to verify on-chain)
  • Who bears the cost of BAL witness generation? (Proposer, user, or relay?)
  • Can outcome preconfs be made slashable if a proposer commits to an execution outcome that doesn’t materialize?

Key Sources

  • Outcome Preconfs: Verifying Block Commitments Without the Block (2026) — BAL-based preconfs; FOL constraint language; uniform verifier
  • What Emerged from the Blockspace Forum Workshop in Cannes (Apr 2026) — constraint sharing; relay merging enabling preconfs; mev-commit integration