-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve chances of tx inclusion #180
Comments
On pause, need to handle this. |
I've extracted from the db the top 10 transactions that took longest to finalize. The graphs below start at the first block that was mined after the tx was submitted and end at the block in which the transaction was included. Sorted by time to finalization: All of the above seem to fall into one of two scenarios:
Since our max fee and max blob fee start at roughly double the base fees and remain valid for at a minimum of 5 blocks (if the price just keeps rising) the key factor that influences when we actually get included is the priority fee. The Geth blobpool docs explain that transactions are mainly picked based on their priority fee. For transactions with the same priority fee, those with fees closer to the current network limits are chosen first, since lower-fee ones can wait. We introduced a 5-block blob fee horizon to keep our transactions valid despite rapidly rising blob base fees. Without this horizon, if our transaction didn’t make it into the next block and fees kept going up, our transaction could become invalid regardless of how high we bumped the priority fee. By extending our blob fee horizon, we've inadvertently made it more likely that our transaction gets postponed—because now there's a larger window where someone else with a higher priority fee or closer-to-limit fees might get chosen first. But the trade-off here is necessary. The horizon ensures our transactions remain valid across multiple blocks during rapid fee increases, even if it means they might be pushed to later blocks under certain conditions. Knowing this, if we want faster finalization, we should consider bumping the priority fee a bit more depending on how late we are. |
Even with the addition of a blob fee horizon, it seems, at times, that the transaction is still not being promptly included.
The examples I've seen all have sufficient max fee per blob gas, so it could be either due to the max fee per gas or the priority fee.
Seeing as alloy multiplies max fee by 2 (giving it an effective horizon of 6-7 blocks), it is probably due to the priority fee being less appetizing to miners.
Analyze replacement transactions and compare them to the conditions of the network at the time the tx was sent. If it turns out that the priority fee was the reason, implement logic that will increase the fee (by increasing the reward perc. given to the historical fees query) depending on how many l2 blocks we're late at the moment.
The text was updated successfully, but these errors were encountered: