Skip to main content

Introduction to PGA (Priority Gas Auctions)

PGA is an ordering policy in which users bid for ordering by attaching a priority fee to each transaction. Ordering becomes a continuous, permissionless, per-transaction competition. PGA is now available for activation across all Arbitrum chains.

Why sunset Timeboost?​

Arbitrum One has used Timeboost since April 2025. Timeboost auctions off a 60-second "express lane" in a sealed-bid, second-price auction and falls back to first-come, first-served (FCFS) ordering for everything else. This policy served to reduce latency-race spam and create the first sequencing revenue stream for the Arbitrum DAO.

However, some design limitations became clear:

The barrier to entry is high: Participating in an ahead-of-time auction requires building custom tooling and forecasting MEV for an entire upcoming round.

It does not serve latency-sensitive applications well: Emerging DeFi primitives such as proprietary AMMs (propAMMs) need cheap, frequent, priority-ordered inclusion to keep onchain parameters fresh. An express lane held by a single controller for 60 seconds at a time is incompatible with these new AMMs.

What are PGA’s benefits?​

Familiar mechanics and a low barrier to entry​

Participants bid by setting maxPriorityFeePerGas on a standard EIP-1559 type 2 transaction. There is no auction to register for and no custom tooling to build. Anyone who already runs a searcher on another EVM chain can participate on day one.

Near-zero operational cost​

PGA adds no infrastructure to run. PGA is a Sequencer flag plus a round-count parameter.

Faster blocks under load​

The Sequencer issues each block as soon as it fills, rather than idling for the remainder of the block window. On a chain with B=250ms and K=2, this yields between 4 and 8 blocks per second: a minimum of 1/B and a maximum of K/B. Under heavy load, your chain confirms faster than its nominal block time.

PGA preserves the great UX that Arbitrum chains are known for​

The default block time for Arbitrum chains continues to be industry-leading at 250ms, and response times can be further reduced by adding 125ms PGA rounds.

PGA preserves Arbitrum's fast block times​

The nominal block time on Arbitrum One remains 250ms, with PGA rounds added at 125ms increments. Arbitrum chains can select the number of rounds based on their needs. On Arbitrum One, there are only 2 PGA rounds, which means that under heavy load, blocks that fill early are issued immediately so that the chain can produce up to 8 blocks per second.

PGA allows more participants to order competition​

Bidding happens per transaction, just-in-time, using a standard EIP-1559 field. There is no separate auction to register for, no ahead-of-time forecast to make. Searchers and applications can participate through tips.

PGA protects low-fee transactions from starvation​

Unlike Ethereum, a transaction doesn’t need to pay tips to get included, and paying no priority fee doesn't mean waiting indefinitely. An anti-starvation boost raises the effective ordering position of transactions left waiting after each round, so ordinary transactions are included within a small number of blocks. The boost changes position in the queue, never the fee actually charged.

The Sequencer includes transactions that pay no priority fee within a small number of blocks. PGA's anti-starvation boost raises the ordering position of every transaction still waiting at the end of each round. The boost changes position in the queue, never the fee charged on inclusion.

PGA maintains a value accrual path for chain owners​

Chain owners may use PGA to capture a portion of the available MEV on their chain that would have otherwise gone entirely to searchers. Priority fees are collected by the chain owner rather than accruing entirely to whoever captures MEV.

How PGA works​

PGA is a transaction ordering policy: a set of rules the Sequencer is trusted to follow when ordering transactions submitted by users. As with FCFS and Timeboost, the Sequencer's job is unchanged:

  1. Accept valid transactions
  2. Place them in an order dictated by the policy
  3. Publish the resulting sequence to a feed
  4. Publish transactions in compressed batches to the chain's data availability layer

With PGA, the priority fee determines transactions' order, evaluated in short ordering rounds that run multiple times per block. This ordering model should be familiar to users of other EVM chains (Base, OP Mainnet, and Unichain).

PGA uses three components that work together:

  • A two-stage mempool: an unordered waiting list that includes arriving transactions, and a priority queue keyed on each transaction's priority fee.

    • PGA rounds: short, fixed-length ordering rounds that can run multiple times per block. Each round promotes the waiting list into the priority queue and transfers the queue into the block being built.
    • An anti-starvation priority boost: a position increase applied at the end of each round to transactions that are still waiting, so low-fee and zero-fee transactions rise over time.

    On Arbitrum One, the block time B is 250ms and the proposed number of rounds per block K is 2, giving a nominal round length of 125ms. Let's look at each component.

