[Bug]: Received and Confirmed Custom Nonce is Ignored by the Transaction Constructor

[ariutokintumi]

Describe the bug

When developing a dApp that's intended to cancel pending transactions, I observed an inconsistency in MetaMask's UI behavior, particularly concerning nonce reuse. I wish to highlight a specific anomaly for this report.

Steps to reproduce

1. Create a transaction, either manually or using a script, with the following configuration:

        gas: 23000n,
        maxFeePerGas: parseEther('1', 'gwei'), // Set gas to 1 gwei (This will ensure the transaction isn't processed quickly. If it does process quickly, retry when gas is greater than 5, for instance.)
        maxPriorityFeePerGas: parseEther('0.000000001', 'gwei'), // 1 wei is the minimum acceptable value for this parameter.

This transaction, once submitted, should remain in the PENDING state within the mempool queue.

2. Now, attempt to override (or replace) the pending transaction using a script (e.g., ethers). Assume that the nonce is '13'. Use this configuration:

        gas: 23000n,
        maxFeePerGas: parseEther('1.1', 'gwei'), // pending tx gas plus 10%
        maxPriorityFeePerGas: parseEther('0.000000002', 'gwei'),  //pending tx priority fee plus 10%, since is wei value, we must rund up
        nonce: 13, // This assumes the nonce of the current pending transaction is 13, if not change to your pending nonce.

3. The observed result and discrepancy can be seen in the provided screenshot:

• A custom nonce (in this case, '13') is set for the transaction.
• This nonce is recognized and confirmed by MetaMask's UI.
• However, the transaction constructor at the bottom ignores the custom nonce.
• Consequently, if we dispatch the transaction via MetaMask, it adopts a new nonce (e.g., '14'), which was not the intended behavior.

Note: Manually entering the nonce value ('13') in the bottom section facilitates the desired transaction flow, successfully replacing the earlier one. This indicates that there isn't an inherent "correction" occurring for an erroneous nonce. The issue appears to stem from a partial UI integration lapse during transaction formulation or dispatch.

Error messages or log output

There aren't explicit error messages, just the deviation from the expected behavior as detailed above.

Version

10.35.1

Build type

None

Browser

Chrome, Firefox, Brave

Operating system

Windows, MacOS, Linux

Hardware wallet

No response

Additional context

There are several other issues pertaining to pending transactions and their overrides. I plan to file separate reports for each to ensure clarity and specificity. There seems to be a notable misalignment between the expected behavior, as dictated by the MetaMask interface, and the actual outcomes experienced by users. This particular bug report is one manifestation of that broader pattern of discrepancies.

[anaamolnar]

Hello, @ariutokintumi. Thanks for the detailed report! I will pass this on to the team.

[ariutokintumi]

gm @anaamolnar, I hope you're doing well. I wanted to inquire if there's been any update regarding this issue or if there's a particular process to follow up on it. We're eager to resolve this as it has some impact on our project's timeline. Please let us know if we can assist or collaborate in any way to expedite a solution. Thank you for your time and understanding.

[bschorchit]

I don't think we currently support nonce management by the dapp. This might be a feature request. I'll check internally.

[ariutokintumi]

I don't think we currently support nonce management by the dapp. This might be a feature request. I'll check internally.

gm @bschorchit, thank you for taking the time to address this issue. As depicted in the provided screenshots and based on the features that have been a part of MetaMask Extensions for years, nonce management is indeed possible.

Users can manage it manually by activating the appropriate option in the Configuration. Once activated, they can input the desired nonce in the provided field, as long as it adheres to the standard.

From a coding perspective, it ought to be feasible. The UI captures it through the call, evident from the screenshot I provided. This indicates that it can be managed programmatically. However, there seems to be a disconnect between the "transaction constructor" and the "received custom nonce." It appears that the "nonce calculation function" is overwriting this custom setting before processing the transaction.

I hope this sheds light on the issue at hand. I'm looking forward to collaborating with you to resolve this matter.

Thank you for your dedication and effort!

[CryptoReuMD]

Hello friends. Tanks for the update. i think it's essential that this bug it's solved. It's native, you can change the Nonce and also you can clear the nonce.

Happy to help

[angelmc32]

I think this is a big bug as the UI indicates that the functionality is expected, and it's a use case that we will see more and more.

[bschorchit]

Per our developer docs, we currently don't support nonce to be managed by the dapp.

[ariutokintumi]

gm @bschorchit, I appreciate the clarification provided in the developer docs. However, I observe a contradiction in the policy that needs addressing. While I understand the caution around nonces as users might mishandle them, MetaMask does permit users to customize nonces as demonstrated here. Yet, it doesn’t extend the same trust to developers who arguably possess equal or greater knowledge than typical users.

Moreover, the scenario of a user interacting with multiple applications, pending transactions, and using the same account across various devices is outlined as problematic. Could you elaborate on the exact issue this scenario presents?

From a logical and programming perspective, this explanation seems inadequate. Interaction protocols exist to be utilized within their defined rules, and misuse is possible in any scenario, not necessarily a valid argument for restriction.

Furthermore, there are notable issues with MetaMask's transaction queue management, leading to user confusion and operational problems, specifically around nonces. I've outlined two clear examples below:

1. Incorrect Transaction Replacement Information: Reproduction Steps: Replace an 'ETH sending transaction' (increasing gasPrice and priorityFee by 10%) with an 'NFT minting transaction'. Observed Issue: MetaMask's UI incorrectly confirms the completion of the initial 'ETH sending transaction', which, in reality, never transpired.

2. Incorrect Transaction Nonce Order: Reproduction Steps: Send three transactions with significantly low gas configurations daily and wait for seven days (mempool re-broadcasting). Observed Issue: The transaction with the lowest nonce (which should be processed first) is mistakenly listed third in MetaMask’s UI queue. Consequently, the 'Speed Up' button is assigned to the wrong nonce, rendering it ineffective when used.

These issues indicate that the complications reside not with the nonces themselves but with the handling of the pending transaction queue and transaction replacements by MetaMask. Addressing these issues would significantly enhance user experience and trust in the platform.

Looking forward to your thoughts and responses to these concerns, which I think should be reconsidered ASAP.

[ariutokintumi]

gm, is here any update about this issue?

I have a lot of more issues about nonce error handling in Meta Mask extension but this is the most important.