Skip to content

Conversation

hmalik88
Copy link
Contributor

@hmalik88 hmalik88 commented Aug 15, 2025

Explanation

What is the current state of things and why does it need to change? An alignment mechanism didn't exist for multichain account groups. It needs to be added because we can have multiple scenarios where misalignment occurs:

  1. State 1 -> State 2 - We will have to align existing account groups when they are created.
  2. New protocols added - Existing groups will have to have an account associated with the new provider (chain).
  3. Basic functionality toggle - With basic functionality off, we can have a scenario where only an EVM account is created when a group is created.
  4. Discovery - When importing an SRP, the discovery process might not necessarily yield a discovered account for every provider and we have to align the group in those scenarios.

What is the solution your changes offer and how does it work? It adds an alignment mechanism at the group level and it runs through the list of providers and checks to see if any accounts exist for that particular group, if there aren't any, then it calls provider.createAccounts with the associated entropy id and group index. Alignment methods were added at the wallet level where a wallet would call align on all of its existing groups and similarly at the service level where it can call align on all of its wallets. Singular methods were also added at the wallet and service level where a particular group associated with a wallet can be aligned and a particular wallet can be aligned by the service.

Note: I also refactored the withCreateAccount in SnapAccountProvider to be a bit more readable and easier to understand.

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

@hmalik88 hmalik88 marked this pull request as ready for review August 18, 2025 07:07
@hmalik88 hmalik88 requested review from a team as code owners August 18, 2025 07:07
cursor[bot]

This comment was marked as outdated.

Copy link
Contributor

@fabiobozzo fabiobozzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! 😎 I can now dispatch MultichainAccountServiceAlignWalletsAction from the clients, now!

Copy link
Member

@gantunesr gantunesr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@hmalik88 hmalik88 enabled auto-merge (squash) August 18, 2025 16:49
@hmalik88 hmalik88 merged commit 7be2c73 into main Aug 18, 2025
223 checks passed
@hmalik88 hmalik88 deleted the hm/add-wallet-alignment branch August 18, 2025 16:55
fabiobozzo added a commit that referenced this pull request Aug 27, 2025
## Explanation

### What is the current state and why does it need to change?

Currently, the `MultichainAccountService` has no mechanism to manage
provider states based on user preferences like the "basic functionality"
toggle. When users disable advanced features (basic functionality OFF),
all providers (EVM, Solana, Bitcoin, etc.) remain active and continue
creating multichain accounts, which goes against the user's preference
for a simplified wallet experience.

The extension's `PreferencesController` manages the basic functionality
toggle (`useExternalServices`), but there was no way to communicate this
state change to the core `MultichainAccountService` to disable
non-essential providers.

### What is the solution and how does it work?

This PR introduces a clean provider state management system that allows
clients to control which providers are active based on user preferences:

1. **Provider-Level Disable Mechanism**: Added `setDisabled(disabled:
boolean)` method to `BaseAccountProvider`. Providers now **can /
should** check `this.isDisabled` in their `createAccounts` methods and
return empty arrays when disabled, preventing new account creation.

2. `EvmAccountProvider` could be disabled, for other reasons in the
future, but does not depend on basic functionality, at all.

3. Added `setBasicFunctionality({ enabled: boolean })` method to
`MultichainAccountService` that:
   - Calls `setDisabled(!enabled)` on all providers
- **Triggers wallet alignment when basic functionality is enabled to
ensure account groups are complete**

4. **Extension Integration**: The extension's `PreferencesController`
now calls this method when the basic functionality toggle changes.

## References

Alignment method provided by: #6326

Stories: 
- [MUL-343](https://consensyssoftware.atlassian.net/browse/MUL-343)
- [MUL-525](https://consensyssoftware.atlassian.net/browse/MUL-525)
- [MUL-524](https://consensyssoftware.atlassian.net/browse/MUL-524)

## Checklist

- [x] I've updated the test suite for new or updated code as appropriate
- [x] 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](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs),
highlighting breaking changes as necessary
- [ ] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes

[MUL-343]:
https://consensyssoftware.atlassian.net/browse/MUL-343?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

---------

Co-authored-by: Charly Chevalier <charly.chevalier@consensys.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants