MetaMask / MetaMask/metamask-extension
Allow setting shorter `pollingInterval` for tx receipts + requirements for tx receipt validity
- Dominant language
- TypeScript
- Stars
- 13.2k
- Forks
- 5.6k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 451
Description
This issue is related to https://github.com/MetaMask/metamask-extension/issues/13302 but it also close to a feature request.
**Context**
I'm experimenting with adding support for inclusion preconfirmations on Ethereum Mainnet using [Bolt](https://boltprotocol.xyz/) ([Flow docs](https://chainbound.github.io/bolt-docs/flows/inclusion-flow)). In essence, this consists of giving an user a near-instant feedback of successful execution on transactions which cannot fail like transfers (after basic balance checks), for which inclusion is credibly guaranteed by proposers using collateral at a later block.
**Why `pollingInterval` and receipts**
One way this could be achieved in MetaMask would be leveraging a shorter `pollingInterval` to ask for a transaction receipt which would be returned by an appropriate RPC aware of this primitive. This is because the wallet knowns already how to update its internal state and display such changes to the user, and the receipt is what's needed in order to show an execution confirmation.
**Receipts validity**
However, one challenge of this is that it requires MetaMask accepting a receipt that isn't completely backed by real data, because `blockHash`, `blockNumber`, `transactionIndex`, `cumulativeGasUsed` cannot be predicted until the block is actually created. At the same time, I'm not sure which of these fields is needed in order to make MetaMask work correctly. I did some attempts and my mocked receipts where rejected, and the tx was shown as still pending.
**Desiderata**
I'd be very grateful to know if it possible to:
- Allow setting a shorter `pollingInterval` for the transactions receipts -- this would benefit the UX also on rollups as outlined on https://github.com/MetaMask/metamask-extension/issues/13302
- Know what MetaMask needs in order to consider a receipt valid. I'm not very familiar with the codebase and I had some difficulties in finding this answer by myself.
- Lastly, if no mocked receipts can be accepted by MetaMask as of now, would you be available to allow this behind an "experimental" feature flag?
Thanks a lot for the collaboration.
Contributor guide
Research direction
No files, tests, or entry points are named. Start by tracing transaction receipt polling and the validation checks that keep a transaction pending, then determine which receipt fields MetaMask requires and whether shorter polling or experimental mocked receipts are feasible. Done would require a decided scope and documented validity requirements.
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
- Needs clarification
- Newbie friendliness
- 25/100