Skip to content

feat: add 7702 methods to ledger#564

Open
montelaidev wants to merge 5 commits into
mainfrom
feat/ledger-7702
Open

feat: add 7702 methods to ledger#564
montelaidev wants to merge 5 commits into
mainfrom
feat/ledger-7702

Conversation

@montelaidev
Copy link
Copy Markdown
Contributor

@montelaidev montelaidev commented Jun 1, 2026

This PR adds the 7702 methods to the ledger keyring. The method itself is not usable until the dmk support has been added.

Examples


Note

Medium Risk
Introduces new hardware-backed authorization signing and signature recovery; iframe/mobile paths reject the operation until device support lands, but mistakes in parity or recovery could affect account safety.

Overview
Adds EIP-7702 delegation authorization signing to the Ledger keyring: LedgerKeyring.signEip7702Authorization unlocks the account, calls a new bridge method deviceSignDelegationAuthorization (chainId, contract address without 0x, nonce), normalizes Ledger v to y-parity, and verifies the result with recoverEIP7702Authorization.

The LedgerBridge contract gains delegation sign types and deviceSignDelegationAuthorization. Iframe and mobile bridges implement the method by throwing (not supported on those transports yet; PR notes DMK work is still pending).

Personal sign and EIP-712 paths now use a shared #parseLedgerRecoveryParam so Ledger v values like hex '1b' parse correctly before legacy normalization.

The v2 LedgerKeyring advertises SignEip7702Authorization in account methods (via EthKeyringMethod). Changelog and Jest coverage thresholds are updated; tests cover the new flow and recovery-param edge cases.

Reviewed by Cursor Bugbot for commit f1b063e. Bugbot is set up for automated code reviews on this repo. Configure here.

@montelaidev montelaidev self-assigned this Jun 1, 2026
@montelaidev montelaidev added the team-accounts This should be handled by the Accounts Team label Jun 1, 2026
@montelaidev montelaidev requested a review from a team as a code owner June 1, 2026 01:20
Copy link
Copy Markdown

@cursor cursor Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Fix All in Cursor

❌ 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 d244a63. Configure here.

Comment thread packages/keyring-eth-ledger-bridge/src/ledger-keyring.ts Outdated
Comment on lines +787 to +792
const value = String(recoveryParam).trim();
const withoutPrefix =
value.startsWith('0x') || value.startsWith('0X') ? value.slice(2) : value;
const radix = /[a-f]/iu.test(withoutPrefix) ? 16 : 10;

return parseInt(withoutPrefix, radix);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I think the logic is wrong here.

If we have a number like 0x100 (= 256), then this would be parsed as 100 (radix=10) which is wrong.

IMO we can do without the regex too:

Suggested change
const value = String(recoveryParam).trim();
const withoutPrefix =
value.startsWith('0x') || value.startsWith('0X') ? value.slice(2) : value;
const radix = /[a-f]/iu.test(withoutPrefix) ? 16 : 10;
return parseInt(withoutPrefix, radix);
const value = String(recoveryParam).trim();
if (value.startsWith('0x') || value.startsWith('0X')) {
return parseInt(value.slice(2), 16);
}
return parseInt(value, 10);

My suggestion is not fully safe either... If the input is 0x or 0X, then parseInt will return NaN. I'm not sure what we should do here? Cause initially we were not even filtering those NaN 😅 I guess we could have an assert(result !== NaN) too? 🤔

Comment on lines +626 to +630
const yParity =
recoveryValue === 0 || recoveryValue === 1
? recoveryValue
: recoveryValue - 27;
const signature = `0x${payload.r}${payload.s}${yParity.toString(16).padStart(2, '0')}`;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to have some comments here.

Also, I wouldn't compute the hex within the format string. Maybe we could have a toSomething(recoveryValue) that would do the right thing? Including the padding formatting?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

team-accounts This should be handled by the Accounts Team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants