Description

Unified Buy V2 (UB2) is always on in production (TRAM-3559). This PR removes the rampsUnifiedBuyV2 remote feature flag and all V1 fallback paths, deletes the legacy Deposit navigator stack, consolidates remaining Deposit/ code under Ramp/, and removes @consensys/native-ramps-sdk (legacy deposit orders no longer poll; they display last-known Redux state).

Key changes:

• Delete flag selectors/hooks and always initialize RampsController at Engine startup
• Route all buy entry points through unified V2 (BuildQuote / TokenSelection)
• Remove duplicate Deposit screens from navigation; use Ramp/Views/* only
• Move shared deposit utils, hooks, components, and types into Ramp/
• Replace SDK types with Ramp/types/legacyDeposit.ts; stop legacy order polling
• Update unit tests, E2E specs, feature-flag registry, and Engine background-state fixture

Review note

This is an intentionally large cleanup PR . It removes the UB2 flag and the legacy buy/Deposit stack so Ramps runs on a single V2 path.

Why one PR: Flag removal and legacy stack removal need to land together. A split merge leaves a dual-stack middle state (two routing models, two test matrices, two places for bugs). We are finishing the UB2 rollout in one atomic step.

Why this matters:

• One buy UX — Design and PM align on V2 only; no more updating unused legacy screens/components "just in case."
• Smaller maintenance surface — Fewer routes, page objects, mocks, and feature-flag branches for every Ramps change.
• Less bug surface — No "V2 flag on but V1 path still reachable" or deeplink/routing drift between stacks.
• Bundle / codebase weight — Meaningful deletion of dead paths (net reduction in code we ship and support).
• Faster follow-up work — Provider, deeplink, KYC, and analytics changes touch one stack, not two.

Expected user impact: Low for users already on UB2 (production default). Behavioral change is removing the unused fork, not redesigning buy.

Suggested review focus (if time is limited):

1. Buy/deeplink routing (handleRampUrl, ramp routes)
2. Remaining legacy entry points after flag removal
3. Test/E2E alignment (V1 assumptions removed)
4. Order/details paths affected by Deposit → Ramp consolidation

Review on a PR this size is appreciated — happy to walk through structure if useful.

Changelog

CHANGELOG entry: null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/TRAM-3559

Manual testing steps

Feature: Unified Buy V2 always enabled

  Scenario: user opens buy from wallet fund menu
    Given the app is unlocked on mainnet with a funded account
    When user taps Buy from the wallet fund menu
    Then BuildQuote or TokenSelection opens via the unified buy flow
    And no legacy aggregator buy fallback is shown

  Scenario: legacy deposit order displays without live polling
    Given a persisted legacy DEPOSIT fiat order exists in order history
    When user opens that order's details
    Then order details render from last-known Redux state

  Scenario: buy deeplink routes to unified flow
    Given the app is unlocked
    When user opens a ramps buy deeplink
    Then navigation lands on the unified buy flow (not legacy Deposit stack)

Screenshots/Recordings

N/A — internal cleanup and dead-code removal; no intentional user-visible UI change.

Before

N/A

After

All testing has been done on RC builds generated from this branch, using real funds in production. Build tested: 8.1.0 (5631).

Transak Order

Coinbase Order

Moonpay Order

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• 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 format if applicable
• I've applied the right labels on the PR (see labeling guidelines). 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 to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.