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 multichain account service to a state-driven model with unified wallet creation (import/create/restore), provider ID-based access, and more robust group alignment and error reporting.

• Core architecture (performance):
  • Build a single ServiceState in MultichainAccountService.init(); pass state slices to MultichainAccountWallet.init and MultichainAccountGroup.init/update to avoid repeated controller scans.
  • Remove legacy sync flows and reverse mappings; providers and groups now track account IDs directly.
• Wallet lifecycle:
  • Unify wallet creation via createMultichainAccountWallet supporting import, create (new vault), and restore; adds use of KeyringController:createNewVaultAnd{Keychain,Restore}.
  • MultichainAccountWallet.createMultichainAccountGroup initializes group early, awaits EVM, runs non‑EVM in background or all (option), tolerates partial failures, and updates group state.
  • discoverAccounts constructs groups from discovered IDs, then aligns.
• Group behavior:
  • MultichainAccountGroup.init/update register provider→IDs and reverse maps; publish multichainAccountGroupUpdated.
  • New getAccountIds(); alignAccounts() uses provider.alignAccounts, handles disabled providers, and aggregates warnings/errors.
• Providers:
  • BaseBip44AccountProvider: add init(accountsIds), internal ID set, alignAccounts() returning IDs, getAccounts(getAccounts) and getAccount(getAccount) by ID.
  • EvmAccountProvider: deterministic ID via getUUIDFromAddressOfNormalAccount; fetch by ID; add created/discovered IDs.
  • {Btc,Sol,Trx}AccountProvider: add created/discovered IDs to internal set.
  • AccountProviderWrapper: add isDisabled() and alignAccounts passthrough; enforce disabled behavior across methods.
• Types/Utils/Messaging:
  • Extend allowed actions with AccountsController:getAccounts and new keyring vault actions; remove unused utilities.
• Tests/Changelog:
  • Update tests to state-driven APIs and new flows; update CHANGELOG with breaking changes and new methods.

^{Written by Cursor Bugbot for commit 602ce8f. 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.

[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.

 

[cursor]

Bug: Stale Account Data Persists After Updates

The init method doesn't clear the #providerToAccounts and #accountToProvider maps when called with update = true. When update() is invoked with partial state (e.g., only one provider's accounts), old entries for other providers remain in the maps, causing stale data accumulation. This is inconsistent with alignAccounts which clears the maps before repopulation.

 

[hmalik88]

State maps are cleared at the only point that they're needed (in the alignAccounts function). The other invocations of update do not require a need to clear the maps.

[cursor]

Bug: Wrapper Data Disconnect: Init vs. Get

AccountProviderWrapper inherits from BaseBip44AccountProvider, creating its own accounts Set. When init() is called on a wrapper instance, it populates the wrapper's inherited accounts Set. However, getAccounts() delegates to the wrapped provider's implementation, which uses the wrapped provider's separate accounts Set. This creates a disconnect where initialization populates the wrapper's Set while retrieval reads from the provider's empty Set, causing getAccounts() to return incorrect results.

packages/multichain-account-service/src/providers/AccountProviderWrapper.ts#L11-L25

core/packages/multichain-account-service/src/providers/AccountProviderWrapper.ts

Lines 11 to 25 in 602ce8f

	*/
	export class AccountProviderWrapper extends BaseBip44AccountProvider {
	private isEnabled: boolean = true;
	private readonly provider: BaseBip44AccountProvider;
	constructor(
	messenger: MultichainAccountServiceMessenger,
	provider: BaseBip44AccountProvider,
	) {
	super(messenger);
	this.provider = provider;
	}
	override getName(): string {

 

---