is gasLimit param should be defined or not.....?

[moneyDev1111]

Hi, I have a script that sends different TXs in different chains and.... it seems like some TXs are stuck or just take too much time to be sent.... So I'm trying to get what happens if I don't specify the gasLimit and should I really do it at all? the behavior seems to be random and I cannot get any logical answer from it.... I would really appreciate someone explain it to me,.. do I have to define it, or not, and which is better. Does it behave the same for legact TXs and EIP 1559 ones.. Btw are there only two type of TXs right now? legacy and EIP 1559? Thank you.

[ricmoo]

The gasLimit has never changed in meaning. In the gas analogy, it is simply how big a gas tank to give your transaction. You pay upfront to fill it up (based on the transaction fee data, which has changed over time from gasPrice in legacy and type 1 transactions to maxFeePerGas and maxPriorityFeePerGas in type 2 (EIP-1559) transactions) and are refunded for any unused gas at the end of the transaction.

The gasLimit though should have no bearing on whether a tx gets included, since if the gas tank is too small it will just run out early, but the miner will have received payment for it despite your tx failing (running out of gas).

In ethers, leaving the gasLimit unspecified will result in ethers using estimateGas to try guessing for you. This is usually fine, and unless you know a better value to use (for example, Vyper can actually compute this for you and include it in the ABI at compile time and is likely a much better solution, but at the cost of some flexibility).

On Ethereum there is actually only EIP-1559 transactions currently. If you use either legacy or type 1 transactions, they are converted to type 2 transactions with gasPrice used as both maxFeePerGas and maxPriorityFeePerGas; this will result in a very overpriced transaction, so it highly discouraged. Using correct EIP-1559 fee data is best for everyone. :)

If your txs are getting stuck, it is likely you are using either too low of a maxFeePerGas (should be 2x the most recent block’s baseFee), maxPriorityFeePerGas (1 gwei should be fine though) or the network is under severe congestion.

Does that all make sense?

[ricmoo]

It’s the same if you don’t add it yourself, yes.

It will be as correct as possible. The necessary costs can change between when queried and the transaction is mined, and weird situations can be hard to predict, but it is generally correct.

For example, if some address A currently has 0 tokens and you estimateGas to send them 1 token, then you submit that transaction but before your transaction is mined, someone else sends them a token (so they now have 1 token), your gas estimate is high and tou will receive a refund. This is because it costs more to change a storage slot from a 0 to non-zero so the first time a balance becomes non-zero it is more expensive.

So, there are are weird edge cases. But you shouldn’t generally need to worry about that.

[moneyDev1111]

what about if a TX is sent "between" blocks? so the ethers will estimate gas for the previous block and then the gas... oh it's not about the gasLimit right, it will be still the same, the gas price will change only...
ok, so then I guess this param is not needed in 99% of times. Thanks a lot!

also you've said this

On Ethereum there is actually only EIP-1559 transactions currently. If you use either legacy or type 1 transactions, they are converted to type 2 transactions with gasPrice used as both maxFeePerGas and maxPriorityFeePerGas; this will result in a very overpriced transaction, so it highly discouraged. Using correct EIP-1559 fee data is best for everyone. :)

so I really don't know if it's a secret I guess no, but to send TXs cheaper on BSC chain one can use ankr rpc endpoint https://rpc.ankr.com/bsc and any TX can be sent with the gasPrice of 1 gwei, instead of 6 or smth while using other rpcs... So I'm sending the TXs this way and it's cheap, so maybe this endpoint somehow support only legacy TXs? and that's also the reason why TXs are stuck at times..

like this

let { gasPrice, maxPriorityFeePerGas, maxFeePerGas } = await provider.getFeeData();

gasPrice = chainSrc === 'bsc' ? parseUnits('1', 'gwei') : gasPrice;

and in a Tx param I define only gasPrice

[ricmoo]

BSC and Polygon do not use the proper economic EIP-1559 model, so they behave more like the previous gas bidding model (like how gasPrice worked), so they have their own rules for setting the fee data, and to be reliable require a gas station which can do the necessary network analysis to determine the best values to use.

So, that would definitely explain why things are stuck. During congestion you need to use advanced tools with network forensics to determine the correct gasPrice… I don’t currently have any gas station built in for these networks though, but you should be able to find one. :)

[moneyDev1111]

Thank you, you're the best!, sorry for distracting, I'm surprised you have time and willing to answer my question. Thank you:)

[ricmoo]

No worries and of course! I help when I can. :)