SIP-25: RPC Routing Snaps #144
Conversation
| 5. **Broadcast Transaction**: The RPC routing Snap broadcasts the signed transaction to the Bitcoin network. | ||
| 6. **Return Result**: The RPC routing Snap returns the result to MetaMask, which forwards it to the dApp. | ||
|
|
||
| ```json |
There was a problem hiding this comment.
This should remove the syntax error highlight from the comment:
| ```json | |
| ```json5 |
There was a problem hiding this comment.
@adonesky1 have you considered who displays the confirmation for requests requiring signatures? I imagine it must be the account snap.
|
|
||
| ## Motivation | ||
|
|
||
| The integration of MetaMask's MultiChain API and protocol Snaps necessitates a standardized approach for routing RPC requests across various blockchain networks. By establishing a standard interface for RPC routing Snaps, we aim to abstract the complexity of non-EVM protocol support away from the MetaMask engineering team, ensuring a seamless and scalable interaction model for decentralized applications (dApps). Because MetaMask is not equipped to interpret requests from non-EVM networks and, for instance, identify which of these requests require signatures or, for methods that do require signatures, which parameters correspond to the account that should sign a transaction, the RPC routing Snap will provide logic for interpreting and routing these requests accordingly. |
There was a problem hiding this comment.
Part of the motivation is to to allow any team to add support for a protocol to MetaMask while maintaining consistent API patterns and avoiding tight code coupling with the whole wallet client codebase. It could still be MetaMask engineering OR external parties contributing code for protocols through Snaps, but they would be able to build, deploy, and maintain protocol support much more efficiently.
|
|
||
| #### Handling Requests | ||
|
|
||
| - **Method**: `handleCaip27Request` |
There was a problem hiding this comment.
| - **Method**: `handleCaip27Request` | |
| - **Method**: `onCAIP27Request` |
We should try to get this matching the existing exports as much as possible.
|
|
||
| ### Minimum Interface for Routing Snaps | ||
|
|
||
| #### Registration with MetaMask |
There was a problem hiding this comment.
Is there a reason we couldn't do registration with a permission instead?
E.g.
{
"initialPermissions": {
"endowment:caip27-router": { "chains": ..., "methods": ..., "events": ... }
}
}| - `methods`: An array JSON-RPC methods the Snap supports. | ||
| - `events`: An array of events the Snap can handle. | ||
|
|
||
| #### Registering Account Snaps |
There was a problem hiding this comment.
Seems like this should be the responsibility of the account Snap to flag as part of its permissions as well.
|
|
||
| 2. **Account Snap Registration**: | ||
| - Account Snaps register with RPC routing Snaps using `accountSnap_register`, declaring their supported CAIP-2 identifiers, methods, and events. | ||
| - RPC routing Snaps maintain a registry of account Snaps and their capabilities. |
There was a problem hiding this comment.
Why would this not fall on MetaMask to maintain this, e.g. via the PermissionController?
|
|
||
| 3. **Handling CAIP-27 Requests**: | ||
| - RPC routing Snaps will interpret incoming CAIP-27 requests, identify the network-specific RPC request format, and route to the appropriate account Snap. | ||
| - If the request does not specify an account the routing Snap must provide UI for users to select from among the eligible signer Snaps for signing the request. |
There was a problem hiding this comment.
Is there a specific reason we would assume the Snap being the best facilitator of this over MetaMask itself?
Abstract
This SIP proposes a minimum standard interface for RPC routing Snaps, which will act as intermediaries between the MetaMask wallet and account Snaps (TODO: add account snaps SIP link here when complete). These routing Snaps will handle registration of account Snaps and interpret incoming CAIP-27 requests, determining whether they require signature and routing them to the appropriate account Snap for signature when applicable. They will broadcast signed transactions to the matching network and return results to MetaMask.
Motivation
The integration of MetaMask's MultiChain API and protocol Snaps necessitates a standardized approach for routing RPC requests across various blockchain networks. By establishing a standard interface for RPC routing Snaps, we aim to abstract the complexity of non-EVM protocol support away from the MetaMask engineering team, ensuring a seamless and scalable interaction model for decentralized applications (dApps). Because MetaMask is not equipped to interpret requests from non-EVM networks and, for instance, identify which of these requests require signatures or, for methods that do require signatures, which parameters correspond to the account that should sign a transaction, the RPC routing Snap will provide logic for interpreting and routing these requests accordingly.
This approach allows for greater flexibility and extensibility, enabling the MetaMask ecosystem to support a wide range of blockchain networks without requiring changes to the core wallet functionality.
This SIP outlines the key responsibilities and minimum interface requirements for RPC routing Snaps, enabling developers to build and deploy routing Snaps for specific blockchain networks.