PGA uses three components that work together. A two-stage mempool holds an unordered waiting list and a priority queue keyed on the priority fee. PGA rounds promote the waiting list into the queue every 125ms, then transfer the queue into the block. An anti-starvation boost raises the queue position of transactions still waiting after each round, never the fee charged, and that feeds the next round. On Arbitrum One the block time is 250ms with 2 rounds per block.

The two-stage mempool​

Transactions arriving at the Sequencer land first in an unordered waiting list. Intake runs continuously and independently of any ordering work.

At the start of each PGA round, the entire waiting list is transferred to the second stage: a priority queue keyed on the transaction's priority fee, computed per EIP-1559 as:

priority_fee_per_gas = min(
  transaction.max_priority_fee_per_gas,
  transaction.max_fee_per_gas - block.base_fee_per_gas
)
Transactions arrive into an unordered waiting list. At the start of each PGA round, the Sequencer moves the whole waiting list into a priority queue keyed on each transaction's priority fee, highest first.

Ties are broken by the arrival timestamp recorded when the transaction first reached the Sequencer, not when it entered the queue.

Three transactions carry the same priority fee of 2 gwei. The Sequencer orders them by the arrival timestamp it recorded when each transaction first reached it, so the earliest arrival goes first.

The queue is re-keyed against the new base fee at the start of every block because the priority fee depends on the base fee, which changes between blocks.

Transactions remain subject to the prevailing base fee, and the mempool remains private. PGA does not grant anyone the right to view or reorder other users' transactions, so the protections against harmful MEV that Arbitrum users rely on are unchanged.

PGA rounds​

The following parameters define PGA rounds:

  • the block time B
  • the proposed number of rounds per block K

A new round begins every B/K. In Arbitrum One, block time B is 250ms, and the number of rounds K is 2, meaning rounds are 125ms.

K remains adjustable for two years after PGA activates, to any value from 1 to 10 inclusively. That gives round lengths from 250ms down to 25ms.

Each round has two phases:

  • The intake phase runs for the full round window, absorbing new arrivals into the waiting list. It overlaps with the previous round's execute phase.
  • The execute phase begins as soon as intake closes. The waiting list moves into the priority queue, and the Sequencer transfers the queue into the block, highest priority first.

The transfer loop ends when the queue is empty, the block is full, or the round's time is up. Anything still queued waits for the next round.

Blocks fill until they reach one of the following:

  • The 32 Mgas gas limit target
  • The 95,000-byte calldata limit
  • The end of the round.

The block hard limit is 64 Mgas, and an individual transaction is capped at 32 Mgas.

If a block fills before its last round, the Sequencer finalizes it immediately and starts the first round of the next block rather than idling for the remainder of the window. This is what allows the chain to exceed its nominal block rate under load. Block production is capped at 8 blocks per second; keeping the spacing between rounds consistent makes the anti-starvation policy behave predictably, since building faster would give older transactions an unfair advantage over newer ones.

The anti-starvation priority boost​

At the end of every round in which the priority queue is not empty, each transaction still waiting receives a priority boost of p / (2K), where p is the priority of the last transaction included in the previous round (or zero if that round included none). K is the number of rounds per block.

Two properties are worth emphasizing:

  • The boost shifts a transaction's position in the queue and nothing else. The fee charged on inclusion is unaffected.
  • It compounds across rounds. A transaction paying no priority fee accumulates boost each round until it outranks the marginal paying transaction, which is what bounds its wait to a small number of blocks. The exact wait depends on the round parameters and on the priority fee the transaction expressed.

What changes when PGA activates​

PGA activates on Arbitrum One some time after the onchain vote passes. On the same day, Timeboost's express lane and its delay logic will be decommissioned:

  • The Timeboost autonomous auctioneer stops accepting new bids.
  • The express lane endpoint shuts down.
  • The Sequencer stops enforcing the 200ms delay on transactions outside the express lane. That delay only applied while an express lane controller held the round.
  • You can withdraw funds you still have locked in the Timeboost auction contract at any time.

On Arbitrum One, PGA sends 97% of the priority fees it collects to the Arbitrum DAO treasury and 3% to the Arbitrum Developer Guild. The DAO accounts for these proceeds periodically and distributes them through a separate vote every six months.