---
title: 'How Timeboost works'
sidebar_label: 'How Timeboost works'
description: 'Learn how Timeboost works and how it can benefit your Arbitrum-based project.'
author: leeederek
sme: leeederek
user_story: As a current or prospective Arbitrum user, I want to understand how Timeboost works and how to use it.
content_type: gentle-introduction
---

import { FlowChart } from '@site/src/components/InteractiveDiagrams/Timeboost/CentralizedAuction';

<a data-quicklook-from="timeboost">Arbitrum Timeboost</a> is a novel <a data-quicklook-from="transaction-ordering-policy">transaction ordering policy</a> for Arbitrum chains that enables chain owners to capture the Maximal Extractable Value (MEV) on their chain, reduce spam, and preserve fast block times, all while protecting users from harmful types of MEV, such as sandwich attacks and front-running.

Timeboost is the culmination of over a year of [research and development](https://arxiv.org/abs/2306.02179) by the team at Offchain Labs. It is currently live on Arbitrum One and Arbitrum Nova, and is available for Arbitrum chains, whose owners can adopt and customize it as they choose.

## Why do Arbitrum chains need Timeboost?

In the past, Arbitrum chains ordered incoming transactions on a <a data-quicklook-from='first-come-first-serve-fcfs'>"First-Come, First-Serve (FCFS)"</a> basis. This ordering policy is simple to understand and implement, enabling fast block times (starting at 250ms and down to 100ms if desired), and protecting users from harmful types of MEV, such as front-running & sandwich attacks.

However, there are a few downsides to an FCFS ordering policy. Under FCFS, searchers have incentives to participate in and attempt to win latency races by investing in offchain hardware. This "race" means that for searchers on Arbitrum chains, generating a profit from arbitrage and liquidation opportunities involves a lot of spam, placing stress on the chain infrastructure and contributing to congestion. Additionally, all captured MEV on an Arbitrum chain under FCFS is allocated to searchers, returning none of the available MEV to the chain owner or the applications on the chain.

## What is Timeboost

Timeboost retains most FCFS benefits while addressing FCFS limitations.

Timeboost is a _transaction ordering policy_. It's a set of rules that the [sequencer](/how-arbitrum-works/deep-dives/sequencer.mdx) of an Arbitrum chain is trusted to follow when ordering transactions submitted by users. In the near future, multiple sequencers will be able to enforce those rules with decentralized Timeboost.

For Arbitrum chains, the sequencer’s sole job is to take arriving, valid transactions from users, place them into an order dictated by the transaction ordering policy, and then publish the final sequence to a [real-time feed](/how-arbitrum-works/deep-dives/sequencer.mdx#real-time-sequencer-feed) and in compressed batches to the chain’s data availability layer. Before Timeboost, the transaction ordering policy was FCFS, and Timeboost is a modified FCFS ordering policy.

#### Timeboost preserves the great UX that Arbitrum chains are known for

- The default block time for Arbitrum chains continues to be industry-leading at 250ms, even with Timeboost. With Timeboost, some transactions not in the express lane may experience a delay to the next block.

#### With Timeboost, Arbitrum chains will continue to protect users from harmful types of MEV

- Timeboost only grants the auction winner a _temporary time advantage_—not the power to view or reorder incoming transactions or to be the first in every block. Furthermore, the transactions' mempool will continue to be private, which means users with Timeboost enabled will remain protected from harmful MEV-like front-running and sandwich attacks.

#### Timeboost unlocks a new value accrual path for chain owners

- Chain owners may use Timeboost to capture a portion of the available MEV on their chain that would have otherwise gone entirely to searchers. There are many flavors of this, too—including custom gas tokens and/or redistribution of these proceeds back to the applications and users on the chain.

#### Timeboost may help reduce spam and congestion on a network

- By introducing the ability to “purchase a time advantage” through the Timeboost auction, it is expected that rational, profit-seeking actors will spend on auctions _instead of_ investing in hardware or infrastructure to win latency races. We expect that this diversion of resources will reduce FCFS MEV-driven spam on the network.

### How does it work?

Timeboost uses three separate components that work together:

- **A special “express lane”** which allows valid transactions to be sequenced as soon as the sequencer receives them for a given round.
- **An offchain auction** to determine the controller of the express lane for a given round. This auction gets managed by an <a data-quicklook-from='autonomous-auctioneer'>autonomous auctioneer</a>.
- **An <a data-quicklook-from='auction-contract'>auction contract</a>** deployed on the target chain to serve as the canonical source of truth for the auction results and handling of auction proceeds.

To start, the default duration of a round is 60 seconds. Transactions not in the express lane will be subject to a default 200-millisecond artificial delay in their arrival timestamp before being sequenced, which means that some non-express lane transactions may be delayed to the next block. It’s important to note that the default Arbitrum block time will remain at 250 milliseconds (which can be adjusted to 100 milliseconds if desired). Let’s dive into how each of these components works.

### The express lane

<ImageZoom src="/img/timeboost-centralized-timeboost-express-lane-workflow.jpg" alt="using the express lane" className="img-900px" />

The express lane implementation uses a special endpoint on the sequencer, formally titled `timeboost_sendExpressLaneTransaction`. This endpoint is special because transactions submitted to it will be sequenced immediately by the sequencer, hence the name "express lane." The sequencer will only accept valid transaction payloads to this endpoint if they are signed correctly by the current round’s <a data-quicklook-from='express-lane-controller'>express lane controller</a>.

Transactions submitted to the sequencer normally will be considered non-express lane transactions and will, therefore, have their arrival timestamp delayed by 200 milliseconds. It is important to note that transactions from both the express and non-express lanes will eventually get sequenced into a single, ordered stream of transactions for the sequencer to post to a data availability layer (and for node operations to construct the chain's state then). The express lane controller does _not_:

- Have the right to reorder transactions.
- Have a guarantee that their transactions will always be first at the “top-of-the-block.”
- Guarantee a profit at all.

The value of the express lane will be the sum of how much MEV the express lane controller predicts they can extract during the upcoming round (i.e., MEV opportunity estimates made before the auction closes) _plus_ the amount of MEV extracted by the express lane controller while they are in control (that they otherwise did not predict). Understanding how the value of the express lane is determined can be useful for chain owners when adjusting to the artificial delay and the time before the auction closes.

### The Timeboost auction

Determining control of the express lane in each round (default: 60 seconds) happens by a per-round auction, which is a sealed-bid, second-price auction. This auction occurs to determine the express lane controller for the next round. In other words, determining the express lane controller can happen at any point in time in the previous auction round. Bids for the auction can be made with any **ERC-20** token, in any amount, and can be collected by any address—at the full discretion of the chain owner.

<FlowChart />

The auction for a round has a closing time that is `auctionClosingSeconds` (default: 15) seconds before the beginning of the round. This closing time means that, in the default parameters, parties have 45 seconds to submit bids before the auction will no longer accept bids. In the 15 seconds between when bidding is over and when the new round begins, the autonomous auctioneer will verify all bids, determine the winner, and make a call to the onchain auction contract to formally resolve the auction.

:::info Bid behavior

The autonomous auctioneer will consider only an address’s most recent bid, meaning that if you have placed a bid and wish to change it, you may resubmit a bid to “update it.” To cancel a bid, place a new bid that is significantly lower than your original bid or bid below the minimum reserve price. Remember that there is a maximum of five bids per round per address to mitigate DDoS risks.

:::

### Auction contract

Before placing a bid in the auction, a party must deposit funds into the `Auction` Contract. At any time, you can make a deposit or add additional funds to an existing deposit. These deposits are fully withdrawable, with a nominal delay (two rounds or two minutes by default), to prevent impacting the outcome of an existing round. There is no minimum deposit amount, but a starting minimum bid of 0.001 **WETH** (the default amount and token) is required, known as the "minimum reserve price".

The chain owner sets the minimum reserve price, which can be updated at any time up to 30 seconds (default) before the start of the next round, ensuring that auction participants always know the reserve price at least 30 seconds before they must submit their bids. A reserve price can also be set by the chain owner (or by an address designated by the chain owner) as a way to raise the minimum bid, as the `Auction` Contract enforces that the reserve price is never less than the minimum reserve price.

Once the autonomous auctioneer determines an auction winner, the `Auction` contract will deduct the second-highest bid amount from the account of the highest bidder and transfer those funds to a `beneficiary` account designated by the chain owner by default. The `expressLaneControllerAddress` specified in the highest bid will become the express lane controller for the round.

:::info Additional FAQs

For frequently asked questions refer to the [Timeboost FAQ](/how-arbitrum-works/timeboost/timeboost-faq.mdx).

:::
