You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Migrate eth_accounts and permittedChains to CAIP-25 endowment (#27847)
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->
## **Description**
This PR replaces the replaces the internal `eth_accounts` and
`endowment:permittedChains` permission structure with a
[CAIP-25](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-25.md)
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.
[](https://codespaces.new/MetaMask/metamask-extension/pull/27847?quickstart=1)
## **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**
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
### **Before**
<!-- [screenshots/recordings] -->
### **After**
<!-- [screenshots/recordings] -->
## **Pre-merge author checklist**
- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask
Extension Coding
Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I’ve included tests if applicable
- [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)).
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.
---------
Co-authored-by: MetaMask Bot <[email protected]>
Co-authored-by: Alex <[email protected]>
Co-authored-by: Elliot Winkler <[email protected]>
Co-authored-by: Mark Stacey <[email protected]>
Co-authored-by: Erik Marks <[email protected]>
Co-authored-by: Frederik Bolding <[email protected]>
0 commit comments