[Bug]: incorrect gas estimation on BSC when gasPrice is not explicitly supplied by the website

[Snugface]

Describe the bug

MetaMask incorrectly estimates gas settings on BSC when no gas price is explicitly supplied by the website.
Likely the bug is only specific to BSC, though I haven't tried reproducing it on other chains.

Steps to reproduce

1. Initiate transaction with a contract on BSC using web3.js without explicitly supplying any gas settings, like so:
   contract.methods.function(args).send({ from: address });
2. Review gas settings automatically picked by Metamask, and observe that they are falsely reported as "suggested by site", while also being too low for the tx to go through

2. Screenshots

3. Send transaction. It will fail with "transaction undepriced" error
4. Now, to avoid this bug one must manually supply gasPrice, for example: contract.methods.function(args).send({ from: address, gasPrice: '3000000000' });
5. Review gas settings again. Same contract, same function, same arguments. Same report from Metamask, that gas settings are supplied by the site. But this time it is true, and those gas settings are adequate

5. Screenshots

6. Send transaction. Transaction succeeds

Error messages or log output

MetaMask - RPC Error: [ethjs-query] while formatting outputs from RPC '{"value":
{"code":-32603,
"data":{
"code":-32000,
"message":"transaction underpriced"
}}}'

Version

10.34.3

Build type

None

Browser

Chrome, Firefox

Operating system

Windows, Linux

Hardware wallet

No response

Additional context

web3.js version 1.6.1
RPC in use: https://bsc-dataseed2.binance.org:443 on website; https://bsc-dataseed1.binance.org:443 in wallet. Likely the same behavior is present on others, but I tested with these.
Same behavior is observed with payable and non-payable contract functions. Behavior only first appeared about 3-5 days back. So far every user who reported this behavior is a Metamask user.
No changes were made to the website codebase recently(for many weeks). So the bug is being caused either by updates in Metamask or in BSC nodes.

[Snugface]

Also just confirmed that the same bug is happening on other websites(which don't explicitly set gas price), not just the site I'm the maintainer of.

[qq919006380]

I had the same issue as you, but it got resolved after switching to a different RPC. Free RPCs can become unstable occasionally, especially during network congestion. You can consider adding a few backup RPCs or opting for paid ones.

[Snugface]

Well, the truth is: RPC is reporting the correct gas price.
web3.eth.getGasPrice() reports 3 Gwei, as it should. And if I manually add that to transaction like so:

rpcGasPrice = await web3.eth.getGasPrice()
contract.methods.function(args).send({ from: address, gasPrice: rpcGasPrice })

it works as expected. And transaction goes through. So the problem isn't with the RPC reporting a wrong value; or at least it reports it correctly to web3.js.

Besides, MM receives 2.5 Gwei from somewhere instead. Not 0, but a specific value. And then also it says to the users that this is what the website suggested to it, which isn't true. It also calculates the gas limit correctly, as you can see from my screenshots.
Moreover, I've never-ever-ever before encountered this issue on BSC, where gas prices are fixed and never change. And no one ever reported it. Until a few days ago.
I can also consistently reproduce it. And other users are reporting it, too. And they, so far, were only MetaMask users. So I believe it is a recently-introduced bug, and not an RPC issue

[arti210]

Describe the bug

MetaMask incorrectly estimates gas settings on BSC when no gas price is explicitly supplied by the website.
Likely the bug is only specific to BSC, though I haven't tried reproducing it on other chains.

Steps to reproduce

1. Initiate transaction with a contract on BSC using web3.js without explicitly supplying any gas settings, like so:
   contract.methods.function(args).send({ from: address });
2. Review gas settings automatically picked by Metamask, and observe that they are falsely reported as "suggested by site", while also being too low for the tx to go through

2. Screenshots

3. Send transaction. It will fail with "transaction undepriced" error
4. Now, to avoid this bug one must manually supply gasPrice, for example: contract.methods.function(args).send({ from: address, gasPrice: '3000000000' });
5. Review gas settings again. Same contract, same function, same arguments. Same report from Metamask, that gas settings are supplied by the site. But this time it is true, and those gas settings are adequate

5. Screenshots

6. Send transaction. Transaction succeeds

Error messages or log output

MetaMask - RPC Error: [ethjs-query] while formatting outputs from RPC '{"value":
{"code":-32603,
"data":{
"code":-32000,
"message":"transaction underpriced"
}}}'

