feat: sync V2 ramps orders with Backup & Sync

[georgeweiler]

Description

Syncs V2 buy/sell order history through Backup & Sync so orders created on Mobile can appear on other Mobile devices, Extension, and Portfolio for the same SRP/Profile Sync profile. It adds the Buy & sell orders setting, runs order sync after unlock when all identity and privacy gates are enabled, and keeps Activity rows distinct when providers reuse placeholder transaction hashes.

Missing ramps-sync toggle values on upgraded wallets default to enabled, matching new installs.

Companion PRs:

• Core: feat(ramps): sync V2 ramps orders via User Storage core#9474
• Extension: feat: sync V2 ramps orders from User Storage metamask-extension#44367
• Portfolio: https://github.com/consensys-vertical-apps/metamask-portfolio/pull/2053

Implementation notes:

• Delegates the User Storage and authentication messenger actions required by ramps-controller order sync.
• Calls RampsController.syncOrdersWithUserStorage() from useIdentityEffects after unlock.
• Falls back to order ID when txHash is missing or DUMMY_TX_ID, and normalizes createdAt for Activity sorting.
• Pins preview ramps/profile-sync controller builds until the companion Core changes are published.

Changelog

CHANGELOG entry: Added Backup & Sync support for buy and sell order history

Related issues

Refs: MetaMask/core#9474

Manual testing steps

Feature: Buy and sell order history sync

  Scenario: Sync a Mobile ramps order to another client
    Given two clients use the same signed-in SRP profile and environment
    And Backup & Sync and Buy & sell orders are enabled
    When a V2 buy or sell order is completed on Mobile
    And the other client is unlocked
    Then the order appears in the other client's order history

  Scenario: Disable ramps order syncing
    Given Backup & Sync is enabled
    When Buy & sell orders is disabled
    Then ramps orders are not pushed to or pulled from User Storage

Automated coverage includes order-sync gating, controller messenger wiring, Activity adapter fallback IDs, settings UI, and controller initialization.

Screenshots/Recordings

N/A — the change adds another row using the existing Backup & Sync settings-toggle component and does not introduce a new layout or interaction pattern.

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
• I've tested with a power user scenario
• I've instrumented key operations with Sentry traces for production performance metrics

The performance items were assessed as not applicable to this profile-sync integration; CI performance checks remain non-blocking.

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.

---

Note

Medium Risk
Touches Backup & Sync / User Storage for financial order history and expands RampsController messenger permissions, with preview controller package pins until Core publishes.

Overview
Enables Backup & Sync for V2 buy/sell order history so Mobile orders can appear on other signed-in clients sharing the same profile.

Adds a Buy & sell orders toggle in Backup & Sync settings, a useRampsOrderSyncing hook that calls RampsController.syncOrdersWithUserStorage() when identity/privacy gates pass, and wires that into useIdentityEffects. Missing isRampsSyncingEnabled values default to enabled on upgrade.

Delegates User Storage and auth messenger actions to RampsController, tracks order-sync error situations, and requires a non-empty chainId when registering precreated orders. Also treats placeholder hashes like DUMMY_TX_ID as invalid Activity keys and normalizes createdAt timestamps so synced orders stay distinct and sortable.

Pins preview @metamask/ramps-controller / @metamask/profile-sync-controller builds until the companion Core release lands.

