Implement Keyring API v2

[jeremytsng]

Explanation

The Stellar snap implemented the Keyring API v1 surface. MetaMask now drives Snap accounts through Keyring API v2, so the snap needs to expose the v2 method set and declare its capabilities in the manifest.

This migrates the keyring handler to v2:

• onKeyringRequest now dispatches through handleKeyringRequest from @metamask/keyring-snap-sdk/v2, and KeyringHandler implements KeyringSnapRpc.
• Adds getAccounts. getAccount returns a KeyringAccount and throws AccountNotFoundException for an unknown id, rather than returning undefined.
• Renames listAccountAssets → getAccountAssets and listAccountTransactions → getAccountTransactions. These are the names the v2 dispatcher binds; it continues to accept the previous method names on the wire, so existing callers are unaffected.
• createAccounts handles bip44:discover in addition to bip44:derive-index and bip44:derive-index-range. For discovery the account is only created when it has on-chain activity; otherwise an empty array is returned and the client stops discovering. All three options now resolve to a single index range and go through one batchCreate call.
• submitRequest returns the handler result directly. v2 declares Promise<Json>, so the previous { pending: false, result } wrapper has been removed.
• Removes the v1-only surface that MetaMask no longer calls: createAccount, listAccounts, discoverAccounts, filterAccountChains and updateAccount, along with the AccountCreated and AccountDeleted events. AccountService.create and #getLowestUnusedIndex became unreachable once account creation went through batchCreate, so they are removed too, together with three exceptions that only those paths raised.

Supporting changes:

• snap.manifest.json declares endowment:keyring.capabilities with scopes: ["stellar:pubnet"] and bip44: { deriveIndex, deriveIndexRange, discover }, so the client knows which account operations the snap supports.
• SUPPORTED_SCOPES is derived from the manifest and used for account creation and discovery, so the manifest is the single source of truth for scopes rather than a separate config value.
• permissions.ts allows the v2 method names. The dapp origin is limited to the methods a dapp may legitimately call; account creation and address resolution remain MetaMask-only.
• packages/snap/tsconfig.json sets moduleResolution: "bundler", which is required to resolve the /v2 subpath exports. This affects type checking only; the bundle is produced by webpack.
• yarn.lock moves @metamask/snaps-utils to a version that recognises the capabilities field. The version previously resolved by the lockfile rejects it with Unknown key: initialPermissions.endowment:keyring.capabilities, so the manifest would not validate without this.

Manual testing

Verified against a local MetaMask Flask build with this snap preinstalled:

• Send funds — native XLM and a classic trustline asset (EURC), both confirmed on chain
• Activate an asset — changeTrust opt-in, confirmed, asset appears in the token list
• Deactivate an asset — behaviour matches main
• Import an existing Secret Recovery Phrase — account and balances resolve, no errors reported by the snap
• Create a new account on a fresh Secret Recovery Phrase

References

Aligns the Stellar snap with the Keyring API v2 migration already applied to the Solana snap in MetaMask/snap-solana-wallet#606.

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

[socket-security]

All alerts resolved. Learn more about Socket for GitHub.

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

Ignoring alerts on:

• @ethersproject/abi@5.8.0
• @ethersproject/abstract-provider@5.8.0
• @ethersproject/abstract-signer@5.8.0
• @ethersproject/address@5.8.0
• @ethersproject/base64@5.8.0
• @ethersproject/bignumber@5.8.0
• @ethersproject/bytes@5.8.0
• @ethersproject/constants@5.8.0
• @ethersproject/hash@5.8.0
• @ethersproject/keccak256@5.8.0
• @ethersproject/logger@5.8.0
• @ethersproject/networks@5.8.0
• @ethersproject/properties@5.8.0
• @ethersproject/rlp@5.8.0
• @ethersproject/signing-key@5.8.0
• @ethersproject/strings@5.8.0
• @ethersproject/transactions@5.8.0
• @ethersproject/web@5.8.0
• @metamask/messenger@1.2.0
• @metamask/messenger@2.0.0
• @metamask/approval-controller@9.0.2
• js-sha3@0.8.0
• @metamask/snaps-utils@12.4.0
• @metamask/permission-controller@12.3.0
• @metamask/permission-controller@13.1.1
• @metamask/slip44@4.5.0
• ses@2.2.0
• @metamask/base-controller@9.1.0
• @metamask/json-rpc-engine@10.5.0
• @metamask/controller-utils@11.20.0
• @metamask/controller-utils@12.3.0

View full report

[jeremytsng]

@SocketSecurity ignore-all

[Copilot]

Pull request overview

This PR migrates the Stellar snap’s keyring handler to the remaining MetaMask Keyring API v2 surface, adding support for getAccounts and secure private-key export via exportAccount, along with required permissions/manifest updates.

Changes:

• Implemented Keyring API v2 semantics in the keyring handler (KeyringRpc), including getAccounts, exportAccount, and updated getAccount missing-id behavior.
• Added wallet-level raw seed export helpers and tests for hex/base58 export round-trips.
• Updated snap permissions/manifest and dependency resolution to support v2 types and keyring capabilities.

Reviewed changes

Copilot reviewed 13 out of 14 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
yarn.lock	Updates lockfile to reflect new/updated dependency graph needed for v2 support.
packages/snap/tsconfig.json	Enables moduleResolution: bundler (and module: preserve) to resolve /v2 subpath types.
packages/snap/src/services/wallet/Wallet.ts	Adds exportKey for raw seed export in hex/base58.
packages/snap/src/services/wallet/Wallet.test.ts	Adds tests validating exportKey output and round-trip behavior.
packages/snap/src/permissions.ts	Adds v2 RPC method permissions (GetAccounts, ExportAccount) and updates selected method constants.
packages/snap/src/handlers/keyring/keyring.ts	Migrates dispatcher to @metamask/keyring-snap-sdk/v2, implements KeyringRpc, adds getAccounts + exportAccount, and redacts export results from debug logs.
packages/snap/src/handlers/keyring/keyring.test.ts	Updates tests for v2 dispatcher usage, new semantics, export behavior, and log redaction.
packages/snap/src/handlers/keyring/api.ts	Adds Base58Struct and handler-level request struct for exportAccount.
packages/snap/src/handlers/keyring/api.test.ts	Adds tests for Base58Struct.
packages/snap/src/context.ts	Wires AccountResolver into KeyringHandler construction.
packages/snap/snap.manifest.json	Declares keyring capabilities for scopes, private-key export formats, and bip44 features.
packages/snap/package.json	Adds @scure/base dependency for base58 encoding.
packages/snap/CHANGELOG.md	Documents added v2 functionality and the getAccount breaking change.
package.json	Pins @metamask/snaps-utils via resolutions to support capabilities validation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[hmalik88]

The description mentions exportAccount but I don't see it was added in the PR, it's not required in v2 but if stellar would indeed support exporting of private keys then I would suggest that you guys just add it in now. You can follow the same pattern that the other snaps are using for this method.

[stanleyyconsensys]

@hmalik88

i think @jeremytsng didnt update the description yet
becoz we dont support export account at begining (it require keyring API to support base32)