[pull] main from MetaMask:main#565
Merged
pull[bot] merged 3 commits intoReality2byte:mainfrom May 6, 2026
Merged
Conversation
## Explanation
This PR adds `payee` rule decoding to
`@metamask/gator-permissions-controller` execution permission decoding.
The 7715 permissions snap can now emit payee restrictions for token
payment permissions. Core needs to decode those caveats into the
existing decoded permission rule shape:
```ts
{ type: 'payee', data: { addresses: Address[] } }
```
This PR supports the latest caveat encoding from the snap PR:
- Native token payees are decoded from `AllowedTargetsEnforcer`.
- Multiple native payees are represented directly as multiple allowed
targets.
- ERC20 token payees are decoded from `AllowedCalldataEnforcer`.
- Single ERC20 payee uses the calldata caveat directly.
- Multiple ERC20 payees is not supported yet.
- Payee caveats require empty args (`0x`).
This also removes `LogicalOrWrapperEnforcer` from native token
permission optional enforcers, since native multi-payee permissions no
longer use it.
## References
- Related snap PR:
MetaMask/snap-7715-permissions#300
## Checklist
- [x] 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
- [x] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Updates execution-permission decoding and dependency versions;
incorrect rule extraction could lead to misinterpreting payee
restrictions or supported enforcer sets across multiple permission
types.
>
> **Overview**
> Adds **`payee` rule decoding** to execution permission decoding,
extracting allowlisted recipient addresses from `AllowedTargetsEnforcer`
(native) and `AllowedCalldataEnforcer` (ERC20) caveats and returning
them alongside existing decoded `rules`.
>
> Updates all known permission rules to recognize the relevant payee
enforcers (including adding `AllowedTargetsEnforcer` to the checksummed
enforcer set) and exports `EXECUTION_PERMISSION_PAYEE_RULE_TYPE` plus a
new `PayeeRule` type.
>
> Bumps `@metamask/delegation-core` to `^2.0.0` and
`@metamask/delegation-deployments` to `^1.3.0`, with expanded test
coverage for payee/redeemer rule combinations and payee caveat
validation (and an explicit exclusion of payee rule extraction for
`erc20-token-revocation`).
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
a5c332e. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: jeffsmale90 <6363749+jeffsmale90@users.noreply.github.com>
## Explanation <!-- 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? --> This PR releases BridgeController ## 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 - [ ] 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk release bookkeeping: version/changelog updates and dependency bumps only, with no runtime logic changes in this diff. > > **Overview** > **Release bump only.** Updates the monorepo version to `960.0.0` and publishes `@metamask/bridge-controller@71.1.0` (adds changelog entry and bumps the package version). > > Propagates the new `@metamask/bridge-controller` version to downstream packages (`bridge-status-controller` and `transaction-pay-controller`) and updates `yarn.lock` accordingly. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit ba9bed3. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
## Explanation <!-- 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? --> Adding networks to `controller-utils` that are included in the dynamic registry but were missing from the package Infura networks list. This addition is necessary to get passed the validation checks in `NetworkController` when adding these networks from the dynamic registry (https://client-config.api.cx.metamask.io/v1/config/networks). ## 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 - [ ] 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/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Moderate risk because it expands the set of built-in Infura networks (chain IDs, tickers, explorer URLs, nicknames), which can affect network validation and default network configuration behavior for consumers. > > **Overview** > Adds missing Infura-supported mainnet networks to `controller-utils` by extending `InfuraNetworkType` and related constants (`BuiltInNetworkName`, `ChainId`, `NetworksTicker`, `BlockExplorerUrl`, `NetworkNickname`) for `megaeth-mainnet`, `monad-mainnet`, `avalanche-mainnet`, and `zksync-mainnet`. > > Updates `NetworkController` test snapshots/expectations so these networks are included in default state/config and corresponding Infura network clients, and records the change in the `controller-utils` changelog. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit bd05e8d. 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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )