Skip to content
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

Post London EIP-1559 Assessment Part II (Breakout #13) #374

Closed
timbeiko opened this issue Aug 16, 2021 · 2 comments
Closed

Post London EIP-1559 Assessment Part II (Breakout #13) #374

timbeiko opened this issue Aug 16, 2021 · 2 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Aug 16, 2021

Date and Time

Date/Time: Friday, Sept 10 at 14:00 UTC (10:00 ET)
Duration: 60 mins

Post-London discussion and assessment of EIP-1559 for implementers, tooling, and infrastructure providers.

Agenda

  • Presentation from Metamask, Jake Haugen
@timbeiko
Copy link
Collaborator Author

timbeiko commented Sep 2, 2021

I might not be able to join the call (@tvanepps is hosting), but want to share some observations using 1559 over the past few weeks.

It seems like some applications pre-generate transactions for wallets to sign and set both the maxPriorityFeePerGas and maxFeePerGas to the same value, at ~2x the current baseFeePerGas. Here is an example from matcha.xyz on MetaMask (not to pick on matcha, I've experienced this across many applications):

Screen Shot 2021-09-01 at 7 07 57 PM

My intuition is that the application or the library it uses to generate transactions probably doesn't have 1559 support and sets both fields to a legacy gasPrice value or something. I really see no case when it makes sense for maxFee to be exactly equal to maxPriorityFee: either you are in a low-demand mode, and maxPriorityFee should be a few gwei, or you are in a high-demand mode, and you should set maxPriorityFee to, say, the 80th or 90th percentile maxPriorityFee from the past handful of blocks [0]. Legacy transactions are processed using maxPriorityFee == maxFee, but if we can save users money at the wallet layer, it makes sense to modify the txn to do so.

Perhaps this is something that wallets can catch and fix? It might be a bit hacky, but something like if the maxFeePerGas is exactly equal to the maxPriorityFeePerGas in an application-generated transaction, then either alert the user or update the values behind the scenes based on the wallet's own oracle?

On this last note, it seems like the oracles from wallets have improved over the past couple weeks :-)


[0] I haven't run the numbers on this, but I suspect when >3 blocks are 100% full, it is likely a good indication we've moved from one mode to the other.

@timbeiko
Copy link
Collaborator Author

Recording of the call https://www.youtube.com/watch?v=YtkU2773K6w

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants