Our Express Lane Sub-Auction

After successfully winning the Timeboost auction for a 60-second round, we hold the express lane token and can submit transactions to the Arbitrum sequencer with zero delay. We then sell the right to the express-lane in “sub-auctions” that finish inside ~100ms. This ensures that transactions arriving through us will be sequenced ahead of those that do not hold express lane rights.

High-Level Flow

1. Round Control: We win the current Timeboost round for a 60-second slot.

2. Sub-Auctions: Every ~100ms, we:

   1. Gather all received orders (transactions and bundles) since the last auction.

   2. Simulate them, compute expected profitability, and sort them (similar to Ethereum builder logic).

   3. Submit them to the sequencer’s express lane endpoint immediately.

Why Sub-Auctions Secure Priority

Imagine a typical scenario where an arbitrage opportunity arises at time t = 0. Two participants want to exploit it:

1. You (the searcher) submit your transaction through our sub-auction.

   1. Our auction collects, sorts, and finalises all received orders within approximately 100ms.

   2. Immediately after (say at t = 100ms), we send your transaction via the express lane, bypassing the 200ms speed bump.

   3. As long as our latency to the sequencer is under 100ms, the Arbitrum sequencer sees your transaction first—before any non-express-lane transactions.

2. Another user (not using our sub-auction) sends their transaction directly to the Arbitrum sequencer.

   1. Their submission is forced to wait the full 200ms.

   2. Even if their network latency to the sequencer is effectively zero, the mandatory speed bump means the earliest their transaction could be accepted is around t = 200ms.

   3. In practice, real searcher latency is always above 0ms, giving you even more of a buffer.

In this example, your total turnaround (auction time + our latency to the sequencer) is below 200ms , so your transaction is finalised and arrives before any competitor transaction. Essentially, you gain effective priority over the rest of the market as long as:

auction_time + kairos_to_sequencer_latency < 200ms + competitor_latency

Payment

Our system requires all express-lane submissions to pay us more than 0 ETH. Any order offering a zero payment is dropped.

• Sorting Logic: We prioritise transactions by the payment value included. Higher-paying transactions are placed earlier in our ordering.

• Single Contrast with Ethereum: On Ethereum, a block builder can set the block.coinbase to themselves. On Arbitrum, we are not the block builder. Therefore, priority fees or coinbase.transfer payments do not go to us automatically.

• Explicit Payment: You must explicity transfer ETH to our address at the end of your contract. This ensures we receive the fee for providing express lane access.

Below is a minimal example of a Solidity contract function that sends a payment (amount_to_send) to our address as part of the transaction logic.

pragma solidity ^0.8.19;

contract ExamplePayment {
    address constant KAIROS_ADDRESS = 0x60E6a31591392f926e627ED871e670C3e81f1AB8;

    function doArbAndPay() external payable {
        // 1. Perform your trading logic here

        // 2. Transfer to Kairos address to pay for express-lane slot
        (bool success, ) = KAIROS_ADDRESS.call{value: amount_to_pay}("");
        require(success, "Payment failed");
    }
}