[pull] main from MetaMask:main#516
Merged
Merged
Conversation
…5887) ## **Description** When users enable privacy mode to hide their balances across the wallet (the setting that replaces the account balance with bullet dots at the top), the Predict feature was not respecting this setting — all monetary values were still displayed in plain text. This PR wraps all sensitive monetary values in the existing `SensitiveText` component (the same component used by Tokens, DeFi, and Card tabs), so they show bullet dots (`•••••••••`) when privacy mode is enabled. **Approach:** - Follows the established hybrid pattern from DeFi/Tokens tabs: standalone/entry-point components read `selectPrivacyMode` directly via `useSelector`; list items receive `privacyMode` as a prop from parent to avoid N redundant selector subscriptions - Uses `SensitiveText` from `component-library` with appropriate length variants (Short/Medium/Long) based on typical value widths ## **Changelog** CHANGELOG entry: Fixed Predictions tab not hiding monetary values when privacy mode is enabled ## **Related issues** Fixes: Privacy mode not respected in Predict feature ## **Manual testing steps** ```gherkin Feature: Privacy mode in Predictions tab Scenario: user enables privacy mode and views Predictions tab Given the user has active predictions and a balance in the Predict tab When user taps the balance area at the top of the wallet to enable privacy mode (balances turn to dots) Then the Predictions tab displays bullet dots instead of: - Available balance amount - Unrealized P&L (amount and percentage) - Claim button amount - Position current values - Position P&L percentages - Position info text (invested amount and shares) - Won/Lost amounts on resolved positions Scenario: user disables privacy mode and views Predictions tab Given the user has privacy mode enabled When user taps the balance area at the top of the wallet to disable privacy mode Then all monetary values in the Predictions tab are displayed normally Scenario: user views activity detail with privacy mode enabled Given the user has privacy mode enabled When user navigates to a Predict activity detail screen Then monetary rows (predicted amount, shares, price per share, net P&L) show bullet dots And non-monetary rows (date, market, outcome) display normally ``` ## **Screenshots/Recordings** ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> https://www.loom.com/share/aa4be270b9a84b02afb79b758a5400ee ## **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. ## **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** > UI-only change that conditionally masks displayed values based on an existing preference; no transaction, auth, or data-flow logic changes beyond additional selector reads and prop plumbing. > > **Overview** > Predict now respects wallet *privacy mode* by hiding monetary values across the feature using `SensitiveText`. > > Updates cover the activity detail screen (amount display and monetary rows), the homepage balance card and positions header (available balance, unrealized P&L, claim amount), and position list items/detail/resolved cards (position info, current value, P&L%, won/lost amounts). Tests are extended to wire `PreferencesController.privacyMode` into state/mocks and assert bullets replace sensitive values when enabled, including passing `privacyMode` as a prop to list items to avoid redundant selector subscriptions. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 688513b. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=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**
- Adds `MegaETH` as selectable network for Bridge/Swap.
- Adds Bridge/Swap feature for `MegaETH` (behind feature flags).
<!--
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: Adds Bridge and Swap feature to `MegaETH`
## **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**
<img width="301" height="619" alt="Screenshot from 2026-02-10 16-49-35"
src="https://github.com/user-attachments/assets/1ff9044a-d30d-4396-9005-08ba1d5c990d"
/>
<img width="301" height="619" alt="Screenshot from 2026-02-10 16-49-51"
src="https://github.com/user-attachments/assets/31035a60-b564-4f7e-b033-76a47a417fb5"
/>
<img width="301" height="619" alt="Screenshot from 2026-02-10 17-00-51"
src="https://github.com/user-attachments/assets/12d1104f-3187-402b-ad2d-cfbf07433356"
/>
<img width="301" height="619" alt="Screenshot from 2026-02-10 17-00-55"
src="https://github.com/user-attachments/assets/e9f31646-eff5-4d4f-9209-873e1d1aaa04"
/>
<img width="301" height="619" alt="Screenshot from 2026-02-10 17-01-12"
src="https://github.com/user-attachments/assets/38ac0847-25ba-45b1-864c-90b2c3eb9fa8"
/>
<!-- [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
- [ ] 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.
## **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**
> Primarily constant/config updates, but they affect which networks and
contract addresses the app targets for bridging/swapping; incorrect
chain IDs or addresses could misroute transactions or break swaps on
MegaETH.
>
> **Overview**
> Adds **MegaETH mainnet** as a supported chain for Bridge/Swaps by
including it in chain/name mappings
(`NETWORK_TO_SHORT_NETWORK_NAME_MAP`, `NETWORK_TO_NAME_MAP`) and
`swapsSupportedChainIds`.
>
> Configures MegaETH-specific defaults: sets the default destination
token to `USDT0`, treats `USDT0` as a stablecoin for the
reduced-slippage path, and registers MegaETH `Bridge` and `Swaps`
first‑party contract addresses.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
ad4d89a. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
) ## **Description** Fixes navigation and token buyability issues in the unified buy V2 flow. **Problem 1 — Navigation error from asset details page:** When clicking the Buy button on the asset details page with unified buy V2 enabled, a navigation error occurred because `createBuildQuoteNavDetails` tried to navigate directly to the deeply nested `RampAmountInput` screen. React Navigation requires navigating through the parent route structure. **Problem 2 — Navigation from TokenSelection to input screen:** When selecting a token from the TokenSelection screen, navigation to AMOUNT_INPUT failed because it used `goToBuy` (which targets the outer route) instead of navigating directly within the same stack. **Problem 3 — Buy button shown for unsupported tokens / errors on tap:** The buyability check (`useTokenBuyability`) only used the legacy V1 token cache. When V2 was enabled, `setSelectedToken` on the RampsController would throw "Token not found" errors due to: - The ramps API returns assetIds in **lowercase**, but `parseRampIntent` produces **checksummed** addresses - Native tokens: API uses `slip44:{coinType}` but `parseRampIntent` uses `slip44:.` placeholder - The controller's `setSelectedToken` uses exact match (`===`) **Solution:** 1. Updated `createBuildQuoteNavDetails` to navigate through the proper nested route structure 2. `TokenSelection` navigates directly to `AMOUNT_INPUT` within the same stack for V2, calling `setSelectedToken` before navigating 3. `useTokenBuyability` moved to `Ramp/hooks/` (ramps domain) and updated with a unified `findMatchingRampToken` function that handles both native (chainId + slip44 namespace) and ERC20 (case-insensitive assetId) matching for V1 and V2 4. `useRampNavigation.goToBuy` resolves assetId to the controller's canonical format before calling `setSelectedToken` 5. Legacy `AssetOverview` now uses the shared `useTokenBuyability` hook instead of inline logic **Not changed:** The smart Buy button in `TokenDetails` sticky bar (`handleBuyPress`) is untouched — it routes to swaps or ramps based on user context and should not be gated by ramp buyability. ## **Changelog** CHANGELOG entry: Fixed navigation error and token buyability checks when purchasing crypto with cash using unified buy V2 ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TRAM-3253 ## **Manual testing steps** ```gherkin Feature: Unified Buy V2 Navigation and Buyability Scenario: User navigates to buy flow from asset details page Given user is on asset details page with unified buy V2 feature flag enabled When user taps the cash "Buy" button on a supported token Then user should navigate to RampAmountInput screen without errors And the selected asset should be pre-filled Scenario: User selects token from token selection screen Given user is on token selection screen in unified buy V2 flow When user selects a token from the list Then user should navigate to RampAmountInput screen And the selected token should be displayed Scenario: Cash buy button hidden for unsupported tokens Given user is on asset details page for a token not supported by ramps Then the cash Buy button should not be displayed But the smart Buy/Sell sticky bar buttons should still be visible Scenario: Smart Buy button is unaffected Given user is on token details page (V2 buttons enabled) Then the sticky bar Buy button should always be visible And it should route to swaps if user has source tokens And it should route to ramps if user has no source tokens ``` ## **Screenshots/Recordings** <div> <a href="https://www.loom.com/share/d21607d8e7ab4717ba2935a5ee83521a"> <p>Unified Buy Phase 2 Navigation Bug Fix - Watch Video</p> </a> <a href="https://www.loom.com/share/d21607d8e7ab4717ba2935a5ee83521a"> <img style="max-width:300px;" src="https://cdn.loom.com/sessions/thumbnails/d21607d8e7ab4717ba2935a5ee83521a-23fb39f536f0385f-full-play.gif#t=0.1"> </a> </div> ### **Before** <!-- Navigation error when clicking buy button; buy button shown for unsupported tokens --> ### **After** <!-- Navigation works correctly; cash buy button only shown for supported tokens; smart button unaffected --> ## **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. ## **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] > **Medium Risk** > Touches ramp navigation and token selection logic used in the buy flow; misrouting or incorrect assetId canonicalization could still break V2 purchase entry for some tokens/chains, though changes are localized and covered by added tests. > > **Overview** > Fixes unified buy V2 navigation by routing into `RampAmountInput` via the correct parent stack (updated `createBuildQuoteNavDetails`) and by having `TokenSelection` set the controller-selected token and navigate directly within the same stack instead of closing the modal and calling `goToBuy`. > > Unifies and hardens ramp token “buyability” checks: introduces `Ramp/hooks/useTokenBuyability` (used by `AssetOverview` and token details), switching between legacy token cache (V1) and controller token list (V2) with case-insensitive/native-token matching; `useRampNavigation.goToBuy` now canonicalizes `assetId` before calling `setSelectedToken` and tolerates missing tokens while loading. Adds/updates tests to cover buy button visibility and V2 navigation behavior, and moves the previous TokenDetails-scoped buyability hook/tests to the ramp domain. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 58f3085. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
## **Description** Implements a new Accounts Menu screen as an intermediary page between the hamburger menu and settings, improving navigation organization for users. This is the first iteration and will eventually look like this <img width="2000" alt="image" src="https://github.com/user-attachments/assets/cd8add7a-4b45-44c6-8b69-661116803646" /> **What is the reason for the change?** The settings section is difficult to navigate. This new page organizes settings into logical sections (Settings, Manage, Resources) to improve UX while we plan a full redesign. **What is the improvement/solution?** Created a new AccountsMenu screen with: - Settings navigation - Resources section (About MetaMask, Request Feature, Support) - Log out functionality - Analytics tracking for all interactions - Performance optimizations (memoized components, Tailwind styling) - Comprehensive test coverage (24 tests) **NOTE:** There will be a follow up PR to address regression related E2E tests. I am working on them at this moment ## **Changelog** CHANGELOG entry: Added new Accounts Menu screen to organize settings navigation with Settings, Manage, and Resources sections ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-397 ## **Manual testing steps** ```gherkin Feature: Accounts Menu Navigation Scenario: user navigates from hamburger menu to settings Given user is on the main app screen When user taps the hamburger menu And user sees the new Accounts Menu screen Then user should see Settings, Manage, Resources sections Scenario: user accesses settings from Accounts Menu Given user is on the Accounts Menu screen When user taps "Settings" Then user should navigate to the Settings screen And analytics should track SETTINGS_VIEWED event Scenario: user logs out with confirmation Given user is on the Accounts Menu screen When user taps "Log Out" Then user should see a confirmation alert When user confirms logout Then app should lock And analytics should track NAVIGATION_TAPS_LOGOUT event Scenario: user cancels logout Given user is on the Accounts Menu screen When user taps "Log Out" And user taps "Cancel" on confirmation alert Then alert should dismiss And analytics should NOT track logout event ``` ## **Screenshots/Recordings** ### First Iteration <img width="350" alt="image" src="https://github.com/user-attachments/assets/1e67ed03-543e-4da6-a4ca-cea476152b59" /> ### Light https://github.com/user-attachments/assets/f79fbc12-4ce2-42db-978f-259bd6cb73c2 ### Dark https://github.com/user-attachments/assets/384a46ab-5436-4e3c-9482-82271a7efcd4 ### **Before** `~` ### **After** `~` ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **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 the app’s primary navigation path into settings and relocates logout/support links, which could cause regressions in deep links/back navigation and E2E flows despite added unit/snapshot coverage. > > **Overview** > Introduces a new `AccountsMenu` screen that sits between the hamburger/menu entry and the existing settings pages, providing *Manage* and *Resources* sections (Settings, Contacts, optional MetaMask Card, optional Permissions, About, Request Feature, Support, and Log out) with associated analytics events and a logout confirmation flow. > > Updates navigation so the Settings tab and `SettingsFlow` now land on `Routes.ACCOUNTS_MENU_VIEW` first, adds the new route constants, and removes the SDK connections section from `SecuritySettings` plus several resource/contact/logout rows from the `Settings` screen; tests, snapshots, and Detox page objects/smoke tests are updated accordingly. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit cc6905d. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Amanda Yeoh <147617420+amandaye0h@users.noreply.github.com>
<!-- 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** Bumps ramps-controller to 8.0.0. Needed for unified buy PRs: - #25848 - #25860 <!-- 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: 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** - [ ] 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. ## **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** > Dependency-only version bump with no direct code changes in this repo; risk is limited to behavioral changes introduced by `@metamask/ramps-controller@8.0.0` at runtime. > > **Overview** > Bumps the `@metamask/ramps-controller` dependency to `^8.0.0`, updating the resolved version from `7.1.0` to `8.0.0`. > > Updates `yarn.lock` to reflect the new package resolution and checksum; no other functional code changes are included. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit ef93d33. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…datedVersionGatedFeatureFlag util (#25983) <!-- 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** This PR adds progressive rollout flag compatibility to `validatedVersionGatedFeatureFlag` util. Without this, `validatedVersionGatedFeatureFlag` incorrectly returns `undefined`. <!-- 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: updated validatedVersionGatedFeatureFlag to support progressive rollout flag format ## **Related issues** Fixes: [MUSD-308: Fix progressive rollout flags compatibility with "validatedVersionGatedFeatureFlag" util](https://consensyssoftware.atlassian.net/browse/MUSD-308) ## **Manual testing steps** ```gherkin Feature: Progressive feature flag support for validatedVersionGatedFeatureFlag Scenario: User correctly sees feature Given user is part of selectedGroup threshold for flag to be enabled When user opens app Then user sees mUSD conversion feature ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> N/A ### **After** <!-- [screenshots/recordings] --> N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **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** > Small, well-tested normalization change limited to feature-flag parsing; main risk is subtle behavior differences if upstream flag payloads have unexpected shapes. > > **Overview** > `validatedVersionGatedFeatureFlag` now supports progressive rollout remote flags that wrap the actual `{ enabled, minimumVersion }` under a `value` property, by unwrapping/normalizing the input before evaluating version gating. > > Tests were expanded to cover wrapped enable/disable cases, wrapped version-fail cases, and malformed/missing wrapped `value` behavior (still returning `undefined` to trigger caller fallback), while preserving the existing override behavior. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 838de2b. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…ser preference (#25677) <!-- 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** <!-- 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? --> These changes consolidates the logic associated with deriving authentication capabilities by leveraging Expo's LocalAuthentication library + introducing a single state for user preference control. This PR sets up the scaffolding along with unit tests. There will be a follow up PR for replacing existing functionality with this. Reference RAPID - https://docs.google.com/document/d/1t3R4n2gA8I_OkrVtXrqVgk1AuMficHvtEYQJjlm8e5E/edit?pli=1&tab=t.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: ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MCWP-306 ## **Manual testing steps** These changes only includes the scaffolding for now. Unit test coverage is provided. ## **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. ## **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** > Touches authentication capability derivation and introduces a new persisted security preference, which could affect how the app chooses keychain storage types if integrated incorrectly; changes are largely additive and covered by tests. > > **Overview** > Adds `expo-local-authentication` and introduces a new `Authentication.getAuthCapabilities(osAuthEnabled, allowLoginWithRememberMe)` helper that queries device enrollment/security level in parallel, derives the effective `AUTHENTICATION_TYPE` (priority: remember-me → biometrics → passcode → password), and returns UI metadata like `authToggleLabel` and whether the toggle should be shown. > > Introduces a new security preference `osAuthEnabled` (Redux action/reducer/state, defaulting to enabled) and a new `useAuthCapabilities` hook to fetch/refresh capabilities and toggle that preference. Includes comprehensive unit tests, plus a Jest mock for `expo-local-authentication`, and updates iOS pods/JS deps to include the new Expo module. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 20db9de. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** Refactor predict transaction toast notifications to follow proper controller architecture. Toast notifications now fire app-wide regardless of which screen the user is on. This is the third iteration addressing the same core issue. The previous two PRs were closed due to architectural feedback: - **PR #25390** — Closed because a `PredictProvider` context was placed too high in the React tree at the Root level. The platform team didn't want feature-specific context at the app root. - **PR #25678** — Closed because toast/navigation logic was placed directly inside `PredictController`. The architecture team noted that controllers must not be UI-aware. This PR takes a hybrid approach that satisfies both concerns: ### Architecture ``` ┌──────────────────────────┐ │ PredictController │ Business layer — emits events, zero UI knowledge │ (messenger events) │ └──────────┬───────────────┘ │ PredictController:transactionStatusChanged ▼ ┌──────────────────────────┐ │ ControllerEventToastBridge│ Platform layer — generic, reusable by any team │ (App.tsx) │ └──────────┬───────────────┘ │ showToast() ▼ ┌──────────────────────────┐ │ usePredictToastRegistrations │ UI layer — Predict-specific toast content │ (event → toast mapping) │ └──────────────────────────┘ ``` **Key changes:** 1. **PredictController** subscribes to `TransactionController:transactionStatusUpdated` internally, filters for predict-type transactions (deposit/claim/withdraw), and emits a clean `PredictController:transactionStatusChanged` messenger event — with zero UI imports. 2. **ControllerEventToastBridge** is a new platform-owned generic component mounted in `App.tsx`. It accepts a registry of event→toast handler mappings and subscribes to controller events via `Engine.controllerMessenger`. Any team (Earn, Perps, etc.) can register handlers in the future. 3. **usePredictToastRegistrations** is a Predict-specific hook that maps the controller event to toast configs (pending spinners, success toasts, error toasts with retry). 4. **Cleanup**: Deleted 8 legacy files (`usePredictDepositToasts`, `usePredictClaimToasts`, `usePredictWithdrawToasts`, `usePredictToasts` + their tests). Net reduction of ~500 lines. ## **Changelog** CHANGELOG entry: Fixed predict transaction toast notifications not appearing when navigating away from the Predict tab ## **Related issues** Fixes: [PRED-579](https://consensyssoftware.atlassian.net/browse/PRED-579) **Previous PRs (for context):** - #25390 — First attempt (context provider at root — rejected by platform team) - #25678 — Second attempt (UI logic in controller — rejected by architecture team) ## **Manual testing steps** ```gherkin Feature: App-wide predict transaction toast notifications Scenario: user deposits funds and sees pending toast Given the user is on the Predict tab When user initiates a deposit Then a pending toast with spinner appears showing "Adding funds..." Scenario: user sees success toast after deposit confirms Given a deposit transaction is pending When the transaction confirms on-chain Then a success toast appears showing the deposited amount Scenario: user sees toast while on a different screen Given the user initiates a deposit from the Predict tab When user navigates away to the Wallet tab And the transaction confirms on-chain Then the success toast still appears on the Wallet tab Scenario: user sees error toast with retry on failed transaction Given a deposit/claim/withdraw transaction is pending When the transaction fails Then an error toast appears with a retry button Scenario: user rejects a transaction Given the user is prompted to confirm a transaction When user rejects the transaction Then no toast is shown and pending state is silently cleared Scenario: user claims winnings and sees toast Given the user has claimable positions When user initiates a claim Then a pending toast appears showing the claim amount And on confirmation a success toast appears Scenario: user withdraws and sees toast Given the user has a balance to withdraw When user initiates a withdrawal Then a pending toast appears And on confirmation a success toast appears with the withdrawn amount ``` ## **Screenshots/Recordings** ### **Before** Toast notifications only fired when the user was on the Predict tab. Navigating away caused toasts to be missed. ### **After** https://www.loom.com/share/e0b58f8a51974982bf558e3ac3b12a03 ## **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. ## **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] > **Medium Risk** > Changes transaction-status event handling and related state cleanups/refresh side effects for Predict, which could impact when pending deposits/claims/withdraws are cleared or when balances refresh. UI toast behavior is also re-routed through a new app-root subscription mechanism that could affect toast delivery if event registration/subscription breaks. > > **Overview** > Predict transaction toasts are refactored from screen-scoped hooks into an **app-wide event-driven flow**: `PredictController` now listens to `TransactionController:transactionStatusUpdated`, filters deposit/claim/withdraw transactions, applies non-UI side effects (e.g., clearing pending deposits/withdraw, confirming claims, refreshing balance/positions), and publishes a new `PredictController:transactionStatusChanged` event with a simplified payload. > > A new generic `ControllerEventToastBridge` is mounted in `App.tsx` to subscribe to controller messenger events and invoke registered handlers with `showToast`; Predict registers a single handler via the new `usePredictToastRegistrations` hook to render pending/success/error toasts (including navigation to transaction details and conditional retry based on sender address). > > Removes the legacy Predict toast hooks (`usePredictDepositToasts`, `usePredictClaimToasts`, `usePredictWithdrawToasts`, `usePredictToasts`) and their tests, and updates tests/messenger wiring accordingly (including safer account lookup when `AccountTreeController` is unavailable). > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4469fff. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> [PRED-579]: https://consensyssoftware.atlassian.net/browse/PRED-579?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
#25909) <!-- 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** When a prediction order fails because the market can't fully fill it (FOK order rejected), instead of showing an inline error, we now display a bottom sheet offering to retry at the best available price with higher slippage (99%). - PredictOrderRetrySheet — New bottom sheet component with two variants: - busy: Warning icon, "Market busy" title, "The market is moving fast, so we couldn't buy/sell at {price}..." - failed: Error icon, "Order failed" title, "There wasn't enough liquidity at this price..." - Uses usePredictBottomSheet for proper lifecycle (X close button, swipe dismiss, overlay cleanup) - usePredictOrderRetry hook — Encapsulates all retry logic to avoid duplication between Buy/Sell previews: - Manages sheet ref, variant state, and retrying flag - handleRetryWithBestPrice(): clones the existing preview with SLIPPAGE_BEST_AVAILABLE (50%) and re-places the order - Opens sheet with busy variant when isOrderNotFilled flips true - Switches to failed variant if the retry also fails - Tracks RETRY_PROMPTED and RETRY_SUBMITTED analytics events - usePredictPlaceOrder hook — Detects "not filled" errors (BUY_ORDER_NOT_FULLY_FILLED / SELL_ORDER_NOT_FULLY_FILLED) and exposes isOrderNotFilled + resetOrderNotFilled. Inline error and onError callback are not triggered for not-filled errors (the sheet handles them instead). - SLIPPAGE_BEST_AVAILABLE = 0.99 — 99% slippage constant for retries. BUY orders are protected by the existing floor (maxAmountSpent + tickSize). SELL orders have no floor — documented in the constant comment. Flow 1. User places prediction → order fails with "not fully filled" 2. "Market busy" sheet appears → user taps "Yes, buy" (or "Yes, sell") 3. Retry places the same order with 99% slippage 4. Success → toast + navigate back | Failure → sheet switches to "Order failed" with "Try again" 5. Close (X) on any sheet → dismiss, user stays on preview, can retry normally <!-- 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: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/PRED-428?atlOrigin=eyJpIjoiZjU2ZDM3MTI4YzkxNGRmNmE3ODk4MGNkNWIyNTVlYTciLCJwIjoiaiJ9 ## **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** https://www.loom.com/share/28e285d2e1f942629c4668e67794c5c7 <!-- 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** - [ ] 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. ## **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] > **Medium Risk** > Touches order-placement error handling and introduces a high-slippage retry path (0.99), which could impact trade execution behavior if mis-triggered or if outcome/status handling is incorrect. > > **Overview** > Adds a new `PredictOrderRetrySheet` bottom sheet ("market busy" vs "order failed") that prompts users to retry when an order can’t be fully filled, with new selector test IDs and localized copy. > > Introduces `usePredictOrderRetry` to orchestrate the retry flow: opens the sheet when `isOrderNotFilled` flips true, retries the same preview at `SLIPPAGE_BEST_AVAILABLE` (0.99), switches to the failed variant on retry failure, and tracks new `PredictTradeStatus` values (`retry_prompted`, `retry_submitted`). > > Refactors `usePredictPlaceOrder` to return a typed `PlaceOrderOutcome`, detect and surface “order not fully filled” errors via `isOrderNotFilled`/`resetOrderNotFilled` (suppressing inline error + `onError` in that case), and wires the retry sheet into both Buy and Sell preview screens with updated error rendering behavior. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit b98ab1b. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Luis Taniça <matallui@gmail.com>
<!--
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**
<!--
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?
-->
Update perps docs to refer to new ADR-42 arch for perps.
## **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**
- [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.
## **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**
> Documentation-only changes (path updates, structure clarification, and
deletion of a migration doc) with no runtime or behavioral impact.
>
> **Overview**
> Updates Perps docs to reflect the controller/UI split introduced by
ADR-042, pointing architectural references and “related files” to
`app/controllers/perps/*` instead of the former UI-layer controller
paths.
>
> Expands `perps-architecture.md` with the new controller directory
structure and multi-provider architecture notes (HyperLiquid +
feature-flagged MYX via `AggregatedPerpsProvider`/routing), and removes
the now-redundant `perps-controller-migration.md` document.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
82c04d3. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=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.
9 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 : )