Description

In QuickBuy Sell mode the user sells the fixed position token and chooses which token to receive. The Receive picker (useReceiveTokens) only listed stablecoins (mUSD/USDC/USDT), so native tokens were never offered.

This PR extends the Receive candidate set to always include the native token of every chain already covered by the stablecoin candidates, so natives and stablecoins are always visible regardless of balance. Natives are built via the existing Bridge helper getNativeSourceToken(chainId) and enriched through the same enrichTokenBalance path (the isNativeAddress branch already handles native balance/pricing), so no controller changes were needed. Candidates are ordered stablecoin-before-native within each chain group and the position chain is sorted first, which keeps a stablecoin as the default selection (sellDestTokenOptions[0]).

Changelog

CHANGELOG entry: Fixed QuickBuy sell flow so native tokens are always shown alongside stablecoins in the "Receive" token list.

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/TSA-642

Manual testing steps

Feature: QuickBuy sell receive token list

  Scenario: user opens the Receive picker when selling a position
    Given I am on a trader position and open QuickBuy
    And I switch to Sell mode
    When I open the "Receive" token picker
    Then the list shows the native token and stablecoins for each supported chain
    And the position chain's stablecoin is selected by default
    And tokens I do not hold still appear with a $0.00 balance

Screenshots/Recordings

Before

N/A

After

N/A

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.

Made with Cursor