[Bug]: Ledger: If blind signing is disabled, Reconnect from the beginning workflow fails

[Unik0rnMaggie]

Describe the bug

While signing a transaction or swapping, if Ledger device is disconnected while blind signing is disabled, the Reconnect from the beginning workflow fails with error:

Device not detected. Please check the previous steps and try again.

This does not happen if blind signing is enabled.

Expected behavior

Reconnect from the beginning flow to display info that blind signing is disabled

Screenshots/Recordings

Screen.Recording.2026-06-16.at.12.16.17.mov

Screen.Recording.2026-06-16.at.12.22.56.mov

Steps to reproduce

1. Connect Ledger device
2. Disable blind signing
3. Disconnect Ledger device by removing USB cable
4. Start Send or Swap Flow
5. Click Connect Ledger in the transaction confirmation
6. Click Reconnect from the beginning
7. Follow the instructions on the screen: reconnect USB cable, unlock device, open Ethereum app
8. Click Connect
9. Notice message Device not detected. Please check the previous steps and try again.
10. Enable blind signing
11. Click Connect
12. Notice it succeeds

Error messages or log output

Where was this bug found?

Internal release testing

Version

13.36.0

Build type

None

Browser

Chrome

Operating system

MacOS

Hardware wallet

Ledger

Additional context

No response

Severity

No response

[mm-token-exchange-service]

Triage Agent -- Classification

Severity: Sev1 (confidence: 0.90) ✅

This blocks the Ledger reconnection workflow entirely when blind signing is disabled, which is a common and recommended security configuration. Users cannot complete transactions or swaps with their Ledger device after a disconnection unless they enable blind signing (which is a security trade-off). This is a major feature broken for a significant user segment with a workaround that compromises security posture.

Size: size-S (confidence: 0.80) ⚠️ Advisory

The root cause is likely in the ensureDeviceReady call during the reconnection flow, where requireBlindSigning defaults to true. The fix likely involves passing requireBlindSigning: false (or the appropriate value based on the transaction type) when calling ensureDeviceReady from the reconnection/recovery flow. This is a well-scoped fix in a small number of files.
Not auto-applied -- confidence below threshold.

Team: team-accounts-framework ✅

Matched via area fallback: area-hardware-wallet (no CODEOWNERS match)

---

Root Cause Analysis

Affected component: HardwareWalletErrorModal / ensureDeviceReady / LedgerAdapter

The ensureDeviceReady method in the EnsureDeviceReadyOptions type has requireBlindSigning defaulting to true. When the error modal's handleRetry function calls ensureDeviceReady() without any options, it uses the default requireBlindSigning: true. The Ledger adapter's ensureDeviceReady implementation then checks whether blind signing is enabled on the device. When blind signing is disabled, this check fails and the adapter throws an error that gets surfaced as 'Device not detected'. The reconnection flow in the error modal does not consider the transaction type — for simple sends (plain native asset transfers), blind signing is not required, so requireBlindSigning should be false. Even for contract interactions, the reconnection check should verify device connectivity first and handle the blind signing requirement separately, rather than failing the entire 'device detected' check.

Evidence:

• EnsureDeviceReadyOptions type shows requireBlindSigning defaults to true
• handleRetry in HardwareWalletErrorModal calls ensureDeviceReady() with no options (using default requireBlindSigning: true)
• Bug reproduces only when blind signing is disabled, confirming the blind signing check is the failing point
• Bug does not reproduce when blind signing is enabled, confirming the check passes when enabled
• The types documentation explicitly states: 'Set to false for simple sends (plain native asset transfers) that don't involve contract interactions'

Suggested Fix

Confidence: medium: likely but needs investigation — the code context strongly suggests this is the issue (default requireBlindSigning: true + no options passed in handleRetry), but the actual LedgerAdapter.ensureDeviceReady implementation is not in the provided context to confirm exactly how it handles the blind signing check

The handleRetry function in the HardwareWalletErrorModal calls ensureDeviceReady() without passing options, causing requireBlindSigning to default to true. The fix should either: (1) pass requireBlindSigning: false during the reconnection check since the reconnection flow is just verifying device connectivity (not signing), or (2) determine the appropriate requireBlindSigning value based on the pending transaction type and pass it through. Option 1 is simpler and more correct — the reconnection check should verify the device is connected and the Ethereum app is open, not enforce blind signing requirements (that should be checked at actual signing time).

Target files: ui/components/app/modals/hardware-wallet-error-modal/hardware-wallet-error-modal.tsx
Target functions: handleRetry

Approach:

1. In the handleRetry function in hardware-wallet-error-modal.tsx, change const result = await ensureDeviceReady(); to const result = await ensureDeviceReady({ requireBlindSigning: false });
2. This separates the 'is the device connected and ready' check from the 'is blind signing enabled' check.
3. The blind signing requirement should be enforced at actual signing time by the signing flow, not during the reconnection recovery check.
4. Add a test case that verifies ensureDeviceReady is called with { requireBlindSigning: false } from the retry handler.
5. Alternatively, if blind signing needs to be checked during reconnection for certain transaction types, the error modal should receive context about the pending transaction type and pass the appropriate requireBlindSigning value.

---

Confidence threshold: 0.85. Labels marked ✅ were auto-applied. Labels marked ⚠️ are advisory only (below threshold).
To re-triage, remove the ta-bot-triage label and re-apply ta-needs-triage.
⚠️ Some dimensions could not be confidently classified. An engineer should review this issue.