Conversation
…r recovery Ledger devices may return v as 0 or 1 (modern format), but signature recovery functions like `recoverPersonalSignature` and `recoverTypedSignature` expect v to be 27 or 28 (legacy format per EIP-191/EIP-712). This caused "The signature doesnt match the right address" errors when Ledger returned v=0 or v=1, as the hex conversion produced "00"/"01" instead of "1b"/"1c". The fix normalizes v before hex conversion in both `signPersonalMessage` and `signTypedData` methods.
gantunesr
previously approved these changes
Jan 30, 2026
Member
gantunesr
left a comment
There was a problem hiding this comment.
Looks good, left a comment about an edge case but feel free to ignore it
danroc
reviewed
Jan 30, 2026
Extract duplicate v normalization logic into a private helper method as suggested in PR review. This improves code maintainability by consolidating the normalization logic in one place. Coverage thresholds adjusted slightly due to branch counting changes from code consolidation (same code paths are tested, just counted differently by Jest).
042f3f2 to
e756502
Compare
gantunesr
approved these changes
Jan 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Ledger devices may return signature
vas 0 or 1 (modern format), but Ethereum'secrecoverexpects 27 or 28. This causes"The signature doesnt match the right address"errors insignPersonalMessageandsignTypedData.Fix
Why This Wasn't Fixed Before
Original bug (pre-2022): The code subtracted 27 from
v:This converted correct values (27/28) into incorrect ones (0/1).
PR #152 (August 2022): Changed to pass through the raw value:
This fixed the case where Ledger returns 27/28, but assumed Ledger always returns 27/28.
The gap: Ledger devices may return 0/1 depending on firmware, signing method, or device model. PR #152 didn't normalize these values.
Issue #10850 was closed prematurely in January 2024 with "I expect this was resolved in PR #152" — but PR #152 only fixed one direction of the problem.
References
This is a well-known issue with a standard fix across the ecosystem:
v = v === 0 || v === 1 ? v + 27 : vif (v <= 1) v += 27Note
Medium Risk
Changes signature formatting in
signPersonalMessageandsignTypedData, which can affect signature verification and downstream consumers if assumptions aboutvdiffer. Scope is small and covered by new unit tests for multiplevcases.Overview
Fixes Ledger signing to normalize the recovery param (
v) so devices returning modern values0/1are converted to legacy27/28before building the final signature inledger-keyring.ts.Adds focused tests covering
vnormalization for bothsignPersonalMessageandsignTypedData, and updates theCHANGELOG.mdentry accordingly (plus minor Jest coverage threshold tweaks).Written by Cursor Bugbot for commit e756502. This will update automatically on new commits. Configure here.