In Base block 52,520,207, sealed at 18:29:21 UTC on 12 October 2026, the transaction at index 53 paid a priority fee of 50 wei per unit of gas. The transaction immediately behind it, at index 54, paid 4,788,608,153 wei. Different senders, same block, one position apart, and the one that paid roughly 95.8 million times less went first.
I assumed that was a freak. So I pulled 600 consecutive blocks and counted. It is not a freak. It is the ordinary case, and the reason is a piece of Base’s architecture that almost nobody playing a game on it has thought about.
TL;DR
- Across 600 consecutive Base blocks (95,979 user transactions, two windows twelve hours apart on 12 October 2026), 70.78% of transactions had at least one cheaper transaction sitting ahead of them in the same block. The median transaction had 13 of them.
- Base does sort by priority fee, but badly: of 7,081,259 comparable cross-sender pairs, the higher bidder came first only 65.44% of the time. A coin flip is 50%. A real priority auction is close to 100%.
- The price response is flat. Paying 1.5 times the other transaction’s tip got you in front 63.9% of the time. Paying more than a thousand times as much got you in front 69.5% of the time. Six orders of magnitude of extra money buys under six percentage points.
- The cause is structural: a 2-second Base block is built as roughly ten 200-millisecond Flashblocks, each sorted separately. I measured a median of exactly 10 price-descending runs per block, in 419 of 600 blocks. Your money only reorders you against people who arrived in the same 200ms slice as you.
- On Ethereum mainnet, the chain this industry calls hostile because it has a builder market, the higher bidder came first 82.00% of the time. A single sequencer did not buy Base a more responsive fee market.
- For a raffle with a hard cap, that means the last ticket is not won at auction. It is won in a latency race that publishes no price, and our July post on transaction ordering described the position too generously.
The claim we made in July, and the one we made last week
In the second instalment of this series, back in July, we wrote this about running a game on Base:
Base currently orders transactions through a single sequencer on a first-come-first-served basis with no public mempool, which strips out the classic sandwich surface that makes Ethereum mainnet such a hostile place to play games.
That post, on being provably fair and still front-run, was careful to say this was a reduction in attack surface and not a guarantee. It was less careful about the words “first-come-first-served”, which it asserted and never checked.
Nine days ago, measuring the Base fee floor, we found something that sits awkwardly beside it: 95% of users tipped when there was no queue to jump. In tonight’s larger sample it is 97.00%, with a median tip of 0.001 gwei on top of a base fee pinned at its 0.005 gwei floor. A twenty per cent premium, paid by almost everyone, on a chain running nowhere near capacity.
Two posts, two unexamined halves. One said the order cannot be bought. The other said everybody is paying anyway. Nobody checked whether the money and the order actually line up. On a raffle round with a ticket cap, that stops being a theoretical question the moment the round is nearly full.
What I measured
Two windows of 300 consecutive Base blocks each, twelve hours apart, so the result is not one quiet evening: 52,520,002 to 52,520,301 (18:22:31 to 18:32:29 UTC) and 52,498,103 to 52,498,402 (06:12:33 to 06:22:31 UTC), both on 12 October 2026. Contiguous, nothing skipped. Full transaction bodies via eth_getBlockByNumber against base-rpc.publicnode.com, with the headline block re-read against mainnet.base.org to confirm the figures are not one endpoint’s opinion.
The 606 system deposit transactions (type 0x7e) are excluded throughout, leaving 95,979 user transactions. Effective priority fee is gasPrice minus the block’s baseFeePerGas, which is what the sequencer actually collected per unit of gas, not what the wallet offered. Pairs are only compared when the two transactions come from different senders, because a sender’s second transaction cannot legally precede their first no matter what either one pays. That exclusion removes about 12,700 pairs and makes the result slightly worse for my argument, not better.
Finding one: it is a price sort
Take every pair of transactions in a block, from different senders, with different tips. Ask whether the one that paid more came first. If ordering ignored price entirely you would get 50%. Here is what each candidate sort key scores:
| Candidate sort key | Pairs ordered “correctly” |
|---|---|
Effective priority fee (gasPrice minus base fee) |
65.44% |
maxPriorityFeePerGas as offered |
63.39% |
| Total fee offered (gas limit times price) | 54.03% |
maxFeePerGas as offered |
50.63% |
| Gas limit | 50.55% |
So the sequencer is not running a lottery. It sorts by the fee it actually collects, and the two keys that look like money but are not, the ceiling you offered and the size of your transaction, are indistinguishable from coin flips. July’s “first-come-first-served” was wrong in a specific direction: money does move you.
It just does not move you much. Not one block of the 600 was perfectly sorted by price. Not one.
Finding two: the price response is flat
If 65% sounds like a weak auction that would tighten up when the stakes rise, it does not. Here is the same statistic split by how much more the dearer transaction in the pair paid:
| You paid this much more | Pairs | You went first |
|---|---|---|
| 1 to 2 times | 1,940,222 | 63.9% |
| 2 to 5 times | 1,852,127 | 63.8% |
| 5 to 10 times | 969,812 | 73.2% |
| 10 to 100 times | 1,212,980 | 58.8% |
| 100 to 1,000 times | 188,215 | 61.0% |
| More than 1,000 times | 462,874 | 69.5% |
Read the right-hand column downwards. It does not climb. Paying ten to a hundred times more than the other party scores worse than paying fifty per cent more. The whole range, across six orders of magnitude of spending, sits between 58.8% and 73.2%.
That is the shape of something that is not really an auction. In an auction, more money buys more of the thing. Here, more money buys a near-constant 65% chance of a result you had a 50% chance of getting for free.
Finding three: a Base block is ten blocks
The explanation is not that the sequencer is sloppy. It is that the thing I was treating as one auction is ten.
Walk each block in index order and count how many times the tip rises from one transaction to the next. A perfectly price-sorted block never rises: one run. A randomly ordered block of 160 transactions rises about 80 times. Base’s blocks rise, on average, 9.34 times, giving a mean of 10.34 descending runs per block, a median of exactly 10, and exactly 10 runs in 419 of the 600 blocks. The minimum across 600 blocks was 8 and 70% landed precisely on ten.
Ten. Base’s own documentation says the pending block tag is “updated every ~200ms with new batches of sequencer-ordered transactions”, and a 2-second block divided by 200 milliseconds is ten batches. Each batch is sorted by price. The batches are not re-sorted against each other, because by the time the next one is built the previous one is already a pre-confirmation somebody has been shown.
I watched it happen rather than inferring it. Polling eth_getBlockByNumber("pending") every 100ms against the Flashblocks endpoint, the in-progress block grows in discrete steps roughly 200ms apart: 1 transaction, then 45, 56, 66, 88, 104, 116, 125, 149, and then the block seals and the counter resets. That first step is worth staring at. The opening 200 milliseconds of every Base block contains exactly one transaction, consuming 46,218 gas, and it is the system deposit that nobody bids for. The first genuine batch of user transactions then arrives in one lump and accounts for a mean of 25.7% of the finished block.
So a quarter of the block is decided before your transaction can possibly compete with it on price, no matter what you pay. This is the same sequencer-shaped seam we found when the raffle deadline turned out to be a counter rather than a clock, seen from the fee side instead of the time side.
Is this just how blockchains are?
No, and the control is the most interesting number I got all night. I ran the identical statistic against two other chains at the same time.
| Chain | Higher bidder first | Price-descending runs vs random ordering |
|---|---|---|
| Base (600 blocks) | 65.44% | 0.130 |
| OP Mainnet (150 blocks) | 73.77% | 0.522 |
| Ethereum mainnet (60 blocks) | 82.00% | 0.467 |
The right-hand column is how many price rises a block actually contains, divided by how many a shuffled block of the same size would contain. Base is by far the most internally sorted chain of the three, at an eighth of random, and simultaneously the least likely to put the higher bidder first. Those two facts only fit together one way: Base’s blocks are several separately sorted lists stapled end to end.
And note the last row. On Ethereum mainnet, the chain this industry calls hostile because it has a builder market, your money works better. 82% against our 65%. Whatever a single sequencer buys you, a more responsive fee market is not it.
What it costs, and what it costs to believe
The money is trivial. The median tip of 0.001 gwei on a 120,000-gas entry is 0.00000012 ETH, which at $2,510.69 is about three hundredths of a US cent. Nobody is being robbed.
The belief is the expensive part. 70.78% of all 95,979 transactions had at least one cheaper transaction ahead of them. The median transaction had 13. The worst had 360 cheaper transactions in front of it in a single block. Anyone who tops up their gas setting believing it secures their place in a filling round is buying a 65% chance at a thing they had a 50% chance of anyway, and the chain gives them no feedback that tells them so, because the transaction confirms either way.
What this means for a raffle with a cap
If a round has a ticket limit and demand exceeds it, somebody gets the last ticket and somebody does not. The question of who is settled by transaction ordering, and tonight’s measurement says it is settled mostly by which 200-millisecond slice your packet reached the sequencer in, with price as a weak tiebreaker inside that slice.
That is a race, not an auction, and in three specific ways a race is worse:
- An auction publishes a price. A race publishes nothing. A losing bidder learns what the thing was worth. A losing racer learns only that they lost, and cannot tell whether they were 10ms late or 400ms late.
- You can improve a bid from a phone. You cannot improve a network path from a phone. The advantage goes to colocation and a direct sequencer connection, which is not on sale at the point of entry and not visible in the transaction.
- The winner of a race pays no premium, so no record exists that the race happened. An auction leaves a trail of what people paid. A latency advantage leaves nothing at all on-chain.
None of this makes a provably fair draw unfair. The random number is still the random number, and the request-side parameters we measured last night are untouched by any of it. What it changes is who is in the field, which is upstream of the draw and invisible to every proof downstream of it.
What Satoshie fixes, and what it does not
The honest split. What our design genuinely handles: because the entry and the resolution are separate transactions, the winning number does not exist when your entry lands, so an earlier slot in the block buys an attacker no information to act on. That is a property of the Chainlink VRF request-and-callback structure, not a promise we are making about ourselves, and it holds whoever is sequencing. July’s post got that part right.
What our design does not handle: if a round has a hard cap and it fills, entering is a race, and nothing in our contract can make it not be one. So the design rules we will hold ourselves to are these. Prefer time-boxed rounds over hard caps, because a round that cannot sell out cannot be raced. Where a cap exists, publish the live fill count so a player can see they are in a race before they commit, rather than afterwards. And never put “pay more gas to secure your ticket” in an interface, because on Base, tonight, that sentence buys five percentage points and a false sense of control.
The checkables for a player, all of them condition-independent: the draw logic is verified and immutable on BaseScan, the VRF coordinator address is fixed in deployed code and readable before you stake, the ticket count is readable before you buy, and the request and fulfilment transaction ids are published with every result. None of those depend on what the sequencer did with your position.
Honest limits
Three, and the first is the real one.
Twenty minutes is not a month. Two windows twelve hours apart agreeing closely (65.82% and 65.04%, with mean runs of 10.32 and 10.35) tells you the result is stable across those two windows. It does not tell you what happens during a mint, a liquidation cascade or any other moment when the fee market actually has to work. The entire point of the fee floor post was that a quiet measurement is a measurement with a date on it.
The mechanism is inferred, not read. I measured run structure, matched it to a documented 200ms cadence, and watched the pending block grow in steps. I did not read the sequencer’s source or an internal build log. Other effects contribute to the 35% of pairs that come out “wrong”, including arrival clustering and the per-sender nonce chains that my cross-sender filter only partly removes.
The ratios are per-gas rates, not total bills. Comparing tips per unit of gas is the right comparison for ordering, but it is not what anyone paid in total. I did not pull 95,979 receipts, so no dollar figure here is a sum of real fees.
Three questions worth asking any on-chain game
- Does your round have a hard cap? If so, what decides who gets the last ticket, and can you show me the measurement rather than the assumption?
- Does your interface ever suggest that paying more gas improves my chances? If it does, ask them for the concordance number on their chain.
- How long is the ordering window on the chain you are playing on, and who can reach it faster than you can?
The lane you are in was assigned
The picture at the top of this post is a start line with numbered lanes. You do not buy lane one. It is assigned to you before the race begins, by a process that has nothing to do with how much you want it.
That is a better model of a Base block than the auction everyone pictures. There is an auction in there, and it is real, and it is worth about fifteen points over a coin flip. The other eighty-five per cent of the decision was made in the 200 milliseconds before your transaction showed up, by a sequencer that was not taking offers at the time.
Knowing which of those you are playing is the whole difference between a cost you can manage and one you cannot see. Satoshie publishes its draws because a result you cannot check is just a claim. The same standard applies to the queue that gets you to the draw, and it took us until tonight to go and measure it.
📷 Photo by Austris Augusts on Unsplash
