Open tayvano opened 5 months ago
Supporting this!
Related issues
Zora: https://github.com/MetaMask/metamask-extension/pull/20501
Ancient8: https://github.com/MetaMask/metamask-extension/pull/22651
An idea is having a new rpc method (e.g. optimism_l1fee
, better if more universal) for networks to report these informations and respective support
👍
any update on this @tayvano ?
@emilianobonassi MetaMask internal teams are building an architecture for supporting gas fee calculations across various L2s. We are not yet ready to build a Snap interface to that, but we are open to exploring it in the future.
Context
Responsibility for network support / network UX on MM side currently split between Confirmations team and Assets team.
"Our gas logic should be more easily extendable so we can hopefully no longer be gatekeepers to networks having an optimal UX"
"Until then, we have to manually add networks/custom logic"
"We’re trying to get away from being a gatekeeper as soon as possible"
internal link to ad-hoc slack convo
Overview / Ideal Outcomes
Networks should be able to better handle gas / txn fee logic on behalf on their users via a Snap.
This will result in better experience for:
end-users who currently face unideal experience on EVM networks if their transaction fee parameters / structure differs from Ethereum
network/protocol/core developers who have to chase MetaMask to update fee handling every time they update something
dapp developers who are reliant on MetaMask to support and update various networks
MM developers who are currently inadvertently gatekeeping ideal network support/experience and thus have to keep track of all the networks and their various fee structures and logic
adjacent / enablement teams who currently have to play biz dev games with protocol/dapp devs who are trying to get get permission from MetaMask so their users txn's dont fail / suck.
tl;dr