Blockspace Pre-confirmations

Coming Soon — Pre-confirmations are currently in development and not yet available in production. The API and pricing below are subject to change.

Pre-confirmations will allow users and searchers to reserve blockspace before a block is built. The engine will provide cryptographic guarantees that a transaction will be included in a specific block, eliminating the uncertainty of the public mempool.

The Problem

In the standard transaction lifecycle, there is no guarantee that a submitted transaction will be included in the next block -- or any specific block. For time-sensitive operations (liquidations, arbitrage, auction bids), this uncertainty creates risk:

  • Transactions may be delayed by multiple blocks.
  • Gas price spikes can make execution unprofitable.
  • Competing transactions may frontrun the opportunity.

The Solution

Pre-confirmations solve this by establishing an agreement between the transaction sender and a block builder before the block is constructed.

Step 1: Request

The user submits a pre-confirmation request specifying the transaction, target block, and maximum fee they are willing to pay.

Step 2: Evaluation

The engine evaluates whether it can include the transaction in the target block given current blockspace demand and builder relationships.

Step 3: Commitment

If accepted, the engine returns a signed pre-confirmation receipt -- a cryptographic commitment that the transaction will be included in the specified block.

Step 4: Inclusion

The engine works with block builders to honor the commitment. If the commitment is broken (transaction not included), the user is compensated according to the SLA terms.

Standards

Pre-confirmations follow the EIP-7547 (Inclusion Lists) specification, which defines a standard interface for proposers to commit to transaction inclusion. The engine extends this with additional guarantees around ordering and execution.

API Endpoint

POST /v1/preconfirm

Request:

{
  "tx": "0xf86c0a8502540be400...",
  "target_block": 19482500,
  "max_fee_wei": "5000000000000000",
  "chain_id": 1,
  "deadline_ms": 2000
}
FieldTypeRequiredDescription
txstringyesSigned transaction bytes.
target_blockintyesBlock number for guaranteed inclusion.
max_fee_weistringyesMaximum fee the sender will pay for the guarantee.
chain_idintyesTarget chain ID.
deadline_msintnoTimeout for the pre-confirmation response (default 3000).

Response (accepted):

{
  "status": "accepted",
  "preconf_id": "pc_abc123...",
  "target_block": 19482500,
  "fee_wei": "3200000000000000",
  "receipt": "0x3045022100...",
  "expires_at": "2026-03-15T14:35:00Z"
}

Response (rejected):

{
  "status": "rejected",
  "reason": "blockspace_unavailable",
  "suggested_block": 19482501
}

Use Cases

  • Liquidations: Guarantee inclusion of a liquidation transaction before the position becomes insolvent.
  • Arbitrage: Lock in blockspace for an arbitrage bundle before the price discrepancy closes.
  • Auction bids: Ensure an on-chain auction bid is included before the auction deadline.
  • Time-locked operations: Guarantee execution of governance votes, option exercises, or vesting claims before expiry.

Pricing Tiers

TierGuaranteeFee MultiplierSLA Compensation
StandardBest-effort inclusion in target block.1.0x base feeNone
ExpressGuaranteed inclusion within +/- 1 block.2.5x base fee50% fee refund on miss
CriticalGuaranteed inclusion in exact target block.5.0x base fee100% fee refund + penalty on miss

Fees are deducted from the max_fee_wei specified in the request. If the actual fee is lower than the maximum, the difference is refunded.

Edit this page