refactor(multichain-account-service): Improved performance across package classes and improved error messages

[hmalik88]

Explanation

MultichainAccountService

• Unified wallet creation into one flow (createMultichainAccountWallet) that handles import/restore/new vault.
• Builds a single ServiceState index in one pass and passes state slices to wallets/groups (cuts repeated controller scans/calls).
• Simplified init path and removed dead accountIdToContext mapping.

MultichainAccountWallet

• init now consumes a pre-sliced wallet state (entropySource → groups → providerName → ids) instead of querying providers.
• Emits clear events on group creation/updates; alignment orchestration uses provider state instead of full scans.

MultichainAccountGroup

• init registers account IDs per provider and fills reverse maps; calls provider.addAccounts(ids) to keep providers in sync.
• Added getAccountIds() for direct access to underlying IDs.
• Improved partial‑failure reporting (aggregates provider errors by name).

BaseBip44AccountProvider

• Added addAccounts(ids: string[]), enabling providers to track their own account ID lists.
• getAccounts() paths rely on known IDs (plural lookups) rather than scanning the full controller list.

EvmAccountProvider

• Switched from address‑based scans to ID‑based fetches (getAccount(s)) for create/discover (removes $O(n)$ scans).

Performance Analysis

n = total BIP-44 accounts in the AccountsController
p = number of providers (currently 4)
w = number of wallets (entropy sources)
g = total number of groups
e = number of created EVM accounts

When fully aligned $g = n / p$.
When accounts are not fully aligned then $g = max(f(p))$, where $f(p)$ is the number of accounts associated with a provider.

Consider two scenarios:

1. State 1 -> State 2 transition, the user has unaligned groups after the transition.
2. Already transitioned to State 2, the service is initialized after onboarding and every time the client is unlocked.

General formulas

For Scenario 2, the formulas are as follows:

Before this refactor, the number of loops can be represented $n * p * (1 + w + g)$, which with $p = 4$, becomes $n^2 + 4n(1 + w)$.

Before this refactor, the number of controller calls can be represented as $1 + w + g$, which with $p = 4$, becomes $1 + w + n/4$.

After this refactor, the number of loops can be represented by $n * p$, which with $p = 4$, becomes $4n$.

After this refactor, the number of calls is just $1$.

For Scenario 1, the formulas are entirely dependent on the breakdown of the number of accounts each provider has amongst the $n$ accounts, let's consider a scenario where Solana has $n/2$, Ethereum has $n/8$, Bitcoin has $n/4$ and Tron has $n/8$, the formulas would be as follows:

Before this refactor, the number of loops in the alignment process can be represented as $(p * g) + (n * e)$, which with $p=4$ and $g = n/2$, becomes $2n + 3n^2/8$. Therefore the number of loops for initialization + alignment in this scenario with $p = 4$ and $g = n/2$, becomes $(19/8)n^2 + (4w + 6)n$.

Before this refactor, the number of controller calls in the alignment process can be represented as $e$, which becomes $3n/8$. Therefore the number of controller calls for initialization + alignment in this scenario with $p = 4$, becomes $1 + w + 5n/8$.

After this refactor, the number of loops in the alignment process can be represented as $p * g$, which becomes $2n$. Therefore, the number of loops for initialization + alignment in this scenario with $p = 4$ and $g = n/2$, becomes $6n$.

After this refactor, the number of controller calls in the alignment process can be represented as $e$ which becomes $3n/8$. Therefore, the number of controller calls for initialization + alignment in this scenario with $p = 4$ and $g = n/2$, becomes $1 + 3n/8$.

In short, previous init performance for loops and controller calls was quadratic and linear, respectively. After, it is linear and constant.

Performance Charts

Below are charts that show performance (loops and controller calls) $n = 0$ -> $n = 256$ for Scenario 1 and 2 with $w = 2$, respectively:

References

N/A

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, highlighting breaking changes as necessary
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

---

Note

Refactors the multichain account service to a state-driven init with unified wallet creation flows, ID-based provider lookups, improved alignment/disabled-provider handling, and updated messaging/types and tests.

• Performance/Architecture:
  • Refactor to state-driven init: build ServiceState once and pass slices to MultichainAccountWallet.init and MultichainAccountGroup.init/update (removes repeated controller scans).
  • Remove legacy sync/event plumbing: drop sync, getAccountContext, #handleOnAccount{Added,Removed}.
• Wallet creation:
  • Unify createMultichainAccountWallet to handle import, create (new vault), and restore; add validation; wire new KeyringController actions.
• Groups/Wallets:
  • Add GroupState/WalletState; groups maintain provider↔account-ID maps; add getAccountIds.
  • Alignment: create missing accounts only where absent; tolerate partial failures (warn); fail only if all providers fail; handle disabled providers by skipping and cleaning state.
• Providers:
  • BaseBip44AccountProvider: track IDs via addAccounts; getAccounts fetches by IDs (AccountsController:getAccounts); add clearAccountsList.
  • EvmAccountProvider: use deterministic ID (getUUIDFromAddressOfNormalAccount) and AccountsController:getAccount; optimize discovery/create; retain retry/timeout.
  • AccountProviderWrapper: add disable semantics, clearing accounts on disable; expose isDisabled.
• Messaging/Types:
  • Expand allowed actions: AccountsController:getAccounts, KeyringController:{createNewVaultAndKeychain,createNewVaultAndRestore}.
• Tests/Changelog:
  • Update tests to new init/state and error handling; update CHANGELOG with breaking notes.

^{Written by Cursor Bugbot for commit 37f79b6. This will update automatically on new commits. Configure here.}

[hmalik88]

Although the getAccounts's return type is (InternalAccount | undefined)[], we're sure to get back all the accounts we want since the accounts list will never be stale.

[hmalik88]

Decided to get rid of this mapping since it was only being used for handling the accountRemoved and accountAdded events, removing this gets rid of a large loop in the init function as well. If there's a particular need for this data at the client level, we can always add this back in.

[ccharly]

I would not use an error message in that case. Maybe we can re-use what you did in the EvmAccountProvider.#createAccount last time, like returning a boolean to indicate if we created accounts or not?

Like const [didCreate, accounts] = .... WDYT?

[hmalik88]

Do you mean changing the provider's createAccounts return type or returning the tuple in the promise in Promise.allSettled? I found this method easier because then we're returning a tuple just for this one use case.

[ccharly]

Well nope, indeed we don't want to change the signature of createAccounts 🤔

Given the current logic of having to "remove" accounts from the provider during alignment, I think we could introduce a BaseBip44AccountProvider.alignAccounts({ entropySource, groupIndex }) method maybe...

This way, for the AccountProviderWrapper, we can automatically "remove" accounts from it when disabled, and for all other cases, we can just return existing and new (missing) accounts from it.

We would always re-use the returned value to update #providerToAccounts accounts so we always make sure to have an "in-sync" list of accounts with the provider.

WDYT?

NOTE: I think we could go with my small PR here:

• refactor(multichain-account-service): add Bip44AccountProvider interface #6959
  This way, we can add the alignAccounts on the new type interface I've introduced.

[hmalik88]

Removed the promise rejection to just return an empty array. I applied the changes you had in your PR to the interface as well. I don't know if we need alignAccounts on the provider level since it essentially becomes an extra wrapper on createAccounts since we have to check at the group level anyway for if a provider is disabled to clear the group's state.

[cursor]

Bug: Unsafe Cast in getAccounts() Method

The getAccounts() method performs an unsafe cast on the result from AccountsController:getAccounts. This action can return undefined values, but the method casts the array to Bip44Account<KeyringAccount>[] without filtering them. This can lead to runtime errors, like "Cannot read property 'id' of undefined," when consumers (e.g., getAccount()) access properties on these undefined entries.

 

[cursor]

Bug: Duplicate Account IDs in Multichain Provider

The BaseBip44AccountProvider.addAccounts method doesn't prevent duplicate account IDs, allowing MultichainAccountGroup.init or update to add the same IDs multiple times. This results in providers holding duplicate account IDs, which may cause unexpected behavior in methods relying on this internal list.

Additional Locations (1)

• packages/multichain-account-service/src/MultichainAccountGroup.ts#L89-L91

 

[cursor]

Bug: Async Provider Failure Leaves Wallet Inconsistent

In createMultichainAccountGroup, when not awaiting all providers, the MultichainAccountGroup is created and added to the wallet's map synchronously. However, the EVM provider's account creation and group initialization are asynchronous. If the EVM provider fails, the group is left in an uninitialized or incomplete state in the map, leading to inconsistent wallet state and unexpected behavior for callers.

 

[cursor]

Bug: Error Handling Anti-Pattern in alignAccounts

The alignAccounts method uses Promise.reject(new Error('Already aligned')) for control flow, which is an anti-pattern. This relies on fragile string matching to distinguish between actual errors and control flow, risking incorrect failure reporting if the message changes.