Description

The isActiveSrc and isActiveDest properties on the chains feature flag are being deprecated. If a chain exists in the chainRanking array, it is now assumed to be enabled as both source and destination. This PR migrates all selectors that previously checked chains[chainId].isActiveSrc / chains[chainId].isActiveDest to instead check for the chain's presence in chainRanking.

This eliminates a pain point where adding a new network required an entry in both chainRanking and chains — now chainRanking is the single source of truth for whether a network is enabled.

Changes:

• selectIsBridgeEnabledSourceFactory — checks chainRanking presence instead of chains[chainId].isActiveSrc
• selectEnabledSourceChains — same migration
• Removed selectEnabledDestChains, selectIsBridgeEnabledDest, and selectIsSwapsLive selectors (no longer needed with the new model)
• Removed unused imports (PopularList, selectHasCreatedSolanaMainnetAccount)
• Updated tests to match new behavior: disabling a chain means removing it from chainRanking

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

Feature: Bridge chain enablement via chainRanking

  Scenario: user opens swap/bridge for a supported network
    Given the user has a wallet with tokens on Ethereum Mainnet
    When user opens the swap or bridge view
    Then Ethereum Mainnet is available as a source network

  Scenario: user opens swap/bridge for a network not in chainRanking
    Given the user has a wallet on a network not listed in chainRanking
    When user opens the swap or bridge view
    Then that network is not available as a source network

  Scenario: user selects destination token on a newly added network
    Given a new network has been added to chainRanking
    When user opens the bridge token selector for destination
    Then the new network appears and its default destination token loads correctly

Screenshots/Recordings

Not applicable — no UI changes.

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.

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.