SIP-26: Account Router Snap #147
Conversation
| - **Account Router**: Native component that forwards signing requests to the | ||
| appropriate Account Snap or native implementation. |
There was a problem hiding this comment.
I see that the Account Router is the one that registers signing methods to the RPC Router, but how are the signing methods registered into the Account Router?
There was a problem hiding this comment.
They are listed in the account object in the methods field.
But it made me think of another problem: the account doesn't list the supported chains (there is a method to get this information, but we should probably move it into the account object).
Co-authored-by: Gustavo Antunes <[email protected]>
Co-authored-by: Charly Chevalier <[email protected]>
| - **Account Address Resolution Snaps**: Snaps that implement the | ||
| `resolveAccountAddress` method to extract the account address from the | ||
| request object. |
There was a problem hiding this comment.
Can these Snaps be the same as Account and Protocol Snaps, or do they have to be separate?
There was a problem hiding this comment.
After talking with @Mrtenz, I believe the Snaps should remain separate. Our goal is for these Snaps to operate without special permissions. Additionally, we should have only one Account Address Resolution Snap per blockchain. This will help simplify the Account (CAIP-2) Snap and prevent any confusion about which Account Address Resolution Snap to use.
| - **Account Snaps**: Snaps that implement the Keyring API and are responsible | ||
| for signing requests and managing accounts. | ||
|
|
||
| - **Protocol Snaps**: Snaps that implement protocol methods that do not require | ||
| an account to be executed. |
There was a problem hiding this comment.
I thought per our discussions with @rekmarks we'd determined that we can't enforce separation of Account + Protocol Snaps?
There was a problem hiding this comment.
Oh I now see the language in your diagram saying that these can be combined. I think its more confusing to represent them as (sortof) separate in the diagram.
As I believe I said in our meeting I don't think we're really getting anything by having these non signing protocol snaps that implement non signing methods if the signing snaps can trivially handle those requests too.
In that case I feel like its clearer to call them something more general than "Account Snaps" since they are not just handling accounts. Maybe "Protocol Snaps" or "CAIP-2 Snaps" (though I'd prefer something that clearly states its purpose without external reference).
There was a problem hiding this comment.
To restate what I said in a meeting: As I read it, they are just two separate permissions that a Snap may or may not put together, and some Snaps (e.g. hardware wallet or SCAs) may want to only ship the account part.
| "<chain_id_1>": [ | ||
| // List of supported methods | ||
| ] | ||
| } |
There was a problem hiding this comment.
this should probably resemble caip-25 and the permission we just created and migrated the old account permissions to:
"eip155:1": {
"methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "get_balance", "personal_sign"],
"notifications": []
},
| "<chain_id_2>", | ||
| // ... | ||
| ] | ||
| } |
There was a problem hiding this comment.
same as below, should resemble caip-25 permission: https://github.com/MetaMask/SIPs/pull/147/files#r1777172390
| method: 'notify:accountCreated', | ||
| params: { | ||
| account: { | ||
| id: '74bb3393-f267-48ee-855a-2ba575291ab0', |
There was a problem hiding this comment.
the snap itself creates the id? we probably shouldn't leave these ids up to the snap developer.
There was a problem hiding this comment.
Yeah, they are UUIDv4, the extension enforces that they are unique when an account is registered.
| account: { | ||
| id: '74bb3393-f267-48ee-855a-2ba575291ab0', | ||
| type: 'eip155:eoa', | ||
| address: '0x1234567890123456789012345678901234567890', |
There was a problem hiding this comment.
this should be a caip-10 address to include the chainid which is missing context here when creating an account:
eip155:1:0xab16a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb
There was a problem hiding this comment.
Yea agreed. We will need some way to associate this account with the appropriate CAIP-2 identifier for routing purposes, whether its making these CAIP-10 addresses or adding a CAIP-2 property on the object.
There was a problem hiding this comment.
This is not a 1:1 mapping to the blockchain account, and for EVM chains the address is the same accross all networks, so I think CAIP-2 addresses are not suitable here.
We have thought about using CAIP-2 namespaces, but it's not in the scope of this SIP, this snippet is an example of the existing API.
| type: 'eip155:eoa', | ||
| address: '0x1234567890123456789012345678901234567890', | ||
| methods: ['eth_signTypedData_v4'], | ||
| options: {}, |
There was a problem hiding this comment.
This is part of the Keyring API and is used by Snap devs to store implementation-dependent information about the account. An example would be to use it to store the tresholds, index, and other metadata used by MPC accounts.
Abstract
This SIP proposes a new API to be implemented by a new Account Router, allowing the forwarding of signing requests to the appropriate account Snap (i.e., Snaps that implement the Keyring API).
Motivation
The Keyring API is being modified to support non-EVM chains. However, a challenge arises in identifying the correct account Snap that should receive the signing request, as this information is often only obtainable from the request itself, which varies based on method and chain.