MetaMask / MetaMask/metamask-extension
MetaMask architecture blocks front-running protection and gasless applications.
- Dominant language
- TypeScript
- Stars
- 13.2k
- Forks
- 5.6k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 451
Description
Currently, MetaMask has 2 huge flaws which block the development of gasless tech and front-running protection for users:
**1. The inability to sign transactions without also broadcasting them (first raised in #3475).**
Relays which protect users from front-running require bundles of signed transaction to be submitted to them (ie [flashbots](https://github.com/flashbots/mev-relay-js) which has 60% of network hashpower right now). Unlike other wallet providers, MetaMask refuses to just sign a transaction without also attempting broadcast. I understand the reasoning for this at the time, but the situation on Ethereum network is now very different from before, and this is a common user requirement. A huge % of blocks now contain bundle-style transactions, and there are a bunch of white-hat tools being built around this need (https://flashbots.tools/)
**2. Exception thrown by MetaMask when submitting 0 GWEI transactions**
A potential workaround for 1 is to connect MetaMask to a custom backend RPC to capture the serialised transaction and increment nonces for multiple user tx's in a bundle. However, MetaMask actually throws exceptions on any TX prices under 1 GWEI. This issue makes it impossible for gasless applications to support MetaMask.
Unfortunately, as part of a team working on next-generation gasless technology, we are in the difficult situation of having to recommend our users away from MetaMask, and instead onto other wallet providers which don't have this limitation. This is a tough move to make considering the popularity of MetaMask and our personal support for the project, but unfortunately in its current form MetaMask architecture blocks support for front-running protection and gasless transactions.
As the situation on Ethereum is different to when decisions such as #3475 were taken, can we revisit this issue and see if there is appetite in the MetaMask team for change. There are a lot of projects and teams now building in the gasless/privacy sphere, and without the issues outlined above being addressed there is a risk of MetaMask no longer being the de-facto wallet for next-generation applications.
Contributor guide
Research direction
Start by reviewing the prior discussion in #3475 and the issue's Flashbots references, then trace the wallet flows for signing versus broadcasting and validation of transaction prices below 1 GWEI. Done would mean MetaMask can support signed transactions without broadcasting and does not reject 0 GWEI transactions for gasless applications.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- blockchain
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100