You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using legacy gas params can be cumbersome, particularly when relying on eth_gasPrice. If the base fee changes too much right before I send a tx, at least in my experience with my local devnet, I'm likely to get an error. This can happen often if I'm sending txs with very high gas limits early on in the chain history.
If we support type-2 gas params (maxFeePerGas, maxPriorityFeePerGas) in CCRs, then users can take advantage of better gas-estimation methods designed for eip-1559.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Describe the feature you would like
Using legacy gas params can be cumbersome, particularly when relying on
eth_gasPrice
. If the base fee changes too much right before I send a tx, at least in my experience with my local devnet, I'm likely to get an error. This can happen often if I'm sending txs with very high gas limits early on in the chain history.If we support type-2 gas params (
maxFeePerGas
,maxPriorityFeePerGas
) in CCRs, then users can take advantage of better gas-estimation methods designed for eip-1559.Additional context
No response
The text was updated successfully, but these errors were encountered: