feat!: expose snap-only keyring methods through service + use explicit keyring.v1 for v1 account management Snaps - #9390
Merged
Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
ccharly
force-pushed
the
cc/feat/snap-account-service-snap-rpc-methods
branch
from
July 6, 2026 13:59
9cd4cab to
0221bce
Compare
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
ccharly
changed the title
keyring.v1 for v1 account management Snaps
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
…rations in withKeyringV2
ccharly
force-pushed
the
cc/feat/snap-account-service-snap-rpc-methods
branch
from
July 7, 2026 10:53
8c7abb2 to
803c8d6
Compare
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
hmalik88
reviewed
Jul 7, 2026
hmalik88
reviewed
Jul 7, 2026
Co-authored-by: Hassan Malik <41640681+hmalik88@users.noreply.github.com>
Co-authored-by: Hassan Malik <41640681+hmalik88@users.noreply.github.com>
hmalik88
previously approved these changes
Jul 7, 2026
hmalik88
approved these changes
Jul 8, 2026
ccharly
enabled auto-merge
July 8, 2026 08:38
FrederikBolding
approved these changes
Jul 8, 2026
montelaidev
pushed a commit
to MetaMask/accounts
that referenced
this pull request
Sep 21, 2026
…591) We don't need to call `saveState` here. That was an old trick used by v1 async `createAccount` flow. Here, we expect every `SnapKeyring.createAccounts` to be naturally wrapped in a `:withKeyringV2` or `:withKeyring` call. This should also have a positive impact in terms of performance since updates can be pinpointed to a specific keyrings, rather than re-persisting everything for 1 keyring change (though, the `KeyringController` still re-serialize all keyrings today... So that might only be a perf improvement in case of non-change/idempotent calls). We stumbled upon this bug with the last change we made on the `multichain-account-service` (wrapping `createAccounts` call in `:withKeyringV2`), see: - MetaMask/core#9390 <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes when keyring state is persisted for batch account creation; callers that invoke `createAccounts` outside a `:withKeyringV2` transaction would no longer get automatic persistence. > > **Overview** > Fixes a **deadlock** when batch account creation runs inside a `:withKeyringV2` (or `:withKeyring`) transaction by **removing the `saveState` callback** from v2 `SnapKeyring.createAccounts` after new accounts are written to in-memory state. > > **`createAccounts` still updates the keyring and returns new plus existing accounts**, but persistence is left to the caller’s transaction wrapper—the same pattern as v1 batch `createAccounts`, unlike async v1 `createAccount` which still persists on its own. > > Tests and the changelog now document that **`saveState` must not be invoked** from `createAccounts` (success, idempotent, concurrent batches, and rollback paths). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit ee5aef5. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
bluluvinn
pushed a commit
to bluluvinn/accounts
that referenced
this pull request
Sep 23, 2026
…etaMask#591) We don't need to call `saveState` here. That was an old trick used by v1 async `createAccount` flow. Here, we expect every `SnapKeyring.createAccounts` to be naturally wrapped in a `:withKeyringV2` or `:withKeyring` call. This should also have a positive impact in terms of performance since updates can be pinpointed to a specific keyrings, rather than re-persisting everything for 1 keyring change (though, the `KeyringController` still re-serialize all keyrings today... So that might only be a perf improvement in case of non-change/idempotent calls). We stumbled upon this bug with the last change we made on the `multichain-account-service` (wrapping `createAccounts` call in `:withKeyringV2`), see: - MetaMask/core#9390 <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes when keyring state is persisted for batch account creation; callers that invoke `createAccounts` outside a `:withKeyringV2` transaction would no longer get automatic persistence. > > **Overview** > Fixes a **deadlock** when batch account creation runs inside a `:withKeyringV2` (or `:withKeyring`) transaction by **removing the `saveState` callback** from v2 `SnapKeyring.createAccounts` after new accounts are written to in-memory state. > > **`createAccounts` still updates the keyring and returns new plus existing accounts**, but persistence is left to the caller’s transaction wrapper—the same pattern as v1 batch `createAccounts`, unlike async v1 `createAccount` which still persists on its own. > > Tests and the changelog now document that **`saveState` must not be invoked** from `createAccounts` (success, idempotent, concurrent batches, and rollback paths). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit ee5aef5. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
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.
Explanation
The new
SnapKeyring(v2), is no longer inheritingSnapKeyringV1(to make v1 calls more explicit).This PR now uses this new pattern (
keyring.v1) and also re-expose Snap-only methods that were part of the v1 keyring-API on theSnapAccountServicedirectly. Those methods can also be called using a standardKeyringClient(v1 or v2), but using the service is generally preferred to remove the need of constructing a keyring client to submit the request to the Snap.References
N/A
Checklist
Note
High Risk
Breaking API changes on RestrictedSnapKeyring and new SnapAccountService surface, plus account-creation and signing-routing behavior for v1 vs v2 Snaps across multichain providers.
Overview
Aligns the monorepo with
@metamask/eth-snap-keyringv23, where v1 account APIs live underkeyring.v1instead of top-levelcreateAccount.RestrictedSnapKeyringnow exposes optionalv1; BTC/SOL/TRX/XLM providers guardkeyring.v1and throw for v2-only Snaps on v1 derive-index creation.SnapAccountServiceadds messenger actions that proxyKeyringInternalSnapClientafterensureReady:getAccountAssets,getAccountBalances,getAccountTransactions,resolveAccountAddress, andsetSelectedAccounts. Selected-account forwarding andhandleKeyringSnapMessageusekeyring.v1when present; v2-only Snaps getsetSelectedAccountsand keyring-only messages via the RPC client (or reject v1 messages).Dependency bumps across controllers:
keyring-api^23.5.0,eth-snap-keyring^23.0.0,keyring-snap-client/keyring-snap-sdk^9.2.0, plusyarn.lock.Reviewed by Cursor Bugbot for commit 768ad9a. Bugbot is set up for automated code reviews on this repo. Configure here.