Version

10.34.3

Build type

None

Browser

Chrome, Firefox

Operating system

Windows, Linux

Hardware wallet

No response

Additional context

web3.js version 1.6.1
RPC in use: https://bsc-dataseed2.binance.org:443 on website; https://bsc-dataseed1.binance.org:443 in wallet. Likely the same behavior is present on others, but I tested with these.
Same behavior is observed with payable and non-payable contract functions. Behavior only first appeared about 3-5 days back. So far every user who reported this behavior is a Metamask user.
No changes were made to the website codebase recently(for many weeks). So the bug is being caused either by updates in Metamask or in BSC nodes.

[Snugface]

"Hey, guys. Metamask team here. We just wanted to thank you for reporting this bug. It's not too serious, but it definitely is a bug that we introduced recently. And it also misleads users, by telling them that gas-estimation was done incorrectly on the side of a web3 app, while it is being done incorrectly by Metamask.
We wanted to show you how much we care about this, that's why for a week we haven't even acknowledged whether this is indeed a bug or not."

[Snugface]

Opened a duplicate issue, against the best practices, but in the hope that it does get some acknowledgement from the maintainers.
#20797

[Snugface]

Updates in the duplicate issue. Comment from a MetaMask representative:
#20797 (comment)

Duplicate of #20699 , opening multiple issues of the same content is not the intended way to get our attention...If anything it undermines it as it creates more noise.

We're still no further with the issue itself though. But that's something, definitely.

[bschorchit]

Due to timing, this seems related with the BNB chain upgrade to use EIP1559. We'll look into it.

[Snugface]

Due to timing, this seems related with the BNB chain upgrade to use EIP1559. We'll look into it.

Thank you!
I was always so confused with baseFee and maxPriorityFee before this, being a BSC dev. Googled the EIP, and found a good explanation
https://www.quicknode.com/guides/ethereum-development/transactions/how-to-send-an-eip-1559-transaction
Will bear in mind that this has also been rolled out to BSC. Really, thank you. This is informative.

[brad-decker]

@Snugface i'm opening a PR that references this issue, but it only helps with the formatting of the error thrown not the error itself. Just wanted to make sure I don't provide any false hope for a prompt resolution ☹️ BUT hopefully this will allow us to get actual stack traces in our error reporting tool that will further our efforts to resolve this (and other) issues.

repost cause the duplicate issue I worked with confused me :P

[Snugface]

@brad-decker Much appreciated! Thank you for continuing to dig into this. Better stack traces are always good.

[segun]

I can't seem to replicate the invalid gas issue, I can see that the label says Site Suggested even though I didn't provide gas, but the gas suggested is enough for the transaction. Asides the wrong labelling, everything seems ok.

Please see attached screen capture.

Here's my source code

   const jsonInterface = [
        {
            "inputs": [],
            "name": "retrieve",
            "outputs": [
                {
                    "internalType": "uint256",
                    "name": "",
                    "type": "uint256"
                }
            ],
            "stateMutability": "view",
            "type": "function"
        },
        {
            "inputs": [
                {
                    "internalType": "uint256",
                    "name": "num",
                    "type": "uint256"
                }
            ],
            "name": "store",
            "outputs": [],
            "stateMutability": "nonpayable",
            "type": "function"
        }
    ];


    if (window.ethereum) {
        await window.ethereum.request({ method: 'eth_requestAccounts' });
        window.web3 = new Web3(window.ethereum);
        console.log('web3 enabled', window.web3);

        const accounts = await window.web3.eth.getAccounts();

        const contract = new web3.eth.Contract(jsonInterface, "0xd4f6d842Bc1526EFB3be6f01d3E6EBDd6A733d0b");
        let result = await contract.methods.retrieve().call();
        console.log('result', result);
        // await contract.methods.store(100).send({ from: accounts[0], gasPrice: '3000000000' });
        await contract.methods.store(100).send({ from: accounts[0]});
        result = await contract.methods.retrieve().call();
        console.log('result', result);
    } else {
        console.error('No Metamask');
    }

and here's the screen capture

Screen.Recording.2023-10-19.at.17.04.01.mov

cc @seaona @bschorchit

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

[github-actions]

This issue was closed because there has been no follow up activity in the last 45 days. If you feel this was closed in error, please reopen and provide evidence on the latest release of the extension. Thank you for your contributions.