Description

This PR replaces the replaces the internal eth_accounts and endowment:permittedChains permission structure with a CAIP-25 endowment. It adds adapter logic to translate to and from the new internal CAIP-25 permissions. This change should be transparent to wallet users and to dapps except for one two cases, see below. This change is required in order to support CAIP-25 and CAIP-27 requests in a follow-up PR that enables the Multichain API.

Related issues

Related: MetaMask/core#4784

Manual testing steps

There should be no user or dapp facing difference in behavior except:

• When calling wallet_revokePermissions and specifying either eth_accounts or endowment:permitted-chains, the entire CAIP-25 permission will be revoked. It will appear to the dapp as if both eth_accounts and endowment:permitted-chains were revoked.
• When calling wallet_getPermissions for a permitted dapp when the wallet is locked, eth_accounts should be returned in addition to endowment:permitted-chains. Currently there is a regression on main where only endowment:permitted-chains gets returned when the wallet is locked.

await window.ethereum.request({
 "method": "wallet_revokePermissions",
 "params": [
  {
    eth_accounts: {}
  }
],
});

await window.ethereum.request({
 "method": "wallet_revokePermissions",
 "params": [
  {
    'endowment:permitted-chains': {}
  }
],
});

await window.ethereum.request({
 "method": "wallet_getPermissions",
 "params": [],
});

Locked Wallet Behavior with dapp connected

Other than the two noted items below, this behavior matches that in main

• eth_accounts returns []
• wallet_getPermissions returns permissions incl eth_accounts
• wallet_revokePermissions works as usual and revokes eth_accounts and revoke permitted-chains together
• • Note this fixes a regression in main where eth_accounts and permitted-chains aren't revoked as a pair if either is revoked
• eth_requestAccounts prompts for unlock, after unlock returns accounts if any are permitted, otherwise shows connection prompt
• wallet_requestPermissions prompts for unlock
• signature methods fails with method or accounts not authorized
• non-signature methods work as usual
• accountsChanged empty array on lock. no event after revokePermissions which makes sense since the dapp was told empty array on lock and now it's actually empty array so no changes have occurred as far as the dapp should be concerned.
• CHANGED: for dapps that were granted chain permissions via the wallet_addEthereum or wallet_switchEthereumChain flows without account permissions, these permissions will be removed with this migration. We think this ok because:
  • This is a very uncommon scenario for dapps to request chain switches without account permissions.
  • These permissions can be regained very trivially with subsequent chain switch requests.

Testing the migration

• Create a dev build from main
• Install the dev build from the dist/chrome directory and proceed through onboarding
• Run this command in the background console:

  chrome.storage.local.get(
    null,
    (state) => {
      state.data.PermissionController = {}; // Replace this line based on instructions below
      chrome.storage.local.set(state, () => chrome.runtime.reload());
    }
  );
  

• Disable the extension
• Switch to main and create a dev build
• Enable and reload the extension
  • You should see in the console that migration 139 has failed

Repeat the above steps but with the line above replaced with the following for example:

• state.data.NetworkController = {};
• state.data.NetworkController = 'foobar';
• state.data.NetworkController.selectedNetworkClientId = null;
• state.data.NetworkController.networkConfigurationsByChainId = 'foobar';

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.