[pull] main from MetaMask:main by pull[bot] · Pull Request #842 · Reality2byte/metamask-mobile

pull · 2026-06-17T17:53:03Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

## **Description**   ## **Changelog**   CHANGELOG entry: adds Swap/Bridge feature to ARC mainnet ## **Related issues**  Fixes: ## **Manual testing steps**  ```gherkin 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](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] 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](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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] > **Low Risk** > Small, additive bridge configuration aligned with other chains; no changes to auth, transactions, or core swap execution logic in this diff. > > **Overview** > Adds **ARC mainnet** to the in-app **Swap/Bridge** flow using the same pattern as other recently added chains. > > **Default destination token** for ARC is **EURC** (`0xbEf5…21c1`), with icon metadata for chain `5042`, in `default-swap-dest-tokens.ts`. > > **Stablecoin slippage** treats ARC’s canonical **USDC** (`0x3600…0000`) as a stablecoin so stable-to-stable swaps can use the lower default slippage path in `useStablecoinsDefaultSlippage`. > > **Bridge UI labeling** maps `NETWORK_CHAIN_ID.ARC` to the display name **Arc** in `app/constants/bridge.ts`. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit dd91e9b. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  Co-authored-by: Satyajeet Kolhapure <77279246+satyajeetkolhapure@users.noreply.github.com>