^{Reviewed by Cursor Bugbot for commit 0609d30. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

🧪 Flaky unit test detection

Run history flaky detection

View recent run history

Historical failure rate is a hint, not proof — review each suggestion in context. See the flaky-test-detection skill for the full pattern reference and manual audit workflow.

Failures / runs sampled per window:

File	7d	15d	30d
app/components/UI/Identity/BackupAndSyncFeaturesToggles/BackupAndSyncFeaturesToggles.test.tsx	0/86	0/165	0/344
app/util/identity/hooks/useRampsOrderSyncing/useRampsOrderSyncing.test.tsx	0/86	0/165	0/344
tests/smoke-appium/wallet/incoming-transactions.spec.ts	0/86	0/165	0/344

AI-detected flaky patterns

app/components/UI/Identity/BackupAndSyncFeaturesToggles/BackupAndSyncFeaturesToggles.test.tsx

• J1 — Missing act() await on async state update (high)
  • The act() call is not awaited, but the onValueChange handler triggers InteractionManager.runAfterInteractions, which is mocked as async (callback) => callback(). Because act() is not awaited, the async microtask chain from the mocked InteractionManager may not be fully flushed before the waitFor polling begins. Under load or in a slow CI environment this can cause mockTrackEvent to be called after waitFor has already timed out, producing an intermittent failure. The same pattern appears in the 'enables a feature when toggling the switch on' test (line ~120). Both act() calls should be awaited so React can flush all pending async state updates before assertions run.
  • Suggested fix in app/components/UI/Identity/BackupAndSyncFeaturesToggles/BackupAndSyncFeaturesToggles.test.tsx:95:

    -    act(() => {
    -      fireEvent(switchElement, 'onValueChange', true);
    -    });
    -
    -    const expectedEvent = AnalyticsEventBuilder.createEventBuilder(
    -      MetaMetricsEvents.SETTINGS_UPDATED,
    -    )
    -      .addProperties({
    -        settings_group: 'backup_and_sync',
    -        settings_type: featureSection.id,
    -        old_value: false,
    -        new_value: true,
    -      })
    -      .build();
    -
    -    await waitFor(() => {
    -      expect(mockTrackEvent).toHaveBeenCalledTimes(1);
    -      expect(mockTrackEvent).toHaveBeenCalledWith(expectedEvent);
    -    });
    +    await act(async () => {
    +      fireEvent(switchElement, 'onValueChange', true);
    +    });
    +
    +    const expectedEvent = AnalyticsEventBuilder.createEventBuilder(
    +      MetaMetricsEvents.SETTINGS_UPDATED,
    +    )
    +      .addProperties({
    +        settings_group: 'backup_and_sync',
    +        settings_type: featureSection.id,
    +        old_value: false,
    +        new_value: true,
    +      })
    +      .build();
    +
    +    await waitFor(() => {
    +      expect(mockTrackEvent).toHaveBeenCalledTimes(1);
    +      expect(mockTrackEvent).toHaveBeenCalledWith(expectedEvent);
    +    });

• J1 — Missing act() await on async state update (high)
  • Same issue as the previous test: act() is not awaited while the handler it triggers is async (via the mocked InteractionManager.runAfterInteractions). The async callback chain may not be settled before waitFor starts polling, causing mockSetIsBackupAndSyncFeatureEnabled to be called after the waitFor timeout in a slow CI run.
  • Suggested fix in app/components/UI/Identity/BackupAndSyncFeaturesToggles/BackupAndSyncFeaturesToggles.test.tsx:120:

    -    act(() => {
    -      fireEvent(switchElement, 'onValueChange', true);
    -    });
    -
    -    await waitFor(() => {
    -      expect(mockSetIsBackupAndSyncFeatureEnabled).toHaveBeenCalledWith(
    -        BACKUPANDSYNC_FEATURES[featureSection.backupAndSyncfeatureKey],
    -        true,
    -      );
    -    });
    +    await act(async () => {
    +      fireEvent(switchElement, 'onValueChange', true);
    +    });
    +
    +    await waitFor(() => {
    +      expect(mockSetIsBackupAndSyncFeatureEnabled).toHaveBeenCalledWith(
    +        BACKUPANDSYNC_FEATURES[featureSection.backupAndSyncfeatureKey],
    +        true,
    +      );
    +    });

app/util/identity/hooks/useRampsOrderSyncing/useRampsOrderSyncing.test.tsx

• J3 — Missing jest.clearAllMocks() between tests (high)
  • The useShouldDispatchRampsOrderSyncing describe block has no beforeEach with jest.clearAllMocks(). The module-level mockSyncOrdersWithUserStorage jest.fn() accumulates call history across all tests in this suite. If a future test in this block (or a test added later) checks call counts on mockSyncOrdersWithUserStorage, it will see stale counts from previous tests. Additionally, the useRampsOrderSyncing describe block calls jest.clearAllMocks() inside the arrangeAndAct helper rather than in a beforeEach, which means if a test throws before reaching arrangeAndAct, the mock state is not cleaned up for the next test. A top-level beforeEach(() => { jest.clearAllMocks(); }) would make isolation robust.
  • Suggested fix in app/util/identity/hooks/useRampsOrderSyncing/useRampsOrderSyncing.test.tsx:62:

    -describe('useShouldDispatchRampsOrderSyncing()', () => {
    -  const testCases = (() => {
    -    const properties = [
    -      'isSignedIn',
    -      'isBackupAndSyncEnabled',
    -      'isRampsSyncingEnabled',
    -      'isUnlocked',
    -      'useExternalServices',
    -      'completedOnboarding',
    -    ] as const;
    -    const baseState = {
    -      isSignedIn: true,
    -      isBackupAndSyncEnabled: true,
    -      isRampsSyncingEnabled: true,
    -      isUnlocked: true,
    -      useExternalServices: true,
    -      completedOnboarding: true,
    -    };
    -
    -    const failureStateCases: {
    -      state: ArrangeMocksMetamaskStateOverrides;
    -      failingField: string;
    -    }[] = [];
    -
    -    properties.forEach((property) => {
    -      const state = { ...baseState, [property]: false };
    -      failureStateCases.push({ state, failingField: property });
    -    });
    -
    -    const successTestCase = { state: baseState };
    -
    -    return { successTestCase, failureStateCases };
    -  })();
    -
    -  it('returns true if all conditions are met', () => {
    +describe('useShouldDispatchRampsOrderSyncing()', () => {
    +  beforeEach(() => {
    +    jest.clearAllMocks();
    +  });
    +
    +  const testCases = (() => {
    +    // ... rest of testCases definition unchanged
    +  })();
    +
    +  it('returns true if all conditions are met', () => {

• J9 — Module-level mutable let binding not reset in beforeEach (high)
  • The module-level mockSyncOrdersWithUserStorage jest.fn() is never reset between tests in the useShouldDispatchRampsOrderSyncing suite. The useRampsOrderSyncing suite calls jest.clearAllMocks() inside arrangeAndAct, but this is not guaranteed to run before every test (e.g. if a test throws before calling arrangeAndAct). If mockSyncOrdersWithUserStorage is given a resolved/rejected value in one test (e.g. via mockResolvedValue), that implementation bleeds into subsequent tests. A beforeEach(() => { mockSyncOrdersWithUserStorage.mockReset(); }) at the top of the file would prevent this.
  • Suggested fix in app/util/identity/hooks/useRampsOrderSyncing/useRampsOrderSyncing.test.tsx:8:

    -const mockSyncOrdersWithUserStorage = jest.fn<Promise<unknown>, []>();
    -
    -jest.mock('../../../../core/Engine', () => ({
    -  __esModule: true,
    -  default: {
    -    context: {
    -      RampsController: {
    -        syncOrdersWithUserStorage: jest.fn(() =>
    -          mockSyncOrdersWithUserStorage(),
    -        ),
    -      },
    -    },
    -  },
    -}));
    +const mockSyncOrdersWithUserStorage = jest.fn<Promise<unknown>, []>();
    +
    +beforeEach(() => {
    +  mockSyncOrdersWithUserStorage.mockReset();
    +});
    +
    +jest.mock('../../../../core/Engine', () => ({
    +  __esModule: true,
    +  default: {
    +    context: {
    +      RampsController: {
    +        syncOrdersWithUserStorage: jest.fn(() =>
    +          mockSyncOrdersWithUserStorage(),
    +        ),
    +      },
    +    },
    +  },
    +}));

tests/smoke-appium/wallet/incoming-transactions.spec.ts

• J7 — Non-deterministic data: live Date.now() / new Date() (medium)
  • Both RESPONSE_STANDARD_MOCK and RESPONSE_STANDARD_2_MOCK use new Date().toISOString() for their timestamp fields. These are evaluated at module load time, so the timestamp changes on every test run. If the mock API server or the app under test uses the timestamp for sorting, deduplication, or display (e.g. showing a relative time like 'just now' vs '1 minute ago'), the rendered text could differ between runs, causing assertions like Assertions.expectTextDisplayed('Received ETH') to fail intermittently when the UI renders a time-dependent label. Pinning to a fixed ISO string eliminates this source of non-determinism.
  • Suggested fix in tests/smoke-appium/wallet/incoming-transactions.spec.ts:57:

    -const RESPONSE_STANDARD_MOCK = {
    -  hash: '0x123456',
    -  timestamp: new Date().toISOString(),
    -  chainId: 1,
    -  blockNumber: 1,
    -  blockHash: '0x2',
    -  gas: 1,
    -  gasUsed: 1,
    -  gasPrice: '1',
    -  effectiveGasPrice: '1',
    -  nonce: 1,
    -  cumulativeGasUsed: 1,
    -  methodId: null,
    -  value: '1230000000000000000',
    -  to: DEFAULT_FIXTURE_ACCOUNT,
    -  from: TRUSTED_INCOMING_SENDER_CHECKSUM,
    -  isError: false,
    -  valueTransfers: [],
    -};
    -
    -const RESPONSE_STANDARD_2_MOCK = {
    -  ...RESPONSE_STANDARD_MOCK,
    -  timestamp: new Date().toISOString(),
    -  hash: '0x2',
    -  value: '2340000000000000000',
    -};
    +const RESPONSE_STANDARD_MOCK = {
    +  hash: '0x123456',
    +  timestamp: '2024-01-01T12:00:00.000Z',
    +  chainId: 1,
    +  blockNumber: 1,
    +  blockHash: '0x2',
    +  gas: 1,
    +  gasUsed: 1,
    +  gasPrice: '1',
    +  effectiveGasPrice: '1',
    +  nonce: 1,
    +  cumulativeGasUsed: 1,
    +  methodId: null,
    +  value: '1230000000000000000',
    +  to: DEFAULT_FIXTURE_ACCOUNT,
    +  from: TRUSTED_INCOMING_SENDER_CHECKSUM,
    +  isError: false,
    +  valueTransfers: [],
    +};
    +
    +const RESPONSE_STANDARD_2_MOCK = {
    +  ...RESPONSE_STANDARD_MOCK,
    +  timestamp: '2024-01-01T12:01:00.000Z',
    +  hash: '0x2',
    +  value: '2340000000000000000',
    +};

This check is informational only and does not block merging.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​metamask-previews/​ramps-controller@​20.0.0-preview-8c482076b

View full report

[socket-security]

All alerts resolved. Learn more about Socket for GitHub.

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

Ignoring alerts on:

• npm/@metamask-previews/ramps-controller@20.0.0-preview-8c482076b

View full report

[github-actions]

⚠️ Performance Test Results

ℹ️ Performance test results are currently non-blocking and will not block this PR.

❌ 4 tests failed · 8 tests · 1 device

📱 Devices tested (1)

Android: Google Pixel 8 Pro (v14.0)

❌ Failed Tests (4)

🔬 App profiling vs main is included under each failed scenario that has a prior baseline.

@metamask-onboarding-team

Fresh SRP wallet creation performance

Platform	Device	Reason	Recording
Android	Google Pixel 8 Pro (v14.0)	Quality gates exceeded	📹 Watch

🔬 App profiling check · Current run 31520857793 · Baseline (last run on main (scenario also failing)) run 30897750395 @ 67486d2

⚠️ No green baseline on main — comparing against the latest usable profiling.

Summary: ⚠️ 5 metrics over +10%: CPU avg (+4.51 (+75.8%)), CPU max (+2.68 (+14%)), Memory max (+116.56 (+16.1%)), Slow frames (+4.31 (+171.7%)), Critical issues (+1 (+100%))

ℹ️ API calls unavailable: Network logs API error: Bad Request

Full metric table (+10% variance rules)

Disclaimer — allowed variance: a +10% margin over the baseline is permitted.

• If Current <= Baseline + 10%, treated as acceptable noise.
• If Current > Baseline + 10%, Current and variance % are highlighted with ⚠️.

Metric	Baseline	Current	Δ
CPU avg	5.95%	10.46%	+4.51 (+75.8%) ⚠️
CPU max	19.17%	21.85%	+2.68 (+14%) ⚠️
Memory avg	586.2 MB	613.03 MB	+26.83 (+4.6%)
Memory max	722.61 MB	839.17 MB	+116.56 (+16.1%) ⚠️
Slow frames	2.51%	6.82%	+4.31 (+171.7%) ⚠️
Frozen frames	0%	0%	0 (0%)
ANRs	0	0	0 (0%)
Issues	2	2	0 (0%)
Critical issues	1	2	+1 (+100%) ⚠️
App size	328.67 MB	329.01 MB	+0.34 (+0.1%)

Account creation after fresh install

Platform	Device	Reason	Recording
Android	Google Pixel 8 Pro (v14.0)	Quality gates exceeded	📹 Watch

🔬 App profiling check · Current run 31520857793 · Baseline (last run on main (scenario also failing)) run 30897750395 @ 67486d2

⚠️ No green baseline on main — comparing against the latest usable profiling.

Summary: ⚠️ 6 metrics over +10%: CPU max (+3.83 (+19.7%)), Memory avg (+276.46 (+56.4%)), Memory max (+313.1 (+55.1%)), Slow frames (+6.18 (+199.4%)), Issues (+1 (+100%)), Critical issues (+1 (+100%))

ℹ️ API calls unavailable: Network logs API error: Bad Request

Full metric table (+10% variance rules)

Disclaimer — allowed variance: a +10% margin over the baseline is permitted.

• If Current <= Baseline + 10%, treated as acceptable noise.
• If Current > Baseline + 10%, Current and variance % are highlighted with ⚠️.

Metric	Baseline	Current	Δ
CPU avg	13.86%	6.25%	-7.61 (-54.9%)
CPU max	19.43%	23.26%	+3.83 (+19.7%) ⚠️
Memory avg	490.61 MB	767.07 MB	+276.46 (+56.4%) ⚠️
Memory max	568.32 MB	881.42 MB	+313.1 (+55.1%) ⚠️
Slow frames	3.1%	9.28%	+6.18 (+199.4%) ⚠️
Frozen frames	0%	0%	0 (0%)
ANRs	0	0	0 (0%)
Issues	1	2	+1 (+100%) ⚠️
Critical issues	1	2	+1 (+100%) ⚠️
App size	328.67 MB	329.01 MB	+0.34 (+0.1%)

Seedless Onboarding: Apple Login New User

Platform	Device	Reason	Recording
Android	Google Pixel 8 Pro (v14.0)	Quality gates exceeded	📹 Watch

🔬 App profiling check · Current run 31520857793 · Baseline (last run on main (scenario also failing)) run 30897750395 @ 67486d2

⚠️ No green baseline on main — comparing against the latest usable profiling.

Summary: ⚠️ 5 metrics over +10%: CPU max (+6.15 (+32.8%)), Memory max (+284.56 (+47.1%)), Slow frames (+11.7 (+383.6%)), Issues (+1 (+100%)), Critical issues (+1 (+100%))

ℹ️ API calls unavailable: Network logs API error: Bad Request

Full metric table (+10% variance rules)

Disclaimer — allowed variance: a +10% margin over the baseline is permitted.

• If Current <= Baseline + 10%, treated as acceptable noise.
• If Current > Baseline + 10%, Current and variance % are highlighted with ⚠️.

Metric	Baseline	Current	Δ
CPU avg	13.93%	6.08%	-7.85 (-56.3%)
CPU max	18.74%	24.89%	+6.15 (+32.8%) ⚠️
Memory avg	540.28 MB	593.86 MB	+53.58 (+9.9%)
Memory max	604.4 MB	888.96 MB	+284.56 (+47.1%) ⚠️
Slow frames	3.05%	14.75%	+11.7 (+383.6%) ⚠️
Frozen frames	0%	0%	0 (0%)
ANRs	0	0	0 (0%)
Issues	1	2	+1 (+100%) ⚠️
Critical issues	1	2	+1 (+100%) ⚠️
App size	328.67 MB	329.01 MB	+0.34 (+0.1%)

Seedless Onboarding: Telegram Login New User

Platform	Device	Reason	Recording
Android	Google Pixel 8 Pro (v14.0)	Timed out	—

✅ Passed Tests (4)

Test	Platform	Device	Duration	Team	Recording
Measure Cold Start To Onboarding Screen	Android	Google Pixel 8 Pro (v14.0)	3.63s	@metamask-mobile-platform	📹 Watch
Onboarding Import SRP with +50 accounts, SRP 3	Android	Google Pixel 8 Pro (v14.0)	7.50s	@metamask-onboarding-team	📹 Watch
Perps open position and close it	Android	Google Pixel 8 Pro (v14.0)	25.84s	@mm-perps-engineering-team	📹 Watch
Seedless Onboarding: Google Login New User	Android	Google Pixel 8 Pro (v14.0)	11.46s	@metamask-onboarding-team	📹 Watch

---

Branch: feat/ramps-order-syncing · Build: E2E · Commit: 22125bc · View full run

[georgeweiler]

@SocketSecurity ignore npm/@metamask-previews/ramps-controller@20.0.0-preview-8c482076b

Reviewed the preview package's order-sync feature: network access is expected because syncOrdersWithUserStorage reads and writes encrypted ramps orders through the MetaMask User Storage service. The package is the companion Core preview pinned for this PR.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit cc82603. Configure here.}

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeAccounts, SmokeConfirmations, SmokeNetworkAbstractions, SmokeNetworkExpansion, SmokeSwap, SmokeStake, SmokeWalletPlatform, SmokeMoney, SmokePerps, SmokeMultiChainAPI, SmokePredictions, SmokeSeedlessOnboarding, SmokeBrowser, SmokeSnaps, SmokeMMConnect
• Selected Performance tags: None (no tests recommended)
• Risk Level: high
• AI Confidence: 100%

click to see 🤖 AI reasoning details

E2E Test Selection:
Hard rule (controller-version-update): @MetaMask controller package version updated in package.json: @metamask/ramps-controller, @metamask/profile-sync-controller, @metamask/assets-controller@npm:^13.1.1, @metamask/ramps-controller@^20.0.0. Running all tests.

Performance Test Selection:
No performance-sensitive code paths were changed. The changes are focused on: (1) a new ramps order syncing feature in identity hooks, (2) a RampsController upgrade, (3) a Checkout bug fix requiring network for order registration, and (4) test infrastructure updates. None of these changes affect app launch, login, onboarding, account list rendering, asset loading, swap execution timing, or other performance-measured flows. The new useRampsOrderSyncing hook runs asynchronously in the background and would not measurably impact any of the defined performance test scenarios.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
94.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud