Skip to content

[pull] main from MetaMask:main#780

Merged
pull[bot] merged 75 commits into
Reality2byte:mainfrom
MetaMask:main
May 22, 2026
Merged

[pull] main from MetaMask:main#780
pull[bot] merged 75 commits into
Reality2byte:mainfrom
MetaMask:main

Conversation

@pull
Copy link
Copy Markdown

@pull pull Bot commented May 22, 2026

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 : )

runway-github Bot and others added 30 commits May 15, 2026 10:46
…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 -->
metamaskbot and others added 27 commits May 21, 2026 08:05
…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 -->
@pull pull Bot locked and limited conversation to collaborators May 22, 2026
@pull pull Bot added the ⤵️ pull label May 22, 2026
@pull pull Bot merged commit 65cbeec into Reality2byte:main May 22, 2026
0 of 2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants