feat: save custom gas settings

[pedronfigueiredo]

Summary

• Persist custom gas fee settings from the advanced gas modals.
• Read saved gas preferences when building fee options for send confirmations.
• Wire mobile PreferencesController and TransactionController integration for saved gas fee preferences.

Related PRs

• feat: reintroduce saved gas settings metamask-extension#43317
• feat(transaction-controller): support saved gas fee levels core#8993

Testing

• yarn jest app/components/Views/confirmations/components/modals/advanced-eip1559-modal/advanced-eip1559-modal.test.tsx app/components/Views/confirmations/components/modals/advanced-gas-price-modal/advanced-gas-price-modal.test.tsx app/components/Views/confirmations/hooks/gas/useGasFeeEstimateLevelOptions.test.ts app/components/Views/confirmations/hooks/gas/useGasPriceEstimateOption.test.ts app/components/Views/confirmations/hooks/gas/usePersistGasFeePreference.test.ts app/core/Engine/controllers/preferences-controller-init.test.ts app/core/Engine/controllers/transaction-controller/metrics_properties/gas.test.ts app/core/Engine/controllers/transaction-controller/transaction-controller-init.test.ts (8 suites, 78 tests).

---

Note

Medium Risk
Changes transaction gas defaults and persisted wallet state for all EVM sends; send navigation now depends on async addTransaction success, so regressions could affect fees or confirmation entry.

Overview
Adds per-account, per-chain persistence for gas choices so confirmations can reuse saved fee levels and custom EIP-1559 / legacy values on later sends.

Write path: New usePersistGasFeePreference calls PreferencesController.setAdvancedGasFee after gas updates in advanced modals and preset estimate hooks (alongside existing updateTransactionGasFees). Preferences init gains persisted advancedGasFee state and metadata.

Read path: TransactionController is wired with getSavedGasFees, loading preferences by normalized from address and chainId (skipped for MM Pay and unsupported levels like dapp-suggested).

Send flow: EVM submit is awaited; navigation to confirmations only runs after addTransaction succeeds, with an alert on failure. submitEvmTransaction returns transactionMeta.

Engine: ApprovalController is initialized via messenger (approval-controller-init) instead of wallet-only options; transaction init messenger includes GasFeeController:fetchGasFeeEstimates. Gas analytics map UserFeeLevel.DAPP_SUGGESTED to dapp_proposed.

^{Reviewed by Cursor Bugbot for commit 3cfc658. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[mm-token-exchange-service]

PR template — items to address before "Ready for review"

Warnings — informational, address before merging:

• PR body does not match pull-request-template.md (one or more section headings are missing). See https://github.com/MetaMask/metamask-mobile/blob/main/.github/scripts/shared/pr-template-checks.ts#L15-L23.

See docs/readme/ready-for-review.md for the full Definition of Ready for Review.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 586023b. Configure here.}

[cursor]

Awaiting EVM submit blocks loader

High Severity

The EVM send path now awaits submitEvmTransaction before navigating to redesigned confirmations. That keeps the user on the send screen until addTransaction finishes and delays mounting the transfer confirmation skeleton loader, which is meant to show while submission runs in the background.

 

^{Triggered by learned rule: Do not await submitEvmTransaction in send/confirm action hooks — blocks skeleton loader}

^{Reviewed by Cursor Bugbot for commit 586023b. Configure here.}