Skip to content

[pull] main from MetaMask:main#317

Merged
pull[bot] merged 4 commits into
dmrazzy:mainfrom
MetaMask:main
Sep 3, 2025
Merged

[pull] main from MetaMask:main#317
pull[bot] merged 4 commits into
dmrazzy:mainfrom
MetaMask:main

Conversation

@pull

@pull pull Bot commented Sep 3, 2025

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.3)

Can you help keep this open source service alive? 💖 Please sponsor : )

ccharly and others added 4 commits September 3, 2025 12:10
…ction (#6439)

## Explanation

Adding new `:addNewKeyring` action so we can use it in the
`MultichainAccountService` when creating/importing new wallets.

This action could also be useful in other context, since it apply to all
keyring types we already support and not only HD keyrings.

## References

N/A

## 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
## Explanation

Add a "getPricing" method to the SubscriptionController, which allows
the frontend to query the available products and their pricing.

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

## 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
…po (#6422)

## Explanation

We identified duplication in JSON RPC middleware logic between the
mobile and extension clients, particularly around the 5792 middleware
stack and capability handling. During recent Wallet API and Perps
integration discussions, the team agreed this presents an opportunity to
abstract and centralize this logic into a core monorepo module.

The motivation here is to:

* Reduce code duplication across mobile and extension clients
* Create a client-agnostic foundation for capabilities (including
auxiliary funds, capability advertising, and required assets)
* Support the upcoming Metamask Pay (MM Pay) initiative by establishing
a standardized middleware layer
* Facilitate future multi-chain and auxiliary funds work without
creating divergent patterns

So the work done on this PR aims to:

1. Create a new core package `eip-5792-middleware` to host shared
middleware logic.
2. Extract the 5792 middleware logic and capability handlers from both
extension and mobile clients.
a.
[Extension](MetaMask/metamask-extension#35541)
   b. [Mobile](MetaMask/metamask-mobile#19064)
4. Refactor them to be client-agnostic and consumable by both clients.
5. Maintain feature parity with existing implementations while improving
modularity and testability.
6. Include initial unit tests and integration hooks.

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes
[#5698](MetaMask/MetaMask-planning#5698)
-->

* Fixes
[#5698](MetaMask/MetaMask-planning#5698)

## 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
- [x] 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
- [x] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes
## Explanation

To remove our dependency on AccountsController and use the new BIP-44
enabled AccountTreeController, this PR contains two main changes:

- Swaps out the listener `AccountsController:selectedAccountChange` for
`AccountTreeController:selectedAccountGroupChange`
- Swaps out the action `AccountsController:getSelectedAccount` for
`AccountTreeController:getAccountsFromSelectedAccountGroup` from which
we derive the EVM-compatible account

This relies on the latest 0.12.1 release of the account-tree-controller
package.

Small things of note:
- The account listener no longer needs the account payload to update the
account address as the race condition of concern [has been
fixed](#5555) (this is relevant to
mention still because despite using the new AccountTreeController event,
it still uses AccountsController under the hood)
- In the new `getSelectedEvmAccount()` function I initially handled the
case of no account being found (which shouldn't be possible) by failing
early with a 'No EVM-compatible account address found' error. But on
seeing how this case is handled by consuming functions (sometimes
returning early, sometimes returning empty objects, sometimes throwing
error) I opted to keep it consistent with the current code

## References

Fixes the core side of this issue:
https://consensyssoftware.atlassian.net/browse/TAT-1315?atlOrigin=eyJpIjoiMmQ2MDY1ZjQ4MDU5NDdiYmJhMjRhYzNiMThhMjEwYzIiLCJwIjoiaiJ9

And should be tested alongside the accompanying mobile repo update:
MetaMask/metamask-mobile#19160

## 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
- [x] 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
- [x] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes
@pull pull Bot locked and limited conversation to collaborators Sep 3, 2025
@pull pull Bot added the ⤵️ pull label Sep 3, 2025
@pull pull Bot merged commit 38f4887 into dmrazzy:main Sep 3, 2025
0 of 2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants