MetaMask / MetaMask/metamask-extension

[Bug]: Too-frequent gas repricing acts as effective DoS

Open
#15,347 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

external-contributor Gas INVALID-ISSUE-TEMPLATE T08-featureRequest team-confirmations
Dominant language
TypeScript
Stars
13.2k
Forks
5.6k
Avg merge
2d 5h
Merged PRs (30d)
451

Description

**Describe the bug**

Too-frequent gas repricing makes it very difficult to click the Confirm button during short windows when it's available for clicking.

Though the exact details of what gas prices might be best for different speeds of confirmation can be computed every block, that doesn't mean they should be. This is a request to add an lock/unlock icon on the screens which refresh for gas repricing, and/or a user-configurable option to not do gas repricing for a transaction more than once every so many seconds/minutes, with a default of 1 minute.

**Steps to reproduce**

1. I am connected to Polygon's Mumbai testnet, and trigger a transaction.
2. The confirmation window pops up, showing an estimated gas fee, max fee, and total (amount + gas fee) and buttons to revert/confirm.
3. This network has a block time of about 5 seconds.
4. What looks like it might be every block, the confirm button becomes inactive (becoming inactive before it's grayed out), then is grayed out while the number go through a disappear and reappear animation, coming back slightly different reflecting new gas price proposals updated to the latest block. The confirmation is disabled for approximately 3 seconds.
5. This makes what should be a relatively simple UX into a frustrating game of cat-and-mouse trying to click to confirm a transaction during a brief window while the button is active. It is also quite unrealistic to expect people to read and understand all 6 numbers, each displayed to 8 decimal points, and consider the impact of clicking Confirm before doing so, within such a short time window before the confirm button is disabled again and the numbers go away for a change.
6. When clicking the Confirm button between the time it is actually disabled and the time it is shown as disabled, or at the beginning of the time it's shown as disabled, the user is left uncertain about whether that transaction has been confirmed and they are simply being presented with another one right away, or if it is still the same first transaction that just hasn't been confirmed yet (it's the latter). This is also a bad user experience.
7. It's worse if you want to edit the priority e.g. to the High or Low setting because then you have to time clicks into the window just right twice per transaction. (The user should also be able to configure which of these is default for new transactions).
8. It's worse on a slower computer.

**Version**

10.17.0

**Browser**

Chrome

**Operating system**

Windows

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the confirmation window on Polygon's Mumbai testnet and trace the gas repricing flow used while the transaction is pending. Done should mean repricing no longer repeatedly blocks the Confirm button, with the chosen locking or configurable update interval reflected consistently in the transaction UI.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.