fix: fix recipient account icons cp-7.60.0

[ccharly]

Description

The icon being used for each recipient addresses was not re-using their account group icons (we use the EVM address of a multichain account group as the seed of account's icons).

This PR fixes this while keeping the original recipient.address as a fallback (which should never happen anyway).

Changelog

CHANGELOG entry: Fix account's icons for send flows

Related issues

Fixes:

• [Bug]: Accounts - The Account Icons are different from the Accounts list menu and the Send flow Recipient list #22806

Manual testing steps

Feature: Send non-EVM token

  Scenario: user starts a send flow for Solana
    Given the user has funds

    When user selects the recipient address
    Then he should see the same icons than the one used for the account list

Screenshots/Recordings

Before

Simulator.Screen.Recording.-.iPhone.16.Plus.-.2025-11-27.at.13.25.36.mov

After

Simulator.Screen.Recording.-.iPhone.16.Plus.-.2025-11-27.at.13.14.06.mov

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.

---

Note

Recipient avatars now derive from the account group’s icon seed (with address fallback), and useAccounts returns accountGroupId; tests updated accordingly.

• UI (recipient):
  • Avatar accountAddress now sourced from account group icon seed via selectIconSeedAddressByAccountGroupId, with fallback to recipient.address.
  • RecipientType extended with accountGroupId; Redux selector added to compute avatar seed.
• Hooks:
  • useAccounts now includes accountGroupId in returned recipient objects.
• Tests:
  • Updated useAccounts.test.ts expectations to include accountGroupId across EVM, Solana, Bitcoin, and Tron cases.

^{Written by Cursor Bugbot for commit bcc1017. This will update automatically on new commits. 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.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeConfirmationsRedesigned, SmokeAccounts, SmokeWalletPlatform
• Risk Level: medium
• AI Confidence: 85%

click to see 🤖 AI reasoning details

Analysis Summary

The PR adds accountGroupId field to recipient handling in the confirmations flow and uses it to determine the correct avatar seed address for multi-account scenarios.

Changed Files:

1. useAccounts.ts: Modified hook to include accountGroupId in the returned RecipientType object
2. recipient.tsx: Added logic to use selectIconSeedAddressByAccountGroupId selector to determine the proper avatar seed address based on account group, falling back to recipient address if needed
3. useAccounts.test.ts: Updated test expectations to include the new accountGroupId field

Impact Analysis:

Direct Impact:

• Confirmations Flow: The changes directly affect how recipients are displayed in the confirmations UI, specifically how avatars are rendered for different account types (EOA, Solana, Bitcoin, Tron accounts)
• Account Management: The changes integrate with the account grouping system and multichain account handling via selectIconSeedAddressByAccountGroupId
• Send Flow: The useAccounts hook is used in send recipient selection, affecting how accounts appear when selecting recipients

Technical Details:

• The new selector selectIconSeedAddressByAccountGroupId prefers EVM account addresses for avatar display, falling back to the first account in a group
• This is part of the multichain account improvements where account groups can contain multiple chain-specific accounts
• The changes are defensive with try-catch and fallback to recipient address

Risk Assessment:

Medium Risk because:

1. Changes affect critical user flow (confirmations/send transactions)
2. Involves account display logic which could affect user experience
3. Touches recipient selection UI component
4. Integrates with multichain account system
5. The hook is imported by 20+ files including various account and permission views

However, mitigating factors:

• Changes are relatively contained and defensive (try-catch, fallbacks)
• Only modifying display logic (avatar seed address), not transaction logic
• Test updates show expected behavior is maintained
• No changes to core transaction processing

Test Tag Selection Rationale:

1. SmokeConfirmationsRedesigned (Primary): Direct changes to confirmation UI components and recipient display logic
2. SmokeAccounts (Secondary): Changes affect account display and account grouping features, particularly multi-account scenarios
3. SmokeWalletPlatform (Tertiary): The useAccounts hook is used across wallet platform features including account selector, account permissions, and account connections

View GitHub Actions results

[sonarqubecloud]

Quality Gate failed

Failed conditions
37.5% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud