Create a SIP that empowers protocol/dapp devs to provide end-users with ideal gas params / txn fee controls on a per-network basis
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
:meow_grumpy: –rekmarks
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
another one
https://github.com/MetaMask/metamask-extension/pull/22800
👍
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.