[pull] main from MetaMask:main#791
Merged
Merged
Conversation
## Feature Flag Registry Drift Report Feature flag drift was detected between E2E tests and production. Download the [`drift-report` artifact](https://github.com/MetaMask/metamask-mobile/actions/runs/26071129717) for the full report. --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Priya <priya.narayanaswamy@consensys.net>
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MMQA-1871 ## **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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > New CI/e2e dependency on Anthropic API keys and flaky vision judgments; swap performance test behavior and Appium selectors changed, which can affect emulator stability but not production app code. > > **Overview** > Adds an **AI visual regression** test framework under `tests/framework/ai-visual/` that captures Appium screenshots, compares them to committed baselines via **Claude** (when `AI_VISUAL_TESTING_ENABLED=true`), and attaches current/baseline/diff/analysis artifacts to Playwright reports plus a run summary JSON. Includes layered prompts, per-screen `createTestConfig` presets, optional `sharp` side-by-side diffs, and `yarn capture-visual-baselines:{android,ios}` scripts. > > Wires the first consumer into **`eth-swap-flow.spec.ts`**: smaller swap amount (`0.0001`), dismiss keypad before quote timing, then `aiVisualTest` on `Swap-Confirmation-ETH-USDC.png` with `swapReview` config. > > **`QuoteView`** Appium paths are hardened for this flow—iOS token pick by XPath `@name`, keypad entry via `keypad-key-*` test IDs (including dot), and Appium keypad dismiss by tapping the bridge scroll view instead of the rate label. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e276300. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.
In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
## **Description**
<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->
## **Changelog**
<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`
If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`
(This helps the Release Engineer do their job more quickly and
accurately)
-->
CHANGELOG entry: update assets unify state mocks
## **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**
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
### **Before**
<!-- [screenshots/recordings] -->
### **After**
<!-- [screenshots/recordings] -->
## **Pre-merge author checklist**
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [ ] 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**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [ ] 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.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Low Risk**
> Changes are limited to tests, fixtures, and mock servers; no
production wallet or transaction logic is modified in this diff.
>
> **Overview**
> This PR updates **test and e2e fixtures/mocks** so flows that now read
unified **`AssetsController`** state (CAIP asset IDs, `assetsInfo`,
`assetsBalance`, `assetsPrice`, `selectedCurrency`) keep passing.
>
> **Unit/integration tests** seed `AssetsController` in Earn
(`EarnInputView`, `useEarnToken`, `useEarnTokens`, earn selectors), Ramp
`useBalance`, confirmations `useTokenFiatRates`, multichain balances,
and **`assets-list`** (checksum addresses, zero-balance cases driven by
`assetsBalance`). **`EarnInputView`** also stabilizes conversion-rate
mocking and drops a brittle `$1` fiat assertion.
>
> **E2E/smoke** add Accounts API **v5** multi-account balance mocks,
**tokens** v2 supported networks / v3 assets / v3 spot prices, and
**`seedUnifiedEvmAssets`** (or inline `AssetsController` seeding) for
send ERC-20, lending, homepage network filter, and network manager
tests.
>
> **API mocking defaults** add empty v5 balances and supported-networks
responses. **`assets-controller-init`** / **bridge** init tests only
rename cases to mention assets unify “hardcoded on for development”
(assertions in the diff are unchanged).
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
458ed37. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** This PR fixes the icons for the hardware wallets in the add hardware wallet screen. <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: fixes the hardware wallet icons in dark and light mode ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MUL-1792?atlOrigin=eyJpIjoiZWY3NWEzMjJmNmUxNDczNTlhNjIyZWFhM2EzNmQ0YzAiLCJwIjoiaiJ9 ## **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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <img width="1080" height="2316" alt="Screenshot_20260527_182837_MetaMask" src="https://github.com/user-attachments/assets/d1e74e2e-a454-4681-9c3c-2c2f0604cfb3" /> <img width="1080" height="2316" alt="Screenshot_20260527_182844_MetaMask" src="https://github.com/user-attachments/assets/726a0328-5b07-43fb-bc8c-2f3bbeeee99e" /> <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Visual and asset changes on a connect-hardware screen only; navigation and analytics behavior unchanged aside from test hygiene. > > **Overview** > The **Add hardware wallet** (`SelectHardware`) screen now picks **Ledger**, **Keystone**, and **OneKey** logos from new light/dark SVG assets via exported `getHardwareThemeAssets`, using `themeAppearance` from app theme. Brand rows use **40×40** SVGs directly instead of the old mixed assets (including a PNG for OneKey). > > The **Other QR wallet** row keeps a rounded tile whose **background and QR icon colors** invert with theme (e.g. black tile / white icon in light mode). Tests cover theme asset mapping, dark-mode render, button pressed opacity, and quieter `console.error` handling in failure paths. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 33f9996. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** Track explore conversions in swaps Segment: Consensys/segment-schema#586 <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: track explore conversions in swaps ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/ASSETS-3264 ## **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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Analytics location mapping only; swap routing logic is unchanged aside from metadata passed to the bridge navigation hook. > > **Overview** > Swap/bridge sessions started from **Token Details** now attribute **Trending Explore** instead of **Token View** when the page was opened from Explore (movers, stocks, crypto trending, RWAs, or generic trending). > > A new `isExploreTokenDetailsSource` helper centralizes which `TokenDetailsSource` values count as Explore. `useHandleOnSwap` passes `SwapBridgeNavigationLocation.TrendingExplore` into `useSwapBridgeNavigation` for those sources; all other entry points still use **Token View**. Opening details from the bridge asset picker (`TokenDetailsSource.Swap`) is unchanged: **Token View** with `skipLocationUpdate: true` so the original bridge session location is preserved. > > Unit tests cover Explore vs wallet list vs bridge-picker behavior. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit f2c4537. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## Summary - Adds a `global-infrastructure-change` hard rule to Smart E2E Selection so changes to globally mounted code always run the full smoke tag set (conservative fallback). - Matches changes under `app/components/hooks/**`, `app/contexts/**`, `app/store/**`, and Engine wiring entry files (`app/core/Engine.ts`, `app/core/Engine/Engine.ts`, `app/core/Engine/index.ts`). - Extracts path matching into `global-infrastructure-paths.ts` and adds unit tests plus a local `tsconfig.json` for the e2e-ai-analyzer package. Fixes the gap exposed by #30381: a 2-file change to `AssetPollingProvider.tsx` passed required CI but skipped stake/snaps shards because the AI selector had no file-to-tag mapping for global hooks/providers. ## Context Smart E2E Selection (`tests/tools/e2e-ai-analyzer/`) previously only had one deterministic guard: `@metamask/*-controller` bumps in `package.json`. Hook/provider changes were left to the LLM, which omitted tags like `SmokeStake` and `SmokeSnaps` that depend transitively on globally mounted code. ## Related - Incident: #30381 - Shadow CI backstop: MCWP - AssetPolling fix: MMASSETS ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> 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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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 - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > CI-only E2E tag selection logic; broader test runs on matching paths, no production app behavior changes in this diff. > > **Overview** > Smart E2E **select-tags** mode now treats edits to app-wide wiring as a **hard rule**: if any changed path matches global infrastructure, selection skips the LLM and runs the **full smoke tag set** (same conservative path as controller bumps). > > A new helper normalizes paths and flags prefixes `app/components/hooks/`, `app/contexts/`, `app/store/`, plus exact Engine entry files `app/core/Engine/Engine.ts` and `app/core/Engine/index.ts` (not the whole `app/core/Engine/` tree). `handlers.ts` wires a `global-infrastructure-change` rule that calls `getGlobalInfrastructureHardRuleReason` and returns a reason listing matching files. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 678d58f. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description**
This pull request updates the version of the
`@metamask/bitcoin-wallet-snap` dependency in the `package.json` file
from `1.10.1` to `1.11.0`.
## **Changelog**
<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`
If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`
(This helps the Release Engineer do their job more quickly and
accurately)
-->
CHANGELOG entry: bumped bitcoin snap v1.11.0
## **Related issues**
Fixes: null
## **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**
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
### **Before**
<!-- [screenshots/recordings] -->
### **After**
<!-- [screenshots/recordings] -->
## **Pre-merge author checklist**
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [ ] 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**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [ ] 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.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Bitcoin Snap behavior ships inside the wallet dependency; regression
risk is in BTC send/receive/sign flows even though the diff is only
version pins.
>
> **Overview**
> Bumps the bundled **Bitcoin wallet Snap** from **1.10.1** to
**1.11.0** by updating `@metamask/bitcoin-wallet-snap` in `package.json`
and the matching `yarn.lock` resolution/checksum. No app source files
change; the mobile client still wires Bitcoin through the same
`npm:@metamask/bitcoin-wallet-snap` preinstalled Snap entry.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
6468634. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** This PR fixes the navigation after forgetting a QR hardware wallet. Previously, the app used `navigation.pop(2)` which could leave the user on an unexpected screen depending on the navigation stack state. Now it uses `CommonActions.reset` to navigate the user back to the home screen (`Routes.ONBOARDING.HOME_NAV`). <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Redirect user to home screen after forgetting qr hardware wallet. ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MUL-1803?atlOrigin=eyJpIjoiOWJmZDc2ZmFlNGRiNDFiYjllYjY0NjQ0NzY1YmU3YWUiLCJwIjoiaiJ9 ## **Manual testing steps** ```gherkin Feature: QR Hardware Wallet Forget Navigation Scenario: user forgets a QR hardware wallet Given user has a QR hardware wallet connected And user is on the Connect QR Hardware screen When user presses "Continue" And user presses the "Forget" button Then user is redirected to the Home screen And the navigation stack is reset (no back navigation to QR screens) ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Localized post-forget navigation change with a focused unit test; no changes to keyring, permissions, or unlock flow. > > **Overview** > After a user **forgets** a QR hardware wallet on `ConnectQRHardware`, navigation no longer uses `navigation.pop(2)`. It now **`CommonActions.reset`** to a single route, **`Routes.ONBOARDING.HOME_NAV`**, so the stack is cleared and the user lands on home instead of depending on how deep the QR flow was pushed. > > Tests mock `dispatch` and assert the reset payload; they also confirm **`navigate`**, **`goBack`**, and **`pop`** are not used for this path. **Unlock** still uses `pop(2)` and is unchanged. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit dfae871. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…30049) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> Removes missing references for the removed DetectedTokens modal. ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> 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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Documentation and TypeScript-only cleanup with no runtime or security impact. > > **Overview** > Removes **stale references** to the deleted **DetectedTokens** modal so they no longer appear in repo metadata or navigation types. > > **CODEOWNERS** drops ownership for `app/components/Views/DetectedTokens`. **`RootStackParamList`** in `app/core/NavigationService/types.ts` removes the `DetectedTokens` modal route entry. No app logic or UI behavior changes in this diff—only alignment after the screen was removed elsewhere. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 734248d. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…5) cp-7.79.0 (#30740) ## **Description** Replaces the **"Open Position"** copy on the Perps Trading Competition opted-in CTA with **"Trade now"**, per [RWDS-1335](https://consensyssoftware.atlassian.net/browse/RWDS-1335). Scope is intentionally copy-only: - `locales/languages/en.json` — `rewards.perps_trading_campaign.open_position_cta` value. - `app/components/UI/Rewards/components/Campaigns/PerpsTradingCampaignCTA.tsx` — comment updated to match. - `app/components/UI/Rewards/components/Campaigns/PerpsTradingCampaignCTA.test.tsx` — mock value, test name, and rendered-text assertion. No behavior, navigation, or analytics changes — the CTA still deep-links to `link.metamask.io/perps?screen=market-list`. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: [RWDS-1335](https://consensyssoftware.atlassian.net/browse/RWDS-1335) ## **Manual testing steps** ```gherkin Feature: Perps Trading Competition CTA copy Scenario: Opted-in user sees the renamed CTA Given I am opted in to the Perps Trading Competition campaign And the campaign is active When I open the Rewards campaigns view Then the campaign CTA reads "Trade now" And tapping it deep-links to the Perps market list ``` ## **Screenshots/Recordings** ### **Before** CTA: "Open Position" ### **After** CTA: "Trade now" ## **Pre-merge author checklist** - [x] I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards. - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [ ] I've documented my code using JSDoc format if applicable - [ ] I've applied the right labels on the PR [RWDS-1335]: https://consensyssoftware.atlassian.net/browse/RWDS-1335?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [RWDS-1335]: https://consensyssoftware.atlassian.net/browse/RWDS-1335?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Copy-only change to an existing i18n string and tests; navigation and campaign logic are unchanged. > > **Overview** > Renames the opted-in **Perps Trading Competition** primary CTA label from **"Open Position"** to **"Trade now"** via `rewards.perps_trading_campaign.open_position_cta` in English (`en.json`). The component still uses the same i18n key and `handleOpenPosition` still deep-links to `link.metamask.io/perps?screen=market-list`; only the displayed string and an inline comment change. Unit tests update the i18n mock, test description, and on-screen text assertion to match. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit a5c865b. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
…CU-681) (#30697) ## **Description** Implements the **Trade** portion of [TMCU-681](https://consensyssoftware.atlassian.net/browse/TMCU-681): when the user taps **Trade** on the wallet home onboarding checklist, the app opens unified swaps with source/destination defaults based on mainnet balances at press time. **Priority:** 1. Mainnet **mUSD** balance > 0 → swap **mUSD → ETH** 2. Else mainnet **ETH** balance > 0 → swap **ETH → BTC** 3. Else → existing `goToSwaps(undefined, undefined)` fallback **Implementation:** - `walletHomeOnboardingTradeSwapAssets.ts` — mainnet mUSD / ETH / BTC `BridgeToken` helpers (local constants; no Ramp edits). - `walletHomeOnboardingTradeSwapBalances.ts` — balance checks via `selectSingleTokenBalance` + `resolveWalletHomeOnboardingTradeSwapPair`. - `useWalletHomeOnboardingTradeSwapPair` — subscribes via `useSelector` and resolves the pair reactively. - `useWalletHomeOnboardingChecklistTradePress` — passes resolved tokens to `goToSwaps` with `ActionLocation.ONBOARDING_CHECKLIST` (TMCU-680 analytics location unchanged). Complements the **Add funds** work in #30692 (separate PR; can merge independently). ## **Changelog** CHANGELOG entry: Improved the wallet home onboarding **Trade** step to open swaps with sensible default tokens (mUSD→ETH or ETH→BTC) when the user has matching mainnet balances. ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-681 ## **Manual testing steps** ```gherkin Feature: Wallet home onboarding trade step swap preselection Scenario: Trade opens swaps with mUSD source and ETH destination when mainnet mUSD balance is positive Given wallet home onboarding checklist is visible on the trade step And the selected account has a positive mainnet mUSD balance When user taps Trade Then unified swaps opens with mUSD as source and ETH as destination Scenario: Trade opens swaps with ETH source and BTC destination when only mainnet ETH balance is positive Given wallet home onboarding checklist is visible on the trade step And the selected account has no mainnet mUSD balance but has positive mainnet ETH balance When user taps Trade Then unified swaps opens with ETH as source and BTC as destination Scenario: Trade opens default swaps when neither mUSD nor ETH mainnet balance is positive Given wallet home onboarding checklist is visible on the trade step And the selected account has no positive mainnet mUSD or ETH balance When user taps Trade Then unified swaps opens with default token selection (no overrides) ``` ## **Screenshots/Recordings** ### **Before** Trade opened unified swaps with default token selection (no source/dest overrides). ### **After** Trade opens with mUSD→ETH or ETH→BTC when the user has the corresponding mainnet balance. <!-- Add screenshots/recordings during manual QA if needed --> ## **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. [TMCU-681]: https://consensyssoftware.atlassian.net/browse/TMCU-681?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Onboarding-only navigation change with balance-driven token defaults and tests; no auth, payments, or core swap execution logic modified. > > **Overview** > **Wallet home onboarding Trade** now opens unified swaps with **preselected source/destination tokens** from the user’s mainnet balances instead of always using empty overrides. > > On **Trade** press, a memoized selector reads **TokenBalancesController** for the selected account: positive **mUSD** (checksummed address key) → **mUSD → ETH**; else positive **ETH** → **ETH → BTC**; otherwise behavior matches the previous **`goToSwaps(undefined, undefined)`** fallback. **`ActionLocation.ONBOARDING_CHECKLIST`** is unchanged. > > **Wallet** wires the checklist through **`useWalletHomeOnboardingChecklistTradePress`**, which reads the latest pair via a ref at tap time. New modules cover mainnet **BridgeToken** helpers, stable swap-pair constants, hooks, and unit tests. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 68f718e. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Description This PR bumps @metamask/tron-wallet-snap from `^1.25.3` to `^1.25.6`. The main purpose of this update is to pull in the latest Tron snap validation fixes, in particular a mechanism to refresh stale or invalid `expiration`, `ref_block_bytes` and `ref_block_hash` before signing in both send/broadcast paths. Preview package: - `@metamask-previews/tron-wallet-snap@1.25.3-preview-995ddc5` Release: - `@metamask-previews/tron-wallet-snap@^1.25.6` Upstream PR: - MetaMask/snap-tron-wallet#305 ## Changelog CHANGELOG entry: bump the `@metamask/tron-wallet-snap` to `^1.25.6` ## Related issues 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 <!-- [screenshots/recordings] --> ### After <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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 - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches Tron signing and broadcast behavior via the wallet snap; scope is limited to a patch dependency bump with no local code edits, but failed or incorrect ref-block handling could still affect Tron sends. > > **Overview** > Bumps **`@metamask/tron-wallet-snap`** from `^1.25.3` to `^1.25.6` in `package.json` and `yarn.lock`, with an **Unreleased** changelog entry. There are **no application source changes** in this repo—the mobile app picks up upstream snap behavior from the new package version. > > Per the PR intent, **1.25.6** brings Tron transaction validation fixes, notably **refreshing stale or invalid `expiration`, `ref_block_bytes`, and `ref_block_hash` before signing** on send and broadcast paths. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b958d77. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: gabrieledm <gabriele.delmonte@proton.me> Co-authored-by: Gabriele Del Monte <37625739+gabrieledm@users.noreply.github.com>
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.
In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
## **Description**
### VIP Localized Text
- Expands VIP backend/contentful localized text support with new fields
for referral points, stats labels, top-tier messaging, and next-tier
referral points copy.
- Replaces several hardcoded/local i18n labels in VIP volume and tier
rows with dashboard.localizedText.
- Updates VIP badge label from VIP {{tier}} to VIP Fox {{tier}} across
locale files.
### VIP Progress Bar
- Fixes top-tier progress messaging: when progress is >= 100, the card
now shows backend-provided topTierDescription instead of “0 points to
next tier.”
- Keeps progress fill clamped between 0% and 100%.
- Local edits make the member ID text theme-aware for better light-mode
contrast.
### VIP Fee Tile
- Adds a fourth benefits carousel tile for referral points.
Pulls referral carryover from the current tier details and formats it as
a percent.
- Uses backend-provided referralPointsTitle and
nextTierReferralPointsDelta.
- Updates skeleton count/tests from 3 fee tiles to 4.
- Local edits make next-tier text use standard alternative color in
light mode and VIP muted gold in dark mode.
### VIP Light Theme
- Adjusts VIP muted text handling so gold text is reserved for dark mode
where it reads better.
- In light mode, member ID and fee-tile helper text now use standard
TextAlternative.
- Badge border gradient was softened to a lighter gold tone.
### VIP Icon
@MetaMask/perps
https://consensyssoftware.atlassian.net/browse/RWDS-1334
- Replaces the old rewards/points fox VIP icon with the shared vip.svg.
- Applies the new icon in the VIP badge, perps fee discount tooltip, and
referral code tag.
- Removes the old metamask-rewards-points-vip.svg asset.
old vip icon:
<img width="14" height="14" alt="old_vip"
src="https://github.com/user-attachments/assets/e45d89b9-152e-4dd8-8c7e-ab1787dbaf05"
/>
new vip icon:
<img width="24" height="24" alt="new_vip"
src="https://github.com/user-attachments/assets/6dcaa3c5-cc88-43fd-b670-ca0cd8318fd4"
/>
### Perps Trading Leaderboard And Stats Fixes
Related backend change:
consensys-vertical-apps/va-mmcx-rewards#596
- Treats leaderboard position as valid only when rank is present,
preventing empty/malformed position data from rendering the stats
header.
- Adds safer fallbacks for invalid rank, pnl, and notionalVolume,
showing — instead of broken/incorrect values.
- Updates formatUsd to return — for invalid/null/undefined numeric
input.
- Prevents qualify-for-rank calculations from using invalid notional
volume.
- Fixes long leaderboard ranks to stay on one line without squeezing the
row layout.
- Adds tests around missing/invalid position data, long ranks, and stat
fallbacks.
<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->
## **Changelog**
CHANGELOG entry: null
## **Screenshots/Recordings**
### **After**
- vip icon change @MetaMask/perps
(tier but with fee discount)
<img width="1220" height="2712" alt="image"
src="https://github.com/user-attachments/assets/108d7f7c-d151-4f58-bdef-188eb74abf65"
/>
<img width="1220" height="2712" alt="image"
src="https://github.com/user-attachments/assets/00dd7c84-f9f2-403c-82a7-8a4482c08832"
/>
( tier, no fee discount, only showing badge)
<img width="1220" height="1230" alt="image"
src="https://github.com/user-attachments/assets/c5a26bb6-b7e9-454d-876c-aa132fcc73b7"
/>
(swaps)
<img width="1220" height="1230" alt="image"
src="https://github.com/user-attachments/assets/87378711-9189-4309-8481-1d418306f9c6"
/>
- changes in vip dashboard now dynamic from contentful (dont mind light
theme, will put up separate pr to enforce dark theme)
<img width="1179" height="2556" alt="Simulator Screenshot - E2E Test -
2026-05-27 at 15 47 00"
src="https://github.com/user-attachments/assets/05c77002-b404-49d7-b447-5964ff0f0f49"
/>
<img width="1179" height="2556" alt="Simulator Screenshot - E2E Test -
2026-05-27 at 18 23 32"
src="https://github.com/user-attachments/assets/b43860ce-6c7f-4959-ad7d-5bafff3460e7"
/>
<img width="1179" height="2556" alt="Simulator Screenshot - E2E Test -
2026-05-27 at 18 23 36"
src="https://github.com/user-attachments/assets/dc045cd0-d0ba-428c-9de4-98553f85381b"
/>
- perps competition relates changes
<img width="1179" height="2556" alt="Simulator Screenshot - E2E Test -
2026-05-27 at 16 50 40"
src="https://github.com/user-attachments/assets/bf801376-a768-4f71-90a1-69c0e62d6df6"
/>
<img width="1179" height="2556" alt="Simulator Screenshot - E2E Test -
2026-05-27 at 16 50 51"
src="https://github.com/user-attachments/assets/d200b94e-3646-4d70-ac92-f9e2cdc0089b"
/>
<!-- [screenshots/recordings] -->
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Broad rewards/VIP UI and DTO changes depend on backend supplying new
localizedText fields; perps position gating changes visible
leaderboard/stats behavior when rank is missing.
>
> **Overview**
> Syncs VIP and perps trading UI with expanded **Contentful/backend
`localizedText`**, refreshes VIP branding, and hardens campaign stats
against malformed API data.
>
> **VIP dashboard & tiers:** `VipLocalizedTextDto` gains
referral-points, volume/stat labels, top-tier copy, and next-tier
referral deltas. `RewardsVipView` drives volume/tier labels from
`dashboard.localizedText`, adds a **referral points** fee carousel tile
(4 tiles + skeletons), shows `topTierDescription` when progress is
≥100%, and passes localized labels into `VipVolumeSection` /
`VipTierRow`. Badge copy becomes **VIP Fox {{tier}}** in locales.
>
> **VIP visual polish:** Shared `vip.svg` replaces legacy fox VIP assets
(badge, referral tag, perps fee discount tooltip); badge gradient/colors
updated. `VipFeeTile` and `VipTierProgressCard` use standard alternative
text in **light** mode and VIP muted gold in **dark** mode.
>
> **Perps trading campaigns:** User position counts only when
`position?.rank` is finite; stats headers hide without a valid rank.
Rank/PnL/volume use `Number.isFinite` and `—` fallbacks; `formatUsd`
returns `—` for invalid input. Leaderboard rank column uses `min-w-8`,
`shrink-0`, and `numberOfLines={1}` for long ranks. Tests cover invalid
position data and UI fallbacks.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
9211b45. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: sophieqgu <sophieqgu@gmail.com>
…ntact options (#30593) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** This PR updates the redesigned homepage NFT behavior for wallets with no NFTs. When a user has zero NFTs, the homepage no longer renders the dedicated NFTs section, including its header, container, and empty-state import copy. This keeps the page cleaner and lets the surrounding sections reflow naturally without leftover gaps. The PR also adds a new homepage “More” section with actions for: - Import a token - Import an NFT - Contact support The import/support actions include Segment tracking with `location: home`. ## **Changelog** CHANGELOG entry: Updated the homepage to hide the NFTs section when users have no NFTs and added import token, import NFT, and contact support actions. ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-739 ## **Manual testing steps** ```gherkin Feature: Homepage NFTs and More section Scenario: user has no NFTs Given the redesigned homepage is enabled And the wallet has zero NFTs When user views the homepage Then the NFTs section is not shown And the More section is shown And Import a token is shown And Import an NFT is shown And Contact support is shown Scenario: user has NFTs Given the redesigned homepage is enabled And the wallet has one or more NFTs When user views the homepage Then the NFTs section is shown And the More section is shown ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <img width="408" height="846" alt="Screenshot 2026-05-25 at 13 05 22" src="https://github.com/user-attachments/assets/fd75f7c9-af03-4883-aaf6-ff69a12a15ba" /> <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > UI and navigation changes on the wallet homepage with analytics updates; no auth, payments, or security-sensitive logic. > > **Overview** > The redesigned homepage **hides the NFTs block entirely when the wallet has no NFTs** (no header, empty state, or placeholder below trending). **NFT detection** now runs from `Homepage` on focus (with abort on blur) instead of from `NFTsSection`. **`NFTsSection`** only renders the grid when the user owns NFTs; skeleton, empty import UI, and in-section detection are removed. > > A new **More** section is always appended with **Import a token**, **Import an NFT**, and **Contact support**, each navigating to the right flow and firing analytics with `location: home`. Section ordering and `useHomeViewedEvent` counts treat NFTs as optional (indices/`totalSectionsLoaded` drop when empty). New i18n strings, `HomepageMoreSelectorsIDs`, and unit tests cover the behavior. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 956e0c4. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…30554) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> **Problem.** The Money Account → Card link approve was submitted via `TransactionController.addTransaction` with `from = moneyAccountAddress` on Monad. Monad gas-sponsorship requires the funding account to hold a 10 MON reserve, and the money account ships with 0 MON, so the link silently failed for the very cohort the feature targets. The existing deposit/withdraw flow does not suffer from this because it submits via `addTransactionBatch` with `isGasFeeSponsored: true`, which routes the transaction through the Sentinel 7702 relay (the user's selected EVM account pays via MM Pay; the relay covers the on-chain MON gas). **Solution.** Bring the card-link approve onto the same sponsorship rail used by deposit/withdraw, without introducing a new transaction type: - `CardController.#linkMoneyAccountCardUnsafe` now submits via `addTransactionBatch` (single inner `tokenMethodApprove`) with `isGasFeeSponsored: true`, `requireApproval: false`, `disableHook: true`, `disableSequential: true`. The inner transaction id is resolved from the returned `batchId` so the existing `awaitTransactionConfirmed` helper still subscribes to confirmation/failure events. - Two pre-flight gates added before submission: (1) Monad sponsorship feature flag via `getGasFeesSponsoredNetworkEnabled`, and (2) money-account 7702 capability via `TransactionController:isAtomicBatchSupported`. Both throw `CardProviderError` if not satisfied, instead of letting the relay reject mid-flight. - `money-account-override.ts` gets a new non-type discriminator `isMoneyAccountCardLinkApprove` (`origin === MMM_CARD && from === primaryMoneyAccount.address`, case-insensitive). The existing `handleUnapprovedTransactionAddedForMoneyAccount` ORs it with the deposit/withdraw matcher so the link approve also seeds `TransactionPayController.accountOverride` with the user's selected EVM account — making MM Pay treat that account as the payer. - `useIsMoneyAccount7702Ready` (new hook) wraps `isAtomicBatchSupported` for the primary money account on the vault chain. Returns `undefined` while pending, `true`/`false` once resolved. - `useMoneyAccountCardLinkage.canLink` is extended to require `isMonadSponsorshipEnabled && is7702Ready === true`, hiding the money-account CTA on SpendingLimit when the path cannot succeed. No JSX change required in the screen. - Card-controller messenger surface widened with `TransactionController:addTransactionBatch`, `getState`, `isAtomicBatchSupported`. End-to-end verified on device: link approve confirms on Monad with `gas_insufficient_native_asset: true` and `account_eip7702_upgraded` set, post-approval call to Baanx returns `success: true`, and `isAlreadyDelegated` flips to `true`. ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Fixed Money Account → Card linking failing when the money account holds no MON, by routing the link approve through the gas-sponsored 7702 relay. ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: Money Account → Card link approve via sponsored relay Background: Given I am logged into MetaMask Mobile And I have a card that is authenticated with Baanx And I have a Money Account with 0 MON on Monad And the Money Account has been EIP-7702-upgraded on Monad And the Monad gas-sponsorship feature flag is enabled Scenario: user links the card using the Money Account as funding source Given I am on the SpendingLimit screen And the Money Account is not yet delegated for the card When user selects the Money Account as funding source And user taps the submit button Then a pending toast should appear And the link approve transaction should be submitted as an EIP-7702 batch And the transaction should be confirmed on Monad without the Money Account holding any MON And a success toast should appear And the Money Account should be reported as delegated Scenario: user cannot link when Monad sponsorship is disabled Given the Monad gas-sponsorship feature flag is off When user opens the SpendingLimit screen Then the Money Account funding source CTA should not be visible And the regular EVM delegation flow should remain available Scenario: user cannot link when the Money Account is not 7702-upgraded Given the Money Account has not been EIP-7702-upgraded on Monad When user opens the SpendingLimit screen Then the Money Account funding source CTA should not be visible And the regular EVM delegation flow should remain available ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- Generated with the help of the pr-description AI skill --> <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **High Risk** > Changes card funding linkage, sponsored transaction submission, and TransactionPay account override—security- and payment-sensitive paths with new controller pre-flight and batch semantics. > > **Overview** > Fixes Money Account → Card linking when the money account has **no MON** on Monad by moving the background **USDC approve** onto the same **gas-sponsored EIP-7702 batch** path used for money-account deposit/withdraw, instead of a plain `addTransaction` from the money account. > > **`CardController.linkMoneyAccountCard`** now submits a single inner `tokenMethodApprove` via **`addTransactionBatch`** with **`isGasFeeSponsored: true`** and no confirmations modal. It **fails closed** before submit if Monad sponsorship is off or **`isAtomicBatchSupported`** says the account is not 7702-ready on the vault chain; it resolves the inner tx id from the batch for the existing confirmation waiter. > > **UI gating:** new **`useIsMoneyAccount7702Ready`** feeds **`useMoneyAccountCardLinkage`**, which requires sponsorship + `is7702Ready === true` for **`canLink`** (and thus Spending Limit’s Money Account CTA via **`canLinkMoneyAccount`**). Link toasts pick up design-system **`Icon`** accessories; **`canSubmitMoneyAccountDelegation`** is removed from the hook surface—background submit uses the same **`canSubmitDelegation`** gate. > > **MM Pay:** **`money-account-override`** treats **`MMM_CARD`** approves from the primary money account like money-account txs so **`accountOverride`** points at the selected EVM payer. Card-controller messenger gains batch/getState/isAtomicBatchSupported actions. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 54113f8. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…30702) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** In the MWP Flow (most easily triggered in the QR code flow specifically), the user was being show several success toasts after accepting the initial permission approval. This was due to the dapp probing for `eth_accounts` after successful connection to determine which account was currently selected. This was fixed by simply not showing a toast for these probing requests as they were not user initiated and do not require user approval ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Improve UX around when toasts are shown for requests made via MetaMask Connect ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/WAPI-1502 ## **Manual testing steps** 1. Connect to https://metamask.github.io/connect-monorepo/latest/ via QR code 2. Accept confirmation in mobile wallet 3. Mobile wallet should not show several success toasts in a row ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > UX-only change in SDK Connect response handling; RPC responses still reach dapps and disconnect clears in-flight request tracking. > > **Overview** > Stops **MetaMask Connect** from showing “return to app” and RPC error toasts when responses belong to background **`eth_accounts`** and **`eth_chainId`** probes, while still forwarding those JSON-RPC replies to the dapp. > > `Connection` now records each in-flight multiplexed request (`name` + id) when it hits the bridge, looks it up on the matching response, and skips host-app notifications only for those silent read methods; other methods keep the existing toast behavior. The map is cleared on disconnect. Tests cover success/error suppression, non-silent methods, and one-time suppression per tracked id. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 425577e. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** The VIP dashboard (`RewardsVipView`) and its tiers detail (`RewardsVipTiersView`) are now always rendered in dark theme, regardless of the user's app-theme setting (light / dark / system). **Why:** the VIP surface has a branded dark aesthetic — gold accents on dark backgrounds — and looks broken in light mode. Christian asked for the same treatment we apply to other dark-only branded surfaces. ## **Changelog** CHANGELOG entry: null ## **Screenshots/Recordings** ### **After** Avoid 'light' bg flicker from main theme (if it's light) by using transition: <img width="1920" height="1080" alt="vip-dark-enforce" src="https://github.com/user-attachments/assets/10ad8ba9-26c9-40ef-ac40-decc2d79694a" /> If not using transition, then we would have this flicker effect: <img width="1920" height="1080" alt="no-enforce" src="https://github.com/user-attachments/assets/7fd7e7be-f440-4869-93c2-fcdecc88bd15" /> ## **Pre-merge author checklist** - [x] I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards. - [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 format if applicable - [ ] I've applied the right labels on the PR <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Rewards UI and navigation presentation only; status bar restore is scoped to VIP screens with dedicated tests and no auth or data changes. > > **Overview** > VIP dashboard and tiers screens now **always render in dark theme**, independent of the user’s light/dark/system app setting. > > A new **`ForcedDarkThemeProvider`** overrides `ThemeContext` and the design-system Tailwind theme with `darkTheme`, sets the status bar to light-content while mounted, and **restores** bar style on unmount based on the user’s real theme (including OS follow). **`RewardsVipView`** and **`RewardsVipTiersView`** wrap their content in this provider. > > **`RewardsNavigator`** applies **`SlideFromRightIOS`** and a **dark default card background** on the VIP and VIP tiers stack screens to avoid a light flash during navigation when the rest of the app is light-themed. > > Unit tests cover the provider (theme, status bar, Android vs iOS) and extend twrnc mocks with `ThemeProvider` for the wrapper. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3bc652d. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## **Description** PR adds chartType property in other chart_interaction events. ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Adds chart_type property in chart_interaction events ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/ASSETS-3263 ## **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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Analytics-only property additions on token overview chart handlers; no auth, data, or trading logic changes. > > **Overview** > **Advanced token overview** `chart_interacted` events now include a **`chart_type`** property (`candlestick` or `line`) derived from the current Redux chart type, not only on explicit chart-type toggles. > > This applies to interactions forwarded from the chart (**`handleChartInteracted`**), **TradingView** clicks, and **timeframe** changes. Callback dependency arrays include **`chartType`** so payloads stay accurate when the user switches modes. > > Tests assert **`chart_type`** on **`timeframe_changed`** tracking. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 4cd55ec. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…action metadata (#30726) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** Adds the client version to the transaction metadata sent to Sentinel. <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Added the client version to the transaction metadata ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: the client version is sent to Sentinel Scenario: user submits a transaction to Sentinel with the client version When user submits a smart transaction or EIP-7702 gasless transaction Then the client version is included in the metadata sent to Sentinel ``` Test with these 3 types of transactions: - Swap with smart transactions enabled (on Arbitrum) - Send with smart transactions enabled (on Arbitrum) - Gasless send with smart transactions *disabled* (on Base) ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <img width="582" height="309" alt="Screenshot 2026-05-28 at 11 16 57" src="https://github.com/user-attachments/assets/752b9aac-f275-4e1d-b181-5979045bb6a5" /> <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Additive metadata only on submit/relay paths; no changes to signing, auth, or transaction execution logic. > > **Overview** > Adds **`clientVersion`** (from `react-native-device-info` **`getVersion()`**) to transaction metadata sent with smart transactions and EIP-7702 gasless relay submissions, alongside existing **`client`** and **`origin`** fields. > > A new helper **`getClientVersionForTransactionMetadata`** in `smartTransactions.ts` is wired through **`smart-publish-hook`** (batch, pre-signed, and fee-signed STX paths) and **`delegation-7702-publish`** relay metadata. **`@metamask/smart-transactions-controller`** is bumped from **^24.0.0** to **^24.2.0** to align with the enriched metadata shape. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 562d03d. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** Ledger hardware wallet users on Monad (and other chains / contracts without a matching Ledger plugin) were hitting a misleading "blind signing is not enabled" error when trying to complete gas-sponsored swaps, even though blind signing was enabled on the device. this PR will resolve the issue #28589 to use new @metamask/eth-ledger-keyring-bridge` <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Fixed a misleading "blind signing is not enabled" error preventing Ledger hardware wallet users from completing gas-sponsored swaps on Monad and other chains without a matching Ledger plugin. ## **Related issues** Fixes: #28589 ## **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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes only the Ledger hardware-wallet signing dependency path used for transactions/swaps; no local code review surface beyond the version bump. > > **Overview** > Bumps **`@metamask/eth-ledger-bridge-keyring`** from `^12.0.2` to **`^12.1.0`** (and refreshes **`yarn.lock`**) so Ledger signing uses the updated bridge stack—**`@metamask/keyring-sdk` ^2.1.1**, explicit **`@ledgerhq/hw-transport`**, and newer **`@ledgerhq/*`** transport/device/error packages. > > There are **no app source changes**; behavior comes from the upgraded package. The intent is to stop a false **“blind signing is not enabled”** failure when Ledger users complete **gas-sponsored swaps on Monad** (and similar chains without a matching Ledger plugin), as in #28589. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b7d5043. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> The `ci-js-deps` artifact (a compressed tarball of `node_modules` shared across CI shards) was causing a hard failure when individual jobs were re-run via GitHub's "Re-run failed jobs" button. **Root cause:** On a normal run, `prepare-ci-js-deps` uploads the artifact and `cleanup-ci-js-deps` deletes it once all consumers finish. When a job is re-run in isolation, `prepare-ci-js-deps` is not re-run (it already succeeded), but the artifact has already been deleted by the cleanup job. The re-running jobs see `prepare-ci-js-deps.result == 'success'` (still true from the original run), attempt the download, and hard-fail with `Artifact not found for name: ci-js-deps`. **Fix:** Add `continue-on-error: true` to the `Download CI JS deps artifact` step in `unit-tests`, `component-view-tests`, and `merge-unit-and-component-view-tests`. The `Extract CI JS deps` step is guarded by `steps.download-ci-js-deps.outcome == 'success'` so a missing artifact silently falls back to the existing `setup-ci-js-deps` action, which detects that `node_modules` is absent and performs a fresh `yarn install`. On normal (first-run) CI the artifact is always present and the behaviour is unchanged. ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** N/A ## **Screenshots/Recordings** ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- Generated with the help of the pr-description AI skill --> Made with [Cursor](https://cursor.com) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Workflow-only change for a temporary artifact path on non-Namespace runners; normal runs still use the artifact when present. > > **Overview** > Makes **non-Namespace** CI jobs tolerate a missing `ci-js-deps` artifact when you **re-run failed jobs** after `cleanup-ci-js-deps` has already deleted it. > > In `unit-tests`, `component-view-tests`, and `merge-unit-and-component-view-tests`, the **Download CI JS deps artifact** step gets an `id`, **`continue-on-error: true`**, and **Extract CI JS deps** only runs when `steps.download-ci-js-deps.outcome == 'success'`. If the download fails, extraction is skipped and **`setup-ci-js-deps`** installs deps when `node_modules` is absent—unchanged on a normal first run when the artifact exists. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit ce43c49. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.
In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
## **Description**
This PR updates the money activity list to show transfers into the money
account as well as deposits.
<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->
## **Changelog**
<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`
If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`
(This helps the Release Engineer do their job more quickly and
accurately)
-->
CHANGELOG entry: show transfers in the money account account activity
list
## **Related issues**
Fixes: MUSD-816
## **Manual testing steps**
```gherkin
Feature: money activity list
Scenario: user transfers from their primary account to their money account address
Given the the transfer is in MUSD and on Monad
When user checks the activity list
Then they see a single received item corresponding to the transfer
Scenario: user receives a transfer from an unknown account to their money account address
Given the the transfer is in MUSD and on Monad
When user checks the activity list
Then they see a single received item corresponding to the transfer
```
## **Screenshots/Recordings**
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
### **Before**
<img width="391" height="163" alt="image"
src="https://github.com/user-attachments/assets/1e60a855-63cc-419f-bd81-793d4456c80e"
/>
<img width="414" height="233" alt="image"
src="https://github.com/user-attachments/assets/d87e614c-9083-4e1b-afbc-d1d5a7d94a56"
/>
<!-- [screenshots/recordings] -->
### **After**
<img width="410" height="312" alt="image"
src="https://github.com/user-attachments/assets/65edf644-5d86-44f9-b817-2d96844e1553"
/>
<img width="405" height="314" alt="image"
src="https://github.com/user-attachments/assets/647ad1ea-bc1d-4efd-b675-a966ae5185b6"
/>
<img width="415" height="792" alt="image"
src="https://github.com/user-attachments/assets/f8a469b3-9f19-4bf9-b5a7-9f4f129fdc0e"
/>
<!-- [screenshots/recordings] -->
## **Pre-merge author checklist**
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [ ] 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**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [ ] 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.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Changes which transactions appear in Money activity and how
amounts/fiat are derived (calldata decoding, status gating); incorrect
filtering could hide or mislabel user funds, though scope is limited to
Monad mUSD flows with broad test coverage.
>
> **Overview**
> **Money account activity** now surfaces **inbound mUSD on Monad**—both
polled `incoming` transfers to the Money address and locally signed
`transfer` / `transferFrom` calls whose calldata recipient matches that
address. Activity is **scoped with `isMusdOnMoneyAccountChain`** so the
same mUSD contract on Mainnet/Linea/BSC does not appear in Money lists.
>
> **Classification and amounts** add `isMusdErc20Transfer`, extend
deposit predicates, and centralize metadata in
**`resolveMusdTransferMeta`** (including **BigInt calldata decoding**
and nested batch mUSD transfers). List rows use **“Received”** (not
“Deposited”) for external/incoming ERC-20 flows; **fiat for mUSD always
uses the 1:1 USD peg**, ignoring bad market prices.
>
> **Details UI**: received transaction types open a dedicated
**`MoneyReceivedDetails`** sheet (fiat hero, From, token received)
instead of the generic transaction details view.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
2843caa. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…alytics (#30246) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> This PR refactors Perps Pills added in this PR: #30025 Adds A/B analytics and transaction attribution for TMCU-725 (homepage Perps empty state: tile carousel vs Explore-style pills). Reuses existing events (Home Viewed, Perps UI Interaction, perps transaction pipeline)—no new event names. **Experiment config (abTestConfig)** - Flag: homeTMCU725AbtestHomepagePerpsPillsEmptyState — control = tile carousel, treatment = pills when empty - getHomepagePerpsPillsEmptyTransactionActiveAbTests() for downstream perps flows - HOMEPAGE_PERPS_PILLS_EMPTY_AB_TEST_HOME_VIEWED_MAPPING with injectWhenPropertiesMatch: { section_name: 'perps', is_empty: true } **Analytics plumbing** - enrichWithABTests: optional injectWhenPropertiesMatch for gated active_ab_tests injection - mergeActiveAbTestAssignmentLists: merge + de-dupe by assignment key - Registry registers the gated Home Viewed mapping only **Homepage Perps UI** - HomepagePerpsHomeSlot: thin A/B adapter — passes emptyStateContent="pills" + title override to PerpsSection in treatment; control unchanged - PerpsSection refactored into PerpsSectionMain / PerpsSectionTrendingOnly + extracted carousel/pills components and hooks - Removed standalone HomepagePerpsMoversSection — pills share the same section shell, header, nav, analytics, and refresh contract as tiles/positions - Pills feed lazy-loaded (skipInitialFetch when pills empty state not shown); section hidden when pills feed loads empty **Attribution wiring** - useHomepagePerpsPillsEmptyTransactionActiveAbTests(shouldShowPillsEmptyState) — only when pills empty state is configured and visible (not on tile carousel control) - PerpsSectionMain: merged trending + pills AB tests on navigation; handleTrendingMarketPress fires PERPS_UI_INTERACTION (WALLET_HOME + active_ab_tests) for tile/pill taps - transactionActiveAbTests threaded through perps funnel: homepage → PerpsHomeView → market list/sections/watchlist → market details → order (withPendingTransactionActiveAbTests) Note: Shared-wrapper active_ab_tests enrichment still requires a real LD assignment (resolveABTestAssignment → isActive). ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: Homepage Perps pills experiment — analytics Scenario: Home Viewed injects active_ab_tests on empty perps section Given LD returns a valid variant for homeTMCU725AbtestHomepagePerpsPillsEmptyState And the user has no open perps positions/orders (section_name perps, is_empty true) When Home Viewed fires Then active_ab_tests includes that flag key (Segment debugger) Scenario: Home Viewed does not inject when perps section has positions Given the user has at least one position or order in the homepage Perps section When Home Viewed fires Then the TMCU-725 Home Viewed mapping does not inject active_ab_tests Scenario: Control — tile tap does not carry pills transaction AB tests Given control (tile carousel) and no positions When the user taps a trending market tile Then Perps UI Interaction fires with WALLET_HOME And transactionActiveAbTests is not attached from the pills hook Scenario: Treatment — pill tap carries merged transaction AB tests Given treatment shows Perps movers pills When the user taps a pill and opens market details Then Perps UI Interaction includes active_ab_tests when assignment is active And navigation params include merged transactionActiveAbTests through to order flow ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches analytics enrichment, navigation param contracts, and perps order/deposit attribution paths across many screens; behavior is heavily tested but regressions could mis-attribute experiments or empty-state UI. > > **Overview** > This PR wires **TMCU-725** (homepage Perps empty state: tile carousel vs Explore-style pills) through UI, analytics, and transaction attribution without new event names. > > **Homepage:** `HomepagePerpsHomeSlot` now only toggles `PerpsSection` props (`emptyStateContent="pills"`, title override) in treatment; the separate `HomepagePerpsMoversSection` is removed so pills share the same section shell, nav, refresh, and analytics as tiles/positions. `PerpsSection` is split into `PerpsSectionMain` / `PerpsSectionTrendingOnly` with shared pill/carousel components moved under `UI/Trending` and `PerpsPillItem`. > > **Attribution:** `transactionActiveAbTests` is threaded from route params through Perps home, market list/sections, watchlist, market details, and order creation (`withPendingTransactionActiveAbTests`). Homepage hooks build pills-only and merged (trending + pills) assignments; control tile flows avoid pills attribution. > > **Analytics:** `enrichWithABTests` gains `injectWhenPropertiesMatch`; the perps-pills flag injects `active_ab_tests` on **Home Viewed** only when `section_name: perps` and `is_empty: true`. `mergeActiveAbTestAssignmentLists` de-dupes by flag key. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 09fccfc. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** Migrates 6 of the 10 Swap & Bridge E2E smoke tests to Component View Tests (CVT) as part of the [E2E → CVT audit](https://docs.google.com/spreadsheets/d/1Plm-ccNqYO-8tkBfZbHZxqiwQbdk4tGg). Added: - bridgeViewTestConstants.ts — USDT_DEST constant - handleUniversalLink.test.ts — 1 enanched unit test - BridgeView.view.test.tsx — 3 new CVT tests (deeplink x2, trending x1) - WalletActions.view.test.tsx — 2 new CVT tests (swap button visibility, navigation) Deleted: - swap-deeplink-smoke.spec.ts (3 tests) - swap-trending-tokens.spec.ts (1 test) - unified-ui-wallet-actions.spec.ts (2 tests) Untouched (cannot migrate): - bridge-action-smoke.spec.ts - gasless-swap.spec.ts - swap-action-smoke.spec.ts ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> 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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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 - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Test-only migration with minor testID refactors; no production swap/bridge or deeplink routing logic changes beyond assertions. > > **Overview** > This PR **moves six Swap/Bridge smoke scenarios from Detox E2E into Component View Tests**, deleting `swap-deeplink-smoke.spec.ts`, `swap-trending-tokens.spec.ts`, and `unified-ui-wallet-actions.spec.ts`. > > **BridgeView** gains CVT coverage for deeplink-driven token pairs (USDC/USDT via `USDT_DEST`), empty/invalid deeplink Redux state (no confirm), and trending zero-state (filters, price bottom sheet, section hidden after `setSourceAmount`), with trending API mocks from `tests/component-view/api-mocking/trending`. > > **WalletActions** adds a route-probe test that the swap control navigates to `Routes.BRIDGE.ROOT`. > > **Test IDs** are centralized: `getTrendingTokenRowItemTestId`, `TrendingTokensBottomSheetTestIds`, and wiring in `TrendingTokenRowItem` / `TrendingTokenPriceChangeBottomSheet`. > > **Deeplink unit test** for universal `SWAP` links now expects `handleSwapUrl({ swapPath: query string })` instead of a path-segment handler. > > Production behavior is unchanged aside from stable `testID` helpers; remaining smoke specs (`bridge-action`, `gasless`, `swap-action`) stay E2E. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 02fda08. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…30731) ## **Description** Adds a dismissible "Perps trading competition" promotional banner to the perps home screen. The banner is positioned between the balance actions (Add funds / Withdraw) and the positions section, matching the Figma design spec. **Motivation:** Drive user engagement with the perps trading competition by surfacing a discoverable CTA on the perps home screen, alongside the existing carousel banner on wallet home and details in the Rewards tab. **Solution:** - New `PerpsCompetitionBanner` component with trophy icon, title, description, close (X) button, and tap-to-navigate behavior - Tapping the banner navigates to the Rewards tab (`Routes.REWARDS_VIEW`) - Dismissing via the X button persists the dismissed state to `StorageWrapper` so the banner is not shown again - Visibility is gated by a new LaunchDarkly feature flag `perps-competition-banner-enabled` (disabled by default) - Full unit test coverage for the banner component (7 tests) and the feature flag selector (8 tests) ## **Changelog** CHANGELOG entry: Added a promotional banner for the perps trading competition on the perps home screen ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TAT-3206 ## **Manual testing steps** ```gherkin Feature: Perps competition banner Scenario: Banner is displayed when feature flag is enabled Given the feature flag "perps-competition-banner-enabled" is enabled And the user has not previously dismissed the banner When user navigates to the Perps home screen Then a banner with title "Perps trading competition" is displayed below the balance actions Scenario: Banner navigates to Rewards tab on tap Given the competition banner is visible on the Perps home screen When user taps the banner body Then the app navigates to the Rewards tab Scenario: Banner is permanently dismissed Given the competition banner is visible on the Perps home screen When user taps the close (X) button on the banner Then the banner disappears And the banner does not reappear on subsequent visits to the Perps home screen Scenario: Banner is hidden when feature flag is disabled Given the feature flag "perps-competition-banner-enabled" is disabled When user navigates to the Perps home screen Then no competition banner is displayed ``` ## **Screenshots/Recordings** ### **Before** N/A - new feature behind a feature flag (disabled by default) ### **After** <img width="1320" height="2868" alt="simulator_screenshot_858AE3BA-CCC3-4997-A550-DAED44D90308" src="https://github.com/user-attachments/assets/8b1253ac-1c32-420d-bba1-55633f87974f" /> ## **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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Promotional UI behind a remote feature flag (off by default); dismiss state and Rewards navigation only—no auth, payments, or trading logic changes. > > **Overview** > Adds a **dismissible competition promotion banner** on the Perps home screen, placed between balance actions and the positions section. > > The new `PerpsCompetitionBanner` is shown only when the remote LaunchDarkly flag `perps-competition-banner-enabled` is on and the user has not dismissed it. Dismissal is stored via `PERPS_COMPETITION_BANNER_DISMISSED` in `StorageWrapper` (best-effort; still hides for the session if persistence fails). Tapping the banner sets a rewards pending deeplink (`campaign: 'perps-comp'`) and navigates to **Rewards**. Close and engage actions emit `PERPS_UI_INTERACTION` analytics with `competition_banner_close` / `competition_banner_engage`. > > Supporting changes: `selectPerpsCompetitionBannerEnabledFlag`, feature-flag registry entry, English copy, Perps home test ID, mocks, and docs/metrics reference updates. Unit tests cover the component and selector. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit bb535c7. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…USD-845) (#30741) ## **Description** Covers two related tickets: - **[MUSD-849](https://consensyssoftware.atlassian.net/browse/MUSD-849)** — "Add your $X.XX mUSD" in the Money "Add money" bottom sheet previously closed the modal with no further action. It now opens the same moneyAccountDeposit confirmation screen as Convert crypto, with **mUSD pre-selected** as the "Pay with" token on the chain holding the user's largest mUSD balance (Mainnet fallback). - **[MUSD-845](https://consensyssoftware.atlassian.net/browse/MUSD-845)** — Deposit toast copy now matches the Figma per intent: - **Convert crypto** → "Converting crypto" → "Conversion complete" / "Conversion failed" + "Unable to convert. Try again." - **Add mUSD** → "Adding funds" → "Funds added" / "Failed to add funds" + "Unable to add funds. Try again." Intent is registered on the deposit batch synchronously in `initiateDeposit()` (the batchId is pre-generated client-side via the same `uuid → bytesToHex` recipe the transaction-controller uses internally), so the toast subscriber can resolve it even when a controller status event fires synchronously on an immediate-failure path. Entries are cleared on every terminal status (success / failed / dropped / cancelled / rejected) and on initiation throw. ## **Changelog** CHANGELOG entry: Fixed the "Add mUSD" option in the Money account "Add money" sheet so it opens the deposit flow with mUSD pre-selected, and corrected the in-progress / success / failed toast copy for both the Convert and Add flows. ## **Related issues** Fixes: [MUSD-849](https://consensyssoftware.atlassian.net/browse/MUSD-849), [MUSD-845](https://consensyssoftware.atlassian.net/browse/MUSD-845) ## **Manual testing steps** ```gherkin Feature: Add mUSD to Money account from bottom sheet Scenario: User with mUSD balance taps "Add your $X mUSD" Given the user has mUSD on Mainnet and/or Linea And the user is on the Money account home screen When the user taps the Add button Then the "Add money" bottom sheet appears And it shows "Add your $X.XX mUSD" option When the user taps "Add your $X.XX mUSD" Then the deposit confirmation screen opens with header "Add funds" And the "Pay with" row is pre-selected to mUSD on the chain with the largest balance Feature: Deposit toast copy reflects entry-point intent Scenario: Convert crypto lifecycle Given the user submitted a deposit via Convert crypto When the transaction is approved Then the in-progress toast title shows "Converting crypto" When the transaction is confirmed Then the success toast title shows "Conversion complete" When the transaction fails Then the failed toast shows "Conversion failed" / "Unable to convert. Try again." Scenario: Add mUSD lifecycle Given the user submitted a deposit via Add mUSD When the transaction is approved Then the in-progress toast title shows "Adding funds" When the transaction is confirmed Then the success toast title shows "Funds added" When the transaction fails Then the failed toast shows "Failed to add funds" / "Unable to add funds. Try again." ``` ## **Screenshots/Recordings** ### **Before** Tapping "Add your $X.XX mUSD" dismissed the bottom sheet with no further action. Deposit toasts used the generic "Transaction in progress / complete / failed" copy. ### **After** Tapping "Add your $X.XX mUSD" opens the deposit confirmation with mUSD pre-selected as "Pay with". Toast copy reflects the user's entry-point intent for the full lifecycle. https://github.com/user-attachments/assets/92f31c24-56ba-492a-aaa5-429a6918e0c1 ## **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 - [ ] I've tested with a power user scenario - [ ] I've instrumented key operations with Sentry traces for production performance metrics 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. [MUSD-849]: https://consensyssoftware.atlassian.net/browse/MUSD-849?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [MUSD-845]: https://consensyssoftware.atlassian.net/browse/MUSD-845?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [MUSD-849]: https://consensyssoftware.atlassian.net/browse/MUSD-849?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes money deposit initiation, confirmation pre-selection, and transaction toast behavior; risk is moderated by tests and scoped to deposit UX, but incorrect chain/token or intent handling could mislead users during fund movement. > > **Overview** > The **Add your $X mUSD** row in the Money **Add money** sheet now starts the same money-account deposit flow as **Convert crypto**, instead of only closing the sheet. It passes **`intent: 'addMusd'`** and a **`preferredPaymentToken`** for mUSD on the chain with the largest per-chain balance (default chain when balances are missing). > > **`initiateDeposit`** accepts optional intent and preferred payment token, pre-generates a **`batchId`**, registers intent in memory before submitting the batch, forwards the token into confirmation navigation, and clears intent on batch failure or terminal transaction status. The deposit confirmation screen passes that token into **`CustomAmountInfo`** as the pre-selected **Pay with** asset. > > Deposit **toasts** (in progress, success, failed) now use separate copy for **convert** vs **add mUSD**, resolved from batch intent in **`useMoneyTransactionStatus`**, with new locale strings. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3317cbe. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…30619) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** Remove Explore page V1 FF and code <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Remove Explore page V1 FF and code ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/ASSETS-3267 & https://consensyssoftware.atlassian.net/browse/ASSETS-3137 ## **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** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Large Explore surface-area change (navigation, DeFi empty state, flag removal) affects all users on the Explore tab; risk is mitigated by expanded component-view and E2E coverage but is still a major UX path change. > > **Overview** > **Explore always uses the tabbed V2 layout** — the `explorePageV2Enabled` remote flag, its selector/tests, and the legacy **Explore Page V1** stack (`ExplorePageV1`, `QuickActions`) are removed. `TrendingView` no longer branches on the flag; it always renders `TabsList` with `testID="explore-tabs"`. > > **Navigation and empty states** — `DefiEmptyState` always opens Explore with `initialTab: SITES` (no V1 two-step `SitesFullView` path). Tab labels expose `${testID}-label` on `Tab` for Detox. > > **Test IDs and automation** — Per-tab scroll `testID`s (`explore-now-scroll-view`, crypto/rwas/dapps, etc.) replace the old single feed scroll ID; component-view and smoke tests navigate tabs (Crypto for trending tokens, route `initialTab` for Sites). Detox `TrendingView` page object drops Quick Actions and scrolls the active tab via `SECTION_TAB_CONFIG` + tab label taps. > > **Mocks/registry** — Component-view trending mocks add RWA search, explore sites, and favicon nocks; feature-flag registry drops `explorePageV2Enabled` and `exploreSectionsOrder`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit fefdaca. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** This PR addresses two previous comments on the local playwright runs implementation. 1. Updates documentation to explain how a `UDID` can be specified in order to distinguish simulators with the same name 2. Updates the flow for dismissing the dev screens in order to work with playwright <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 3. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MMQA-1881 ## **Manual testing steps** N/A ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Changes are limited to local E2E test flows, fixture bootstrap timing, docs, and unit tests with no production app or security impact. > > **Overview** > **Local Playwright E2E** now dismisses React Native dev UI in two phases instead of one monolithic flow: the **Metro development server picker** runs as early as possible (including right after `launchApp` and before waiting on fixture `/state.json`), and the **developer menu** runs afterward once JS is up. > > The Playwright dismissal logic no longer taps **Fast refresh** to close the menu; it uses **xmark** / **Close**, optional Android **back**, and still handles **Continue** onboarding. **`withFixtures`** wires the split helpers for Appium and avoids double-dismiss of the server picker. Docs add **iOS `device.udid`** guidance; the sample **ios** Playwright project exposes an empty **`udid`** field. **Jest unit tests** cover the new Playwright helpers. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 6c739fa. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** Updates the onboarding interest questionnaire (“What do you want to do with MetaMask?”) to match the TMCU-792 design refresh: - Options are shown in a **two-column grid** with consistent 8px gutters (50% column wrappers + padding). - Each card uses a **top-right selection indicator** and keeps the **existing option illustrations** in `app/images/`. - Copy updates in `en.json`: “Buy and sell crypto tokens” and “Trade perpetuals” (`advanced_trades` id unchanged for analytics). - **Continue** still calls `onComplete()` directly (crypto experience screen is **TMCU-833**, separate PR). ## **Changelog** CHANGELOG entry: Updated the onboarding interest questionnaire layout to a two-column grid with refreshed option labels. ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-792 ## **Manual testing steps** ```gherkin Feature: Onboarding interest questionnaire grid (TMCU-792) Scenario: user completes interest questionnaire after opting in to metrics Given the user is on the OptinMetrics screen during onboarding And the interest questionnaire eligibility check returns true When the user opts in to basic usage data and taps Continue Then the interest questionnaire is shown with six options in a two-column grid And the user can select multiple options And tapping Continue submits analytics and proceeds with onboarding (onComplete) Scenario: user can skip selecting interests Given the user is on the interest questionnaire screen When the user taps Continue without selecting any option Then onboarding continues with skipped interest analytics ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** | Light Mode | Dark Mode | |------------|-----------| | <img width="300" alt="questionnaire_light" src="https://github.com/user-attachments/assets/dafd9077-f68d-4ca8-9bed-5362947608ad" /> | <img width="300" alt="questionnaire_dark" src="https://github.com/user-attachments/assets/16629619-d53d-4fec-a277-b128429a044b" /> | ### **After** | Light Mode | Dark Mode | |------------|-----------| | <img width="300" alt="questionnaire_light" src="https://github.com/user-attachments/assets/34981465-f9d9-4651-bf89-0adbdc5880c0" /> | <img width="300" alt="questionnaire_dark" src="https://github.com/user-attachments/assets/e43e09bb-3813-49a3-9582-cc7ea2b68d68" /> | ## **Pre-merge author checklist** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [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** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Onboarding UI and copy only; selection analytics and Continue flow are unchanged aside from layout. > > **Overview** > Refreshes the onboarding **interest questionnaire** to a **two-column card grid** (8px gutters) instead of full-width list rows. Each option is a fixed-height card with the illustration and label repositioned and a new **top-right selection indicator** (`InterestSelectionIndicator`). > > English copy updates two labels: *Buy and sell crypto tokens* and *Trade perpetuals* (option ids unchanged for analytics). **Continue** still only invokes `onComplete()`—tests now assert it does not call navigation. > > Adds unit tests for the indicator and extends questionnaire tests for the grid layout, i18n strings, and continue behavior. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit ecf523e. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 : )