Create a SIP that empowers protocol/dapp devs to provide end-users with ideal gas params / txn fee controls on a per-network basis

[tayvano]

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

[emilianobonassi]

Supporting this!

Related issues

Zora: MetaMask/metamask-extension#20501

Ancient8: MetaMask/metamask-extension#22651

[emilianobonassi]

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

[emilianobonassi]

another one

MetaMask/metamask-extension#22800

[agileurbanite]

👍

[emilianobonassi]

any update on this @tayvano ?

[Montoya]

@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.