Better bidding with eip1559
eip1559 bids take a variable reference price, helping you stay afloat
There's been a healthy discussion on the benefits of eip1559, with proponents arguing eip1559 makes gas prices predictable. Yet this term is ill-defined, and thus misunderstood. We’ll dive into various interpretations here, leading us to observe how the eip1559 bidding grammar improves on the current paradigm.
Crystal ball predictability
Before we start, let's immediately rule out predictability as the ability to estimate what the fee will be 1 block, 5 blocks, 10 blocks, 1,000 blocks from now. Such predictions are more “macroeconomic” in nature, as they rely on analysing the demand for transacting on the Ethereum network and future changes affecting the supply of gas (e.g., eth2, rollups etc.)
To some extent, eip1559 gives us bounds on how much the basefee varies over some number of blocks. At an update rate of 12.5% maximum, the basefee doubles every 6 blocks assuming these 6 blocks are full. This is a guarantee that the basefee will not increase past a certain value in a given amount of time, but it still does not tell us what the entry price will be.
Inclusion predictability
Let's try this definition: we care more about predicting inclusion given some bid made by the user. What does this mean in the current system?
A user bids some gas price with their transaction. Given the (changing) environment of the fee market, the gas price is a parameter to some random variable denoting inclusion delay. So given the gas price bid, the user should expect to be included after some number of blocks. The delay is zero when the user is included in the next block. The game is to predict how long the delay will be given the gas price offered.
What can we tell about the inclusion delay? It turns out, not much. One thing that seems natural is that a higher gas price should never harm your chances of being included, so if Alice bids less than Bob, Alice should never be included before Bob. A gas price of zero should give you infinite delay. A gas price of infinity should give you zero delay.
These are all nice mathematical facts, not so useful in reality, but pretty much the only things we can tell for sure. Let's be more concrete.
At any point in time, we have a collection of pending bids, ordered from highest to lowest. This is the observable demand curve. The top bids up until 12.5M gas will be included in the next block.1 Maybe your bid places high enough in that list to be included. Maybe more bids come in the meantime and you are pushed out of the top of the list, and not included, but once these top bids are included, you are at the top again and you are included one block later, etc etc.
In other words, there is some distribution over the possible outcomes: included now, included a block later, included two blocks later... We can sort of guess this distribution by looking at the current bids and perhaps how bids have evolved in the recent past. This is what most oracles do.
eip1559 improves on this paradigm by quoting the correct cut-off price. We spent some time looking at how eip1559, and the basefee in particular, achieve pricing the variable congestion observed on-chain. This study led us to break down eip1559 into three different cases.
We'll call effective demand the amount of gas demand by users who are willing to pay at least the basefee plus the miner fee. There are three cases worth taking a closer look at:
Undertarget: The effective demand is lower than the gas target.
Overtarget: The effective demand is higher than the gas target, and lower than the gas limit.
Overfull: The effective demand is higher than both the target and the limit.
At most points in time, when blocks are under- or overtarget, we are guaranteed to be included in the next block by following the simple bidding strategy of paying the fixed 1 Gwei miner fee on top of the basefee. Case closed. Overfull blocks is the bad case: there are too many users who could potentially be included in the next block, in spite of the current basefee level. Scarcity!
So with 1559, we’ve reduced the space of salient outcomes to pretty much two:
Either we are included at the quoted basefee + miner fee,
Or there is enough effective demand to push us into the overfull case.
The bizarro fee market
What are the bad things that happen in the overfull case with eip1559 activated? It turns out, bad things in the overfull case still seem less bad than they are in the current paradigm. We’ll do a thought experiment where we imagine the demand, the users and everything are the same in two parallel worlds, except one world uses the current fee market while the other has activated eip1559.
First, note that because blocks can double in size, there are situations where we are priced out of the current fee market, which don’t happen under eip1559, since the block slack allows for our inclusion. So there isn't a strict equivalence between being priced out currently and blocks being overfull in eip1559. In other words, in the eip1559 world the block is overtarget, but not overfull, so we are next-block included, no scarcity, everything worked out; yet in the parallel, current fee market world the inclusion delay is greater than 0. That’s a net win.
Let's look at a worse case, one where we are both priced out in the current fee market, and we might not be next-block included in eip1559 world (equivalently, we are not next-block included in the current fee market world and we are in the overfull case in the eip1559 world).
In the current fee market world, let's assume an all-knowing oracle quotes me the exact cut-off price at the time of my transaction, i.e., the gas price in the ordered list where transactions bidding above that gas price are exactly enough to fill a block. All I have to do to get in at that exact instant is bid above the cut-off. Let’s say that cut-off is 100 Gwei, so I bid 100 Gwei.
Bad luck: a bunch of users are doing the same, right after I place my bid. They are bidding randomly, sometimes above my bid, sometimes below, meanwhile the all-knowing oracle picks this pattern up and starts quoting a higher cut-off price, higher than my bid is (110, 120, 130, ...), because the list gets longer and the bids at the top get more competitive. For a string of blocks there is enough sustained demand of users outbidding me, while I wait.
But maybe I didn't mean to bid so low! Rather, if I knew I wouldn't be included with my initial bid, I might have wanted to revisit it slightly higher than I sent it, maybe to 150 Gwei instead. I can still do that, of course (replace-by-fee), but it means I am sitting in front of Etherscan or Metamask and monitoring my transaction all this while.
Overfull blocks in eip1559
How does eip1559 improve upon this pattern? Transactions sent in eip1559 world have two parameters:
The maximum fee: the most I am willing to pay.
The inclusion fee: meant to carry the miner fee, with or without the strategic fee.
The maximum fee parameter allows me to set the highest value I am willing to pay, which including both the basefee and the inclusion fee. I don't believe wallets even need to ask the user to set that parameter themselves. Of course wallets should always give the option to do so, but a wallet could simply set fee cap to whatever basefee is, times 2. As we’ve seen, it takes 6 full blocks (at 2x capacity) for basefee to double. This is pretty safe.2
In the parallel world of the current fee market, the all-knowing oracle had direct access to the demand to quote its price. In eip1559 world, the all-knowing oracle is the basefee, in the sense that the correct cut-off price is the basefee plus the fixed, 1 Gwei, miner fee.
We’ll repeat the scenario seen in the current fee market world. I send my transaction in, following the basefee + 1 Gwei inclusion fee strategy, and setting my maximum fee to 2x the current basefee.
The herd joins in the fun, there are too many of us to include, even with the slack: in this world, blocks are overfull. The basefee increases as a result. Some in the herd are bidding strategically, deviating from the 1 Gwei default and adding 2, 3, 4 Gweis to ensure they are included quickly. As long as these strategic users are enough to fill a block, I am at the back of the queue. If there aren’t so many of them, maybe I am included in the next block after I sent in my transaction.
If I am not included, maybe I’ll be in the next block. The herd would need to push basefee high enough, beyond twice its initial quote, to overtake my maximum fee and price me out entirely. The point is that my bid remains competitive, unlike my previously fixed 100 Gwei bid. I might get in by the fourth block after I sent my transaction. Basefee is at most 160 Gwei now. If the demand from the herd only pushed the basefee to 150 Gwei, that's what I end up paying. Another win: I always pay the lowest amount at the time I am included.
Surfing on sine waves
To summarise our thought experiment, we get two major wins with eip1559. First, the block slack means that the inclusion delay induced by sudden and short demand bursts is dampened. Second, the bidding grammar of eip1559, taking as reference a variable fee (basefee) and adding on to it means that we are not constrained to a fixed bid and instead follow the market where it leads us.3 This paradigm ensures we also pay the lowest amount when we are included and need not nurse our bid throughout to ensure we remain competitive.
This opens the door for wallet simplification too. Most of the time, a wallet can hide all parameters away from the user, simply quoting the current basefee with a binary “Send transaction / Don’t send” interface. As stated in my tweet above, a smart wallet should still rely on transaction pool monitoring to detect shifts in demand that would push the market into the overfull case. If a shift is observed, the wallet could let the user know that the market is heating up and suggest either:
Raising the maximum fee parameter if the user has low time preference and simply wants to be eventually included in a reasonable amount of time.
Raising the inclusion fee parameter if the user needs fast inclusion, skipping ahead of the queue.
Setting a notification to be sent when basefee comes back down to a preferred level, at which point the user sends the transaction themselves.
Note that in hot markets as in relatively stable ones, the user can also always set their maximum fee to somewhere lower than basefee. If the current basefee is 100 Gwei but the user never wants to pay more than 50, they set the maximum to 50.4
Otherwise… Let the duck carry you.
Many thanks to Sacha Saint-Leger for edits and comments, and Tim Beiko for useful comments on this draft (and the previous one).
Also check this out
Micah Zoltu wrote a great post in November 2020, A Tale of Two Pricing Schemes, going even deeper in the weeds of how transactions fail and how 1559 improves the pattern.
Last Friday the much-anticipated 1559 community call happened. In my view there was more consensus than expected, with MEV (Maximum / Miner Extractable Value) coming out as a clear direction for future revenue. We’ll talk about this more in a future post, but in the meantime you can also check out Micah talking about MEV with Michael Carter (a.k.a., BitsBeTrippin’) or the excellent post by Hasu and Georgios Konstantopoulos estimating bounds on MEV under 1559.
Barring block shenanigans such as a pool mining an empty block because it’s more profitable to do so, which apparently happens whenever a block is found so quickly that the transactions meant to be included in it don’t even get the time to be processed.
We could go behavioural economics on this and instead of having a fixed multiplier, have the multiplier follow a decreasing function of the basefee. If basefee is 1 Gwei, perhaps I don’t mind paying up to 10 Gwei, so 10x. If basefee is 100 Gwei, I probably am not willing to pay 1,000 Gwei, but 200 Gwei might be fine, so 2x.
Sure, it’s better to pay less, but if we could pay less and be included, we’d not be in one of these knotty cases in the first place, and eip1559 would still help us place the correct bid.
Assuming transaction pools are graciously willing to keep the 50 Gwei transaction in mind until basefee comes down to that level, which is not a given, hence the notification idea.
What will https://txstreet.com/v/eth look like after basefee? To even be on a bus you have to be higher than current basefee?
No one seems to be writing about what the transaction pool will look like. I usually dont care about getting included in 6 blocks, I only care about 1 day.
As someone who doesn't care about inclusion in the next 6 blocks, and really only in the next day, I wish someone would write an article about what the pending transaction pool will look like after this.
i.e. What will https://txstreet.com/v/eth do?
To even be on a bus you have to be offering the current base fee?