# Introduction **Kairos: Arbitrum Timeboost Integration** *Brought to you by Gattaca, creators of Titan Builder and Titan Relay.* **Kairos** is a native integration with **Arbitrum Timeboost** that offers a streamlined path for searchers and other participants to access express-lane blockspace—without directly engaging in each round-level Timeboost auction. Through the Kairos API, users can submit express-lane transactions and bundles with ease, gaining prioritized access and reducing both latency and operational complexity. **Key Advantages** * **Guaranteed Priority**\ Eliminate the 200ms auction delay. Express-lane transactions are submitted ahead of standard first-come-first-serve (FCFS) traffic, ensuring consistent priority. * **Minimal Integration Overhead**\ Leverage a familiar, well-documented RPC interface. Kairos closely mirrors standard Ethereum workflows, requiring minimal adjustments. * **Efficient Cost Model**\ Avoid the upfront expense of reserving blockspace for 60 seconds. With Kairos, you only pay on a per-transaction basis—and only when your transaction is successfully included. * **Full Ethereum Bundle Compatibility**\ Continue using standard builder features such as bundle atomicity, revert guarantees, cancellation support, and refund mechanisms. *** For searchers already familiar with Ethereum builder APIs, integrating with Kairos will be a seamless experience. The system is optimized for ease of adoption, operational efficiency, and predictable performance within Arbitrum's Timeboost ecosystem. # A Quick Overview of Timeboost ### Overview Arbitrum has introduced **Timeboost**, an optional transaction ordering mechanism that augments the default First-Come, First-Served (FCFS) policy with a **sealed-bid second-price auction** for **express-lane rights**. This mechanism provides successful bidders with prioritized access to blockspace by bypassing an artificial delay applied to standard transactions. **Artificial Delay Mechanism** In Timeboost, all transactions submitted to Arbitrum’s sequencer are subject to a **200ms artificial delay** before they are eligible for inclusion—except for those sent by the **express-lane token holder**. This delay functions as a "latency equalizer," ensuring that transaction ordering is no longer dictated solely by raw network latency. **Express Lane Auction Structure** * **Round Duration**\ Timeboost operates in **60-second rounds**. Each round grants exclusive express-lane access to a single address, referred to as the **round winner**. * **Lane Control Rights**\ The winning bidder may designate any address to act on their behalf for that round. This control can be **delegated, sub-leased, or transferred**. Gattaca leverages this capability by bidding for round access and redistributing express-lane privileges to searchers via an internal sub-auction. * **Transaction Wrapping**\ When a searcher submits a transaction to Gattaca for express-lane inclusion, we automatically **wrap the transaction in the express-lane format** and **sign it using the authorized token holder’s credentials**. This signals to the Arbitrum sequencer that the transaction is exempt from the 200ms delay and should be prioritized accordingly. # 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. ```solidity 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"); } } ``` # JSON-RPC Endpoints # Submission API Unlike on Ethereum mainnet, Kairos is not the block builder on Arbitrum. As such, we cannot extract builder payments implicitly. To ensure proper compensation and inclusion, submissions must explicitly transfer ETH within the transaction or bundle payload to the following address: `0x60E6a31591392f926e627ED871e670C3e81f1AB8` # timeboost\_sendTransaction ### Request Body ```bison { "jsonrpc": "2.0", "id": "1", "method": "timeboost_sendTransaction", "params": [ { // String // Signed EIP-2718 rlp encoded tx hex. tx } ] }‍ ``` ### **CURL Example** ```bash curl -s \ -X POST \ -H "Content-Type: application/json" \ --data '{ "jsonrpc": "2.0", "id": "1", "method": "timeboost_sendTransaction", "params": [ { "tx": "0x12…ab" } ] }' \ https://rpc.kairos-timeboost.xyz ``` ### ‍**Response Example** ```json { "jsonrpc": "2.0", "id": 1, "result": { "id": "f278b3a2-004e-48dd-859a-2021e46776ee", "express_lane_controller": true } } ``` `express_lane_controller` is `true` if Kairos currently controls the express lane. # timeboost\_sendBundle ### Request Body ```json { "jsonrpc": "2.0", "id": 1, "method": "timeboost_sendBundle", "params": [ { // Array[String] // A list of signed transactions to execute in an atomic bundle, // list can be empty for bundle cancellations. txs, // Array[String] // A list of sequencer transactions (rlp encoded bytes) for Kairos to simulate ahead of your bundle. pendingTxs, // (Optional) Array[String] // A list of tx hashes that are allowed to revert or be discarded. revertingTxHashes, // (Optional) String // Any arbitrary string that can be used to replace or cancel this bundle. replacementUuid, } ] } ``` ### Pending Transactions Searchers may send bundles that depend on changes in the sequencer feed state that Kairos has not fully processed, causing bundles to revert during simulation. To avoid this, transactions can be added to the `pendingTxs` field and will be applied on top of local state before bundle simulation. If Kairos has already processed these transactions, they are simply ignored and the bundle is simulated as normal. ### **CURL Example** ```bash curl -X POST \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "timeboost_sendBundle", "params": [ { "txs": [ "0x123456", "0x123456" ], "pendingTxs": [ "0x123456" ] } ], "id": 1 }' \ https://rpc.kairos-timeboost.xyz ``` ### ‍**Response Example** Result will contain the internally generated uuid, which can be used to query the [Stats API](/json-rpc-endpoints/stats-apis/timeboost_getorderinfo) ```json { "jsonrpc": "2.0", "id": 1, "result": { "id": "f278b3a2-004e-48dd-859a-2021e46776ee", "express_lane_controller": true } } ``` `express_lane_controller` is `true` if Kairos currently controls the express lane. # eth\_sendRawTransaction ### We also support the standard `eth_sendRawTransaction` method. For more details on using `eth_sendRawTransaction`, please refer to the [Ethereum JSON-RPC documentation](https://ethereum.org/en/developers/docs/apis/json-rpc/). ### Request Body ```json { "jsonrpc": "2.0", "id": "1", "method": "eth_sendRawTransaction", "params": [ // String // Signed EIP-2718 rlp encoded tx hex. tx ] }‍ ``` ### **CURL Example** ```bash curl -s \ -X POST \ -H "Content-Type: application/json" \ --data '{ "jsonrpc": "2.0", "id": "1", "method": "eth_sendRawTransaction", "params": ["0x12…ab"] }' \ https://rpc.kairos-timeboost.xyz ``` ### ‍**Response Example** ```json { "jsonrpc": "2.0", "id":1, "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" } ``` # Stats APIs # timeboost\_getOrderInfo Use this endpoint to trace a transaction/bundle based on a UUID. A UUID is returned in the response when a transaction/bundle is submitted. This UUID can then be used to query detailed information about the specific submission. ### Request Body ```json { "jsonrpc": "2.0", "id": 1, "method": "timeboost_getOrderInfo", "params": [ // [String] The order's UUID, returned upon successful submission. "123e4567-e89b-12d3-a456-426614174000", ] } ``` ### CURL Example ```bash curl -X POST \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "timeboost_getOrderInfo", "params": ["123e4567-e89b-12d3-a456-426614174000"], "id": 1 }' \ https://rpc.kairos-timeboost.xyz ``` ### Response Fields ```c /// The id returned when submitting the tx/bundle. uuid: String, /// Type of payload submitted: `0` for a transaction, `1` for a bundle. payload_type: Integer, /// The hash of the transaction. Only applicable for single transaction payloads. tx_hash: String, /// The Ethereum address of the transaction sender. sender: String, /// Timestamp (UTC) when the order was received by the RPC server. recv_ts: String, /// Contains an error message if the submitted order was malformed or invalid. order_validation: String, /// The Timeboost round number active when the order was processed. round: Integer, /// `true` if the transaction was successfully simulated. sim_status: bool, /// The type of simulation performed (e.g., "tob" for top-of-block, "seq" for sequence simulation). sim_type: String, /// Contains the error message from a failed simulation. sim_result: String, /// The hash of the specific transaction that failed during a bundle simulation. sim_tx_hash: String, /// `true` if the transaction reverted during simulation. reverted: bool, /// Estimated payment calculated from the initial top-of-block simulation. payment_initial_sim: String, /// Estimated payment calculated from the final sequence simulation. payment_block_sim: String, /// **DEPRECATED**: This field is obsolete and will be removed. Avoid using it. cutoff_ms: Integer, /// The 0-based index of this order within the constructed sequence. pos_in_sequence: Integer, /// `true` if the order was included in a sequence sent to the builder. sent_to_sequencer: bool, /// The sequence number this order was associated with when sent. seq: Integer, /// Timestamp (UTC) when the sequence was sent to the builder. seq_ts: String, /// `true` if Kairos controlled the Expresslane when this order was processed. express_lane_controller: bool, /// The HTTP status code received from the builder after submission. express_lane_status_code: Integer, /// The reason phrase or error message from the builder's HTTP response. express_lane_reason: String, /// Timestamp (UTC) of the reply from the builder. express_lane_reply_ts: String, /// The block number where this transaction was mined. Populated once confirmed. mined_block_number: Integer, ``` ### ‍**Response Example** #### Successfully Sent to Express Lane ```json { "jsonrpc": "2.0", "id": 1, "result": { "uuid": "3213f42a-6da3-44ea-9d71-55ca5affea45", "payload_type": 0, "tx_hash": "d0845898d06c783c8251e98b5678e78355f3cbe7456ded481c4fd57892ed8dd5", "sender": "2798a73dd32a2eafe849825a4b515ae5187eda29", "recv_ts": "2025-11-12T09:57:30.293Z", "order_validation": "", "round": 584524, "sim_status": true, "sim_type": "", "sim_result": "", "sim_tx_hash": "", "reverted": false, "payment_initial_sim": "13", "payment_block_sim": "13", "cutoff_ms": 1762941450293, "pos_in_sequence": 0, "sent_to_sequencer": true, "seq": 0, "seq_ts": "2025-11-12T09:57:30.296+00:00", "express_lane_controller": true, "express_lane_status_code": 200, "express_lane_reason": "", "express_lane_reply_ts": "2025-11-12T09:57:30.321Z", "mined_block_number": 214418215 } } ``` #### Failed Bundle Simulation ```json { "jsonrpc": "2.0", "id": 1, "result": { "uuid": "d06d7885-f9ff-4984-8481-b59b2aa48db2", "payload_type": 0, "tx_hash": "993a7cdff9bcc0f1b15b6ef559a44d64c48da04d47618c96f03865cda8cecca4", "sender": "3333a73dd32a2eafe849825a4b515ae5187eda42", "recv_ts": "2025-11-13T10:44:22.188Z", "order_validation": "", "round": 586011, "sim_status": false, "sim_type": "block_sim", "sim_result": "{"err_type":"evm_error","err_txt":"nonce too low: address 0x3333A73dd32A2eafE849825a4b515aE5187eDA42, tx: 419453 state: 419454"}", "sim_tx_hash": "993a7cdff9bcc0f1b15b6ef559a44d64c48da04d47618c96f03865cda8cecca4", "reverted": false, "payment_initial_sim": "13", "payment_block_sim": "0", "cutoff_ms": 1763030662188, "pos_in_sequence": 1, "sent_to_sequencer": false, "seq": 0, "seq_ts": "", "express_lane_controller": true, "express_lane_status_code": 0, "express_lane_reason": "", "express_lane_reply_ts": "1970-01-01T00:00:00Z", "mined_block_number": null } } ``` If the uuid is not found, response will be: `{"jsonrpc":"2.0","id":1,"result":null}.` # timeboost\_getRoundSequence This endpoint returns the hashes of all transactions that were submitted to the express lane for a specific round, along with their sequence numbers. ### Request Body ```json { "jsonrpc": "2.0", "id": 1, "method": "timeboost_getRoundSequence", "params": [ // [Integer] The starting round number (must be a Kairos-controlled round). 1234, ] } ``` ### CURL Example ```bash curl -X POST \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "timeboost_getRoundSequence", "params": [1234], "id": 1 }' \ https://rpc.kairos-timeboost.xyz ``` ### ‍**Response Example** ```json { "jsonrpc": "2.0", "id": 1, "result": [ "0x..1", "0x..2", "0x..3", "0x..4", "0x..5", "0x..6" ] } ``` # timeboost\_getAuctionWinnerByRound (Deprecated) {% hint style="danger" %} **Deprecation Notice** These endpoints are deprecated and is removed. Please migrate to the new **Auction Stream API** to ensure continued functionality. [View the Auction Stream Documentation](/auction-stream) {% endhint %} This endpoint returns the status of the current or specified Timeboost round, including its start and end timestamps. Use this endpoint to determine whether Kairos is the express-lane signer for a given round. If Kairos is not the signer, we will not be running a sub-auction for that round, and express-lane access via Kairos will be unavailable. ### Sample Request by Round ```json { "jsonrpc": "2.0", "id": 1, "method": "timeboost_getAuctionWinnerByRound", "params": [ // [Integer] Specific round you want to find out if we are the winner for. 1234, ] } ``` ### Sample Request by Timestamp ```bison { "jsonrpc": "2.0", "id": 1, "method": "timeboost_getAuctionWinnerByTs", "params": [ // [Integer] UTC timestamp since the epoch. 1761238476, ] } ``` ### CURL Example ```json curl -X POST \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "timeboost_getAuctionWinnerByRound", "params": [121212], "id": 1 }' \ https://rpc.kairos-timeboost.xyz/stats ``` ### **Response Example** ```json { "jsonrpc": "2.0", "id": 1, "result": { // Requested round stats "current_winner": "", "current_round": 121212, "current_round_start_timestamp": "2025-01-27 19:51:34 UTC", "current_round_end_timestamp": "2025-01-27 19:52:34 UTC", // Optional next round stats "next_winner": "", "next_round_start_timestamp": "2025-01-27 19:52:53 UTC", "next_round_end_timestamp": "2025-01-27 19:53:53 UTC" } } ``` We will know the next round winner 15 seconds before the round starts as that's when the auction ends. So for the final 15s of a round you will see both current\_winner and next\_winner added. # Parallel Kairos Lanes ### Overview Parallel 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. Additional headers are required to authenticate and declare your payment | Header | Description | | ------------------ | ------------------------------------ | | `X-Kairos-Payment` | Your Kairos bid amount in wei. | | `X-Api-Key` | API key provided by the Kairos team. | #### Method: `eth_sendRawTransaction` **Endpoint:** `https://optimistic-rpc.kairos-timeboost.xyz` **Request** ``` curl https://optimistic-rpc.kairos-timeboost.xyz \ -X POST \ -H "Content-Type: application/json" \ -H "X-Kairos-Payment: " \ -H "X-Api-Key: " \ --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. ### Websocket API Specification Searchers who prefer to use websocket for submissions can use the following example. Main difference between HTTP submissions is that the `Payment` value must be added to the payload vs beign set in the header. ``` import asyncio import json import websockets HOST = "optimistic-rpc.kairos-timeboost.xyz" API_KEY = PAYMENT = 1000 WS_URL = f"ws://{HOST}/ws" VALID_TX = "0xabcd" HEADERS = {"x-api-key": API_KEY} def rpc(tx, payment=PAYMENT, id=1): return json.dumps({"jsonrpc": "2.0", "method": "eth_sendRawTransaction", "params": {"tx": tx, "payment": payment}, "id": id}) async def send_test_txs(): async with websockets.connect(WS_URL, extra_headers=HEADERS) as ws: for i in range(3): await ws.send(rpc(VALID_TX, id=i)) resp = json.loads(await ws.recv()) print("Got Resp", resp) assert "result" in resp and resp["result"].startswith("0x"), f"Unexpected response: {resp}" print("PASS: multiple txs on same connection") asyncio.run(send_test_txs()) ``` #### (BETA) Method: `eth_sendBundle` \* **Endpoint:** `https://optimistic-rpc.kairos-timeboost.xyz` **Request** ``` curl -X POST https://optimistic-rpc.kairos-timeboost.xyz \ -H "Content-Type: application/json" \ -H "X-Api-Key: " \ -H "x-kairos-payment: " \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "eth_sendBundle", "params": [ { "txs": [ "0xf86c...", "0xf86d..." ] } ] }' ``` **Response** A `200` status code confirms the bundle was accepted with the bundle hash returned. BundleHash algorithm 
keccak256(concat(tx_hashes))
\*Note : The ordering of Bundle Txs landed onchain are best effort as the seqeuncer does not accept Bundle submissions. [^1]: # Auction Stream This WebSocket stream emits an event whenever Kairos secures the winning bid for the upcoming Timeboost round. ### WSCAT Example ```bash wscat -c wss://rpc.kairos-timeboost.xyz/ws/auction_events ``` ### Sample Response {% code fullWidth="false" %} ```json { "round_number": 282555, "start_ts_ms": 1744823300000, "end_ts_ms": 1744823359000 } ``` {% endcode %} Note: You may receive up to two events upon connection: one for the current, active round and another for the next scheduled round. # Resources & Endpoints ### Base URLs for JSON-RPC Endpoints #### Mainnet: * Over Http: [`https://rpc.kairos-timeboost.xyz`](https://rpc-sepolia.kairos-timeboost.xyz/stats) * Over Websocket: [`wss://rpc.kairos-timeboost.xyz`](https://rpc-sepolia.kairos-timeboost.xyz/stats) * Rate Limit: 50 requests per second #### Sepolia Testnet: * Over Http: [`https://rpc-sepolia.kairos-timeboost.xyz/`](https://rpc-sepolia.kairos-timeboost.xyz/) * Over Websocket: [`wss://rpc-sepolia.kairos-timeboost.xyz/`](https://rpc-sepolia.kairos-timeboost.xyz/) #### Payment Address * `0x60E6a31591392f926e627ED871e670C3e81f1AB8`