How to optimize the gasPrice and gas options in a contract send() function? [duplicate]

Question

There are many questions and answers about estimating the amount of gas consumed. This question is about what to do with this estimate.

What values should we actually provide to gas and gasPrice in the send() options, to make sure transactions go through, but we won't pay too much:

myContract.methods.myMethod(123).send({
    from: myAddress,
    gas: myGasLimit,
    gasPrice: myGasPrice
    }, function(error, transactionHash){
    ...
});

Most people seem to advise to set the gas option to 10-20% above estimatedGas (which can be retrieved via the web3 interface).

But what about the case where the estimate is wrong? Because not-used gas is returned, why not set the maximum to something huge? What about the gasPrice, should we leave that up to the miner or actually set a value?

So far I didn't provide any values for gas and gasPrice in the send options, and that resulted in wildly varying amounts of actually paid gas between wallets. In the browser with MetaMask a contract deploy costs 0.000633134 Ether (on Rinkeby) and the same deploy in the CoinbaseWallet costs 0.01268828 Ether (also on Rinkeby). Apparently the gasPrice at the CoinbaseWallet transaction was 20 GWei compared to 1 GWei for the MetaMask transaction.

Edit: clarification of this question:

To make my question more clear: where the question I link to above is about the limitations of the getEstimate function, I am here asking about best practices after having used this function to get an estimate.

Having an estimate, what values do I provide for the gas and gasPrice fields to limit the risk to pay too much and to be picked up in the first upcoming block?

Let's assume here that the method is our own and we know that the estimate is more or less correct (no state changes are possible that make the gas consumption substantially larger).

From the current answers I can conclude: don't set the gas limit too high (so the 10-20%-higher-than-the-estimate-rule sounds good?)

About the gasPrice: I did some experiments and saw that MetaMask uses the value the dapp sets and CoinBaseWallet ignores it. So maybe letting the wallet (and if possible the end-user) decide is the way to go?

Answer 1

I think this is an important topic.

The reason to not to put huge amounts is that the transaction may revert and in some cases consume all your gas.

Also, the estimation will change if the function is time-dependent in some way, meaning that the code to be executed is dependent on the previous instructions. That said if you know the function you are executing you can determinate if letting the node to decide the necessary gas is or is not convenient.

Hope this help

Answer 2

Pro's and cons on setting a high limit on gas:

• pro: the transaction will less likely run out of gas.
• pro: as it is a proxy for the estimated gas usage, the miner might be persuaded to prioritize this transaction as it hints to a high reward (esp. in combination with the gas price, see below) while unused gas will be returned anyway (but see below).
• con: the transaction may actual use up more than you would be prepared to spend, e.g. due to some loop or other unexpected number of operations executed.
• con: on an out of gas event, all gas will be forfeited: When running out of gas, the transaction fails, but Ether spent on gas is not returned.
• con: in theory I think you could hit a miner that assigns higher gas usage to certain EVM operations, thus using more gas than a standard miner would.

Pro's and cons of setting (willing to pay) a high gasPrice:

• pro: your transaction will be included in the next block with a higher probability as miners will generally pick transactions with a high gas price first, especially if the associated gas limit (proxy for the estimated gas usage) is substantial.
• con: you will actually pay this gas price, even if there are not many transactions competing to be included in the next block.

So for the gas limit, you want to have a good estimate based on the actual parameters of the transaction and the current state of storage your transaction accesses and uses, and indeed add a bit of margin to account for the change in state between said estimate and the actual execution of the transaction, as you do not want to run out of gas (and thus spent all gas on a failed transaction) because of a slight increase there.

As for the gas price, ideally you would let the enduser choose, based on the current running averages of the gas price for "fast" (next block) transactions, "average" transactions (with in a minute?), and "cheap" transactions. For these running averages you could refer to ETH Gas Station.

The Coinbase Wallet seems to set the gas price to 20 GWei, which is quite high. Fine when transferring Ether or buying a Token, but when calling some functions of a contract the transaction cost can be prohibitive. Wallets should give their user the option to set the gas price, with a good associated UX.