[pull] main from MetaMask:main#780
Merged
Merged
Conversation
…or available count cp-7.78.0 (#30211) - feat(rewards): benefits preview uses Tag for available count (#30196) <!-- 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** > **Section header spacing alignment:** [`CampaignsPreview.tsx`](app/components/UI/Rewards/components/Campaigns/CampaignsPreview.tsx) — the campaigns preview **header row** now uses **`gap-1`** instead of **`gap-2`** between the title row items (spinner when shown, heading, chevron), matching the **Benefits** preview header spacing on the Rewards dashboard. The Rewards dashboard **Benefits** preview header previously used a numeric `BadgeCount` beside the section title. This change replaces it with a design-system **`Tag`** (`TagSeverity.Neutral`) that shows how many benefits are available using the localized string `rewards.benefits.available_count` (e.g. `%{count} available` in English). Counts above 99 display as `99+`. The header row is full width with **`justifyContent: space-between`**: the title and chevron stay on the leading side; the tag sits on the **trailing** edge so it matches the intended layout. Spacing uses `gap-1` between the title and chevron. The empty-state header no longer renders a redundant null badge slot. **Motivation:** Align with design (muted pill copy and alignment) and keep copy in i18n for the translation pipeline (English source string only in `en.json`). **Automated tests:** `yarn jest app/components/UI/Rewards/components/Benefits/BenefitsPreview.test.tsx` ## **Changelog** CHANGELOG entry: Updated the Rewards benefits preview header to show how many benefits are available using a tag label next to the section title; aligned campaigns preview section header spacing with the benefits preview (`gap-1`). ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: Rewards benefits preview header Scenario: User sees benefits count when they have benefits Given the user is opted into Rewards and the benefits API returns at least one benefit When user opens the Rewards dashboard (home) and scrolls to the Benefits preview Then a neutral tag shows the correct count and available wording for the current locale And the tag is aligned to the far right of the header row with the title and chevron grouped on the left And tapping the header row still navigates to the full benefits view Scenario: User has no benefits Given the user has no benefits in the list When user opens the Rewards dashboard and views the Benefits preview Then the count tag is not shown and the empty state behaves as before Feature: Rewards campaigns preview header spacing Scenario: User compares section headers on Rewards home Given the user is on the Rewards dashboard home tab When user views the Campaigns preview section header Then the title row uses gap-1 between the title row elements, matching the Benefits preview header spacing ``` ## **Screenshots/Recordings** ### **Before** Numeric badge style (`BadgeCount`) adjacent to the Benefits title (previous implementation). ### **After** <img width="413" height="827" alt="image" src="https://github.com/user-attachments/assets/bd00ee97-2ae3-4ccb-b924-51ba6d0ca677" /> Neutral `Tag` with “{count} available” (per locale), title + chevron on the left, tag aligned to the trailing edge. (Screenshot also attached in an earlier PR update.) ## **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** > Low risk UI/i18n change with unit test updates; primary risk is minor layout/regression in rewards preview headers and count formatting around the 99/99+ boundary. > > **Overview** > The Benefits preview header now replaces the numeric `BadgeCount` with a neutral design-system `Tag` that shows a localized `rewards.benefits.available_count` label (capped to `99+`), and adjusts header layout to keep the title+chevron grouped left with the tag right-aligned. > > Campaigns preview header spacing is tightened (`gap-1`), and tests were expanded to cover the new benefits count behavior (including empty state and 99/99+ cases) plus treating `undefined` campaigns as an empty list. Adds the new English i18n key `rewards.benefits.available_count`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 5ece706. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [f8f126d](f8f126d) Co-authored-by: Andrew Cohen <imandrewcohen@gmail.com>
…running perf builds (#30224) - fix: cp-7.78.0 add correct permissions to running perf builds (#30223) <!-- 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 `run-performance-e2e-experimental.yml` and `run-performance-e2e-release.yml` GitHub Actions workflows to grant `permissions.contents: write` (instead of read-only) so they are at least as permissive as the reusable `run-performance-e2e.yml` workflow they call. > > Adds an inline comment documenting the transitive requirement (via the BrowserStack upload workflows). > ## **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. --> - [ ] 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** > Low risk workflow-only change that broadens GitHub token permissions to match the called reusable workflow; main risk is over-permissioning if not actually required. > > **Overview** > Updates the `run-performance-e2e-experimental.yml` and `run-performance-e2e-release.yml` GitHub Actions workflows to grant `permissions.contents: write` (instead of read-only) so they are at least as permissive as the reusable `run-performance-e2e.yml` workflow they call. > > Adds an inline comment documenting the transitive requirement (via the BrowserStack upload workflows). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 54b2260. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [8fbb9a4](8fbb9a4) Co-authored-by: Curtis David <Curtis.David7@gmail.com>
…pay transactions in activity (#30217) - fix: cp-7.77.0 cp-7.78.0 missing metamask pay transactions in activity (#30145) ## **Description** The Activity tab had several bugs causing MetaMask Pay transactions to be missing, duplicated, or unreachable from the source chain. This PR addresses four root causes in production code plus a test alignment for the bridge smoke E2E: 1. **Source-chain visibility.** Submitted EVM transactions were filtered strictly by `tx.chainId`, so a MetaMask Pay parent was only visible on its destination chain. The source chain is recorded on `metamaskPay.chainId` (for gasless flows) or on linked child transactions via `requiredTransactionIds` (for non-gasless flows). A new `selectRelatedChainIdsByTransactionId` selector returns the full set of chain IDs a transaction relates to, and the Activity list now matches against that set. 2. **Dedupe fallback collapsed internal MetaMask Pay transactions.** When a transaction had no nonce, `selectLocalTransactions` fell back to `txParams.actionId` as the dedupe key. `actionId` is a top-level field on `TransactionMeta`, not on `txParams`, so for MetaMask Pay internal transactions (which have no nonce) every entry collapsed onto the same `undefined` key and all but one were dropped. The fallback now uses the top-level `id`, which is always present. 3. **Local transactions were scoped to the wrong account.** `selectLocalTransactions` gated on `selectEvmAddress` — the EVM address of the **currently selected internal account**. When the user picked a non-EVM account (e.g. Solana), this was `undefined` and the selector returned an empty list. Switching to "All popular networks" did not restore the address because that toggle changes enabled networks, not the selected account. It now uses `selectSelectedAccountGroupEvmInternalAccount`, the same source already used by the Activity tab's API query. 4. **Incoming-transaction duplicates.** The `TransactionController` incoming-transactions feature stores incoming transfers as separate `TransactionMeta` entries marked with `isTransfer !== undefined`. The accounts API also returns these transactions in its confirmed history, producing duplicate rows in the Activity tab. The dedupe step now skips entries with `isTransfer !== undefined`, leaving the accounts-API row as the canonical source. 5. **Bridge smoke E2E row alignment.** The Activity list merges pending smart transactions in alongside the real `TransactionMeta` row, producing a stale shell entry that lands at row 0. `bridge-action-smoke` was asserting on row 0 and timing out. The test now asserts on row 1, with a TODO to remove the STX-state merge from the Activity selectors and restore row 0. ## **Changelog** CHANGELOG entry: Fixed MetaMask Pay transactions appearing duplicated or missing from the Activity tab, including on the source chain and when the selected account is non-EVM. ## **Related issues** Fixes: [#30066](#30066) ## **Manual testing steps** ```gherkin Feature: MetaMask Pay Activity visibility Scenario: User views Activity on the chain that funded a MetaMask Pay transaction Given the user has completed a MetaMask Pay transaction funded by a token on chain X with destination chain Y And both chains X and Y are enabled networks When the user opens the Activity tab with chain X selected Then the MetaMask Pay transaction is visible in the list When the user opens the Activity tab with chain Y selected Then the MetaMask Pay transaction is also visible in the list Scenario: User views Activity after switching to a non-EVM account Given the user has pending MetaMask Pay transactions visible in the Activity tab When the user switches to a non-EVM account in the same account group And switches back to "All popular networks" Then the pending MetaMask Pay transactions remain visible Scenario: User views a single on-chain MetaMask Pay transaction Given the user has completed a single-chain MetaMask Pay transaction (for example an mUSD conversion) When the user opens the Activity tab Then the transaction appears exactly once ``` ## **Screenshots/Recordings** ### **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) - [ ] 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 ## **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] > <sup>[Cursor Bugbot](https://cursor.com/bugbot) is generating a summary for commit f45d17e. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [ff95f16](ff95f16) Co-authored-by: Matthew Walsh <matthew.walsh@consensys.net>
…essibility cp-7.78.0 (#30233) - chore: align carousel card heights for accessibility (#30201) <!-- 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** Use fluid heights on cards so large system text doesn’t clip. Problem before: fixed heights + large accessibility text scaling = content clipping inside cards. Now: cards and skeletons are fully fluid (no height prop needed). Only ViewMoreCard keeps a height, and only as a min-h directly inline in WhatsHappeningSection, so it sits at the same height as a typical card at normal font scale. How it looks now with huge font: <img height="800" alt="Simulator Screenshot - iPhone 17 Pro - 2026-05-14 at 18 39 46" src="https://github.com/user-attachments/assets/9097c9eb-c49a-45c4-b998-2392c06676dc" /> And normal/default font size: <img height="800" alt="Simulator Screenshot - iPhone 17 Pro - 2026-05-14 at 18 50 02" src="https://github.com/user-attachments/assets/e4a61f2b-425a-44d4-b650-677f288304e0" /> ## **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** > Low risk UI/layout change to remove fixed card heights; main risk is minor visual regression in carousel alignment across devices/font scales. > > **Overview** > Makes the What’s Happening carousel cards and loading skeletons **fluid-height** by removing the fixed Tailwind height prop (`twHeightClassName`) from `WhatsHappeningCard` and `WhatsHappeningCardSkeleton`, preventing content clipping with large accessibility text. > > Keeps the “View more” tile visually aligned by switching it to a `min-h-[230px]` constraint, and updates the skeleton test to assert the expected 2-line title and 3-line description placeholder configuration. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 00186c9. 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: Devin Stewart <49423028+Bigshmow@users.noreply.github.com> [a55aeb3](a55aeb3) Co-authored-by: António Regadas <antonio.regadas@consensys.net> Co-authored-by: Devin Stewart <49423028+Bigshmow@users.noreply.github.com>
…ymarket withdraw (#30250) - feat: cp-7.78.0 support deposit-wallet polymarket withdraw (#29953) ## **Description** Adopts the new Polymarket deposit-wallet support landed in [@metamask/transaction-pay-controller@22.5.0](MetaMask/core#8754) so Polymarket users whose pUSD lives in a deposit wallet (a per-user batch contract on Polygon) can withdraw cross-chain through MetaMask Pay. Highlights: - Lets Polymarket deposit-wallet users withdraw cross-chain through MetaMask Pay. - Gated behind a new remote feature flag, with the existing "withdraw unavailable" sheet preserved when off. - Polishes Predict withdraw activity rendering. ## **Changelog** CHANGELOG entry: null ## **Related issues** <!-- Internal --> ## **Manual testing steps** ```gherkin Feature: Polymarket deposit-wallet withdraw Scenario: deposit-wallet user with the flag on Given enableDepositWalletWithdraw is on And the user has a Polymarket deposit wallet with pUSD balance on Polygon When the user taps Withdraw on the Predict balance Then the standard Pay confirmation opens And confirming submits via the Polymarket strategy with no Polygon gas Scenario: deposit-wallet user with the flag off Given enableDepositWalletWithdraw is off When the user taps Withdraw on the Predict balance Then the existing "Withdraw unavailable" sheet is shown ``` ## **Screenshots/Recordings** ### **Before** ### **After** <img width="300" alt="Activity" src="https://github.com/user-attachments/assets/13d5a0e9-a39d-4c0a-9fde-468c5a0a7743" /> ## **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 ## **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 withdrawal behavior and MetaMask Pay transaction configuration for Polymarket `predictWithdraw`, including new controller callbacks and retry logic; mistakes could impact withdraw routing/fees for affected users. Gated by a remote feature flag, limiting blast radius. > > **Overview** > Enables Polymarket *deposit-wallet* users to run `predictWithdraw` through MetaMask Pay when the new `confirmations_pay_extended.enableDepositWalletWithdraw` flag is on; when off, the existing “withdraw unavailable” handling remains. > > Updates Predict/Pay plumbing for deposit-wallet withdraws: `PredictController.prepareWithdraw` now omits `gasFeeToken` for deposit-wallet accounts, `useTransactionPayPostQuote` skips `refundTo` and marks `isPolymarketDepositWallet`, and Transaction Pay initialization wires new Polymarket callbacks that can derive deposit-wallet addresses and submit deposit-wallet batches (with “wallet busy” retries + keyring signing support). > > Polishes confirmations activity rendering for `predictWithdraw` by adding a dedicated `predict_withdraw` title and treating it as a receive-summary type using the source token/network metadata. Tests are added/updated accordingly, and `@metamask/transaction-pay-controller` is bumped to `22.5.0`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 054697c. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [4997055](4997055) Co-authored-by: Matthew Walsh <matthew.walsh@consensys.net>
…ase branch (#30262) - fix: cp-7.78.0 ensure perf e2e run on release branch (#30258) <!-- 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: ## **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** > Low risk: only adjusts GitHub Actions gating logic for when the performance E2E workflow runs, without touching app/runtime code. > > **Overview** > Ensures the `run-performance-e2e-release.yml` workflow runs for **all** pushes to `release/*` branches (in addition to `workflow_dispatch`), instead of only running on push when the commit was a `metamaskbot` version bump. > > Keeps the scheduled trigger behavior (checking for recent `metamaskbot` version bumps) but updates comments/logging to reflect the new push trigger conditions. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3cdedbe. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [c1071c4](c1071c4) Co-authored-by: Curtis David <Curtis.David7@gmail.com>
…ake it theme-aware cp-7.78.0 (#30273) - fix(Rewards): Update theMiracle logo and make it theme-aware cp-7.78.0 (#30213) <!-- 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? --> The logo for theMiracle displayed at the bottom of the Benefits screen was incorrect and was hard to see in dark theme This uses the updated, correct logo as an SVG and swaps the color when in dark mode. ## **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/RWDS-1302 ## **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="1170" height="2532" alt="Simulator Screenshot - iPhone 16e - 2026-05-15 at 11 03 13" src="https://github.com/user-attachments/assets/9de0b304-234c-43b7-9cff-a20786909548" /> ## **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** > Low risk UI-only change: swaps an SVG asset and passes a theme-derived `color` prop to improve contrast; minimal logic impact covered by unit test updates. > > **Overview** > Updates the Rewards Benefits footer to render the TheMiracle logo using the current theme text color by wiring `useTheme()` into `TheMiracleFooter` and passing a `color` prop to the SVG component. > > Replaces `themiracle-logo.svg` with the corrected artwork and adjusts the unit test to mock/verify the new `color` prop is set to `colors.text.default`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 0ee0184. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [ea0f772](ea0f772) Co-authored-by: Christian Montoya <christian.montoya@consensys.net>
…e on first deposit cp-7.77.0 cp-7.78.0 (#30277) - fix(predict): fix unregistered wallet issue on first deposit cp-7.77.0 cp-7.78.0 (#30267) ## **Description** Fixes the first-deposit flow for new Predict users whose Polymarket deposit wallet has been created but is not fully registered yet. Polymarket advised that `STATE_MINED` can happen before the wallet is usable on their side, so the deposit wallet relayer polling now treats only `STATE_CONFIRMED` as a successful completion state. This keeps polling through mined responses until Polymarket confirms the wallet, preventing the follow-up batch transaction from failing with "wallet is not registered". ## **Changelog** CHANGELOG entry: Fixed a bug that caused a user's first Predict deposit to fail while their deposit wallet was still registering. ## **Related issues** Fixes: PRED-886 ## **Manual testing steps** ```gherkin Feature: Predict first deposit wallet registration Scenario: user makes their first Predict deposit Given a new Predict user does not have a registered Polymarket deposit wallet When user starts their first deposit Then the app creates the deposit wallet And waits until the relayer reports STATE_CONFIRMED And proceeds with the wallet batch transaction without a "wallet is not registered" error ``` ## **Screenshots/Recordings** N/A - logic-only relayer polling change. ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example 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. ## Testing - `yarn jest app/components/UI/Predict/providers/polymarket/depositWallet.test.ts --runInBand` <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes deposit-wallet relayer polling completion criteria, which can affect first-deposit transaction flow timing and success. Low code surface area but touches user-critical deposit execution behavior. > > **Overview** > Fixes Predict first-deposit failures by tightening Polymarket relayer success detection: `waitForDepositWalletTransaction` now treats only `STATE_CONFIRMED` (not `STATE_MINED`) as a completion state before proceeding. > > Updates the related unit test to expect continued polling through `STATE_MINED`/no-hash responses until a `STATE_CONFIRMED` transaction hash is returned. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit a36ba27. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [dafc42c](dafc42c) Co-authored-by: Luis Taniça <matallui@gmail.com>
#30312) - chore: ohlcv reduce initial delay cp-7.78.0 (#30292) ## **Description** ## Problem Chart data took ~9-10 seconds to display after navigating to token details. Performance logs showed it takes approximately 9.4 seconds from WebSocket subscription until the first bar update arrives from the server. ## Solution Implemented immediate REST API polling to provide data while waiting for the first WebSocket update: 1. **Reduced staleness threshold** from 10s to 5s 2. **Added immediate data fetch** via REST API right after WebSocket subscription ## Timeline Observed ``` T=0ms - Subscribe to WebSocket T=~300ms - First REST data arrives (immediate!) T=5s - Second REST poll (WebSocket not ready yet) T=9.4s - First WebSocket update arrives, REST polling stops T=14.4s+ - WebSocket continues with regular updates (~5s intervals) ``` ## **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: OHLCV chart data now loads in ~300ms via REST API while establishing WebSocket connection, reducing initial load time from 9.4s to 300ms. ## **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] > **Medium Risk** > Changes chart data fetching timing by triggering immediate REST polls and a shorter staleness threshold, which could increase network traffic or cause unexpected polling behavior if timing assumptions are wrong. > > **Overview** > Reduces perceived OHLCV chart load time by **polling the `/latest` REST endpoint immediately after a successful WebSocket subscribe**, instead of waiting for the first WS bar. > > Shortens the WS staleness threshold from `10s` to `5s`, tweaks stale detection to use `>=`, and adds basic numeric validation in `fetchLatestBar` to drop malformed REST responses. Tests are updated to reflect the new timing and the additional initial REST fetch (many cases now expect **two** `fetch` calls: immediate + staleness/chain-down). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit a3d5c11. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [cd875d0](cd875d0) Co-authored-by: sahar-fehri <sahar.fehri@consensys.net>
…alerts cp-7.78.0 (#30311) - fix: release-blocker restore gas estimate alerts cp-7.78.0 (#30266) <!-- 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? --> Fixes release blocker regression #30260 for release 7.78.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: restores gas estimate alerts on all networks except strictly gas-sponsored ones ## **Related issues** Fixes: #30260 ## **Manual testing steps** Same testing intructions as for #29835 Add non-regression for issues raised in #30260, which may include for example calling `pause` on [Mainnet USDC](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#writeProxyContract) and checking that the "gas estimation failed" alert shows at least somewhere (can be second alert, but it needs to exist). ## **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** > Changes confirmation alert gating logic for gas estimation failures and sponsorship reserve warnings, which could alter what users see during transaction approval on different networks. Risk is moderate because it affects transaction UX/decisioning but does not change signing or on-chain behavior. > > **Overview** > Restores and tightens when gas-related confirmation alerts are shown by introducing `useIsGasSponsored`, which returns true only when **both** the gasless transaction is supported and the current chain is enabled via the `gasFeesSponsoredNetwork` feature flag. > > `useGasEstimateFailedAlert` now suppresses the “gas estimate failed” warning only when `useIsGasSponsored` is true (instead of suppressing for any gasless-supported/pending checks), and `useGasSponsorshipWarningAlert` now shows the Monad reserve-balance blocking warning only when sponsorship is expected for the transaction. Tests were updated and a new unit test suite was added for `useIsGasSponsored`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit d06ea89. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [ac8df0d](ac8df0d) Co-authored-by: maxime-oe <maxime.ouairy-ext@consensys.net>
…nge cp-7.78.0 (#30324) - chore: related assets pills with price change (#30259) <!-- 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 related assets as pills with price variation, in a sliding carousel. When the user taps a pill, it will redirect to the asset perps page. Also fires the segment `WHATS_HAPPENING_INTERACTED` / `related_asset_pressed` analytics event on tap. https://github.com/user-attachments/assets/aff6636d-58df-4177-8413-a32a41f704d9 ## **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] > **Medium Risk** > Adds new interactive UI inside the `What's Happening` carousel that subscribes to live perps price streams and triggers trade navigation + analytics on tap, which can impact performance and event accuracy if miswired. > > **Overview** > **Adds a horizontal “related assets” pill slider to each `WhatsHappeningCard`**, replacing the prior single “`<symbol> +N`” label and moving the date display to the top row alongside the impact badge. > > Each pill can optionally show **24h % change from live perps prices**, and when tradable is **pressable to open perps trade navigation** while emitting a new analytics interaction type `related_asset_pressed` (`MetaMetricsEvents.WHATS_HAPPENING_INTERACTED`). > > To support live pricing, the homepage `WhatsHappeningSection` carousel is now wrapped in `PerpsStreamProvider`, and `useWhatsHappeningAssetPrices` is refactored to accept `RelatedAsset[]` directly (with tests updated/added for the new pill/slider behavior and updated skeleton layout). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 77b44dd. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [2e2cce7](2e2cce7) Co-authored-by: António Regadas <antonio.regadas@consensys.net>
…explore cp-7.78.0 (#30328) - chore: adds ab test for WH positioning in explore cp-7.78.0 (#30303) <!-- 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 an AB test for the positioning of the Whats Happening section in the Explore page. <!-- 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: no-changelog ## **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** > Low risk UI-only change gated by a remote A/B test flag; primary risk is unintended section ordering or missing content in Explore for certain variants. > > **Overview** > Adds a new remote A/B test (`socialAiTSA531AbtestWhatsHappeningExplore`) to control whether the Explore "Now" tab shows *Whats Happening* before or after the *Predict* carousel. > > `NowTab` now reads the variant via `useABTest` and renders the two intro sections in the chosen order, while analytics are updated to attach the new assignment to `EXPLORE_INTERACTED` events (registry + unit test coverage). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 166fec1. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [e3a4312](e3a4312) Co-authored-by: João Santos <joaosantos15@users.noreply.github.com>
After release/7.77.0 was merged into stable in #29883, the existing release/7.78.0 -> stable PR (#30207) showed conflicts because stable had diverged. This sync brings stable back into release/7.78.0 so the next 7.78.0 release PR is conflict-free. Conflict resolution summary (22 conflicting files): - Build artifact / version bumps (kept release/7.78.0): bitrise.yml, android/app/build.gradle, ios/MetaMask.xcodeproj/project.pbxproj (also drops the QA build configuration block that was deleted on main in #29830 and was still present on 7.77.0). - Dependency files (kept release/7.78.0): package.json, yarn.lock. No stable-only commit modified these files; 7.78.0's surface is a strict superset of stable's. - Workflow / route / docs (kept release/7.78.0): build-android-e2e.yml, run-e2e-smoke-tests-ios.yml, Money* (Views, routes), Ramp PLAN.md, app/constants/navigation/Routes.ts. No stable-only commit touched these files. - Cherry-pick conflicts (kept release/7.78.0): each had exactly one stable-only commit (a runway cherry-pick into release/7.77.0) whose original PR is already on main and therefore on release/7.78.0: TabsIconBar.* (#29889), usePredictBuyError.* (#30064), FilterBar.tsx (#30020), Homepage.tsx (#29757), NowTab.test.tsx (#29912), HyperLiquidProvider.ts (#30114), test-snap-get-entropy.spec.ts (#30043). - Locales (restored from release/7.78.0): de/el/es/fr/hi/id/ja/ko/pt /ru/tl/tr/vi/zh.json. Auto-merge picked up stable's no-trailing- newline form and dropped a small number of new keys from main; reset to 7.78.0's content which is a superset. Net delta vs release/7.78.0: only the [7.77.0] section in CHANGELOG.md. Co-authored-by: Cursor <cursoragent@cursor.com>
This sync brings `stable` into `release/7.78.0` CHANGELOG entry: null <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk: documentation-only change updating release notes and version comparison links, with no runtime code impact. > > **Overview** > Adds a new `7.77.0` section to `CHANGELOG.md` with the release notes (Added/Changed/Fixed items). > > Updates the changelog footer links so `[Unreleased]` now compares from `v7.77.0`, and adds the `[7.77.0]` compare link (`v7.76.3...v7.77.0`). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit dba98f8. 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: metamaskbot <metamaskbot@users.noreply.github.com> Co-authored-by: runway-github[bot] <73448015+runway-github[bot]@users.noreply.github.com> Co-authored-by: Juanmi <95381763+juanmigdr@users.noreply.github.com> Co-authored-by: Vince Howard <vincenguyenhoward@gmail.com> Co-authored-by: Pedro Pablo Aste Kompen <wachunei@gmail.com> Co-authored-by: sahar-fehri <sahar.fehri@consensys.net> Co-authored-by: Xiaoming Wang <7315988+dawnseeker8@users.noreply.github.com> Co-authored-by: infiniteflower <139582705+infiniteflower@users.noreply.github.com> Co-authored-by: Luis Taniça <matallui@gmail.com> Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Christopher Ferreira <104831203+christopherferreira9@users.noreply.github.com> Co-authored-by: Remi ARQUEVAUX <r.arquevaux@gmail.com> Co-authored-by: Prithpal Sooriya <prithpal.sooriya@consensys.net> Co-authored-by: metamaskbotv2[bot] <214045046+metamaskbotv2[bot]@users.noreply.github.com> Co-authored-by: Patryk Lucka <5708018+PatrykLucka@users.noreply.github.com> Co-authored-by: Caainã Jeronimo <caainaje@gmail.com> Co-authored-by: Monte Lai <monte.lai@consensys.net> Co-authored-by: gantunesr <17601467+gantunesr@users.noreply.github.com> Co-authored-by: Xiaoming Wang <dawnseeker8@users.noreply.github.com> Co-authored-by: Nico MASSART <NicolasMassart@users.noreply.github.com> Co-authored-by: Shane T <muldots@gmail.com> Co-authored-by: Aslau Mario-Daniel <marioaslau@gmail.com> Co-authored-by: Matthew Walsh <matthew.walsh@consensys.net> Co-authored-by: Alejandro Garcia Anglada <aganglada@gmail.com> Co-authored-by: Nicholas Gambino <nicholas.gambino@consensys.net>
… cp-7.78.0 (#30358) - feat: add AI disclaimer to whats happening cp-7.78.0 (#30352) <!-- 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 a disclaimer to the Market Insights page when the AI button is clicked. <!-- 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: no-changelog ## **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 - [ ] 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** > Low risk UI-only change that adds a new bottom-sheet visibility state and callback wiring; primary risk is minor regressions in the Whats Happening detail view interaction flow. > > **Overview** > Adds an **AI disclaimer** flow to the `What's happening` detail carousel: tapping the **AI pill** on `WhatsHappeningExpandedCard` now triggers an `onAIDisclaimerPress` callback, which `WhatsHappeningDetailView` uses to show/hide `MarketInsightsDisclaimerBottomSheet`. > > Updates unit tests to cover the new AI-pill press behavior and bottom sheet open/close rendering logic. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 026dd93. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [5efac50](5efac50) Co-authored-by: João Santos <joaosantos15@users.noreply.github.com>
Same recipe as #30345 (post-7.77.0 sync). After release/7.77.1-ota was merged into stable in #30309, the 7.78.0 release PR (#30207) shows conflicts again. This sync brings stable back into release/7.78.0 so the next 7.78.0 -> stable merge is conflict-free. Conflict resolution (3 substantive files): - package.json: take release/7.78.0. The 7.77.1 cherry-pick (#30265 -> #29953) added pinned controller resolutions for the OTA line (controller-utils ^11.0.0, network-controller ^30.0.0, network-enablement-controller 5.1.0); 7.78.0 already has the original feature plus newer pins (network-controller 31.0.0, transaction-controller ^65.4.0). Keeping ours preserves the newer pins. - yarn.lock: take release/7.78.0. Only stable-only commit modifying yarn.lock is the cherry-pick (#30265); its original (#29953) is already in 7.78.0 (also re-cherry-picked as #30250). - app/constants/ota.ts: silent regression caught — auto-merge dragged stable's `OTA_VERSION = 'v7.77.1'` into 7.78.0. Restored to release/7.78.0's sentinel `'vX.XX.X'` (no OTA shipped yet on the next native build). Auto-merged correctly (no fix needed): - CHANGELOG.md: stable's `[7.77.1]` section inserted between `[Unreleased]` and `[7.77.0]`; footer compare links unchanged. - locales/languages/en.json + several confirmations/Predict files: auto-merged content equals release/7.78.0. Net delta vs release/7.78.0: only CHANGELOG.md (+12 / -1). Co-authored-by: Cursor <cursoragent@cursor.com>
This sync brings `stable` back into `release/7.78.0` CHANGELOG entry: null <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Documentation-only change updating the changelog; no runtime code paths are modified. > > **Overview** > Adds a new `7.77.1` section to `CHANGELOG.md` documenting Predict cross-chain withdrawals via MetaMask Pay (for Polymarket Deposit Wallet users) and a fix for first Predict deposits failing during wallet registration. > > Updates the compare links so `Unreleased` now targets `v7.77.1...HEAD` and adds the `7.77.1` diff link. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit fefc74e. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…issing or non-positive network fee data (#30494) - fix: handle BTC quote when BTC quote has missing or non-positive network fee data (#30313) ## **Description** This pull request improves how the Bridge UI handles and displays cases where the network fee is unavailable, especially for Bitcoin (BTC) bridges. It introduces a new hook to detect unavailable network fees, updates the logic for disabling/enabling the confirm button, and adjusts messaging and analytics accordingly. The changes also include comprehensive tests for these scenarios. **Key changes:** **1. Handling Network Fee Unavailability in the UI** - Added the `useIsNetworkFeeUnavailable` hook to detect when the network fee (especially for BTC) is unavailable and integrated it into both `BridgeView` and `SwapsConfirmButton` components. This disables the confirm button and updates the label to "Insufficient funds" when the fee is unavailable. **2. Analytics and Event Tracking** - Updated the `useBridgeQuoteEvents` hook and its consumers to track when the network fee is unavailable, emitting a new `network_fee_unavailable` warning instead of the generic insufficient gas warning. **3. Gas Fee Calculation Logic** - Modified `useHasSufficientGas` to use `totalNetworkFee.amount` for BTC quotes instead of `gasFee.effective.amount`, ensuring correct balance validation for Bitcoin transactions. **4. Testing and Coverage** - Added and updated tests for both the UI and hooks to cover scenarios where the BTC network fee is unavailable, ensuring proper button states, messaging, and analytics events. This includes new test cases for `SwapsConfirmButton` and `useBridgeQuoteEvents`, and additional BTC-specific tests for `useHasSufficientGas`. These updates ensure that users are clearly informed when a bridge transaction cannot proceed due to unavailable network fees, especially for Bitcoin, and that analytics accurately reflect this state. ## **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 BTC quote when BTC quote has missing or non-positive network fee data ## **Related issues** Fixes: Bridging BTC is failing at the transaction crafting in certain cases ## **Manual testing steps** BTC quote with unavailable fee 1. Open the Bridge/Swap flow. 2. Select BTC as the source token and ETH as the destination token. 3. Enter an amount that can produce a BTC quote. 4. Simulate or reproduce a quote where the BTC network fee is 0 or unavailable. 5. Confirm the CTA shows Insufficient funds. ## **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** > Updates bridge confirmation disablement, labeling, and analytics around fee/gas validation, which can block submissions and alter event warnings; impact is mostly limited to BTC and UI state handling but affects core swap/bridge CTA logic. > > **Overview** > **Improves BTC quote handling when network fee data is missing/invalid.** Adds `useIsNetworkFeeUnavailable` to detect BTC quotes with missing, non-finite, or non-positive `totalNetworkFee.amount`, and uses it to disable submission and show *Insufficient funds* (instead of *Insufficient gas*) in `BridgeView`, `SwapsConfirmButton`, and Quick Buy. > > **Adjusts fee validation + analytics.** `useHasSufficientGas` now prefers `totalNetworkFee.amount` for BTC when checking gas sufficiency, and `useBridgeQuoteEvents` emits a new `network_fee_unavailable` warning (taking precedence over insufficient gas). > > **Expands test coverage.** Adds/updates unit tests to cover BTC network-fee-unavailable cases across confirm button states, “Get new quote” enablement, quote warnings, Quick Buy button errors, and BTC gas validation. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 30e4c63. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [5042fdb](5042fdb) Co-authored-by: Fred <frederic.heng@consensys.net>
…L to fix invalid-URL error in 2.23.0 cp-7.78.0 (#30496) - fix(analytics): normalise Segment proxy URL to fix invalid-URL error in 2.23.0 cp-7.78.0 (#30463) ## Summary `@segment/analytics-react-native` 2.23.0 introduced a strict `validateURL` regex via [PR #1157](segmentio/analytics-react-native#1157) that only allows `[a-zA-Z0-9_.-]` in query-param values. The MetaMask Segment proxy URL encodes the write key as standard base64 in a query param (`?b=<base64>==`), and the trailing `=` padding characters are rejected by this regex. When the URL fails validation `SegmentDestination.getEndpoint()` silently falls back to `https://api.segment.io/v1/b`. Events reach Segment's default endpoint but the proxy write key is only valid through `fn.segmentapis.com`, so they are rejected — causing **no events to appear in Mixpanel**. ## Change Added `normalizeProxyUrl` in `platform-adapter.ts` that strips trailing `=` padding from query-param values before passing the URL to the Segment client config. - Stripping base64 padding is safe: decoders infer it from data length and the proxy server accepts both forms. - The `=` key–value separator is preserved (the regex uses a lookahead `(?=&|$)` to match only padding at the end of a param value). - Contains a `TODO` to remove once upstream fixes the regex to accept all RFC 3986 query characters. ## Test plan - [ ] Run the app in dev mode and verify analytics events appear in Mixpanel - [ ] Verify no "Invalid URL has been passed" errors in the console - [ ] Run unit tests: `yarn jest platform-adapter` Made with [Cursor](https://cursor.com) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Moderate risk because it changes how the Segment client is configured and could affect where analytics events are sent if the proxy URL is altered incorrectly, though the change is narrowly scoped and covered by unit tests. > > **Overview** > Fixes Segment proxy URL validation failures by normalizing `SEGMENT_PROXY_URL` before passing it to `createClient`, stripping trailing base64 `=` padding from query-param values (while preserving key/value separators). > > Adds focused unit coverage for `normalizeProxyUrl` across common URL shapes (single/double padding, multi-param URLs) and a wiring test to ensure `createPlatformAdapter` passes the normalized `proxy` value into Segment client configuration. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit ee00a41. 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: João Santos <joaosantos15@users.noreply.github.com> [66f0cb2](66f0cb2) Co-authored-by: tommasini <46944231+tommasini@users.noreply.github.com> Co-authored-by: João Santos <joaosantos15@users.noreply.github.com>
…78.0 (#30516) - fix: Perps withdraw back-swipe toast cp-7.78.0 (#30504) ## Summary Fixes the Perps withdraw confirmation flow so user-initiated confirmation rejection, including iOS back-swipe, does not show the retryable "withdrawal wasn't started" error toast. ## Root Cause PR #30299 added an `addTransactionBatch` catch path that navigates back and shows the withdrawal-start failure toast for every rejected batch initialization. Back-swiping the confirmation rejects the approval with a user-rejected error, so that normal cancellation path was being treated as a real initialization failure. ## Changes - Detect user-rejected errors before showing the withdrawal-start failure toast. - Keep the existing retry toast behavior for real `addTransactionBatch` failures. - Add regression coverage for user rejection so it does not call `goBack`, build the retry toast, or show the toast. Fixes #30485. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk: scoped to Perps withdraw error handling and adds a regression test; behavior only changes for user-rejected/cancel paths. > > **Overview** > Prevents Perps withdraw confirmation cancellations (user-rejected errors) from being treated as `addTransactionBatch` failures: on rejection, the hook now rethrows without calling `navigation.goBack()` or showing the retryable “withdrawalStartFailed” toast. > > Adds a regression test covering a `providerErrors.userRejectedRequest()` rejection to ensure no back navigation or toast is triggered, while keeping the existing retry-toast behavior for real batch initialization failures. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c23f2c3. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [b76275a](b76275a) Co-authored-by: Pedro Figueiredo <ganseki.figueiredo@gmail.com>
…ctly to TPSL header cp-7.78.0 (#30515) - fix(perps): apply safe area top inset directly to TPSL header cp-7.78.0 (#30503) ## **Description** The TPSL (Take Profit / Stop Loss) page header was intermittently positioned too high, overlapping the status bar / notch area. This occurred both when creating a TPSL from the order screen and when editing a TPSL for an open position. **Root cause:** The screen relied on the shimmed `SafeAreaView` with `edges={['top', 'bottom']}` to apply the top safe area inset. The shim (`SafeAreaViewWithHookTopInset`) turns off the native top inset and re-applies it via a hook-based `paddingTop`. With the `transparentModal` presentation mode used by this screen, the hook-based top inset was intermittently not applied, causing the header to render too high. **Fix:** Follow the same proven pattern used by `PerpsOrderHeader` — apply the top inset directly to the header view using `useSafeAreaInsets()`, and only use `SafeAreaView` for the bottom edge. This is deterministic and does not depend on the shimmed SafeAreaView lifecycle for transparent modals. ## **Changelog** CHANGELOG entry: Fixed TPSL page header overlapping the status bar area ## **Related issues** Fixes: TAT-3213 ## **Manual testing steps** ```gherkin Feature: TPSL page header alignment Scenario: user creates a TPSL from the order screen Given the user is on the Perps order screen with an asset selected When user taps the TPSL / Auto close button Then the TPSL page opens with the header properly below the status bar / notch area Scenario: user edits a TPSL for an open position Given the user has an open Perps position with or without existing TP/SL values When user taps the Auto close / Edit TPSL button on the position Then the TPSL page opens with the header properly below the status bar / notch area Scenario: user repeatedly opens and closes the TPSL page Given the user is on the Perps order screen When user opens and closes the TPSL page multiple times Then the header is consistently aligned below the safe area every time ``` ## **Screenshots/Recordings** ### **Before** https://consensys.slack.com/archives/C092T3GPHQD/p1779353500168619 ### **After** <img width="1320" height="2868" alt="Simulator Screenshot - iPhone 17 Pro Max - 2026-05-21 at 11 40 56" src="https://github.com/user-attachments/assets/71ea9e56-f7d6-43ea-8e22-d00c4ca78c5a" /> Header is consistently positioned below the safe area. ## **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** > Low risk UI layout change limited to safe-area handling in the Perps TPSL screen; no business logic or data flow changes. > > **Overview** > Fixes an intermittent layout issue where the Perps TPSL header could render under the status bar/notch. > > `PerpsTPSLView` now uses `useSafeAreaInsets()` to add top padding directly on the header, and updates `SafeAreaView` to only apply the bottom safe area (`edges={['bottom']}`) so top inset behavior is deterministic in modal presentation. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit f3dd563. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [1635a36](1635a36) Co-authored-by: Michal Szorad <michal.szorad@consensys.net>
… quote-aware fee handling (#30526) - fix: add BTC swap reserve enforcement with quote-aware fee handling (#30404) ## **Description** This pull request enhances the `useInsufficientNativeReserveError` hook to support Bitcoin (BTC) native reserve logic, ensuring accurate handling of minimum reserve requirements and quote-aware calculations for BTC swaps. It also improves test coverage for these scenarios and refactors related code for better clarity and extensibility. **BTC Native Reserve Support and Logic Improvements:** * Added BTC mainnet support to the minimum native reserve calculation, introducing a specific reserve threshold for BTC and handling BTC chain IDs using CAIP format. The hook now accounts for BTC-specific requirements when determining if a swap would violate the minimum reserve. **Testing Enhancements:** * Added comprehensive test cases for BTC reserve logic, including scenarios for reserve breaches, quote-aware calculations, and edge cases where reserve or fees restrict swaps. Introduced BTC token and quote mocks for robust test coverage. **Refactoring and Type Improvements:** * Refactored types and utility functions to support both EVM and non-EVM (CAIP) chain IDs, improving maintainability and future extensibility. **Integration Updates:** * Updated `BridgeViewContent` and `SwapsConfirmButton` components to pass the `activeQuote` prop to the hook, enabling quote-aware reserve checks in the UI flow. ## **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 BTC swap reserve enforcement with quote-aware fee handling ## **Related issues** Fixes: Bridging BTC is failing at the transaction crafting in certain cases ## **Manual testing steps** BTC max amount / reserve validation 1. Use a BTC account with a small balance. 2. Select BTC as source and ETH as destination. 3. Enter an amount that would leave less than 0.00003 BTC after the swap. 4. Confirm the warning banner says Minimum BTC reserve balance is required. 5. Confirm the message displays a reserve of 0.00003 BTC. 6. Confirm the CTA shows Insufficient funds. 7. Click Use max allowed. 8. Confirm the input is reduced to the max amount shown in the banner. ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <img width="400" height="800" alt="BTC-swap" src="https://github.com/user-attachments/assets/b0990cdc-d0a3-4903-a544-eed08bc60ac8" /> ## **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** > Updates swap/bridge validation for BTC to enforce a minimum native reserve using quote-provided network fees/overhead, which can block transactions if miscomputed. Changes are localized and covered by new unit tests, but affect user-facing amount limits and submit eligibility. > > **Overview** > **Adds BTC native reserve enforcement to swap/bridge submit validation.** `useInsufficientNativeReserveError` now supports CAIP chain IDs, defines a BTC mainnet minimum reserve (`0.00003`), and for BTC uses `activeQuote` to subtract quoted network fees and source-side overhead when computing the max swappable amount. > > **Integrates quote-aware checks in the UI flow.** `BridgeView` and `SwapsConfirmButton` now pass `activeQuote` into the hook so banners/CTAs and the confirm button correctly reflect BTC reserve + fee constraints. > > **Expands test coverage.** Adds BTC-specific unit tests covering reserve boundary conditions, quote fee consumption, decimal truncation, and cases where gas validation should own the failure. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit da0093c. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [bc03176](bc03176) Co-authored-by: Fred <frederic.heng@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: 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**
<img width="1179" height="2556" alt="Simulator Screenshot - E2E Test -
2026-05-20 at 13 45 24"
src="https://github.com/user-attachments/assets/0f07ee43-b1ee-43bf-8db6-dd08b5a68998"
/>
<!-- [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
- [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`.
-->
- [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**
> Primarily deletes agent/command documentation and updates
`.cursor/BUGBOT.md` to reference new testing docs; no runtime app logic
changes, with minor risk of broken internal tool references if any
removed skill files are still expected by automation.
>
> **Overview**
> Removes a large set of repo-local AI skill and command documentation
under `.agents/skills/` and `.claude/` (including related reference
guides), effectively decommissioning those legacy harness entrypoints.
>
> Updates `.cursor/BUGBOT.md` to reference the new SSOT testing docs
under `docs/testing/` for unit, e2e, and component view test guidelines
instead of the previous `.cursor/rules/*` references.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
164cbb6. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
…tion rows cp-7.78.0 (#30533) - fix: show fallback token icons in confirmation rows cp-7.78.0 (#30502) ## **Description** Fixes missing token icons in confirmation rows when token metadata is unavailable in local token state. The confirmation `TokenIcon` now falls back to the shared MetaMask token icon URL when it has an address, chain ID, and symbol, while still rendering nothing when neither token metadata nor a symbol is available. This also passes the receive token symbol from `PayWithRow` into `TokenIcon`, so Perps and Predict deposit/withdraw rows can render the token icon fallback for mUSD and other supported ERC-20 tokens with missing local metadata. ## **Changelog** CHANGELOG entry: Show fallback token icons in confirmation rows ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1411 ## **Manual testing steps** ```gherkin Feature: Confirmation token icon fallback Scenario: user withdraws mUSD from Perps or Predict Given the user has an mUSD balance And the user starts a Perps or Predict withdraw flow When the Receive row displays mUSD Then the mUSD token icon is shown next to the token symbol ``` ## **Screenshots/Recordings** ### **Before** ### **After** N/A ## **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 - [x] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk UI change that only affects how token icons are resolved/rendered in confirmation rows. Main risk is incorrect fallback URL generation for some chains, but it’s covered by new unit tests. > > **Overview** > Fixes missing token icons in confirmation flows by updating `TokenIcon` to accept an optional `symbol` and, when local token metadata is absent, fall back to a MetaMask-hosted token icon URL (while still rendering nothing when neither metadata nor `symbol` is available). > > Updates `PayWithRow` to pass the displayed token `symbol` into `TokenIcon` (notably for *Receive/withdraw* rows), and expands unit tests to validate symbol propagation and fallback URL generation across multiple supported chains. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 8921cc4. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [a0f1af8](a0f1af8) Co-authored-by: Daniel <80175477+dan437@users.noreply.github.com>
…lore page (#30535) - feat(predict): Enable Bottom Sheet via Explore page cp-7.78.0 (#30481) ## **Description** Predict market cards on the Explore feed now open the Buy/Sell preview as an in-place bottom sheet (matching the dedicated Predict feed) when the `predictBottomSheet` feature flag is on, instead of routing to the full-page bet slip. ### What changed 1. **Mounted `PredictPreviewSheetProvider` at the `HomeTabs` level** in `app/components/Nav/Main/MainNavigator.js`, wrapping the `Tab.Navigator`. The provider was previously only mounted inside `PredictScreenStack`, so triggering `openBuySheet`/`openSellSheet` from any other tab fell back to navigation. Mounting at `HomeTabs` makes the sheet usable from Explore (and any future tab that needs it) while keeping the existing in-Predict behavior untouched (`PredictScreenStack` still mounts its own provider; the inner one shadows the outer for usage). 2. **Why mount at `HomeTabs` and not inside the tab itself?** `BottomSheet` from `@metamask/design-system-react-native` uses `absolute inset-0` for its container. If the provider is mounted inside an individual tab's content area, the sheet's parent is smaller than the viewport and the sheet gets clipped at the top of the screen and below by the bottom tab bar. Mounting at `HomeTabs` puts the sheet's parent at the full-viewport `Home` Stack.Screen card, which is the smallest level above the tab bar that gives correct dimensions. 3. **Fixed a duplicate-toast and stale-suppression bug** that the new placement exposes. With both `HomeTabs` and `PredictScreenStack` providers now mounted simultaneously while the user is inside the Predict stack, both used to: - independently fire the state-based "Try again" failure toast on `activeOrder.error` transitions (no dedup in `ToastService`); - increment the same `_providerSheetModeCount` counter that gates `shouldSuppressLegacyOrderFailureToast()`, which then swallowed the legacy failure toast in tabs/flows where the active provider could not actually fire its own toast (e.g. Wallet/Trade/Money/Rewards, or HomepageDiscoveryTabs which mounts in `disableBottomSheet` mode). Replaced the module-level counter with a registration **stack** (`_sheetModeProviders`). Each entry holds the provider's id and a `hasBuyParams()` getter. The topmost (most recently mounted, innermost in the tree) entry is the only "active" one: - The state-based toast effect in `PredictPreviewSheetContext.tsx` bails out unless the current provider is active — so only the innermost provider fires the Retry toast. - `shouldSuppressLegacyOrderFailureToast()` now consults the active entry's `hasBuyParams()`, so the legacy toast is only suppressed when the active provider will actually surface its own toast. 4. **Test coverage** for the multi-provider scenario in `PredictPreviewSheetContext.test.tsx`: - Topmost provider fires the failure toast exactly once when both are mounted. - Outer provider becomes active again after the inner unmounts. - Outer (sheet-mode) provider still fires when the inner provider is mounted with `disableBottomSheet`. - `shouldSuppressLegacyOrderFailureToast` correctly tracks the topmost provider across mount/unmount. 5. Added `PredictPreviewSheetProvider` to the Predict barrel (`app/components/UI/Predict/index.ts`) for consistency, and a rationale comment in `MainNavigator.js` explaining why the wrap lives at `HomeTabs` (so a future maintainer doesn't move it back inside a tab). ### Files touched - `app/components/Nav/Main/MainNavigator.js` - `app/components/Nav/Main/MainNavigator.test.tsx` (mock update) - `app/components/UI/Predict/contexts/PredictPreviewSheetContext.tsx` - `app/components/UI/Predict/contexts/PredictPreviewSheetContext.test.tsx` - `app/components/UI/Predict/index.ts` ## **Changelog** CHANGELOG entry: Added in-place buy/sell bottom sheet to Predict market cards on the Explore feed when the `predictBottomSheet` feature flag is enabled. ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: Predict bottom sheet on Explore feed Scenario: open buy sheet from Explore with feature flag ON Given the predictBottomSheet feature flag is enabled And the user is on the Explore tab And the Explore feed is showing Predict market cards When the user taps "Yes" on a Predict market card Then a buy preview bottom sheet opens in place And the sheet is anchored above the bottom tab bar (no clipping at the top or bottom) And the user can swipe the sheet down to dismiss it Scenario: navigation fallback when feature flag is OFF Given the predictBottomSheet feature flag is disabled And the user is on the Explore tab When the user taps "Yes" on a Predict market card Then the app navigates to the full-page bet slip (legacy behavior, unchanged) Scenario: Predict tab behavior is unchanged Given the predictBottomSheet feature flag is enabled And the user is on the Predict tab When the user taps an outcome on a market card Then the buy preview bottom sheet opens in place (existing behavior) And there is exactly one Retry toast if the order subsequently fails Scenario: only the topmost provider fires the failure toast Given the predictBottomSheet feature flag is enabled And the user opened and dismissed a buy sheet from Explore And the user navigated to the Predict tab and opened/dismissed another buy sheet And the user is now on the Predict tab with both sheets dismissed When the active Predict order transitions to a failed state Then the user sees exactly one "Try again" toast (not two) And tapping Retry reopens the most recently used sheet's market context ``` ## **Screenshots/Recordings** ### **Before** <!-- Recording: tapping Yes on an Explore market card navigates to the full-page bet slip (or, with the earlier broken fix, opens a clipped sheet). --> ### **After** <!-- Recording: tapping Yes on an Explore market card opens the bottom sheet in place, anchored above the tab bar, with no clipping. --> https://github.com/user-attachments/assets/6bcb24e9-b81c-4c8f-b193-295440cd5805 ## **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 - [x] I've tested with a power user scenario - [ ] I've instrumented key operations with Sentry traces for production performance metrics > _Performance checks N/A: this PR only repositions an existing React provider higher in the tree and refactors a module-level counter into a registration stack. No new subscriptions/renders on hot paths; the failure-toast effect now does strictly less work in non-active providers._ ## **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 top-level navigation composition and refactors module-scoped toast suppression/dedup logic for Predict order failures; regressions could affect bottom sheet rendering or toast behavior across tabs. > > **Overview** > Enables Predict market cards opened outside the Predict tab (e.g. Explore) to use the in-place Buy/Sell preview bottom sheet by mounting `PredictPreviewSheetProvider` above the home `Tab.Navigator`. > > Refactors `PredictPreviewSheetContext` to handle multiple simultaneously-mounted providers via a registration stack: only the topmost sheet-mode provider can fire the state-driven Retry toast, and legacy order-failure toast suppression now depends on the active provider having remembered buy params (reducing stale suppression). Tests are updated/added to cover multi-provider dedup and the new suppression behavior, and `PredictPreviewSheetProvider` is exported from the Predict barrel. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 51b7817. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [22e0934](22e0934) Co-authored-by: Aslau Mario-Daniel <marioaslau@gmail.com>
…Action cp-7.78.0 (#30545) - chore: New Crowdin Translations by GitHub Action cp-7.78.0 (#30163) Co-authored-by: metamaskbot <metamaskbot@users.noreply.github.com> Co-authored-by: Laurel <153323700+i18nlaurel@users.noreply.github.com> [7d19702](7d19702) Co-authored-by: metamaskbotv2[bot] <214045046+metamaskbotv2[bot]@users.noreply.github.com> Co-authored-by: metamaskbot <metamaskbot@users.noreply.github.com> Co-authored-by: Laurel <153323700+i18nlaurel@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
- chore: update uuid to v14.0.0 (#29224) <!-- 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: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MCWP-557 ## **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** > Major-version bump of `uuid` can change module format/typing and affect any runtime UUID generation paths, especially in React Native/Jest transforms. The code changes are small but dependency behavior changes could surface at build/test time or in places relying on `uuid` options. > > **Overview** > **Upgrades `uuid` from `^8.3.2` to `^14.0.0`** (and updates `yarn.lock` accordingly), removing the now-unneeded npm audit ignore entry for the prior `uuid` advisory. > > Adjusts test infrastructure for the new `uuid` package shape: adds `uuid` to Jest’s `transformIgnorePatterns` allowlist, updates `analyticsId.test.ts`’s `v4` mock typing, and tweaks `accountsControllerTestUtils.ts` to cast the `v4({ random })` input to `Uint8Array` for the updated type expectations. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 608d200. 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: tommasini <46944231+tommasini@users.noreply.github.com> Co-authored-by: tommasini <tommasini15@gmail.com> [8f0d058](8f0d058) Co-authored-by: João Loureiro <175489935+joaoloureirop@users.noreply.github.com> Co-authored-by: tommasini <46944231+tommasini@users.noreply.github.com> Co-authored-by: tommasini <tommasini15@gmail.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** Adding methods to get money account transaction data array to be added to perps / predict transactions. ## **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/CONF-1428 ## **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** NA ## **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** > Adds new exported helpers that compute and encode on-chain calldata for Money Account deposits/withdrawals, including RPC reads for quotes/rates; incorrect encoding or dependency on store/provider availability could impact transaction construction. > > **Overview** > Adds two new public utilities, `getMoneyAccountDepositTransactionsData` and `getMoneyAccountWithdrawTransactionsData`, that return raw calldata arrays for Money Account **deposit** (approve+deposit) and **withdraw** (withdraw+ERC-20 transfer) flows, sourcing vault config/money account from Redux and short-circuiting to `[]` when required state/provider is unavailable. > > Extends `moneyAccountTransactions.test.ts` with coverage for both helpers, including expected hex output shape, correct recipient encoding for withdrawals, and error propagation/early-return behavior when prerequisites are missing. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 4ae58fe. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
# 🚀 v7.78.0 Testing & Release Quality Process Hi Team, As part of our new **MetaMask Release Quality Process**, here’s a quick overview of the key processes, testing strategies, and milestones to ensure a smooth and high-quality deployment. --- ## 📋 Key Processes ### Testing Strategy - **Developer Teams:** Conduct regression and exploratory testing for your functional areas, including automated and manual tests for critical workflows. - **QA Team:** Focus on exploratory testing across the wallet, prioritize high-impact areas, and triage any Sentry errors found during testing. - **Customer Success Team:** Validate new functionalities and provide feedback to support release monitoring. ### GitHub Signoff - Each team must **sign off on the Release Candidate (RC)** via GitHub by the end of the validation timeline (**Tuesday EOD PT**). - Ensure all tests outlined in the Testing Plan are executed, and any identified issues are addressed. ### Issue Resolution - **Resolve all Release Blockers** (Sev0 and Sev1) by **Tuesday EOD PT**. - For unresolved blockers, PRs may be reverted, or feature flags disabled to maintain release quality and timelines. ### Cherry-Picking Criteria - Only **critical fixes** meeting outlined criteria will be cherry-picked. - Developers must ensure these fixes are thoroughly reviewed, tested, and merged by **Tuesday EOD PT**. --- ## 🗓️ Timeline and Milestones 1. **Today (Friday):** Begin Release Candidate validation. 2. **Tuesday EOD PT:** Finalize RC with all fixes and cherry-picks. 3. **Wednesday:** Buffer day for final checks. 4. **Thursday:** Submit release to app stores and begin rollout to 1% of users. 5. **Monday:** Scale deployment to 10%. 6. **Tuesday:** Full rollout to 100%. --- ## ✅ Signoff Checklist Each team is responsible for signing off via GitHub. Use the checkbox below to track signoff completion: # Team sign-off checklist - [x] Accounts - [x] Assets - [x] BE Trade - [x] Bots Team - [x] Card - [x] Confirmations - [x] Core Platform - [x] Delegation - [x] Design System - [x] Earn - [x] Engagement - [x] LavaMoat - [x] Mobile Platform - [x] Mobile UX - [x] Money Movement - [x] Networks - [x] Onboarding - [x] Perps - [x] Predict - [x] Rewards - [x] Social & AI - [x] Swaps and Bridge - [x] team-mobile-delivery - [x] Transactions This process is a major step forward in ensuring release stability and quality. Let’s stay aligned and make this release a success! 🚀 Feel free to reach out if you have questions or need clarification. Many thanks in advance # Reference - Testing plan sheet - https://docs.google.com/spreadsheets/d/1tsoodlAlyvEUpkkcNcbZ4PM9HuC9cEM80RZeoVv5OCQ/edit?gid=404070372#gid=404070372
This PR syncs the stable branch to main for version 7.78.0. *Synchronization Process:* - Fetches the latest changes from the remote repository - Resets the branch to match the stable branch - Attempts to merge changes from main into the branch - Handles merge conflicts if they occur *File Preservation:* Preserves specific files from the stable branch: - CHANGELOG.md - bitrise.yml - android/app/build.gradle - ios/MetaMask.xcodeproj/project.pbxproj - package.json Indicates the next version candidate of main to 7.78.0
…erprint (#30569) ## **Description** Adds `scripts/perps/agentic/lib/compute-cache-fp.js`, an agentic-local native-build fingerprint, and switches the build cache in `bc_fingerprint` to use it instead of `scripts/generate-fingerprint.js`. The project-wide fingerprint script and `fingerprint.config.js` are untouched, so EAS Build, EAS Update, and the OTA fingerprint guard in `nightly-ota-updates.md` keep their existing semantics. **Why:** `--mode auto`'s shared cache (#30565) was keyed off the same fingerprint EAS/OTA depend on, which conservatively hashes build outputs (`ios/build/`, `.gradle/`, IDE `xcuserdata`, env-populated `xcconfig`/`google-services.json`). Those paths diverge per worktree, so two slots on the same commit hashed to different keys and never shared a cached `.app` — the cross-worktree benefit the cache was designed for never landed. The new fingerprint uses the same `extraSources` (so anything that genuinely affects the binary still participates) but ignores the per-worktree noise paths. Verified across three worktrees on the same commit (`c06187a24c`, all on `main`): ``` mm-1: c7fe9e2161109d4ff2e092e068821a2e9984aac5 mm-5: c7fe9e2161109d4ff2e092e068821a2e9984aac5 mm-6: c7fe9e2161109d4ff2e092e068821a2e9984aac5 ``` Identical → next `--mode auto` dispatch on any of these slots will install the cached artifact from whichever slot built first. ## **Changelog** CHANGELOG entry: null ## **Related issues** Follows #30565. ## **Manual testing steps** ```gherkin Feature: Agentic cache fingerprint decoupled from project fingerprint Scenario: Project fingerprint unchanged When I run "node scripts/generate-fingerprint.js" Then the hash is the same as on `main` before this PR And EAS / OTA tools that depend on it are unaffected Scenario: Agentic cache fingerprint ignores build artifacts Given a worktree at any state When I capture the agentic fingerprint And I write a poison file under `ios/build/` And I capture the agentic fingerprint again Then the two fingerprints are identical Scenario: Cross-worktree fingerprint match on same commit Given two worktrees (mm-5, mm-6) at the same git commit When I compute the agentic fingerprint in each Then they match And `--mode auto` on the second slot installs from the cached artifact stored by the first ``` Programmatic check the test suite runs: ```bash bash scripts/perps/agentic/lib/test-build-cache.sh ``` New section "agentic fp ignores build artifacts" verifies the ignorePaths actually take effect. ## **Screenshots/Recordings** N/A — script-only change, no UI surface. ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable (new "agentic fp ignores build artifacts" assertion in `test-build-cache.sh`) - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable (file-level rationale in `compute-cache-fp.js`) - [x] I've applied the right labels on the PR #### Performance checks (if applicable) - [ ] I've tested on Android — N/A (script-only) - [ ] I've tested with a power user scenario — N/A - [ ] I've instrumented key operations with Sentry traces — N/A (developer tooling) ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR. - [ ] I confirm that this PR addresses all acceptance criteria. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes the cache key used for agentic preflight native build reuse; incorrect ignore/hashing boundaries could cause stale or mismatched cached binaries across worktrees. > > **Overview** > Decouples the agentic shared native build cache fingerprint from the repo-wide EAS/OTA fingerprint by introducing `scripts/perps/agentic/lib/compute-cache-fp.js` and switching `bc_fingerprint` to use it. > > The new fingerprint inherits `fingerprint.config.js` `extraSources` (plus explicitly hashes `app/core/InpageBridgeWeb3.js`) while adding `ignorePaths` for per-worktree build outputs (e.g., `ios/build`, Xcode `xcuserdata`, `.gradle`, NDK `.cxx`) so cache artifacts can be shared across parallel worktrees. > > Updates agentic docs to describe the new keying behavior and extends `test-build-cache.sh` with boundary tests ensuring ignored paths don’t shift the fingerprint while binary-affecting sources still do (and adjusts the fast-mode failure test to reference the new script). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 32aa686. 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.
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 : )