…31732) - chore: removed trailing slash for arc explorer url cp-7.81.1 cp-7.82.0 (#31718)   ## **Description**   Removed the trailing slash from the Arc explorer URL defined in `app/util/networks/customNetworks.tsx` so now the URL is correctly generated. ## **Changelog**   CHANGELOG entry: null ## **Related issues**  Fixes: ## **Manual testing steps**  ```gherkin 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**   - [X] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [X] I've completed the PR template to the best of my ability - [X] I've included tests if applicable - [X] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [X] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [X] 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist**  - [X] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [X] 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. [9c5a30b](9c5a30b) Co-authored-by: Gabriele Del Monte <37625739+gabrieledm@users.noreply.github.com>

…1.1-ota for PR #31611 (#31753) - feat(card): gate Money Account card linkage on allowlisted spending token (#31611) ## **Description**  **Reason for the change:** The Money Account ↔ MetaMask Card linkage and the card funding token placeholders were derived purely from the provider's delegation settings, without checking whether the spending token (VEDA, on Monad) was actually enabled in the `cardFeature` remote feature flag. As a result, cardholders/authenticated users could be shown a "Link card" CTA — and a VEDA/mUSD placeholder token — even when the token was not allowlisted (or was explicitly disabled) in the feature flag, leading to a dead CTA and tokens that should not be offered. **Improvement/solution:** This PR makes the feature flag the source of truth for whether the Money Account card spending token is offered, and hides the card section / drops the placeholder when it is not: - **`vedaToken.ts`** — adds `isMoneyAccountCardTokenAllowlisted(chains)`, which returns `true` only when the VEDA spending token (matched by the canonical `veda` symbol, the same key the provider's delegation settings use) is present **and** not disabled (`enabled !== false`) in any configured chain of the `cardFeature` flag. - **`useMoneyAccountCardLinkage.tsx`** — reads the `cardFeature` flag via `selectCardFeatureFlag`, computes `isMoneyAccountCardSupported`, and gates both the resolved `moneyAccountCardToken` (now `null` when unsupported) and `hasRequirements` on it. When VEDA is missing or disabled, `canLink`/`hasMoneyAccountRequirements` become `false` and `moneyAccountCardToken` is `null`. - **`MoneyHomeView.tsx`** — `metamaskCardMode` can now be `null`. For authenticated/cardholder users, `link` mode is only offered when `hasMoneyAccountRequirements` is met; otherwise the entire `MoneyMetaMaskCard` section (and its divider) is hidden rather than rendering a dead "Link card" CTA. - **`buildTokenList.ts`** — `buildDelegationTokenList` gains an opt-in `enforceSupportList` flag. When enabled, a delegation token is dropped unless it matches the SDK/feature-flag support list by address (case-insensitive) **or** symbol. The SDK-token lookup was hoisted earlier so it applies to all entries (including the VEDA entry). - **`cardController.ts`** — `selectCardAvailableTokens` now passes `enforceSupportList: true` and filters the feature-flag tokens to those with `enabled !== false` before building placeholders, so disabled/unlisted tokens never appear as funding placeholders. - **`featureFlagController/card/index.ts`** — updates `defaultCardFeatureFlag`: adds the Monad (`eip155:143`) chain entry with USDC and FoxConnect addresses, and adds `amUSD` (Aave Linea mUSD) on Linea and `WETH` on Base. Unit tests were added/updated across the hook, selectors, and utils to cover the allowlisted, missing, and disabled token cases. ## **Changelog**  CHANGELOG entry: Fixed the MetaMask Card section on the Money screen so the "Link card" option and funding token placeholders are only shown when the card spending token is enabled in the card feature configuration. ## **Related issues** Fixes: null ## **Manual testing steps** ```gherkin Feature: Money Account card linkage gated on allowlisted spending token Scenario: Card section is hidden when the spending token is not allowlisted Given I am an authenticated cardholder on the Money home screen And the card spending token (VEDA) is not present in the cardFeature flag When the Money home screen renders Then the MetaMask Card section is not shown And no "Link card" CTA is offered Scenario: Card section is hidden when the spending token is disabled Given I am an authenticated cardholder on the Money home screen And the card spending token (VEDA) is present but disabled in the cardFeature flag When the Money home screen renders Then the MetaMask Card section is not shown Scenario: Link CTA is offered when the spending token is allowlisted Given I am an authenticated cardholder on the Money home screen And the card spending token (VEDA) is enabled on Monad in the cardFeature flag When the Money home screen renders Then the MetaMask Card section is shown in "link" mode And the Money Account funding token placeholder is displayed as mUSD Scenario: Unsupported funding placeholders are dropped Given a delegation token is not present in the cardFeature support list When the available card tokens are computed Then that token does not appear as a funding placeholder ``` ## **Screenshots/Recordings**  ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist**  - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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] > **Medium Risk** > Changes user-visible card linkage and funding token lists based on remote feature flags; misconfiguration could hide valid link CTAs or show fewer placeholders than before. > > **Overview** > **Money Account ↔ MetaMask Card flows now respect the `cardFeature` remote flag** for the VEDA (mUSD) spending token, instead of trusting delegation settings alone. > > `isMoneyAccountCardTokenAllowlisted` decides whether VEDA is enabled on Monad in the flag (by `veda` symbol or matching address, including mUSD-labeled entries). **`useMoneyAccountCardLinkage`** nulls the card token and clears requirements when not allowlisted, so **`canLink`** stays false. **Money home** only shows link mode when requirements pass; otherwise the MetaMask Card block is hidden for cardholders/authenticated users (no dead “Link card” CTA). > > **Card funding placeholders** use **`buildDelegationTokenList`** with optional **`enforceSupportList`**: tokens must match the flag/SDK list by address or symbol; **`selectCardAvailableTokens`** turns this on and skips `enabled: false` entries. Default **`cardFeature`** adds Monad (`eip155:143`) and extra Linea/Base tokens in config defaults. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c3d67d0. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  [7b0e275](7b0e275)

…31755) - feat: add swap/bridge to ARC mainnet (#31413)   ## **Description**   ## **Changelog**   CHANGELOG entry: adds Swap/Bridge feature to ARC mainnet ## **Related issues**  Fixes: ## **Manual testing steps**  ```gherkin 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](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] 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](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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] > **Low Risk** > Small, additive bridge configuration aligned with other chains; no changes to auth, transactions, or core swap execution logic in this diff. > > **Overview** > Adds **ARC mainnet** to the in-app **Swap/Bridge** flow using the same pattern as other recently added chains. > > **Default destination token** for ARC is **EURC** (`0xbEf5…21c1`), with icon metadata for chain `5042`, in `default-swap-dest-tokens.ts`. > > **Stablecoin slippage** treats ARC’s canonical **USDC** (`0x3600…0000`) as a stablecoin so stable-to-stable swaps can use the lower default slippage path in `useStablecoinsDefaultSlippage`. > > **Bridge UI labeling** maps `NETWORK_CHAIN_ID.ARC` to the display name **Arc** in `app/constants/bridge.ts`. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit dd91e9b. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  Co-authored-by: Satyajeet Kolhapure <77279246+satyajeetkolhapure@users.noreply.github.com> [d333a48](d333a48)

…1.1-ota for PR #31662 (#31748) - feat: arc network integration cp-7.82.0 cp-7.81.1 (#31662)   ## **Description**   Fixes Arc support for mobile client. Same fixes than the ones added in extension: MetaMask/metamask-extension#43509 Includes changes from #31644 This includes: - Only Arc USDC native token is shown in the main wallet list and the send flow. The Arc USDC ERC20 is hidden. - Only Arc USDC ERC20 is shown in the swaps flow. The Arc USDC native is hidden. - Aggregated balance is only counted once. No double counting for USDC native + ERC20. ## **Changelog**   CHANGELOG entry: Fixed Arc native token support ## **Related issues**  Fixes: ## **Manual testing steps**  ```gherkin 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**  https://github.com/user-attachments/assets/e96de5ee-307a-467a-9467-61fb2c568d0a ## **Pre-merge author checklist**   - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] 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](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. [1e03645](1e03645) --------- Co-authored-by: Bernardo Garces Chapero <bernardo.chapero@consensys.net>

This PR updates the change log for 7.81.1. (Hotfix - no test plan generated.) --------- Co-authored-by: metamaskbot <metamaskbot@users.noreply.github.com> Co-authored-by: sleepytanya <sleepytanya@gmail.com>

…31791) - fix(predict): fix scoreboard score cutoff for wide scores cp-7.82.0 (#31555) ## **Description** Fix game clock width on the Predict sport scoreboard to prevent wide scores (e.g., 123) from being cut off. On devices like iPhone 17 Pro, the score container had insufficient width, causing scores with 3+ digits to be clipped. The fix adjusts the score display layout to properly accommodate wider score values. ## **Changelog** CHANGELOG entry: Fixed a bug causing wide sport scores to be cut off on the predict scoreboard. ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/PRED-960 ## **Manual testing steps** ```gherkin Feature: Predict sport scoreboard Scenario: user views a game with a wide score (3+ digits) Given the user is on the Predict scoreboard screen And a live or completed sport game has a score of 100 or higher (e.g., Knicks 123 vs Spurs 118) When user views the scoreboard card Then the full score is displayed without being cut off ``` ## **Screenshots/Recordings** ### **Before**  ### **After** <img width="320" alt="Simulator Screenshot - mm-blue - 2026-06-11 at 12 23 33" src="https://github.com/user-attachments/assets/f06ef67d-abd0-46c6-a49c-438aeb8ae8c9" /> <img width="320" alt="Simulator Screenshot - mm-blue - 2026-06-11 at 12 23 25" src="https://github.com/user-attachments/assets/648109fd-b2d7-4bdf-8df2-e25b4ac4b534" /> ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example ## **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] > **Low Risk** > UI-only layout change in Predict scoreboard; scheduled non-compact cards no longer reserve invisible score slots. > > **Overview** > Updates **Predict sport scoreboard** score rendering so live and final games can show wide scores (e.g. 100+) without clipping. > > **`showScores`** is now tied to **`isLive || isEnded`** instead of hiding scores only in compact scheduled cards. Scheduled games no longer render score text or the old invisible fixed-width placeholders. > > Fixed Tailwind width classes on score **`Text`** (`w-12` / `w-16` / `opacity-0 w-16`) are removed; scores keep padding only so they can grow with digit count and give the center status area more flexible space. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b78a1ea. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  [9db931b](9db931b) Co-authored-by: Luis Taniça <matallui@gmail.com>

…31796) - fix(predict): chart content cut off on iPhone 17 Pro cp-7.82.0 (#31505) ## **Description** The Predict game-market chart draws an endpoint label for each outcome (the team/player name above, the percentage below) to the right of each line. Depending on the data, these labels were being cut off on three different edges: 1. **Top** — when the leading outcome was high and the trailing outcomes were clustered low (e.g. `70% / 21% / 11%`), the de-clutter logic shifted the whole label stack up to keep the bottom label on screen, pushing the top label's name off the top edge. 2. **Bottom** — when two outcomes were clustered near the chart floor (e.g. `91% / 6% / 3%`), the lowest label was pushed below the chart and its percentage was cut off. 3. **Right (horizontal)** — wide content overflowed the reserved right gutter: the 3-digit value `100%` and long team/player names like `UDVARDY` were clipped at the right edge. **What changed** - **Vertical (top & bottom):** Replaced the one-directional "push down + shift up" label spacing with a **two-sided resolution** in `getSeparatedLabelYPositions`. Labels are pushed down to honor the minimum gap; if the bottom value would overflow the floor, the bottom is anchored at `MAX_LABEL_Y` and the rest are pushed back up; the top is then guarded at `MIN_LABEL_Y`. Two named bounds (`MIN_LABEL_Y`, `MAX_LABEL_Y`) make the visible region explicit, so neither the top name nor the bottom value can clip. - **Horizontal (right):** Replaced the fixed right content inset with a **content-aware** one. `getChartRightInset(labels, maxValue)` sizes the right gutter to the widest element that will actually render (team name *or* value) across the series, clamped to a sensible range so a very long name can't squeeze the chart away. The gutter stays tight for short content (no wasted space) and widens only when a long name or `100%` needs it. Both the static endpoint view and the scrub tooltip use the same inset. - All chart inset constants are co-located in `PredictGameChart.constants.ts`. Note: SVG text cannot be measured synchronously in React Native, so horizontal width is approximated from conservative glyph-advance ratios (leaning slightly wide to avoid clipping) and clamped. ## **Changelog** CHANGELOG entry: Fixed Predict game-market chart labels (team/player names and percentages) being cut off at the top, bottom, and right edges. ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/PRED-955 ## **Manual testing steps** ```gherkin Feature: Predict game chart labels are fully visible Scenario: Leading outcome is high with clustered low outcomes Given I open a 3-outcome game market (e.g. ~70% / ~21% / ~11%) When the game chart renders Then the top outcome's name and percentage are fully visible (not clipped at the top) Scenario: Two outcomes are clustered near the chart floor Given I open a game market like ~91% / ~6% / ~3% When the game chart renders Then the lowest outcome's name and percentage are fully visible (not clipped at the bottom) Scenario: An outcome reaches 100% Given I open a settled/lopsided market showing 100% / 0% When the game chart renders Then "100%" is fully visible (not clipped on the right) Scenario: Long team/player names Given I open a market with long names (e.g. SNIGUR / UDVARDY) When the game chart renders Then both names are fully visible (not clipped on the right) Scenario: Short names and 2-digit values Given I open a market with short names and 2-digit values (e.g. GER / KOR · 94%) When the game chart renders Then the labels hug the right edge with no excessive empty gap Scenario: Scrubbing the chart Given any of the markets above When I drag across the chart to show the tooltip Then the tooltip labels and percentages are fully visible at every position ``` ## **Screenshots/Recordings** ### **Before** <img width="415" height="861" alt="Screenshot 2026-06-10 at 16 43 52" src="https://github.com/user-attachments/assets/b24f6f37-ea32-4cfc-bc1f-639550aadf29" /> <img width="421" height="881" alt="Screenshot 2026-06-10 at 16 44 41" src="https://github.com/user-attachments/assets/eaf3de16-497b-418f-9b14-33f967951541" /> <img width="426" height="885" alt="Screenshot 2026-06-10 at 14 57 54" src="https://github.com/user-attachments/assets/cd9f2012-f9c0-4272-98a5-e388cfc2b3ad" />  ### **After** <img width="427" height="889" alt="Screenshot 2026-06-10 at 16 48 51" src="https://github.com/user-attachments/assets/d2f45481-d6d0-4521-aee7-54f1c1b37ec6" /> <img width="425" height="897" alt="Screenshot 2026-06-10 at 14 34 17" src="https://github.com/user-attachments/assets/5fad254c-0d87-4b9f-8316-83f4539384f3" /> <img width="414" height="890" alt="Screenshot 2026-06-10 at 16 46 05" src="https://github.com/user-attachments/assets/ee257f2b-8e7e-4448-9c8c-9663fd02b28c" />  ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable)  - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example ## **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] > **Low Risk** > Predict chart layout and label positioning only; no auth, payments, or data-path changes, with expanded unit tests. > > **Overview** > Fixes **Predict game-market chart** endpoint labels (names and percentages) clipping at the **top**, **bottom**, and **right** on devices like iPhone 17 Pro (PRED-955). > > **Vertical:** `getSeparatedLabelYPositions` now uses explicit **`MIN_LABEL_Y` / `MAX_LABEL_Y`** bounds and two-sided layout: enforce minimum gap, **anchor the bottom** at the floor when needed, then **guard the top** so name/value text stay inside the chart. Two-label stacks go through **`fitLabelStackWithinChart`**. > > **Horizontal:** Replaces the fixed **80px** right inset with **`getChartRightInset(labels, maxValue)`**, which estimates width from team names and values (including **100%**) and clamps between min/max so short labels stay tight and long names are not clipped. **`PredictGameChartContent`** applies this inset everywhere (lines + tooltip) and keeps pan/scrub math in sync via a ref. > > Tests cover the new spacing behavior and dynamic right inset. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b4ed809. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  [512d2ab](512d2ab) Co-authored-by: Caainã Jeronimo <caainaje@gmail.com>

…31797) - fix(predict): add ES and IN to Predict geo-block overlay cp-7.82.0 (#31721) ## **Description** Users in countries where Predict isn't available could still reach the bet flow and submit an order, which was then rejected by the relay at submit time with `PREDICT_NOT_ELIGIBLE`. The client-side additional geo-block overlay (`GEO_BLOCKED_COUNTRIES`) only listed `DE` and `RO`, even though Spain and India had been manually geo-blocked in the backend. As a result, users in those regions slipped through the upfront guard, submitted, and failed — inflating the order-failure rate (Mixpanel Jun 11–14: India 97%, Spain 90%). This change adds `ES` (Spain) and `IN` (India) to the client-side geo-block overlay so these users are blocked **before** submitting an order, aligning the client with the backend geo-block overrides and removing the submit-then-fail failures. ## **Changelog** CHANGELOG entry: null  ## **Related issues** Fixes: [PRED-1016](https://consensyssoftware.atlassian.net/browse/PRED-1016) ## **Manual testing steps** ```gherkin Feature: Predict geo-block overlay Scenario: user in a geo-blocked region cannot submit a bet Given the user's region resolves to ES (Spain) or IN (India) When the user opens the Predict bet flow Then the bet UI is blocked/disabled upfront And the user cannot submit an order that would fail with PREDICT_NOT_ELIGIBLE Scenario: user in an allowed region is unaffected Given the user's region resolves to a non-blocked country (e.g. US, PT) When the user opens the Predict bet flow Then the user can proceed as before ``` ## **Screenshots/Recordings** ### **Before** N/A — constant/list change only; no visual change beyond the existing geo-block UI being applied to the additional regions. ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - [x] I've tested with a power user scenario - [x] I've instrumented key operations with Sentry traces for production performance metrics ## **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. [PRED-1016]: https://consensyssoftware.atlassian.net/browse/PRED-1016?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [a1a6b1b](a1a6b1b) [PRED-1016]: https://consensyssoftware.atlassian.net/browse/PRED-1016?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: Luis Taniça <matallui@gmail.com>

…31798) - fix(predict): normalize moneyline betslip labels and icons cp-7.82.0 (#31648) ## **Description** This PR fixes incorrect bet submission header content for Predict moneyline markets, especially World Cup-style markets where the selected outcome could show duplicated team names or the wrong avatar in preview flows. It introduces a shared buy-header formatter that normalizes neg-risk moneyline selections back to consistent `Yes · <team or Draw>` labeling, resolves the correct team logo for the selected side, and reuses that logic across the standard buy preview, the preview sheet, and the buy-with-any-token preview header. The PR also adds focused test coverage for the new formatting behavior and draw handling. ## **Changelog** CHANGELOG entry: Fixed incorrect Predict bet submission labels and icons for moneyline markets. ## **Related issues** Fixes: PRED-964 ## **Manual testing steps** ```gherkin Feature: Predict moneyline buy preview headers Scenario: User opens a moneyline market buy preview Given the user opens a Predict sports market with team-based moneyline outcomes When the user selects a team outcome and opens the buy preview Then the header shows "Yes" as the selected side label And the header keeps the selected team name as the descriptor And the header shows the selected team's logo instead of a generic outcome image Scenario: User opens the buy preview from the pay-with-any-token flow Given the user is in the Predict buy-with-any-token flow for a moneyline market When the user reaches the preview header Then the header uses the same normalized label and team logo as the standard buy preview Scenario: User selects a draw moneyline outcome Given the user opens a moneyline market that includes a draw outcome When the user previews the draw selection Then the header shows "Yes" as the selected side label And the descriptor is shown as "Draw" ``` ## **Screenshots/Recordings** ### **Before** https://github.com/user-attachments/assets/95e925dc-a89a-473f-9618-9750b85f1a11 ### **After** https://github.com/user-attachments/assets/366f3317-9278-48f5-b13d-4a59eafd796e ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. [1bbd123](1bbd123) Co-authored-by: Caainã Jeronimo <caainaje@gmail.com>

OTA hotfix: branch release/7.81.1-ota. Native semver and build version are not bumped. OTA_VERSION in app/constants/ota.ts is v7.81.1. CHANGELOG.md header and production git tag both use bare 7.81.1 / v7.81.1; the -ota suffix is branch-only.

## **Description** Opening the block explorer from a money-activity transaction detail sheet left the user stuck behind a black overlay with nothing interactive: the repro steps for this were: 1. Open the money account and tap an activity row to see the transaction details sheet. 2. Tap "View on block explorer" — **nothing happens** (the WebView never appears). 3. Try to close the sheet — a black overlay covers the screen and no action is possible. The reason this happened is that the detail sheet is a full-screen `BottomSheet` mounted as a `presentation: 'transparentModal'` screen on top of the main navigation stack. The `Webview` screen is a **sibling** on that same stack. The explorer handler navigated while the sheet was still presented. This led to the webview being shown behind the already open modal - and when closing the modal we ended in a weird state with the webview dismissed but a lingering overlay. The fix for this is to dismiss the sheet **before** navigating, then push the WebView from the post-close callback. This pops the transparent modal first, so the WebView lands on the now-top stack and is visible, and no overlay is left behind. This matches the existing `onCloseBottomSheet(navigateFunc)` convention already used across the app (e.g. `AddFundsBottomSheet`, `AssetSelectionBottomSheet`).   ## **Changelog**   CHANGELOG entry: prevent black overlay lingering after closing txn modal ## **Related issues**  Fixes: MUSD-985 ## **Manual testing steps**  ```gherkin Feature: money activity Scenario: user close txn details modal Given user clicks on a txn modal details page When user clicks block explorer, then closes the modal Then they end up back on the money activity list ``` ## **Screenshots/Recordings**   ### **Before**  ### **After** https://github.com/user-attachments/assets/68702a6d-2f99-49cc-9340-75e3c8c0c63c  ## **Pre-merge author checklist**   - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. Co-authored-by: Shane T <shane.odlum@consensys.net>

This PR syncs the stable branch to main for version 7.81.0. *Synchronization Process:* - Fetches the latest changes from the remote repository - Resets the branch to match the stable branch - Attempts to merge changes from main into the branch - Handles merge conflicts if they occur *File Preservation:* Preserves specific files from the stable branch: - CHANGELOG.md - bitrise.yml - android/app/build.gradle - ios/MetaMask.xcodeproj/project.pbxproj - package.json Indicates the next version candidate of main to 7.81.0

## **Description**  Aligns the QuickBuy bottom sheet visuals with the Figma designs: - **Amount headline**: `fontSize: 48` → `TextVariant.DisplayMd` `(32px)` - **Secondary amount**: `TextVariant.BodyMd` → `TextVariant.BodySm` `(14px)` with single-line ellipsis truncation - **Rate tag pill**: `TextVariant.BodySm` → `TextVariant.BodyXs` `(12px)` <img height="790" alt="Simulator Screenshot - iPhone 17 Pro - 2026-06-17 at 10 21 22" src="https://github.com/user-attachments/assets/86565948-8edd-4047-901a-3945b27b764d" /> ## **Changelog**   CHANGELOG entry: null ## **Related issues**  Fixes: ## **Manual testing steps**  ```gherkin 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** NA ### **After** NA ## **Pre-merge author checklist**   - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.

## **Description** This PR replaces real trader handles used in unit test fixtures and assertions with generic mock names. 1. **What is the reason for the change?** The social leaderboard and top trader unit tests hardcoded real trader handles. Referencing real account names in the test suite is undesirable; mock data should be anonymous and self-evidently fake. 2. **What is the improvement/solution?** All occurrences were replaced with generic placeholders (`trader1` / `trader2` / `trader3`) consistently across fixtures and the assertions that depend on them. Scope: **test-only**. No source, component, or snapshot files were changed, and there is no behavior change. The renames are purely cosmetic to the test data. ESLint/Prettier auto-formatting (via the pre-commit hook) collapsed a few now-shorter multi-line assertions, which is included in the diff. Affected suites (11 files): - `Homepage/Sections/TopTraders/components/TopTraderCard.test.tsx` - `Homepage/Sections/TopTraders/components/TraderRow.test.tsx` - `Homepage/Sections/TopTraders/hooks/useTopTraders.test.ts` - `Settings/NotificationsSettings/SocialAINotificationPreferencesContent.test.tsx` - `SocialLeaderboard/NotificationPreferences/hooks/useFollowedTraders.test.ts` - `SocialLeaderboard/TopTradersView/TopTradersView.test.tsx` - `SocialLeaderboard/TraderPositionView/TraderPositionView.test.tsx` - `SocialLeaderboard/TraderProfileView/TraderProfileView.test.tsx` - `SocialLeaderboard/TraderProfileView/components/ProfileHeader.test.tsx` - `SocialLeaderboard/TraderProfileView/components/TraderNotificationsBottomSheet/TraderNotificationsBottomSheet.test.tsx` - `SocialLeaderboard/TraderProfileView/hooks/useTraderProfile.test.ts` ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: Social leaderboard / top trader unit tests Scenario: developer runs the affected jest suites Given the unit test fixtures use generic mock trader names When the developer runs the 11 affected jest suites Then all suites pass with no behavior change ``` N/A — automated unit tests only; no manual app testing applies. ## **Screenshots/Recordings** ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. Co-authored-by: Cursor <cursoragent@cursor.com>

## **Description** The E2E test runner was downloading all run artifacts (no name: filter on download-artifact), which included the unused 675 MB ci-js-deps tarball, build metadata, and source maps on every shard. The job only needs the built APKs (Android) or .app bundle (iOS) — node_modules is set up separately via yarn install in setup-e2e-env. Replaced the broad "download everything" steps with explicit named downloads scoped to the two APK artifacts (Android) and the .app artifact (iOS), for both namespace and current runner paths.   ## **Changelog**   CHANGELOG entry: ## **Related issues**  Fixes: ## **Manual testing steps**  ```gherkin 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**   - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] 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](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist**  - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] 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.

…er (CONF-1551) (#31703) ## **Description** Predict pay-with-any-token (PWAT) / deposit-and-order flows (`TransactionType.predictDepositAndOrder`) are submitted as batch transactions whose nested txs are typed `predictDepositAndOrder` (overridden in `PredictController.initPayWithAnyToken`). They were mis-tagged in analytics: `transaction_type = batch`, `mm_pay_use_case` undefined, and `polymarket_account_created` never set — making them impossible to query in Mixpanel without brittle proxy filters (`batch` + `mm_pay` + Polygon + error string). This aligns PWAT deposit-and-order metrics with the other MM Pay flows (mirroring the existing `perps_deposit_and_order`): - `base.ts`: map `predictDepositAndOrder` (standalone and batch-nested) to `transaction_type = predict_deposit_and_order`. - `metamask-pay.ts`: add `predictDepositAndOrder` to `PAY_TYPES` and `USE_CASE_MAP` so `mm_pay = true` and `mm_pay_use_case = predict_deposit_and_order` are emitted; detect `polymarket_account_created` for PWAT batches via the Safe-proxy-create selector (`0xa1884d2c`) in nested transactions. - `useTransactionPayMetrics.ts`: attribute `simulation_sending_assets_total_value` to PWAT like other deposit flows. Standard `predict_deposit` metrics are unchanged. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1551 ## **Manual testing steps** ```gherkin Feature: Predict pay-with-any-token deposit-and-order metrics Scenario: PWAT deposit-and-order emits Predict-specific analytics Given I hold a token other than the Polymarket deposit token on a supported chain When I place a Predict order paying with that token (deposit-and-order) And the batch transaction finalizes Then the "Transaction Finalized" event has transaction_type = predict_deposit_and_order And the event has mm_pay = true and mm_pay_use_case = predict_deposit_and_order And polymarket_account_created is true when the Safe is deployed within the batch ``` Verified via unit tests in `base.test.ts`, `metamask-pay.test.ts`, and `useTransactionPayMetrics.test.ts`. ## **Screenshots/Recordings** N/A — analytics-only change with no UI impact. ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example ## **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.

… (1/3) (#31715) ## **Description** The tagging foundation for the headless Money / "Add funds" deposit analytics (TRAM-3623). Additive only - the regular Buy (UB2) and the other confirmation flows are unchanged. What changed: - New `ramp_type` value `HEADLESS` and new field `ramp_surface` (`money_account | perps | prediction`), reusing existing `Ramps`-prefixed events (no new taxonomy). - `ramp_type=HEADLESS` single-sourced off the per-screen `headlessSessionId` (never a global lookup), so it stays consistent across the headless flow (fixes the prior `UNIFIED_BUY_2` to `DEPOSIT` flip mid-flow). - `ramp_surface=money_account` seeded on the headless session. - `region` added (from the Ramps controller) on events that were missing it; terminal events snapshot the surface before the session is torn down. - Failure events (`Ramps Order Failed`, `Ramps OTP Failed`, `Ramps KYC Application Failed`, `Ramps Checkout HTTP Error Received`) carry `error_message` and the HEADLESS tags, emitted from React hosts. ## **Stack & merge order (TRAM-3623)** Three stacked client PRs + a paired schema PR. **Merge order:** 1. **#31715** (foundation, base `main`) - merge first; #31716 and #31764 depend on its shared types. 2. Then **#31716** (funnel) and **#31764** (tx-failed) - both stacked on the foundation branch and independent of each other, so merge in **either order**. When #31715 merges, GitHub retargets them to `main`; rebase onto `main`, then merge. Paired schema PR, must land alongside (it defines the `HEADLESS` / `ramp_surface` / `region` these events emit, else they fail validation): Consensys/segment-schema#621 _This PR is the foundation (step 1)._ ## **Changelog** CHANGELOG entry: null (Internal analytics tagging only; no end-user-facing behavior change.) ## **Related issues** Refs: https://consensyssoftware.atlassian.net/browse/TRAM-3623 ## **Manual testing steps** ```gherkin Feature: Headless deposit analytics tagging Scenario: Headless Money "Add funds" deposit emits HEADLESS-tagged events Given a returning user on the Money / "Add funds" deposit flow When the user proceeds through the headless deposit (e.g. Apple Pay to mUSD) Then every emitted Ramps event carries ramp_type=HEADLESS, ramp_surface=money_account, and region And no ramp_type flip to DEPOSIT / UNIFIED_BUY_2 occurs mid-flow Scenario: Regular Buy (UB2) is unaffected Given a user on the regular Buy (UB2) flow When the user proceeds through Buy Then events keep their existing UNIFIED_BUY_2 ramp_type and ramp_surface stays undefined ``` `yarn lint:tsc` clean (only pre-existing unrelated `termsOfUse` errors); unit tests green; no UB2 regression. ## **Screenshots/Recordings** N/A - analytics tagging only, no visual change. Event payloads verified via the analytics debugger; funnel recording tracked in TRAM-3623. ### **Before** N/A ### **After** After video: https://consensys.slack.com/archives/C0AK3NXRM7W/p1781627226380379 ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - [x] I've tested with a power user scenario - [x] I've instrumented key operations with Sentry traces for production performance metrics ## **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. --------- Co-authored-by: saustrie-consensys <270766059+saustrie-consensys@users.noreply.github.com>

## **Description**  Builds the PRED-917 Popular Today section for the redesigned Predict homepage. The section uses the same related-tag source as the full `popular-today` feed, renders a configurable two-row chip rail by default, shows loading skeletons while tags load, and hides when no tags are available. This also fixes the feed filter pill UX after navigating from a Popular Today chip: when an `initialFilterId` is resolved by the feed config, the shared Predict chip list now scrolls the active pill into view so users can see which filter is selected. ## **Changelog**  CHANGELOG entry: Added a Popular Today section to the Predict homepage. ## **Related issues**  Fixes: null ## **Manual testing steps**  ```gherkin Feature: Predict Popular Today homepage section Scenario: user opens Popular Today from the redesigned Predict homepage Given the Predict feature is available And the Predict homepage redesign flag is enabled When the user opens the Predict homepage Then the Popular Today section appears with related-tag chips in two rows When the user taps a Popular Today chip Then the app opens the Popular Today feed And the tapped filter is selected And the selected filter pill is scrolled into view ``` Automated verification run locally: - `yarn jest app/components/UI/Predict/components/PredictChipList/PredictChipList.test.tsx app/components/UI/Predict/views/PredictHome/components/PredictPopularTodaySection/PredictPopularTodaySection.test.tsx --runInBand --silent --coverage=false` - `yarn lint:tsc` ## **Screenshots/Recordings**  ### **Before** N/A — previous redesigned home rendered a Popular Today placeholder. ### **After** <img width="395" height="718" alt="Screenshot 2026-06-16 at 10 42 56 AM" src="https://github.com/user-attachments/assets/00335ef2-a1b3-476d-8148-1d14c9665950" /> ## **Pre-merge author checklist**   - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Considered for this UI-only Predict homepage/feed chip change; no Android-specific code paths were changed. - [x] I've tested with a power user scenario - Considered not applicable; this change does not touch account/token list scaling paths. - [x] I've instrumented key operations with Sentry traces for production performance metrics - Considered not applicable; this change reuses existing Predict query/list paths and does not add new production tracing-worthy operations. For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. --------- Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

…e when apy can't be fetched (#31861)   ## **Description**  When the live APY can't be fetched,`MoneyHowItWorksView` and `MoneyEarnCryptoInfoSheet` were silently displaying a hardcoded `4%` fallback. This removes that fallback — users now see `-` instead of a potentially misleading number. ## **Changelog**  CHANGELOG entry: removes hardcoded 4% fallback apy used in MoneyHowItWorksView and MoneyEarnCryptoInfoSheet ## **Related issues**  Fixes: [MUSD-1003](https://consensyssoftware.atlassian.net/browse/MUSD-1003) ## **Manual testing steps**  ```gherkin Feature: APY empty state in Money components Scenario: APY unavailable shows dash instead of hardcoded value Given the Money feature is enabled And the APY data cannot be fetched (network offline or API error) When the user opens the "How it works" screen Then the APY placeholder shows "-" instead of "4%" Scenario: APY available shows live value Given the Money feature is enabled And the APY data is available When the user opens the "How it works" screen Then the live APY percentage is displayed ``` ## **Screenshots/Recordings**  ### **Before**  N/A ### **After**  N/A ## **Pre-merge author checklist**  - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.  [MUSD-1003]: https://consensyssoftware.atlassian.net/browse/MUSD-1003?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

## **Description**  This PR adds Bitcoin Wallet Standard connectivity support to MetaMask Mobile.   It registers the Bitcoin Wallet Standard provider in the inpage bridge, adds the mobile connection/signing flow needed by Bitcoin-compatible dapps, and extends the E2E coverage with Bitcoin Wallet Standard test dapps and smoke tests for connect, disconnect, and sign message flows. It also updates Android build fingerprinting/prebuild behavior so E2E APKs include the latest inpage bridge provider bundle instead of reusing stale cached assets. ## **Changelog**   CHANGELOG entry: Added Bitcoin Wallet Standard connectivity support for compatible dapps ## **Related issues**  Refs: Bitcoin Wallet Standard connectivity support for MetaMask Mobile. ## **Manual testing steps**  ```gherkin Feature: Bitcoin Wallet Standard connectivity Scenario: Connect and disconnect from a Bitcoin test dapp Given MetaMask Mobile is installed with the Bitcoin Wallet Standard feature available And the Bitcoin Wallet Standard test dapp is open in the in-app browser When the user connects MetaMask from the dapp wallet selection modal Then the dapp shows MetaMask as connected When the user disconnects from the dapp Then the dapp shows MetaMask as disconnected Scenario: Sign a message from a Bitcoin test dapp Given MetaMask Mobile is connected to the Bitcoin Wallet Standard test dapp When the user requests a message signature from the dapp And the user approves the signature request in MetaMask Then the dapp receives a successful signature response ``` ## **Screenshots/Recordings**   ### **Before** N/A  ### **After** N/A  ## **Pre-merge author checklist**   - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist**  - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] 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] > **Medium Risk** > Touches dapp-facing inpage injection and multichain connect/sign flows (user approvals), though the change follows the established Solana pattern with mostly test and fingerprint updates. > > **Overview** > Adds **Bitcoin Wallet Standard** exposure in the mobile in-app browser by mirroring the existing Solana wallet-standard inpage path. > > The inpage bridge now registers `@metamask/bitcoin-wallet-standard` via a multichain API client over `window.postMessage`, wired from `bitcoinWalletStandard.js` into `index.js` alongside the ETH and Solana injectors. Dependencies add `@metamask/bitcoin-wallet-standard` and bump `@metamask/multichain-api-client` to `^0.11.0`. > > **Build / CI:** `fingerprint.config.js` includes `./scripts/inpage-bridge` so E2E/native builds pick up inpage provider changes instead of stale bundles. > > **E2E:** Introduces `@metamask/test-dapp-bitcoin`, a `BITCOIN_TEST_DAPP` fixture variant, `bitcoin-connection.flow`, and `BitcoinTestDapp` page object. Smoke tests cover connect/disconnect, persistence after refresh, and sign-message approval. A small unused helper was removed from `solana-connection.flow.ts`. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 7d06ed4. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  --------- Co-authored-by: 0xEdouard <15703023+0xEdouardEth@users.noreply.github.com>

## Description The Social Leaderboard rows (leaderboard list + homepage carousel) display ROI **100× too large** on every tab. `roiPercent7d` (formerly `roiPercent30d`) from the social API is already a whole-percent value (e.g. `20.98` → "20.98%"), but `useTopTraders` multiplied it by 100 again, so `+20.98%` rendered as `+2098.0%`. Fixes [TSA-727](https://consensyssoftware.atlassian.net/browse/TSA-727). ## Changes - `useTopTraders`: drop the `* 100` — map `percentageChange: entry.roiPercent7d ?? 0` directly. - `useTopTraders.test.ts`: the previous fixtures used **fractions** (`roiPercent7d: 0.43`) which masked the bug; updated to whole-percent values and adjusted the mapping assertion. ## Why it wasn't caught The unit test asserted `percentageChange === roiPercent7d * 100` against fractional fixtures, encoding the wrong assumption. Real Clicker/social-api data returns whole percents (confirmed against the leaderboard payload, e.g. `roiPercent7d: 20.98`). ## Test plan - `yarn jest .../TopTraders/hooks/useTopTraders.test.ts` — 33/33 pass. - `yarn jest .../TopTraders .../SocialLeaderboard/TopTradersView` — 143/143 pass (no ROI-display regressions; the row/card/view tests build `TopTrader` objects directly). - `yarn lint:tsc` 0 errors · prettier clean. ## Notes Branched from latest `main` (the 7d PR #31570 that introduced this exact line is already merged). Separate from TSA-729 (headline-vs-position-list discrepancy), which is tracked independently. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [TSA-727]: https://consensyssoftware.atlassian.net/browse/TSA-727?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

## **Description** For money deposits add max support for selected source tokens. ## **Changelog**   CHANGELOG entry: ## **Related issues**  Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1541 ## **Manual testing steps** NA ## **Screenshots/Recordings** NA ## **Pre-merge author checklist**   - [X] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [X] I've completed the PR template to the best of my ability - [X] I've included tests if applicable - [X] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [X] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [X] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [X] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [X] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.

…counts (MUSD-975) (#31857)   ## **Description**   On the Money account page, tapping **Send → "Another account"** (Between accounts) created a transaction that landed in Activity stuck in a pending state, and no Send flow (amount entry / account selection) was ever shown. The transfer initiator runs from the bottom sheet's *post-close* callback. The design-system `BottomSheet` calls `goBack()` — which pops and unmounts the sheet — **before** invoking that callback. When an `unapproved` transaction already existed in state, `useConfirmNavigation` took its deferred-navigation branch, whose `useEffect` lives in the now-unmounted sheet and therefore never fires. Navigation silently died while `addTransactionBatch` (a plain promise, unbound from the React lifecycle) still ran and created a transaction that got stuck pending. Each failed attempt left another `unapproved` transaction, so the bug was self-perpetuating. This mirrors the fix already shipped for the deposit sheet (`MoneyAddMoneySheet`): reject any pending transaction while the sheet is still mounted, then defer the close+navigate until state clears, so `navigateToConfirmation` always takes its reliable immediate-navigate path. The initiator is resolved at run-time via a key so a deferred run uses the up-to-date navigation closure rather than a stale snapshot. The guard is applied to the withdrawal, perps, and predictions options on the sheet. ## **Changelog**   CHANGELOG entry: Fixed a bug where starting a Money transfer while another transaction was pending left a stuck pending transaction without opening the Send flow. ## **Related issues**  Fixes: https://consensyssoftware.atlassian.net/browse/MUSD-975 ## **Manual testing steps**  ```gherkin Feature: Money account transfer ("Between accounts") Scenario: starting a transfer while a transaction is already pending Given the user is on the Money account page And an unapproved transaction is already pending When user taps "Send" And user selects "Another account" Then the pending transaction is cleared And the Send flow opens for amount entry and account selection And no extra transaction is left stuck in the Activity list ``` ## **Screenshots/Recordings**   ### **Before**  N/A ### **After**  N/A ## **Pre-merge author checklist**   - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist**  - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] 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.

…31884) ## **Description**   Standardises the toast messages shown when a user **Sends** from the Money account into **Perps** and **Predict**. Previously these flows showed the Perps- and Predict-specific toasts, which looked different from the rest of the Money account (different icons, colours, copy, and no close button). This routes Money-funded Perps/Predict deposits through the existing Money toast pipeline (`MoneyTransactionMonitor` / `useMoneyToasts`) so they show the standard pending → success → failed toasts, and suppresses the divergent Perps/Predict deposit toasts for these Money-funded sends. Native (non-Money) Perps/Predict deposits are unaffected. Aligned with the Perps team (Matthieu approved). ## **Changelog**   CHANGELOG entry: Standardised the toast messages shown when sending from the Money account to Perps and Predict. ## **Related issues**  Fixes: https://consensyssoftware.atlassian.net/browse/MUSD-969 ## **Manual testing steps**  ```gherkin Feature: Standardised Money account Send toasts Scenario: User sends funds from the Money account to Perps Given the user is on the Money account home screen When the user taps Send and sends mUSD to Perps Then a "Sending funds" toast is shown while the transaction is pending And on confirmation a "Funds sent" toast showing the amount available in Perps is shown And the toast matches the standard Money account toast style (not the legacy Perps toast) Scenario: User sends funds from the Money account to Predict Given the user is on the Money account home screen When the user taps Send and sends mUSD to Predict Then a "Sending funds" toast is shown while the transaction is pending And on confirmation a "Funds sent" toast showing the amount available in Predict is shown And the toast matches the standard Money account toast style (not the legacy Predict toast) ``` ## **Screenshots/Recordings**   ### **Before**  _To be added after manual testing._ ### **After**  https://github.com/user-attachments/assets/b40a90b7-1993-4df8-8aa4-690beab5fa2d ## **Pre-merge author checklist**   - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist**  - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] 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.

…cated, verifying, and residency-blocked users (#31806) ## **Description**  The MetaMask Card section on Money Home previously only handled a small set of states, which meant unauthenticated cardholders did not see a way to link their Money Account to the Card, users mid-KYC saw nothing, and users in restricted residency regions could still attempt to link (only to fail later in the flow). This PR makes the Card linkage experience aware of the full set of user states: - **Unauthenticated cardholders** now see the link CTA. The linkage hook now exposes `hasMoneyAccountBaseRequirements` (requirements that do not depend on `isMoneyAccountCardSupported`), letting cardholders who have not authenticated yet enter the link flow. - **Verification in progress**: authenticated-but-not-yet-verified users now see a dedicated `verifying` mode on the `MoneyMetaMaskCard` with a banner explaining their identity verification is being reviewed, instead of an empty section. - **Restricted residency regions**: a new residency check blocks Money Account → Card linking for users whose KYC country/US-state falls within the mUSD-conversion blocked regions. Blocked users are prevented from linking across every entry point (sheet, background confirm, pending-link resume), the Money Account funding entry is filtered out of available card tokens, and failures emit a `RESIDENCY_BLOCKED` analytics reason. - The Card-mode selection logic on Money Home was extracted into a pure, unit-tested `deriveMoneyMetaMaskCardMode` helper, and the Money Home content layout was refactored into a single ordered list of sections so the Card section is reliably placed and dividers are rendered consistently. The section ordering reacts to Card mode (the Card surfaces earlier for active/linking users). - Residency data (`countryOfResidence`, `usState`) is now surfaced through the Baanx card provider and `CardAccountStatus`, with new `cardController` selectors building the residency region and computing the blocked state. - Minor UI/UX polish: introduced a shared `FLAT_BANNER_ALERT_STYLE` for flat, fully-rounded banners on Money/Card Home, removed the redundant divider above the link section on Card Home, and adjusted spacing. ## **Changelog**  CHANGELOG entry: Improved the MetaMask Card section on Money Home so unauthenticated cardholders can start linking, users in identity verification see a pending-review banner, and users in restricted regions are prevented from linking their Money Account to the Card. ## **Related issues**  Fixes: CARD-447 ## **Manual testing steps** ```gherkin Feature: Money Account to MetaMask Card linkage states on Money Home Scenario: Unauthenticated cardholder can start linking from Money Home Given I am a cardholder who has not authenticated the Card And my Money Account meets the base linkage requirements When I open Money Home Then I see the MetaMask Card section in "link" mode with a link CTA And tapping the CTA starts the link flow Scenario: User with identity verification in progress sees a pending banner Given I have authenticated the Card but my identity is not yet verified When I open Money Home Then I see the MetaMask Card section in "verifying" mode And I see a banner stating my identity verification is being reviewed Scenario: User in a restricted residency region cannot link Given my Card KYC residency region is in the mUSD-conversion blocked regions When I open Money Home Then the link CTA is not offered for the Money Account → Card step And the Money Account funding entry is not listed among available Card tokens Scenario: Linked user can manage the Card Given my Money Account is already linked to the Card When I open Money Home Then I see the MetaMask Card section in "manage" mode ``` ## **Screenshots/Recordings**  ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example ## **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.

…31792) ## **Description** Marketing/customer support asked for an entry point on the VIP pilot **referee** page so VIP referees can reach **priority support**. This adds a "Contact priority support" CTA (plus a short wallet-connect disclaimer) to the bottom of the VIP referee dashboard (`RewardsVipRefereeView`). Tapping it opens the existing in-app support WebView (`support.metamask.io`) with two extra query params: - `priority=vip` — a fixed tag so the support-side automation can fast-path the request to a human; - `account=<address>` — the user's account address, so that automation can verify enrollment via the **existing** support API (`GET /support/subscriptions/check?account=`, an `x-api-key` server-to-server endpoint added in Season 1 / RWDS-157 that returns the account's subscription status + tier). This intentionally reuses the Season-1 support-verification flow (which keys off the **account address**, not a subscription id), rather than inventing a new lookup. > [!NOTE] > Pending confirmation from the support/Intercom side: the `priority=vip` tag **value**, and whether the support automation already reads these inbound params / calls `/support/subscriptions/check`. The tag is isolated in a single URL builder (`buildVipPrioritySupportUrl`) so it's a one-line change. The `account` param name matches the existing support endpoint's query key. The disclaimer copy is also placeholder wording. ## **Changelog** CHANGELOG entry: Added a "Contact priority support" link to the VIP referee dashboard that routes VIP users to priority support. ## **Related issues** https://consensyssoftware.atlassian.net/browse/RWDS-1394 ## **Manual testing steps** 1. Open the app as a VIP **referee** (VIP program flag on, user is a VIP referee with a subscription id). 2. Navigate to the VIP referee page ("VIP Pilot"). 3. Scroll to the bottom — confirm the "Contact priority support" button and the disclaimer text render below the stats / "Last updated" row. 4. Tap the button — confirm the in-app WebView opens `support.metamask.io` with `&priority=vip&account=<your account address>` appended to the URL. ## **Screenshots/Recordings** ### **Before** N/A — new entry point; nothing rendered here previously. ### **After** <img width="1179" height="2556" alt="Simulator Screenshot - E2E Test - 2026-06-16 at 15 53 20" src="https://github.com/user-attachments/assets/659101c4-2ca1-42b6-9b1d-023ece8998f7" /> <img width="1179" height="2556" alt="Simulator Screenshot - E2E Test - 2026-06-16 at 15 53 25" src="https://github.com/user-attachments/assets/76899d30-bfaf-403a-9dfa-badc5d1e03bd" /> <img width="1179" height="2556" alt="Simulator Screenshot - E2E Test - 2026-06-16 at 16 09 35" src="https://github.com/user-attachments/assets/388a4e82-cf88-4fa1-84f9-ac3caf1fa1cb" /> <img width="1179" height="2556" alt="Simulator Screenshot - E2E Test - 2026-06-16 at 16 10 45" src="https://github.com/user-attachments/assets/701f7794-7b3d-47ba-b229-1a49155a7c81" /> ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pulled and built the branch, run the app, tested 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. --------- Co-authored-by: sophieqgu <sophieqgu@gmail.com>

## **Description** This PR stabilizes the performance E2E suite after recent app-side eligibility and UI timing changes. Changes included: - Updates BrowserStack's default geo location from Spain (`ES`) to Sweden (`SE`) so Predict performance tests do not hit the geoblocked-region modal by default. - Gives the Predict deposit flow a slightly longer Android threshold for opening the deposit screen and validates against the transaction fee row instead of the previous total row. - Re-enables the multiple-SRP import performance scenario. - Makes seedless Apple and Google onboarding resilient when the marketing opt-in checkbox is unavailable or fails to settle. - Extends the seedless Google onboarding timeout to avoid premature timeout during slower BrowserStack runs. - Sets the BrowserStack project-name fallback used by these sessions. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: performance E2E stabilization only ## **Manual testing steps** N/A - this PR updates automated performance E2E test configuration and test expectations. Validation is performed by running the affected BrowserStack performance pipeline. ## **Screenshots/Recordings** N/A - no user-facing UI changes. ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.

…31764) ## **Description** Wires the headless `RAMPS_TRANSACTION_FAILED` event for the money-deposit headless ramp flow (TRAM-3623 AC5), based on the foundation PR (#31715) - see the merge order below. Late / terminal headless failures are tagged controller-side, on the existing `RampsController:orderStatusChanged` metrics handler (`handleOrderStatusChangedForMetrics`). When a failing order has a registered headless context, the handler emits `RAMPS_TRANSACTION_FAILED` (tagged `ramp_type=HEADLESS`, plus `ramp_surface`, `region`, `error_message`) and returns, suppressing the generic ONRAMP/OFFRAMP emit for that order. This keeps the failure event tagged consistently with the rest of the headless funnel even when the failure arrives after the webview has closed, and guarantees a single emit per failure. Same-session approach (Option B): the in-memory context registry is populated while the headless session is live, so a failure observed later in the same app session can still be classified. A `TODO` notes Plan A (durable cross-session context, persisted with the order) as the eventual follow-up so a failure observed after an app restart can also be tagged. What's included: - Headless terminal-failure handling folded into the existing `event-handlers/analytics.ts` metrics handler (a single `orderStatusChanged` subscriber; no separate sibling handler). - In-memory `headlessOrderContextRegistry` (set / get / delete of order to headless context), written by `useTransakRouting` when a headless order is created and read by the handler at terminal time. - Unit coverage across the controller analytics, registry, and init suites (plus the Checkout / `useTransakRouting` suites), including an explicit "a headless failure emits exactly one `RAMPS_TRANSACTION_FAILED`, not `OFFRAMP_PURCHASE_FAILED`" assertion. TRAM-3534 overlap: the in-review #31207 re-maps deposit terminal events on this same handler. This PR deliberately lands the headless tagging in that same function, so #31207's later merge surfaces a normal, localized conflict to reconcile (the single tagged emit is preserved) rather than a silent runtime double-emit. This PR does not depend on #31207 and can merge first. ## **Stack & merge order (TRAM-3623)** Three stacked client PRs + a paired schema change. **Merge order:** 1. **#31715** (foundation, base `main`) - merge first; #31716 and #31764 depend on its shared types. 2. Then **#31716** (funnel) and **#31764** (tx-failed) - both stacked on the foundation branch and independent of each other, so merge in **either order**. When #31715 merges, GitHub retargets them to `main`; rebase onto `main`, then merge. Paired schema (already merged): Consensys/segment-schema#621 defines the `HEADLESS` / `ramp_surface` / `region` these events emit. This PR adds no new schema (the COMPLETED event is intentionally left untagged). _This PR is the tx-failed AC5 work (step 3, sibling of #31716)._ ## **Changelog** CHANGELOG entry: null (Internal analytics tagging only; no end-user-facing behavior change.) ## **Related issues** Refs: https://consensyssoftware.atlassian.net/browse/TRAM-3623 ## **Manual testing steps** ```gherkin Feature: Headless RAMPS_TRANSACTION_FAILED tagging Scenario: A terminal failed headless order emits a single tagged failure event Given a headless money-deposit order created via the MM Pay flow And the headless order context is registered for that order When the order transitions to a terminal failed state (even after the webview closed) Then exactly one RAMPS_TRANSACTION_FAILED is emitted, tagged ramp_type=HEADLESS plus ramp_surface and region And no OFFRAMP_PURCHASE_FAILED is emitted for that order ``` Unit tests green across the controller analytics / registry / init suites and the Checkout / `useTransakRouting` suites. ## **Screenshots/Recordings** N/A - controller-side analytics tagging only, no visual change. Verified via unit tests and the analytics debugger; recording tracked in TRAM-3623. ### **Before** N/A ### **After** After video: https://consensys.slack.com/archives/C0AK3NXRM7W/p1781627226380379 ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - [x] I've tested with a power user scenario - [x] I've instrumented key operations with Sentry traces for production performance metrics ## **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. --------- Co-authored-by: saustrie-consensys <270766059+saustrie-consensys@users.noreply.github.com>

…mation review page (#31906)   ## **Description**  Fix money account default selection should not work on MM Pay confirmation review page. ## **Changelog**   CHANGELOG entry: ## **Related issues**  Fixes: money_selection_fix ## **Manual testing steps** NA ## **Screenshots/Recordings** NA ## **Pre-merge author checklist**   - [X] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [X] I've completed the PR template to the best of my ability - [X] I've included tests if applicable - [X] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [X] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [X] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [X] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [X] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.

## **Description** change feature flag structure to make it more generic. ``` "enablePredictMoneyAccountTransactions": true, "enablePerpsMoneyAccountTransactions": true ``` is now: ``` "enableMoneyAccountTransactions": { "perpsDeposit": true, "perpsWithdraw": true, "predictDeposit": true, "predictWithdraw": true }, ``` ## **Changelog**   CHANGELOG entry: ## **Related issues**  Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1569 ## **Manual testing steps** NA ## **Screenshots/Recordings** NA ## **Pre-merge author checklist**   - [X] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [X] I've completed the PR template to the best of my ability - [X] I've included tests if applicable - [X] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [X] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [X] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [X] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [X] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.

## **Description** Additional MM Pay metrics properties. ## **Changelog**   CHANGELOG entry: ## **Related issues**  Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1419 ## **Manual testing steps** NA ## **Screenshots/Recordings** NA ## **Pre-merge author checklist**   - [X] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [X] I've completed the PR template to the best of my ability - [X] I've included tests if applicable - [X] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [X] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [X] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [X] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [X] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.

…#31762) Remove the AddNewAccount component and all navigation entry points to it. Snap account creation via this UI is no longer supported — accounts will be created through the v2 keyring pattern in a future migration. Changes: - Delete the AddNewAccount component and its BottomSheet wrapper - Remove Routes.SHEET.ADD_ACCOUNT and its screen registration in App.tsx - Remove carousel Solana slide that navigated to AddNewAccount - Remove bitcoin network selection fallback that navigated to AddNewAccount - Remove the ADD_ACCOUNT branch from the create-account deeplink handler - Remove AddNewAccount enum value from AccountConnectScreens ## **Description**  Remove the AddNewAccount component and all navigation entry points to it. Snap account creation via this UI is no longer supported — accounts will be created through the v2 keyring pattern in a future migration. Changes: - Delete the AddNewAccount component and its BottomSheet wrapper - Remove Routes.SHEET.ADD_ACCOUNT and its screen registration in App.tsx - Remove carousel Solana slide that navigated to AddNewAccount - Remove bitcoin network selection fallback that navigated to AddNewAccount - Remove the ADD_ACCOUNT branch from the create-account deeplink handler - Remove AddNewAccount enum value from AccountConnectScreens ## **Changelog**  CHANGELOG entry: Deeplink for /create-account won't create accounts automatically, but other behavior will remains (e.g. following-up with the appropriate flow). ## **Related issues**  Fixes: N/A ## **Manual testing steps**  ```gherkin 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](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] 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](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. --------- Co-authored-by: Hassan Malik <hbmalik88@gmail.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

#31909) ## **Description**  This PR polishes the Card spending-limit experience around route navigation and Money Account linking. **Reason for the change:** 1. The Card root screen was hardcoded to always animate with the full-screen slide-from-bottom modal options, regardless of where it was entered from. This made non-modal entry points (e.g. navigating deeper into the Card flow) feel inconsistent. 2. When linking a Money Account in the manage flow, the spending-limit screen locked the entire UI (and blocked back navigation) while linking was in progress, even though that linking happens in the background and does not require the user to stay on the screen. **Improvement/solution:** 1. **Dynamic Card route animation** — `MainNavigator` now reads an optional `animation` route param on the `CARD.ROOT` screen, defaulting to `slide_from_right`. `MoneyHomeView` explicitly passes `animation: 'slide_from_bottom'` so the Money → Card entry point keeps its modal feel, while other entry points slide in from the right. 2. **Unblock Money Account linking** — `useSpendingLimit` now exposes a dedicated `isUiInteractionLocked` flag (`isLoading && (!isMoneyAccountSource || isOnboardingFlow)`) separate from `isLoading`. The `SpendingLimit` `beforeRemove` guard now uses `isUiInteractionLocked` instead of `isLoading`, so a user linking a Money Account in the manage flow can still navigate back while background linking continues. The post-submit `goBack()` is now guarded by `navigation.isFocused()` to avoid popping the wrong screen when focus has already moved. ## **Changelog**  CHANGELOG entry: Fixed the Card screen navigation animation so it matches its entry point, and allowed Money Account linking to continue in the background without locking the spending-limit screen. ## **Related issues** Fixes: null ## **Manual testing steps** ```gherkin Feature: Card route navigation and Money Account linking Scenario: Card screen slides from bottom when opened from Money home Given I am on the Money home screen When I tap the MetaMask Card section to open Card home Then the Card screen animates in with a slide-from-bottom transition Scenario: Card screen slides from the right for non-modal entry points Given I navigate into the Card flow from a non-Money entry point When the Card root screen is presented Then the Card screen animates in with a slide-from-right transition Scenario: User can leave the spending-limit screen while a Money Account links in the background (manage flow) Given I am a cardholder on the spending-limit screen in the manage flow And my funding source is a Money Account When I submit a spending limit and Money Account linking starts in the background Then the UI is not locked And I can navigate back while linking continues Scenario: UI stays locked during onboarding linking Given I am on the spending-limit screen in the onboarding flow When I submit and linking is in progress Then the UI interaction is locked until linking completes ``` ## **Screenshots/Recordings** ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.

…#31894)   ## **Description**  `PerpsProgressBar` selected `withdrawalProgress` with an inline fallback `(state) => state?.withdrawalProgress || { progress: 0, lastUpdated: 0 }`. The `|| { ... }` allocated a brand-new object literal on every Redux evaluation whenever `withdrawalProgress` was null/undefined, breaking selector referential stability and triggering spurious re-renders of the component on unrelated dispatches. This PR hoists a module-scope constant `EMPTY_WITHDRAWAL_PROGRESS = { progress: 0, lastUpdated: 0 } as const` so the fallback is a stable reference, and switches `||` to `??` so a valid object with `progress: 0` is not incorrectly replaced by the fallback. ## **Changelog**  CHANGELOG entry: null ## **Related issues**  Refs: https://consensyssoftware.atlassian.net/browse/TAT-3328 ## **Manual testing steps**  ```gherkin Feature: Perps withdrawal progress bar stability Scenario: User watches the withdrawal progress bar during unrelated updates Given the user is on a Perps screen showing the withdrawal progress bar with no active withdrawal When unrelated PerpsController state updates dispatch (e.g. price ticks) Then the progress bar still renders correctly (empty/zero progress) And the component does not re-render spuriously while withdrawalProgress is null/undefined And when a withdrawal with progress 0 is present it is shown unchanged (not replaced by the fallback) ``` ## **Screenshots/Recordings**  ### **Before** N/A — no visual change (performance-only refactor). ### **After** N/A — no visual change (performance-only refactor). ## **Pre-merge author checklist**  - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. Co-authored-by: Cursor <cursoragent@cursor.com>

## **Description** Every UB2 buy is observed by two emitters: the RampsController listener (`handleOrderStatusChangedForMetrics`) and the legacy `fiatOrders` polling saga (`getRampsV2AnalyticsPayload`). Before this PR they were inconsistent, the controller path even fell through to `Off-ramp Purchase Completed` whenever `orderType !== 'BUY'` (e.g. Transak Apple Pay's `'DEPOSIT'`), and once that was renamed, the two paths were emitting `Ramps Transaction Completed`/`Failed` with two different payload shapes (legacy on-ramp purchase vs. unified deposit). Now both emit the same payload the deposit-flow funnel already produces: `ramp_type: 'UNIFIED_BUY_2'`, `amount_source`, `amount_destination`, `country`, `chain_id`, `gas_fee`, `processing_fee`, `total_fee`, plus `error_message` on failure. One Mixpanel event name → one schema across every UB2/deposit producer. With `ONRAMP_PURCHASE_*` / `OFFRAMP_PURCHASE_*` deprecation in flight, this is the schema that survives. Also folds in the related code bug from the ticket: `Aggregator/types/analytics.ts:390` had `OFFRAMP_PURCHASE_FAILED` typed as `OfframpCanceled` (sell-cancellation) instead of `OffRampPurchaseFailed`. One-line type fix; latent today because the saga's union type absorbed it via the `OffRampPurchaseCanceled = OffRampPurchaseFailed` alias. Out of scope (intentional): V2 sell-side, V2 buy cancellation, the deposit emitter itself, and `Ramps Transaction Confirmed` (already correct upstream). ## **Changelog** CHANGELOG entry: Fixed UB2 Transak buy orders firing the wrong Mixpanel completion event so analytics dashboards correctly attribute on-ramp purchases. ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TRAM-3534 ## **Manual testing steps** ```gherkin Feature: UB2 buy orders emit unified Ramps Transaction events Scenario: a Transak credit/debit-card buy completes successfully Given UB2 is enabled And the user starts a Transak credit/debit-card buy on Staging When the order polls through to COMPLETED Then a "Ramps Transaction Completed" event reaches Mixpanel QA for that order And the event carries ramp_type: "UNIFIED_BUY_2" And the event carries the unified payload (amount_source, amount_destination, country, chain_id, gas_fee, processing_fee, total_fee) And no "Off-ramp Purchase Completed" event fires for the same order And the legacy keys order_type, crypto_out, chain_id_destination are not present under the unified event name Scenario: a Transak buy fails (declined card or expired quote) Given UB2 is enabled And the user starts a Transak buy that will be declined or whose quote will expire When the order reaches FAILED or IdExpired Then a "Ramps Transaction Failed" event reaches Mixpanel QA for that order And the event carries ramp_type: "UNIFIED_BUY_2" And the event carries error_message populated from the order's status description Scenario: regression — deposit-flow Apple Pay buy is unchanged Given the user starts a Transak deposit-flow Apple Pay buy When the order completes Then a "Ramps Transaction Completed" event still reaches Mixpanel QA And the event carries ramp_type: "DEPOSIT" (unchanged from before this PR) ``` Unit tests: ```bash yarn jest \ app/components/UI/Ramp/utils/getRampsV2AnalyticsPayload.test.ts \ app/core/Engine/controllers/ramps-controller/event-handlers/analytics.test.ts \ app/components/UI/Ramp/Deposit/utils/getDepositAnalyticsPayload.test.ts # 37/37 passing ``` ## **Screenshots/Recordings** ### **Before** Pre-fix evidence is in the ticket. ### **After** <img width="4578" height="2582" alt="image" src="https://github.com/user-attachments/assets/f9079cfd-8882-495a-a941-b53e919fdfd7" /> Video unavailable due to issues with Transak Staging: https://consensys.slack.com/archives/C08BSCL8UKA/p1781649926539899 ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. --------- Co-authored-by: Cursor <cursoragent@cursor.com>

…NBA champion discovery references cp-7.82 (#31873)   ## **Description**   Updates the homepage Predict empty-state discovery list to prioritize live World Cup games. When the World Cup live feed returns an ongoing game, the middle row now displays that live game with the same Live pill treatment used by the BTC row and opens the existing Predict market details game experience. When there is no live World Cup game, the row falls back to the main `2026 FIFA World Cup Winner` market. The retired NBA Champion discovery row and its feature flag plumbing were removed. ## **Changelog**   CHANGELOG entry: Updated the Predict homepage empty state to feature live World Cup games when available ## **Related issues**  Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-923 ## **Manual testing steps**  ```gherkin Feature: Predict homepage empty state discovery Scenario: user sees a live World Cup game in the Predict empty state Given Predict is enabled And the user has no Predict positions And the World Cup live feed returns an ongoing game When the user opens the wallet homepage Then the Predictions section shows the live World Cup game row And the row shows a Live pill with a zero-padded minute value when under 10 minutes And tapping the row opens Predict market details for that game Scenario: user sees the World Cup winner market when no game is live Given Predict is enabled And the user has no Predict positions And the World Cup live feed has no ongoing games When the user opens the wallet homepage Then the Predictions section shows the 2026 FIFA World Cup Winner row And the NBA Champion row is not shown ``` ## **Screenshots/Recordings**   ### **Before** <img width="382" height="336" alt="Screenshot 2026-06-17 at 11 17 55" src="https://github.com/user-attachments/assets/5ad4c673-7b24-4d17-836d-4fb3af4b895a" />  ### **After** <img width="392" height="348" alt="Screenshot 2026-06-17 at 11 12 22" src="https://github.com/user-attachments/assets/287571bf-c689-46c4-b727-85d5c4460c3e" />  ## **Pre-merge author checklist**   - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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.

maxime-oe and others added 30 commits June 11, 2026 16:34

Bump OTA version to 7.81.0

f6344a4

[skip ci] Bump version number to 5485

f237bc3

fix(card): solve conflicts

9315676

Merge branch 'release/7.81.1-ota' into cherry-pick-7-81-1-7b0e275

27b8c38

[skip ci] Bump version number to 5489

bef2a15

[skip ci] Bump version number to 5491

2a5240a

[skip ci] Bump version number to 5494

4ec7a07

release: release-changelog/7.81.1 (#31738)

c79c209

This PR updates the change log for 7.81.1. (Hotfix - no test plan generated.) --------- Co-authored-by: metamaskbot <metamaskbot@users.noreply.github.com> Co-authored-by: sleepytanya <sleepytanya@gmail.com>

[skip ci] Bump version number to 5497

2146bfa

revert build number bump

37d319e

Merge branch 'stable' into release/7.81.1-ota

0b1e479

fix changelog

3f13d20

release: 7.81.1 (OTA) (#31737)

b95589a

OTA hotfix: branch release/7.81.1-ota. Native semver and build version are not bumped. OTA_VERSION in app/constants/ota.ts is v7.81.1. CHANGELOG.md header and production git tag both use bare 7.81.1 / v7.81.1; the -ota suffix is branch-only.

Merge origin/main into stable-main-7.81.0

30d9191

ghgoodreau and others added 19 commits June 17, 2026 13:29

pull Bot locked and limited conversation to collaborators Jun 17, 2026

pull Bot added the ⤵️ pull label Jun 17, 2026

pull Bot merged commit 517b56a into Reality2byte:main Jun 17, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[pull] main from MetaMask:main#842

[pull] main from MetaMask:main#842
pull[bot] merged 49 commits into
Reality2byte:mainfrom
MetaMask:main

pull Bot commented Jun 17, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

Conversation

pull Bot commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

pull Bot commented Jun 17, 2026 •

edited

Loading