Priority gas auction: Definition & Examples

A priority gas auction (PGA) is a competition in which participants repeatedly offer higher transaction fees to obtain favourable execution order on a blockchain. The term is associated with public-mempool races to capture the same short-lived trading opportunity. For a quant, the consequence is that an apparent trading surplus can be transferred into execution fees—and a participant can pay a fee even after losing the opportunity.

A PGA is a particular mechanism for competing over maximal extractable value, rather than a synonym for every gas fee or every blockspace auction.

What the original auction model describes

Daian and co-authors' 2019 Flash Boys 2.0 documented bots competing for execution priority on Ethereum decentralised exchanges. In their setting, one participant's execution could consume an arbitrage opportunity, leaving later attempts unable to earn the same revenue.

The public mempool is the collection of pending transactions known to a node, rather than a single globally synchronised queue. Competitors could observe fee bids and respond, but propagation delays meant their views differed. The paper models continuous-time bidding with imperfect information and, in its proof-of-work setting, uncertain block-arrival time. Those assumptions matter: this was not a simultaneous sealed-bid auction with a known deadline.

The authors describe a partial all-pay feature: an included losing transaction could still consume gas and pay for attempted execution. “All-pay” does not mean every broadcast revision is charged on-chain. A version that is never included has no on-chain execution fee. The distinction between a failed execution and an unexecuted message is essential when measuring losses.

A fictional fee ledger under EIP-1559

The historical paper predates EIP-1559. To translate the economic problem into newer Ethereum fee accounting, consider a separate fictional base-layer execution example, with no blob fees or additional builder payments.

EIP-1559 separates a burned base fee from a priority payment to the block's fee recipient. For a valid transaction, write

b

for the block's base fee,

c

for the priority-fee cap, and

m

for the total fee cap, all in gwei per gas. If

m\ge b

p=\min(c,m-b),\qquad \text{execution fee in ETH}=g(b+p)10^{-9},

where $p$ is the effective priority fee and $g$ is the gas actually billed. A larger total cap is not automatically the price paid.

Assume the successful transaction uses 150,000 gas, with

b=20

c=35

and

m=70

gwei per gas. Its effective priority fee is 35 and its total price is 55 gwei per gas:

\begin{aligned} \text{execution fee}&=150{,}000\times55\times10^{-9}=0.00825\ \text{ETH},\\ \text{base fee burned}&=150{,}000\times20\times10^{-9}=0.003\ \text{ETH},\\ \text{priority payment}&=150{,}000\times35\times10^{-9}=0.00525\ \text{ETH}. \end{aligned}

If the realised trading revenue before this execution fee is 0.012 ETH, the amount retained is

0.012-0.00825=0.00375

ETH before other costs. This assumes the opportunity is captured; it is not an expected profit or a fee recommendation.

Now suppose a competing transaction is also included, but reverts after the opportunity has disappeared. Assume it is billed 80,000 gas at a 20 gwei base fee plus a 20 gwei effective priority fee. Its execution charge is

80{,}000\times40\times10^{-9}=0.0032

ETH, with no trading revenue in this scenario. Reverting the trade does not refund the computation already charged. Ethereum's gas documentation explains why unsuccessful execution still incurs a fee. A transaction that is never included incurs no on-chain execution fee, although infrastructure or other off-chain costs may remain.

Historical public fee competition feeds block construction. In a separate fictional EIP-1559 example, 0.012 ETH gross revenue splits into 0.003 ETH burned, 0.00525 ETH priority payment and 0.00375 ETH retained before other costs. An included reverting loser pays 0.0032 ETH; a never-included transaction has no on-chain execution fee.

Original mechanism diagram and fictional execution-fee ledger. The accounting example is separate from the paper's historical proof-of-work auction setting; all gas quantities and prices are stipulated.

Public bidding is only one route to blockspace

Ethereum now uses proof of stake; the original paper's miners and random mining deadline describe its historical setting. Ethereum's MEV documentation explains the transition and the distinction between transaction searchers, builders and proposing validators.

Private order flow changes what competitors can observe. In the Flashbots architecture, searchers can submit transaction bundles privately to builders, which combine bundles with public transactions. A bundle can express ordering conditions; this differs from repeatedly raising a visible public fee bid. Privacy from the public mempool also does not imply privacy from the builder or eliminate trust assumptions.

MEV-Boost provides a marketplace in which builders offer complete blocks through relays to proposing validators. The payment offered for a block is different from one transaction's priority fee. Block construction therefore involves interactions among transactions and opportunities, rather than a universal ranking of isolated transactions by tip.

The highest visible tip does not guarantee inclusion, first position or successful execution. This follows from the distinction between fee incentives and block selection: transaction validity, arrival, available blockspace, competing bundles and the builder's chosen block all matter. EIP-1559's transaction-ordering discussion itself discusses client choices rather than imposing a universal highest-tip-first consensus rule.

For analysis, record whether a transaction was publicly observed, included, successful and charged—not merely its offered fee. A ledger containing only successful trades misses included failures; a chain-only view misses unexecuted bidding revisions. Neither alone reconstructs the public auction or the private competition behind a block.

Sources

Daian et al., Flash Boys 2.0 (2019), §§III-C, IV-A and V-A: public PGAs, observational limits and the historical auction model.
EIP-1559, Abstract, Specification and Transaction Ordering: fee caps, burn, priority payment and ordering incentives.
Ethereum, Gas and fees, What is gas? and How are gas fees calculated?: billed execution and unsuccessful transactions.
Ethereum, Maximal extractable value, Maximal extractable value and Builder API: post-Merge roles.
Flashbots, Auction overview, Searchers, Block Builders and Trust Assumptions: private bundles and their visibility limits.
Flashbots, MEV-Boost overview, What is MEV-Boost? and How does MEV-Boost work?: builders, relays and proposers. Protocol and architecture documentation checked 29 October 2026.