Skip to content

feat(keyring): enable P2TR taproot account creation#598

Open
marcopeereboom wants to merge 2 commits into
MetaMask:mainfrom
marcopeereboom:feat/enable-p2tr-taproot
Open

feat(keyring): enable P2TR taproot account creation#598
marcopeereboom wants to merge 2 commits into
MetaMask:mainfrom
marcopeereboom:feat/enable-p2tr-taproot

Conversation

@marcopeereboom
Copy link
Copy Markdown

@marcopeereboom marcopeereboom commented Apr 22, 2026

Explanation

The snap currently restricts account creation to P2WPKH only, enforced
by three guards in KeyringHandler documented as v1 restrictions. The
full P2TR pipeline already exists: @metamask/bitcoindevkit handles
taproot natively, caipToAddressType maps P2tr → 'p2tr',
Purpose.Taproot = 86 and purposeToAddressType are defined in
entities/account.ts, and the extension UI maps P2tr to 'Taproot'.
Only the whitelist checks block taproot.

This PR widens the whitelist to accept P2TR alongside P2WPKH:

  • createAccount: accept BtcAccountType.P2tr in address type validation
  • #extractAddressType: accept BIP-86 (purpose 86) derivation paths
  • discoverAccounts: include P2TR in the address type discovery list

No new dependencies. No changes to BDK integration, CAIP mappings, or
account infrastructure. Existing P2WPKH behavior is unchanged.

References

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed
  • I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Note

Medium Risk
Expands supported account types and derivation-path validation, and doubles discovery calls (P2WPKH + P2TR) which can impact account creation/discovery behavior across networks. While scoped to whitelisting/validation, it touches keyring account flows that affect wallet state and UX.

Overview
Enables Taproot (P2TR) accounts alongside existing P2WPKH in KeyringHandler.

createAccount now accepts BtcAccountType.P2tr, validates defaults accordingly, and #extractAddressType permits BIP-86 (purpose 86) derivation paths (updating related error messages). discoverAccounts is expanded to include P2TR in discovery, and tests/changelog are updated to cover the new behavior.

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

Remove v1 P2WPKH-only guards from createAccount, extractAddressType,
and discoverAccounts. The full P2TR pipeline (BDK descriptors, CAIP
type mappings, BIP-86 derivation paths, extension UI) already exists;
only the whitelist checks blocked taproot.

Widen address type validation to accept P2TR alongside P2WPKH. Accept
BIP-86 (purpose 86) derivation paths. Include P2TR in account
discovery so existing taproot UTXOs are found during wallet setup.

Test coverage: unskip existing BIP-86 vector, add P2TR derivation
path extraction, P2TR-only creation, P2TR+path combined validation,
and P2TR account discovery with history filtering.
@Nabilislam722
Copy link
Copy Markdown

I would Love to see this. This is Massive TBH P2TR taproot account creation system on MetaMask is personally needed...

Copy link
Copy Markdown

@Nabilislam722 Nabilislam722 left a comment

Choose a reason for hiding this comment

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

Utilizing it.each for the derivation path tests is a great way to handle the matrix of Bitcoin address types BIP-84 for p2wpkh

@marcopeereboom
Copy link
Copy Markdown
Author

FWIW, I tested all of this code using metamask flask and I was able to send and move ordinals.

@Battambang
Copy link
Copy Markdown
Contributor

There is already this Taproot PR #578 opened. Pending due to updates in MM clients to QA.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants