Recipe Coverage

Recipe skipped — CDP offline, code review only.

Overall recipe coverage: 0/2 ACs PROVEN
Untestable: AC1, AC2 — CDP offline, code review only

Warning: Coverage escalation: AC1, AC2 not proven on device.
Reason: CDP offline in this slot — no live device validation possible.
Human reviewer must validate manually before merging.

Prior Reviews

No prior reviews.

Acceptance Criteria Validation

Code Quality

• Pattern adherence: Follows codebase conventions — Set-based keyring detection, dedicated utility file with tests, it.each for parameterized tests
• Complexity: Appropriate — minimal helper function, no over-engineering
• Type safety: Good — uses HyperLiquidAbstractionMode type, no as any casts added
• Error handling: N/A — the helper is a pure predicate with no error paths
• Anti-pattern findings: No magic strings (keyring types are in a named constant set), no controller portability violations, no missing event tracking

Fix Quality

• Best approach: This is the correct fix. Extracting shouldDeferUnifiedAccountSetup to a shared utility is cleaner than inlining the expanded condition. The Set-based approach for MIGRATABLE_ABSTRACTION_MODES mirrors the existing HARDWARE_KEYRING_TYPES pattern.
• Would not ship: Nothing — this is ready to ship.
• Test quality: Tests assert the right behavior — all 3 migratable modes are tested for both defer and allow paths, plus 2 non-migratable modes (unifiedAccount, portfolioMargin) and undefined. The it.each in HyperLiquidProvider.test.ts was correctly expanded from a single dexAbstraction case to all 3 modes. Tests would fail if the fix is reverted.
• Brittleness: Low risk. MIGRATABLE_ABSTRACTION_MODES in the utility and the explicit guard in HyperLiquidProvider.ts (line 747-751) enumerate the same modes — if a new mode is added to one but not the other, behavior would be inconsistent. This is a minor maintenance concern, not a blocker.
• Core sync divergence: Mobile's HARDWARE_KEYRING_TYPES now has 5 entries (added Trezor, OneKey, Lattice) but core/packages/perps-controller/src/services/HyperLiquidWalletService.ts still only lists Ledger + QR. The file comment says it's "inlined to keep this service portable between mobile and the core monorepo" — the two are now out of sync. A matching core PR should follow.

Live Validation

• Recipe: skipped (CDP offline)
• Result: SKIPPED
• Video: skipped (CDP offline)
• Native changes: none
• Metro errors: Circuit breaker warnings (pre-existing, unrelated to PR)
• Log monitoring: Metro logs checked, no PR-related errors

Correctness

• Diff vs stated goal: Aligned — defers all signing-backed migrations for hardware wallets, not just dexAbstraction
• Edge cases: Covered — undefined mode (new account with no abstraction data) correctly returns false (no deferral). portfolioMargin and unifiedAccount are handled upstream before reaching the defer check.
• Race conditions: None introduced — the in-flight lock mechanism is unchanged
• Backward compatibility: Preserved — software wallet behavior unchanged; hardware wallets get stricter deferral (more conservative, not breaking)

Static Analysis

• lint:tsc: PASS — 0 errors
• Tests: 371/371 pass (3 suites: HyperLiquidProvider, HyperLiquidWalletService, hyperLiquidAbstraction)

Architecture & Domain

• The new hyperLiquidAbstraction.ts utility is well-placed in controllers/perps/utils/ — portable, testable, no mobile imports.
• Hardware keyring type strings are inlined (mirroring @metamask/keyring-controller) to keep the service portable between mobile and core monorepo, which aligns with the existing comment in HyperLiquidWalletService.ts:17.
• Note: HyperLiquidProvider.ts (8,633 lines) and its test file (10,751 lines) are well above the 2,500-line guardrail. This PR is net-positive (extracts logic out) but the files remain cautionary examples of unchecked growth.

Risk Assessment

• LOW — Conservative behavioral change that defers more operations for hardware wallets. Software wallet path is unchanged. Comprehensive test coverage. No new UI, no state schema changes.

Recommended Action

APPROVE

Clean, well-tested fix that achieves its stated goal. No issues found that would block merge. Human reviewer should validate the hardware wallet prompting behavior on a physical device since CDP was offline for this review.

• [suggestion] app/controllers/perps/services/HyperLiquidWalletService.ts:19: Mobile now lists 5 hardware keyring types but core/packages/perps-controller/src/services/HyperLiquidWalletService.ts still only has Ledger Hardware and QR Hardware Wallet Device. The comment on line 17 says this is 'inlined to keep this service portable between mobile and the core monorepo' — but they've now diverged. Should this change be mirrored in core to stay in sync?
• [suggestion] app/controllers/perps/utils/hyperLiquidAbstraction.ts:3: The MIGRATABLE_ABSTRACTION_MODES set here (dexAbstraction, default, disabled) must stay in sync with the explicit guard in HyperLiquidProvider.ts:747-751 that bails on unknown modes. Consider adding a comment cross-referencing each location, or extracting the known-mode list to a shared constant so they can't drift apart.

E2E Test Selection:
The changes in this PR are focused on the HyperLiquid Perps trading infrastructure:

1. HyperLiquidWalletService.ts (behavioral change): Adds Trezor Hardware, OneKey Hardware, and Lattice Hardware to the HARDWARE_KEYRING_TYPES set. Previously only Ledger and QR hardware wallets were recognized. This means these hardware wallet users will now correctly be deferred from signing prompts when browsing Perps (matching the existing Ledger/QR behavior). This is a meaningful behavioral change for hardware wallet users.

2. hyperLiquidAbstraction.ts (new utility): Extracts shouldDeferUnifiedAccountSetup() into a standalone utility. The logic is also broadened — previously only dexAbstraction mode was deferred; now default and disabled modes are also deferred when allowUserSigning=false. This changes the deferral behavior for software wallet users in default/disabled abstraction modes.

3. HyperLiquidProvider.ts (refactor + behavioral): Uses the new utility, which changes the deferral condition from currentMode === 'dexAbstraction' && !allowUserSigning to shouldDeferUnifiedAccountSetup(currentMode, allowUserSigning) — covering more modes.

4. TradingReadinessCache.ts: Comment-only change, no behavioral impact.

Tag Selection Rationale:

• SmokePerps: Directly tests perpetuals trading functionality including Add Funds flow, balance verification, and the Perps interface — all directly affected by these changes to hardware wallet detection and unified account setup deferral.
• SmokeWalletPlatform: Required per SmokePerps tag description since Perps is a section inside the Trending tab. Changes to Perps views affect Trending.
• SmokeConfirmations: Required per SmokePerps tag description since Add Funds deposits are on-chain transactions that go through the confirmation flow.

The changes do not affect: browser, accounts, identity, network management, swaps, staking, money/ramps, snaps, or multi-chain API functionality.

Performance Test Selection:
The changes affect the HyperLiquid Perps provider's initialization and trading readiness flow, specifically the unified account setup deferral logic and hardware wallet detection. The shouldDeferUnifiedAccountSetup function now covers more abstraction modes, which could affect the timing of the Perps initialization sequence and how quickly the Perps interface becomes ready for trading. The @PerformancePreps tag covers perps market loading, position management, add funds flow, and order execution — all of which depend on the initialization path modified in this PR.