Description

Tier 3 of MMQA-1364 (allowlist reduction), scoped to the signature-insights endpoint only. NFT API entries (/users/.../tokens, /collections, /explore/sites, prod/dev/uat hosts) are deferred to follow-up tickets in the same tier.

Why this response shape. The SDK's own decodeSignature (@metamask/signature-controller/utils/decoding-api) returns this exact shape (type: 'UNSUPPORTED_SIGNATURE') when the signature method is anything other than SignTypedDataV3/V4. The wallet's TypedSignV3V4Simulation (app/components/Views/confirmations/components/info/typed-sign-v3v4/simulation/simulation.tsx:18-22) checks decodingData?.error and falls through to either the permit fallback or the "simulation unavailable" placeholder in DecodedSimulation. Returning the same shape keeps the wallet on a known-graceful code path with no errors logged.

Why regex, not exact URLs. Same rationale as Tier 2: covers any future chainId without re-introducing live requests when a new chain is added to default fixtures. Sanity-checked against the 3 chainIds in the previous allowlist (0x1, 0x539, 0xaa36a7), plus mixed-case hex, plus rejection cases (non-hex, extra query params, different host).

Spec audit. Grepped E2E specs that exercise SignTypedDataV3/V4:

• tests/smoke/confirmations/signatures/signatures-typed.spec.ts — V3/V4 cases on chainId=0x539. Will trigger the mock. Assertions are on row components (AccountNetwork, Message, OriginInfo); no asserts on decoded simulation content. Safe.
• tests/smoke/confirmations/signatures/alert-system.spec.ts — V1 only on Sepolia (0xaa36a7). V1 doesn't call the API per SDK code. Unrelated.
• Snap and api-spec tests — peripheral, no decoded-content asserts.

No spec asserts on decodingData.stateChanges rendering, so the default mock is safe across the codebase.

Files changed

• tests/api-mocking/mock-responses/defaults/signature-insights.ts — new
• tests/api-mocking/mock-responses/defaults/index.ts — import + spread into DEFAULT_MOCKS.POST
• tests/api-mocking/mock-e2e-allowlist.ts — removed 3 entries

Out of scope

• NFT API entries (/users/tokens, /collections, /explore/sites, prod/dev/uat hosts) — deferred to separate Tier 3 tickets

Changelog

CHANGELOG entry: null

Related issues

MMQA-1779 — parent epic MMQA-1364

Manual testing steps

Feature: signature-insights default mock for E2E tests

  Scenario: SignTypedDataV4 confirmation does not hit live signature-insights
    Given the E2E mock server is running with default mocks loaded
    And a dapp is connected on any EVM chain
    When the user triggers an eth_signTypedData_v4 request
    Then mockttp returns the UNSUPPORTED_SIGNATURE error shape
    And the wallet renders the "simulation unavailable" placeholder
    And validateLiveRequests() does not record a live request to signature-insights

Screenshots/Recordings

Before

Every eth_signTypedData_v3 / _v4 exercised by smoke specs fired a live POST to signature-insights.api.cx.metamask.io. The 3 chainId-specific allowlist entries silenced validateLiveRequests(), but the call still reached the live decoding API and whatever it returned was rendered as decoded state changes in the wallet UI.

After

mockttp intercepts the POST and returns the SDK's own UNSUPPORTED_SIGNATURE error shape. The wallet's TypedSignV3V4Simulation checks decodingData?.error and falls through to the confirm.simulation.unavailable placeholder in DecodedSimulation — the same path the wallet takes when the API errors live. Spec assertions on row components (origin, message, account/network) continue to pass. validateLiveRequests() records zero leaks for signature-insights.

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

For performance guidelines and tooling, see the Performance Guide.

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.