Narrow getStateForAssetSelector inputs: whole-controller spreads over-subscribe selectAssetsBySelectedAccountGroup, re-deriving all assets on asset-irrelevant controller churn

[MajorLift]

Performance audit finding · Severity: Sev3 (corrected from High — see below) · Effort: Low–Medium · Fix risk: Low (behavior-preserving input narrowing) · Test safety net: Partial
Owner: @MetaMask/metamask-assets (suggested)
File: app/selectors/assets/assets-list.ts:107,157

What is this about?

Correction to the original framing. This ticket previously claimed the cost was a per-check deep compare of the entire asset state that "scales with power-user data." That mechanism does not hold up under inspection:

• createDeepEqualSelector uses fast-equals deepEqual (app/selectors/util.ts:30), not lodash. deepEqual short-circuits on reference-equal sub-values (an a[key] === b[key] fast path per key) and bails on the first difference. A fresh wrapper object does not force a full traversal.
• The bulk slices in the composite — allTokens, tokenBalances, marketData, balances, conversionRates, assetsMetadata, accountsAssets, … — are each produced by a createDeepEqualSelector in assets-migration.ts, so they are reference-stable when unchanged. deepEqual hits === on those keys and never descends into the thousands-of-entries token/balance subtrees.

So the per-check compare is ~O(number of top-level composite keys) pointer comparisons, not O(asset count). The deep-compare cost is not the problem.

The real issue is input over-subscription → unnecessary result recomputation. getStateForAssetSelector (:107) spreads three whole controllers into the composite:

return {
  ...AccountTreeController,   // 5 fields; consumer reads only `accountTree`
  ...AccountsController,      // ≈ internalAccounts (consumed)
  /* … stabilized get* slices: allTokens, tokenBalances, marketData, … … */
  ...NetworkController,       // 3 fields; consumer reads only `networkConfigurationsByChainId`
  accountsByChainId,
};

But the upstream consumer _selectAssetsBySelectedAccountGroup reads a narrow AssetListState (@metamask/assets-controllers, selectors/token-selectors.ts:94) — from those three controllers it uses only accountTree, internalAccounts, and networkConfigurationsByChainId. The spreads drag every other field into the deep-equal'd composite, where any change to an extraneous field flips deepEqual to false and re-runs the full asset derivation — producing a new output reference that cascades to the 15+ dependent selectors and the per-row selectAsset (#31492).

The extraneous fields are exactly the ones that churn on background timers, unrelated to any balance/price change:

• NetworkController.networksMetadata — network availability / EIP-1559 status polling (per enabled network).
• NetworkController.selectedNetworkClientId — changes on every network switch.
• AccountTreeController.isAccountTreeSyncingInProgress — a boolean that toggles on every account-tree sync cycle (≥2 deepEqual=false flips per sync).
• AccountTreeController.hasAccountTreeSyncingSyncedAtLeastOnce, accountGroupsMetadata, accountWalletsMetadata — sync / metadata churn.

Each of these, while an asset surface is mounted, triggers a full asset re-derivation + a per-row selectAsset cascade across every visible token-list row — even though no token, balance, or price changed.

Component footprint (the cascade blast radius — GitHub code search, two hops from the root):

• Direct consumers: useTokensWithBalance (Bridge), useTokenAtomicActions (TokenDetails), and the send flow's useAccountTokens/useRouteParams.
• Via selectSortedAssetsBySelectedAccountGroup: the wallet token list itself (app/components/UI/Tokens/index.tsx — which renders TokenListItem per row, where selectAsset adds the per-row multiplier of Fix 3 per-row parameterized-selector cache misses in TokenListItem (fresh object-literal args) #31492; 26 component-side selectAsset references) and the Homepage tokens section.
• Via the useTokensWithBalance hook alone: 29 files — Bridge token selection and batch-sell, Card (asset balances, swaps, spending limit), Perps payment tokens, and the leaderboard QuickBuy flow.

Net: roughly 50 unique non-test files across 8 product surfaces (wallet home, homepage, token details, send, bridge, card, perps, quick-buy). On each spurious recompute the token list multiplies the per-row selectAsset re-derivation by every visible row.

Scenario

N/A — see Technical Details.

Design

N/A — internal performance change; no UI/design impact.

Technical Details

Fix direction — narrow the three spreads to the exact consumed fields; leave the already-stabilized get* slices untouched:

const getStateForAssetSelector = (state: RootState) => {
  const { AccountTreeController, AccountsController, NetworkController } =
    state.engine.backgroundState;

  return {
    accountTree: AccountTreeController.accountTree,
    internalAccounts: AccountsController.internalAccounts,
    allTokens: getTokensControllerAllTokens(state),
    allIgnoredTokens: getTokensControllerAllIgnoredTokens(state),
    tokenBalances: getTokenBalancesControllerTokenBalances(state),
    marketData: getTokenRatesControllerMarketData(state),
    assetsMetadata: getMultiChainAssetsControllerAssetsMetadata(state),
    accountsAssets: getMultiChainAssetsControllerAccountsAssets(state),
    allIgnoredAssets: getMultiChainAssetsControllerAllIgnoredAssets(state),
    balances: getMultiChainBalancesControllerBalances(state),
    conversionRates: getMultichainAssetsRatesControllerConversionRates(state),
    currencyRates: getCurrencyRateControllerCurrencyRates(state),
    currentCurrency: getCurrencyRateControllerCurrentCurrency(state),
    networkConfigurationsByChainId:
      NetworkController.networkConfigurationsByChainId,
    accountsByChainId: getAccountTrackerControllerAccountsByChainId(state) as /* … */,
  };
};

After this, the composite's only recompute triggers are genuine asset-relevant changes; networksMetadata / selectedNetworkClientId / account-tree sync-flag churn no longer invalidates it.

Keep createDeepEqualSelector — do not switch to a plain createSelector. The three narrowed fields (accountTree, internalAccounts, networkConfigurationsByChainId) are raw state reads, not deep-equal-stabilized, so a reducer that replaces one with a new-but-deeply-equal reference would force a recompute under a plain selector; deepEqual absorbs that. (This is the opposite of the original ticket's suggestion to drop the deep-equal wrapper, which would regress recompute frequency on these surfaces.)

Verify before narrowing that _selectAllAssets (via selectAllAssetsGrouped) and the Tron path (selectTronSpecialAssetsBySelectedAccountGroup) consume the same AssetListState and read no field beyond it.

Threat Modeling Framework

N/A — performance-only change; behavior is preserved, no new data flow / trust boundary / attack surface.

Acceptance Criteria

• Dispatching a NetworkController.networksMetadata update (or toggling AccountTreeController.isAccountTreeSyncingInProgress) with token/balance/price data unchanged does not increment selectAssetsBySelectedAccountGroup.recomputations().
• Recompute count on selectAssetsBySelectedAccountGroup increments ~once per actual asset-state change (token add/remove, balance, price, account-tree structure), not per background poll/sync.
• Profiler on a power-user profile: token list / asset surfaces stop re-deriving during network-status polling and account-tree sync; re-measure Fix 3 per-row parameterized-selector cache misses in TokenListItem (fresh object-literal args) #31492 after this lands.

References

• Files: app/selectors/assets/assets-list.ts:107 (input), :157 (wrapper); app/selectors/util.ts:30 (createDeepEqualSelector = fast-equals deepEqual); @metamask/assets-controllers selectors/token-selectors.ts:94 (AssetListState — the narrow consumed-field set)
• Downstream: Fix 3 per-row parameterized-selector cache misses in TokenListItem (fresh object-literal args) #31492 (per-row selectAsset — the recompute-cascade target, not a deep-compare cost)
• Pattern: input over-subscription (selector subscribes to whole controllers but reads a few fields), not the deep-compare cost originally claimed. Distinct failure shape from Stop deep-comparing the full transaction history per check in selectLocalTransactions #31499.
• Source: mms-performance dependency-tree mapping (perf: Augment mms-performance with frontend learnings from the Extension performance audit skills#49, mm-selector-cascade)
• Status: UNVALIDATED — mechanism corrected and verified against source; magnitude (background-trigger frequency × re-derivation cost while asset surfaces are mounted) still needs profiler confirmation.

[metamask-ci]

Triage Agent -- Classification

Severity: Sev2 (confidence: 0.88) ✅

This is a performance bottleneck affecting the asset list rendering path, particularly for power users with many tokens across multiple chains. It causes excessive recomputation and deep-equal comparisons on every Redux dispatch, degrading UI responsiveness. However, the app remains functional - it's a performance issue, not a crash or data loss scenario. Workaround exists (fewer tokens/chains).

Size: size-M (confidence: 0.82) ⚠️ Advisory

The fix requires restructuring how getStateForAssetSelector provides inputs to selectAssetsBySelectedAccountGroup. Instead of building a fresh composite object via spread operators, the function needs to be decomposed into individual memoized selectors that can be passed as separate input selectors to createDeepEqualSelector. This likely touches multiple selectors in assets-list.ts and potentially assets-migration.ts, and requires careful testing to ensure memoization works correctly across the dependency chain of 15+ downstream selectors.
Not auto-applied -- confidence below threshold.

Team: team-assets ✅

Matched via area fallback: area-tokens (no CODEOWNERS match)

---

Root Cause Analysis

Affected component: getStateForAssetSelector in app/selectors/assets/assets-list.ts

The getStateForAssetSelector function creates a fresh composite object on every call using spread operators (...AccountTreeController, ...AccountsController, ...NetworkController) combined with individual property assignments. Because this function is used as the sole input selector for selectAssetsBySelectedAccountGroup (wrapped in createDeepEqualSelector), the memoization check always fails on reference equality (it's a new object every time), forcing the deep-equal fallback comparison. This deep-equal comparison must traverse the entire asset-related state tree (all tokens, all balances, all market data, all rates across all chains) on every Redux dispatch. Since selectAssetsBySelectedAccountGroup is the root of 15+ dependent selectors including per-row selectAsset, every downstream selector also gets invalidated, causing a cascade of recomputations. The pattern in balances.ts shows the correct approach: individual memoized selectors like selectAccountTreeStateForBalances, selectTokenBalancesStateForBalances, etc., each extracting a narrow slice, passed as separate input selectors to createSelector. This allows reselect to do cheap reference equality checks on each individual slice rather than deep-comparing the entire composite.

Evidence:

• getStateForAssetSelector uses spread operators to create a fresh object: { ...AccountTreeController, ...AccountsController, allTokens: ..., tokenBalances: ..., marketData: ..., ... }
• selectAssetsBySelectedAccountGroup uses createDeepEqualSelector with getStateForAssetSelector as sole input, meaning every dispatch triggers a deep-equal comparison of the entire composite
• selectAllAssetsGrouped also uses getStateForAssetSelector with the same problem
• selectTronSpecialAssetsBySelectedAccountGroup also uses getStateForAssetSelector
• balances.ts demonstrates the correct pattern with individual memoized selectors for each state slice
• selectAsset depends on selectAssetsBySelectedAccountGroup, creating per-row cache misses

Suggested Fix

Confidence: high: clear from code context

Decompose getStateForAssetSelector into individual memoized input selectors (following the pattern established in balances.ts), and pass them as separate inputs to createDeepEqualSelector for selectAssetsBySelectedAccountGroup and related selectors. This allows reselect to perform cheap reference equality checks on each individual state slice rather than deep-comparing the entire composite object.

Target files: app/selectors/assets/assets-list.ts
Target functions: getStateForAssetSelector, selectAssetsBySelectedAccountGroup, selectAllAssetsGrouped, selectTronSpecialAssetsBySelectedAccountGroup

Approach:

1. Replace getStateForAssetSelector with individual memoized selectors for each state slice it currently extracts. Many of these already exist in assets-migration.ts (e.g., getTokensControllerAllTokens, getTokenBalancesControllerTokenBalances, getTokenRatesControllerMarketData, etc.) and can be reused directly.

2. Create additional memoized selectors for the controller state spreads: selectAccountTreeControllerState, selectAccountsControllerState, selectNetworkControllerState (some may already exist).

3. Refactor selectAssetsBySelectedAccountGroup to use these individual selectors as separate input selectors. The result function should compose them into the AssetListState shape that _selectAssetsBySelectedAccountGroup expects. Since the composition happens inside the result function, it only runs when one of the individual inputs actually changes (by reference).

4. Apply the same pattern to selectAllAssetsGrouped and selectTronSpecialAssetsBySelectedAccountGroup.

5. Consider whether createDeepEqualSelector is still needed for these selectors, or if regular createSelector suffices now that inputs are properly memoized. The deep-equal wrapper may still be useful for the output (the assets object), but the input memoization should prevent unnecessary result function invocations.

6. Verify that selectAsset (the per-row selector) benefits from the improved memoization of its selectAssetsBySelectedAccountGroup dependency.

Example refactored pattern:

export const selectAssetsBySelectedAccountGroup = createDeepEqualSelector(
  [
    selectAccountTreeControllerState,
    selectAccountsControllerState,
    getTokensControllerAllTokens,
    getTokensControllerAllIgnoredTokens,
    getTokenBalancesControllerTokenBalances,
    getTokenRatesControllerMarketData,
    getMultiChainAssetsControllerAssetsMetadata,
    getMultiChainAssetsControllerAccountsAssets,
    getMultiChainAssetsControllerAllIgnoredAssets,
    getMultiChainBalancesControllerBalances,
    getMultichainAssetsRatesControllerConversionRates,
    getCurrencyRateControllerCurrencyRates,
    getCurrencyRateControllerCurrentCurrency,
    selectNetworkControllerState,
    getAccountTrackerControllerAccountsByChainId,
  ],
  (accountTree, accounts, allTokens, allIgnoredTokens, tokenBalances, marketData, assetsMetadata, accountsAssets, allIgnoredAssets, balances, conversionRates, currencyRates, currentCurrency, networkController, accountsByChainId) => {
    const assetsState = {
      ...accountTree,
      ...accounts,
      allTokens,
      allIgnoredTokens,
      tokenBalances,
      marketData,
      assetsMetadata,
      accountsAssets,
      allIgnoredAssets,
      balances,
      conversionRates,
      currencyRates,
      currentCurrency,
      ...networkController,
      accountsByChainId,
    };
    return callSelectAssetsBySelectedAccountGroup(assetsState);
  },
);

---

Confidence threshold: 0.85. Labels marked ✅ were auto-applied. Labels marked ⚠️ are advisory only (below threshold).
To re-triage, remove the ta-bot-triage label and re-apply ta-needs-triage.
⚠️ Some dimensions could not be confidently classified. An engineer should review this issue.