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
}
| Field | Type | Required | Description |
|---|---|---|---|
tx | string | yes | Signed transaction bytes. |
target_block | int | yes | Block number for guaranteed inclusion. |
max_fee_wei | string | yes | Maximum fee the sender will pay for the guarantee. |
chain_id | int | yes | Target chain ID. |
deadline_ms | int | no | Timeout 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
| Tier | Guarantee | Fee Multiplier | SLA Compensation |
|---|---|---|---|
| Standard | Best-effort inclusion in target block. | 1.0x base fee | None |
| Express | Guaranteed inclusion within +/- 1 block. | 2.5x base fee | 50% fee refund on miss |
| Critical | Guaranteed inclusion in exact target block. | 5.0x base fee | 100% 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.