Parallel Kairos Lanes

Overview

Fast Lanes are a set of new pipelines for Kairos that provide more consistent priority over non-timeboosted flow.

There are two components:

1. Dedicated CEX/DEX Lanes Isolated pipelines for high-volume CEX/DEX arbitrage searchers with dedicated compute and network resources.

2. Kairos Optimistic Mode A short-term optimisation that uses an optimistic payment mechanism to bypass the Kairos simulation step, while still participating in the standard Kairos sub-slot auction.

Dedicated CEX/DEX Lanes

Latency requirements for CEX/DEX arbitrage are different to dex-led arbs. CEX/DEX searchers operate on off-chain price signals from centralized exchanges rather than reacting to on-chain activity, so they need to get transactions on-chain as fast as possible in response to external price movements. We run this lane parallel to the Kairos sub-slot auctions.

Kairos Optimistic Mode

Motivation

Our standard Kairos sub-auction simulates orders at the bottom of the latest Block Stream block. We have found that 1. waiting for the Block Stream block and 2. simulating that block before trialling simulations for new orders introduces a lot of latency variance that is often causing orders sent through Kairos to lose their priority edge over non-timeboosted flow.

As a short-term optimisation while we improve simulation performance, we're introducing a permissioned optimistic submission mode for Kairos.

How It Works

1. You submit a transaction to the Kairos optimistic endpoint with an X-Kairos-Payment header specifying your bid in wei.

2. This optimistic payment mechanism means we trust the declared header value upfront, allowing your transaction to bypass the slow simulation queue and immediately go to the ordering phase of the Kairos auction.

3. Your transaction still flows through the same Kairos sub-slot auction as standard submissions, with the same payment model and ordering. At sub-slot close, we sort and compare results from both the optimistic and standard Kairos paths, then submit in optimal order.

4. Payment works exactly the same as standard Kairos. You must include an explicit ETH transfer to the Kairos payment address within your transaction. The X-Kairos-Payment header simply declares the expected amount so we can sort without simulation.

In tests, we have found this to be highly successful, achieving over 99% priority compared to non-timeboosted transactions.

As we bring standard Kairos simulation latency down, we expect to phase this out in favour of the fully permissionless Kairos auction.

Safeguards & Enforcement

Since the optimistic payment mechanism bypasses simulation, we verify compliance on-chain after inclusion:

• Payment check: If the transaction was successful (i.e., didn't revert or immediately return) the ETH amount transferred to the Kairos payment address must match or exceed the value declared in the X-Kairos-Payment header.

• Enforcement: If a transaction fails either check, the searcher's API key access is revoked.

API Specification

The API uses the standard Arbitrum JSON-RPC interface. An additional header is required to declare your payment:

Header	Description
X-Kairos-Payment	Your Kairos bid amount in wei.

Method: eth_sendRawTransaction

Endpoint: https://todo.kairos-timeboost.xyz

Request

curl https://todo.kairos-timeboost.xyz \
  -X POST \
  -H "Content-Type: application/json" \
  -H "X-Kairos-Payment: <amount-in-wei>" \
  --data '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "eth_sendRawTransaction",
    "params": ["0x..."]
  }'

Response

A 200 status code confirms the transaction was accepted for express-lane submission.

Payment

Payment works identically to standard Kairos. All transactions must include an explicit ETH transfer to the Kairos payment address within the transaction payload. The transfer amount must match or exceed the value declared in the X-Kairos-Payment header.

Important: Kairos optimistic mode only supports single transactions, not bundles. Searchers should ensure the Kairos payment is made at the end of their transaction, not as a separate transaction.

Transactions that do not include the declared payment will be flagged and may result in access revocation.