feat(btc-provider): accept P2TR accounts and add testnet4

[marcopeereboom]

Explanation

BtcAccountProvider currently restricts Bitcoin account compatibility
to P2WPKH only and limits capabilities and discovery to mainnet and
testnet3. This blocks taproot (P2TR) accounts from being tracked by
the provider and prevents testnet4 usage.

This PR makes three changes to BtcAccountProvider:

• isAccountCompatible: accept P2TR accounts alongside P2WPKH so that
  taproot accounts created through discovery or future UI options are
  correctly managed by the provider
• capabilities.scopes: add BtcScope.Testnet4 so the provider
  advertises testnet4 support
• discoverAccounts: include BtcScope.Testnet4 in discovery scopes
  so existing testnet4 accounts are found during wallet setup

Default account creation via createAccountV1 remains P2WPKH — no
behavioral change for existing callers. The snap already has full P2TR
and testnet4 support; this change enables the provider to work with
accounts the snap can now create.

References

• Snap P2TR support: feat(keyring): enable P2TR taproot account creation snap-bitcoin-wallet#598
• Wallet standard ordinals: feat(connect): support ordinals purpose for P2TR addresses bitcoin-wallet-standard#30
• Wallet standard testnet4: feat(scope): add testnet4 network support bitcoin-wallet-standard#31

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
Medium risk because it changes Bitcoin account compatibility, advertised discovery scopes, and overrides resyncAccounts to delete/re-create Snap accounts—mistakes could lead to missing or duplicated accounts if scope/type inference is wrong.

Overview
Bitcoin provider enhancements. BtcAccountProvider now treats P2TR accounts as compatible, advertises BtcScope.Testnet4, and runs discovery across Mainnet, Testnet, and Testnet4 to match its capabilities.

Resync behavior change. Overrides resyncAccounts to re-create missing Snap accounts using the original account.type and first account.scopes entry (instead of defaulting to P2WPKH/Mainnet), adds guards for empty scopes, and reports/propagates re-creation failures after keyring removal to avoid silent inconsistent state.

Tests were updated/expanded to cover P2TR compatibility, multi-scope discovery, and the new resync scenarios.

^{Reviewed by Cursor Bugbot for commit 2adb7c4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[marcopeereboom]

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

[marcopeereboom]

Addressed the Copilot/Bugbot feedback — it was right.

Root cause: SnapAccountProvider.resyncAccounts() re-creates missing snap accounts by calling createAccountV1, which in BtcAccountProvider hardcodes addressType: P2WPKH and scope: Mainnet. With P2TR and testnet4 accounts now managed by this provider (via isAccountCompatible), a desync would silently re-create them with wrong derivation parameters — different address, original funds unreachable.

Fix: Override resyncAccounts in BtcAccountProvider to pass the original account.type and account.scopes[0] directly to keyring.createAccount() instead of funneling through createAccountV1. The delete-extras path is preserved as-is from the base class.

Also rebased onto upstream/main to clean out the merge commits.

Tests: 3 new (P2TR type preservation, testnet4 scope preservation, P2WPKH/Mainnet identity), full package suite passes (13 suites, 322 tests).

[cursor]

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

^{Reviewed by Cursor Bugbot for commit 0fbd4e0. Configure here.}

[cursor]

Resync override doesn't track re-created account IDs

Medium Severity

The resyncAccounts override calls keyring.createAccount(...) directly and discards the returned KeyringAccount. The base class's resync path goes through this.createAccounts() → createBip44Accounts(), which calls this.accounts.add(snapAccount.id) to register the newly created account in the provider's internal tracking set. Since the override skips this, re-created accounts won't appear in getAccounts() or be found by getAccount() after resync completes.

 

^{Reviewed by Cursor Bugbot for commit 0fbd4e0. Configure here.}

[marcopeereboom]

BtcAccountProvider overrides the entire resyncAccounts method from SnapAccountProvider to fix a single concern: the base implementation re-creates missing snap accounts via createAccounts() → createAccountV1(), which hardcodes addressType: BtcAccountType.P2wpkh and scope: BtcScope.Mainnet. This silently converts P2TR or testnet4 accounts, making the original taproot addresses unreachable.

The override copy-pastes ~60 lines of the snap-has-more deletion path and the MetaMask-has-more re-creation path from the base class, changing only the re-creation call to use account.type and account.scopes[0] instead of the hardcoded defaults.

If SnapAccountProvider.resyncAccounts evolves — new error handling, different deletion strategy, additional config knobs, observability hooks — BtcAccountProvider's override silently diverges. There's no compiler or test signal that the base changed. The two implementations will drift, and future bugs in the base fix won't propagate to BTC accounts.

This also sets a precedent: every new provider that supports multiple address types or network scopes will need its own full override with the same copy-paste pattern (Solana, future account types).

Here is an idea on how to fix it; make the base class's re-creation step a virtual method that subclasses can override surgically:

// In SnapAccountProvider:
protected recreateAccount(
  keyring: RestrictedSnapKeyring,
  account: Bip44Account<InternalAccount>,
  entropySource: EntropySourceId,
  groupIndex: number,
): Promise<void> {
  return this.createAccounts({
    type: AccountCreationType.Bip44DeriveIndex,
    entropySource,
    groupIndex,
  });
}

Then resyncAccounts calls this.recreateAccount(...) instead of this.createAccounts(...) directly. BtcAccountProvider overrides only recreateAccount:

// In BtcAccountProvider:
protected override async recreateAccount(
  keyring: RestrictedSnapKeyring,
  account: Bip44Account<InternalAccount>,
  entropySource: EntropySourceId,
  groupIndex: number,
): Promise<void> {
  const scope = account.scopes?.[0];
  if (!scope) {
    throw new Error(
      `Account ${account.id} has no scopes, cannot determine target network`,
    );
  }
  await withTimeout(
    () =>
      keyring.createAccount({
        entropySource,
        index: groupIndex,
        addressType: account.type,
        scope,
      }),
    this.config.createAccounts.timeoutMs,
  );
}

This keeps all sync logic (deletion, size comparison, error reporting, the removeAccount-before-create dance) in one place, and subclasses only define how a single account gets re-created. The recreateAccount hook is a small refactor in SnapAccountProvider and eliminates the copy-paste for all current and future providers.