Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
Attempt to send any erc20 token with default gas limit/gwei set. Most are being set with gas limit of 40 - 45,000 gas limit. Checking back about a month ago (pre hard fork, pre MM v.7.7.1, the same tokens were being sent with 140 - 150,000 gas limit set.
Expected behavior
Better estimation of gas limit / gwei in order to not have failed tx.
Screenshots

Browser details (please complete the following information):
Additional context
Reference support tickets 27977, 27941, 27985, 28023
examples of tokens set with gas limits below 45,000:
IND, MKR, DAI, CAT, OCEAN, OXT, NMR, KICK, DATA
Interestingly, KCS seems to stay at the 100,000 default. SNX seems to have gas limit estimated properly, over 224,000.
I can confirm some people including myself are having the same issues.
I noticed if you manually increase the gwei the gas limit increases to an appropriate amount as well. For Dai I saw a default gas limit set to 42801, when increasing gwei, the gas limit changes to ~55,000+ (it seems to check again).
Tried and failed to reproduce this issue. Here are my notes:
Attempting to send FOAM tokens from within MetaMask desktop UI.
Initiated an eth_estimateGas call of:
curl 'https://api.infura.io/v1/jsonrpc/mainnet' -H 'authority: api.infura.io' -H 'accept: application/json' -H 'origin: chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn' -H 'content-type: application/json' -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36' -H 'infura-source: metamask/internal' -H 'sec-fetch-site: cross-site' -H 'sec-fetch-mode: cors' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en,fr;q=0.9,en-US;q=0.8,es;q=0.7' --data-binary '{"id":417110591973,"jsonrpc":"2.0","method":"eth_estimateGas","params":[{"from":"0xfdea65c8e26263f6d9a1b5de9555d2931a33b825","value":"0x0","data":"0xa9059cbb000000000000000000000000fdea65c8e26263f6d9a1b5de9555d2931a33b8250000000000000000000000000000000000000000000000000000000000000000","to":"0x4946fcea7c692606e8908002e55a582af44ac121","gas":"0x90a61c"}]}' --compressed
Which returned a value of {"jsonrpc":"2.0","id":417110591973,"result":"0x8e54"}.
That hex value translates to 36436.
Clicking Edit gas > Advanced to view the gas estimate in UI shows a gas limit of 54654, which is 50% higher, and accurately reflects the 1.5x buffer we add when suggesting a gas limit.
This transaction was sent with the MetaMask-suggested gas limit.
This transaction resulted in a success.
Maybe FOAM wasn't one of the affected tokens. Trying again with one listed by David Pazdan.
On checking his latest comment, I see that he experienced a correct estimate upon editing gas value. This suggests that maybe the increased gas buffer is only being added after "Edit" is clicked. I will now try again without opening the edit screen, and I will try with DAI:
This initiated the following request to infura:
curl "https://api.infura.io/v1/jsonrpc/mainnet" -H "authority: api.infura.io" -H "accept: application/json" -H "origin: chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn" -H "content-type: application/json" -H "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36" -H "infura-source: metamask/internal" -H "sec-fetch-site: cross-site" -H "sec-fetch-mode: cors" -H "accept-encoding: gzip, deflate, br" -H "accept-language: en,fr;q=0.9,en-US;q=0.8,es;q=0.7" --data-binary "^{^\^"id^\^":417110591976,^\^"jsonrpc^\^":^\^"2.0^\^",^\^"method^\^":^\^"eth_estimateGas^\^",^\^"params^\^":^[^{^\^"from^\^":^\^"0xfdea65c8e26263f6d9a1b5de9555d2931a33b825^\^",^\^"value^\^":^\^"0x0^\^",^\^"data^\^":^\^"0xa9059cbb000000000000000000000000c5b8dbac4c1d3f152cdeb400e2313f309c410acb00000000000000000000000000000000000000000000000000038d7ea4c68000^\^",^\^"to^\^":^\^"0x6b175474e89094c44da98b954eedeac495271d0f^\^",^\^"gas^\^":^\^"0x904ec9^\^"^}^]^}" --compressed
Which resulted in this response:
{"jsonrpc":"2.0","id":417110591976,"result":"0xcb1a"}
Which translates to 51994 gas, which is more expensive than a FOAM transfer, but could totally be within normal variation.
I opened the inspector then to see what the gas estimates were being used by the UI.
The TX was initialized with a gas value of 0x130a7 or 77991, which is the higher fudged value, so this looks good so far.
Then there is then an estimatedGas value set to the same thing, so it's all looking good so far, in terms of the tx using the upward-fudged estimate of what the node told us.
This transfer was also successful, and so I have been unable to reproduce this bug.
I would like to analyze some state logs from users who were affected, to see when the estimate may be varying unacceptably.
In the meanwhile, we could increase our gas-buffer value from 1.5 to something else. Would we dare give it a full 2x?
David has a good bug reproduction video. In it, he:
I'd ask: Are affected users all using the advanced gas inputs? I enabled advanced gas inputs, and also used the action-view to send, neither allowed me to reproduce the issue.
I'm only able to reproduce this consistently with advanced gas controls enabled. Disabling it seems to fix. Also interesting, the default gwei is greatly different when this setting is enabled vs disabled.
I'll circle back with others to see if they all have advanced gas setting enabled. 馃憤
support case with logs to review: 28817
will add more here as we get them.
Following advice from the support team, I have increased my Gas Limit to 100,000 for each of the ERC20 token and saved this setting via the 'Advance Options' button. This seems to have fixed the issue for me.
Thanks MM support.
Most helpful comment
I'm only able to reproduce this consistently with advanced gas controls enabled. Disabling it seems to fix. Also interesting, the default gwei is greatly different when this setting is enabled vs disabled.
I'll circle back with others to see if they all have advanced gas setting enabled. 馃憤