Description

Problem statement:

• Some networks like Monad require a Reserve Balance to be kept at all times in a given account.
• This constraint is usually not explicitly reflected in UX in most wallets, but the limit is real and a tx may fail if user accounts go below that minimum reserve. For example it is of 10 MON for Monad.
• MetaMask Swap will always run a pre-flight simulation while fetching, triggering an error message when trying to swap MON in a swap that would put it's reserve below the 10 MON threshold.

Proposed solution

• Keep showing quotes to the user when it this situation (same as the "not enough balance" situation) -> Lift this balance constraint during pre-flight simulation by setting the insufficientBal parameter to true.
• Display a specific Banner Alert for this specific issue, explaining the constraint of the user.
• (nice to have) Add a Use max available CTA in the Alert Banner that will prefill automatically balance - minimumReserve as source amount. This solution ticks three boxes:

1. Preserves the "max" button original behavior without polluting it with per-chain logic.
2. Avoids terrible UX where clicking on "max" would not select "max".
3. Allows the user to be informed about the constraint, and be aware of the consequences.

Changelog

CHANGELOG entry: Swap/Bridge to warn user if native balance will go below a minimum threshold.

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/NEB-1113?atlOrigin=eyJpIjoiYmRkZGU5ZjE0MTRhNDM4OTgyNWZjOGJlMDU1YTliZDMiLCJwIjoiaiJ9

Manual testing steps

Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.