From 6572c7079b5fd4e93c21f912b8d37d34d696bef8 Mon Sep 17 00:00:00 2001 From: Alex Date: Mon, 29 Jul 2024 16:27:50 -0500 Subject: [PATCH 1/8] wip --- SIPS/sip-x.md | 226 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 226 insertions(+) create mode 100644 SIPS/sip-x.md diff --git a/SIPS/sip-x.md b/SIPS/sip-x.md new file mode 100644 index 00000000..e5662aeb --- /dev/null +++ b/SIPS/sip-x.md @@ -0,0 +1,226 @@ +--- +sip: x +title: Standard Interface for Bitcoin RPC Router Snaps +status: Draft +discussions-to: TBD +author: Alex Donesky (@adonesky1) +created: 2024-07-29 +--- + +## Abstract + +This SIP proposes a standard interface for Bitcoin RPC router Snaps, which will act as intermediaries between the MetaMask wallet and account Snaps serving the Bitcoin network. These routing Snaps will handle registration of account Snaps and interpret incoming CAIP-27 requests, routing them to the appropriate account Snap for signature or processing, and broadcasting the signed transactions to the Bitcoin network. + +## 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 router 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). + +## Specification + +### Overview + +RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, registering themselves with MetaMask and managing account Snap registrations for their respective networks. They will interpret CAIP-27 requests, route network-specific RPC requests, and facilitate user-specified account Snap options for signing requests, and broadcast signed transactions to the network. + +### Key Responsibilities + +1. **Registration with MetaMask**: + - RPC router Snaps must register with MetaMask for the CAIP-2 identifiers they can serve. + +2. **Account Snap Registration**: + - RPC router Snaps will expose an interface for account Snaps to register themselves based on matching CAIP-2 identifiers. + - Account Snaps must declare the methods and events they support. + +3. **Handling CAIP-27 Requests**: + - RPC router Snaps will interpret incoming CAIP-27 requests, identify the network-specific RPC request format, and route to the appropriate account Snap. + - They must provide an option for users to specify the account Snap for signing requests. + - They will broadcast the signed transactions to the Bitcoin network. + +### Minimum Interface for Routing Snaps + +#### Registration with MetaMask + +- **Method**: `rpcRouter_register` +- **Description**: Registers the routing Snap with MetaMask for a specific CAIP-2 identifier, specifying the methods and events it can handle. +- **Parameters**: + - `caip2`: The CAIP-2 identifier the Snap can handle. + - `methods`: A list of JSON-RPC methods the Snap supports. + - `events`: A list of events the Snap can handle. + +#### Registering Account Snaps + +- **Method**: `accountSnap_register` +- **Description**: Allows account Snaps to register with the routing Snap, specifying the CAIP-2 identifier and the methods and events they support. +- **Parameters**: + - `caip2`: The CAIP-2 identifier the account Snap can handle. + - `methods`: A list of JSON-RPC methods the account Snap supports. + - `events`: A list of events the account Snap can handle. + +#### Handling Requests + +- **Method**: `handleCaip27Request` +- **Description**: Interprets and routes CAIP-27 requests to the appropriate account Snap based on the CAIP-2 identifier and method. +- **Parameters**: + - `scope`: The CAIP-2 identifier of the target chain. + - `request`: The JSON-RPC request object. +- **Example Implementation**: + ```javascript + async function handleCaip27Request(scope, request) { + const { method, params } = request; + const { requiresSignature, account } = identifySignatureMethods(method, params); + + if (requiresSignature) { + const accountSnap = findAccountSnap(scope, method); + if (accountSnap) { + const signedTransaction = await accountSnap.handleRequest(request); + return await broadcastTransaction(signedTransaction); + } else { + throw new Error(`No account Snap found for scope: ${scope} and method: ${method}`); + } + } else { + return await sendDirectRequest(method, params); + } + } + ``` + +### Detailed Functionality + +1. **RPC Router Snap Registration**: + - RPC router Snaps register with MetaMask via `rpcRouter_register`, specifying the CAIP-2 identifiers they can handle and the methods/events they support. + - MetaMask maintains a registry of all RPC router Snaps and their capabilities. + +2. **Account Snap Registration**: + - Account Snaps register with RPC router Snaps using `accountSnap_register`, declaring their supported CAIP-2 identifiers, methods, and events. + - RPC router Snaps maintain a registry of account Snaps and their capabilities. + +3. **Handling CAIP-27 Requests**: + - When MetaMask receives a CAIP-27 request, it validates the request and forwards it to the appropriate RPC router Snap based on the CAIP-2 identifier. + - The RPC router Snap interprets the request and routes it to the appropriate account Snap. + - If the request requires a signature, the RPC router Snap either forwards the request to the appropriate account Snap or allows the user to specify which account Snap should handle the request. + - The signed transaction is then broadcast to the Bitcoin network by the RPC router Snap. + +### Identifying Methods Requiring Signatures + +- **Method**: `identifySignatureMethods` +- **Description**: Identifies which JSON-RPC methods require user signatures and routes these requests to the appropriate account Snap. +- **Parameters**: + - `method`: The JSON-RPC method being requested. + - `params`: The parameters of the JSON-RPC request. +- **Returns**: + - `requiresSignature`: A boolean indicating whether the method requires a signature. + - `account`: The account to be used for signing, if specified. + +- **Example Implementation**: + ```javascript + function identifySignatureMethods(method, params) { + const signatureMethods = ["sendtoaddress", "sendmany", "signrawtransactionwithkey"]; + const requiresSignature = signatureMethods.includes(method); + let account = null; + + if (requiresSignature && params.length > 0) { + account = params[0]; // Example for extracting the account from parameters + } + + return { requiresSignature, account }; + } + ``` + +### Example Workflow for Handling Requests + +#### Request Requiring Signature + +1. **Receive Request**: MetaMask receives a CAIP-27 request to send Bitcoin (`method: sendtoaddress`). +2. **Identify Method**: The RPC router Snap identifies that the `sendtoaddress` method requires a signature. +3. **Route to Account Snap**: The RPC router Snap routes the request to the appropriate Bitcoin account Snap. +4. **Account Snap Signs**: The account Snap signs the transaction. +5. **Broadcast Transaction**: The RPC router Snap broadcasts the signed transaction to the Bitcoin network. +6. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. + +```json +{ + "id": 1, + "jsonrpc": "2.0", + "method": "wallet_invokeMethod", + "params": { + "scope": "bip122:000000000019d6689c085ae165831e93", // Bitcoin Mainnet + "request": { + "method": "sendtoaddress", + "params": [ + "1BitcoinAddress", + 0.1, + "donation", + "seans outpost" + ] + } + } +} +``` + +#### Request Not Requiring Signature + +1. **Receive Request**: MetaMask receives a CAIP-27 request to get the blockchain info (`method: getblockchaininfo`). +2. **Identify Method**: The RPC router Snap identifies that the `getblockchaininfo` method does not require a signature. +3. **Send Direct Request**: The RPC router Snap sends the request directly to the Bitcoin node. +4. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. + +```json +{ + "id": 1, + "jsonrpc": "2.0", + "method": "wallet_invokeMethod", + "params": { + "scope": "bip122:000000000019d6689c085ae165831e93", // Bitcoin Mainnet + "request": { + "method": "getblockchaininfo", + "params": [] + } + } +} +``` + +### Diagram + +```mermaid +sequenceDiagram + participant DApp as DApp + participant MetaMask as MetaMask + participant RouterSnapBTC as Bitcoin Router Snap + participant AccountSnapBTC as Bitcoin Account Snap + participant BTCNode as Bitcoin Node + + %% Registration Flow + rect rgb(255, 245, 245) + RouterSnapBTC->>MetaMask: rpcRouter_register(bip122:000000000019d6689c085ae165831e93, methods, events) + AccountSnapBTC->>RouterSnapBTC: accountSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) + end + + %% CAIP-27 Flow for Request Requiring Signature + rect rgb(245, 245, 255) + DApp->>MetaMask: CAIP + +-27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: sendtoaddress) + MetaMask->>RouterSnapBTC: Forward CAIP-27 Request + RouterSnapBTC->>AccountSnapBTC: Route Request to Account Snap + AccountSnapBTC->>RouterSnapBTC: Return Signed Transaction + RouterSnapBTC->>BTCNode: Broadcast Signed Transaction + RouterSnapBTC->>MetaMask: Forward Result + MetaMask->>DApp: Return Result + end + + %% CAIP-27 Flow for Request Not Requiring Signature + rect rgb(245, 245, 255) + DApp->>MetaMask: CAIP-27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: getblockchaininfo) + MetaMask->>RouterSnapBTC: Forward CAIP-27 Request + RouterSnapBTC->>BTCNode: Send Direct Request + BTCNode->>RouterSnapBTC: Return Result + RouterSnapBTC->>MetaMask: Forward Result + MetaMask->>DApp: Return Result + end +``` + +## Backwards Compatibility + +This proposal introduces new Snap interfaces and does not break existing functionality. It builds upon the CAIP-25 and CAIP-27 standards, ensuring seamless integration with the MultiChain API. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE). From b17655363f0d1e700d7614ee75821da740c81b8b Mon Sep 17 00:00:00 2001 From: Alex Date: Mon, 29 Jul 2024 16:45:30 -0500 Subject: [PATCH 2/8] tweaks --- SIPS/sip-x.md | 127 +++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 116 insertions(+), 11 deletions(-) diff --git a/SIPS/sip-x.md b/SIPS/sip-x.md index e5662aeb..1ddc55c1 100644 --- a/SIPS/sip-x.md +++ b/SIPS/sip-x.md @@ -1,6 +1,7 @@ --- + sip: x -title: Standard Interface for Bitcoin RPC Router Snaps +title: Standard Interface for RPC Router Snaps status: Draft discussions-to: TBD author: Alex Donesky (@adonesky1) @@ -9,7 +10,7 @@ created: 2024-07-29 ## Abstract -This SIP proposes a standard interface for Bitcoin RPC router Snaps, which will act as intermediaries between the MetaMask wallet and account Snaps serving the Bitcoin network. These routing Snaps will handle registration of account Snaps and interpret incoming CAIP-27 requests, routing them to the appropriate account Snap for signature or processing, and broadcasting the signed transactions to the Bitcoin network. +This SIP proposes a standard interface for RPC router Snaps, which will act as intermediaries between the MetaMask wallet and account Snaps serving various blockchain networks. These routing Snaps will handle registration of account Snaps and interpret incoming CAIP-27 requests, routing them to the appropriate account Snap for signature or processing, and broadcasting the signed transactions to the respective blockchain network. ## Motivation @@ -19,7 +20,7 @@ The integration of MetaMask's MultiChain API and protocol Snaps necessitates a s ### Overview -RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, registering themselves with MetaMask and managing account Snap registrations for their respective networks. They will interpret CAIP-27 requests, route network-specific RPC requests, and facilitate user-specified account Snap options for signing requests, and broadcast signed transactions to the network. +RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, registering themselves with MetaMask and managing account Snap registrations for their respective networks. They will interpret CAIP-27 requests, route network-specific RPC requests, facilitate user-specified account Snap options for signing requests, and broadcast signed transactions to the network. ### Key Responsibilities @@ -28,12 +29,12 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r 2. **Account Snap Registration**: - RPC router Snaps will expose an interface for account Snaps to register themselves based on matching CAIP-2 identifiers. - - Account Snaps must declare the methods and events they support. + - Account Snaps must declare the signing methods they support with the router Snap. 3. **Handling CAIP-27 Requests**: - RPC router Snaps will interpret incoming CAIP-27 requests, identify the network-specific RPC request format, and route to the appropriate account Snap. - They must provide an option for users to specify the account Snap for signing requests. - - They will broadcast the signed transactions to the Bitcoin network. + - They will broadcast the signed transactions to the respective blockchain network. ### Minimum Interface for Routing Snaps @@ -96,7 +97,7 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r - When MetaMask receives a CAIP-27 request, it validates the request and forwards it to the appropriate RPC router Snap based on the CAIP-2 identifier. - The RPC router Snap interprets the request and routes it to the appropriate account Snap. - If the request requires a signature, the RPC router Snap either forwards the request to the appropriate account Snap or allows the user to specify which account Snap should handle the request. - - The signed transaction is then broadcast to the Bitcoin network by the RPC router Snap. + - The signed transaction is then broadcast to the respective blockchain network by the RPC router Snap. ### Identifying Methods Requiring Signatures @@ -177,6 +178,86 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r } ``` +### Example Workflow for Solana + +#### Request Requiring Signature + +1. **Receive Request**: MetaMask receives a CAIP-27 request to send Solana (`method: sendTransaction`). +2. **Identify Method**: The RPC router Snap identifies that the `sendTransaction` method requires a signature. +3. **Route to Account Snap**: The RPC router Snap routes the request to the appropriate Solana account Snap. +4. **Account Snap Signs**: The account Snap signs the transaction. +5. **Broadcast Transaction**: The RPC router Snap broadcasts the signed transaction to the Solana network. +6. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. + +```json +{ + "id": 1, + "jsonrpc": "2.0", + "method": "wallet_invokeMethod", + "params": { + "scope": "sol:1", // Solana Mainnet + "request": { + "method": "sendTransaction", + "params": [ + { + "recentBlockhash": "5eykt4UsFv8P8NJdTRE4Rkk4L + +77eC1HbDRHUfW8rQJxa", + "signatures": [ + { + "publicKey": "3No4UR3oHPAbSmQZo3CTsN3tFN6pQ8QyDpXdbFTc6cw2", + "signature": null + } + ], + "instructions": [ + { + "programId": "11111111111111111111111111111111", + "data": "3BxsTbNvQBsMdFNV", + "keys": [ + { + "pubkey": "3No4UR3oHPAbSmQZo3CTsN3tFN6pQ8QyDpXdbFTc6cw2", + "isSigner": true, + "isWritable": true + }, + { + "pubkey": "4No4UR3oHPAbSmQZo3CTsN3tFN6pQ8QyDpXdbFTc6cw2", + "isSigner": false, + "isWritable": false + } + ] + } + ] + } + ] + } + } +} +``` + +#### Request Not Requiring Signature + +1. **Receive Request**: MetaMask receives a CAIP-27 request to get the Solana account info (`method: getAccountInfo`). +2. **Identify Method**: The RPC router Snap identifies that the `getAccountInfo` method does not require a signature. +3. **Send Direct Request**: The RPC router Snap sends the request directly to the Solana node. +4. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. + +```json +{ + "id": 1, + "jsonrpc": "2.0", + "method": "wallet_invokeMethod", + "params": { + "scope": "sol:1", // Solana Mainnet + "request": { + "method": "getAccountInfo", + "params": [ + "3No4UR3oHPAbSmQZo3CTsN3tFN6pQ8QyDpXdbFTc6cw2" + ] + } + } +} +``` + ### Diagram ```mermaid @@ -185,19 +266,22 @@ sequenceDiagram participant MetaMask as MetaMask participant RouterSnapBTC as Bitcoin Router Snap participant AccountSnapBTC as Bitcoin Account Snap + participant RouterSnapSOL as Solana Router Snap + participant AccountSnapSOL as Solana Account Snap participant BTCNode as Bitcoin Node + participant SOLNode as Solana Node %% Registration Flow rect rgb(255, 245, 245) RouterSnapBTC->>MetaMask: rpcRouter_register(bip122:000000000019d6689c085ae165831e93, methods, events) AccountSnapBTC->>RouterSnapBTC: accountSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) + RouterSnapSOL->>MetaMask: rpcRouter_register(sol:1, methods, events) + AccountSnapSOL->>RouterSnapSOL: accountSnap_register(sol:1, methods, events) end - %% CAIP-27 Flow for Request Requiring Signature + %% CAIP-27 Flow for Bitcoin Request Requiring Signature rect rgb(245, 245, 255) - DApp->>MetaMask: CAIP - --27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: sendtoaddress) + DApp->>MetaMask: CAIP-27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: sendtoaddress) MetaMask->>RouterSnapBTC: Forward CAIP-27 Request RouterSnapBTC->>AccountSnapBTC: Route Request to Account Snap AccountSnapBTC->>RouterSnapBTC: Return Signed Transaction @@ -206,7 +290,7 @@ sequenceDiagram MetaMask->>DApp: Return Result end - %% CAIP-27 Flow for Request Not Requiring Signature + %% CAIP-27 Flow for Bitcoin Request Not Requiring Signature rect rgb(245, 245, 255) DApp->>MetaMask: CAIP-27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: getblockchaininfo) MetaMask->>RouterSnapBTC: Forward CAIP-27 Request @@ -215,6 +299,27 @@ sequenceDiagram RouterSnapBTC->>MetaMask: Forward Result MetaMask->>DApp: Return Result end + + %% CAIP-27 Flow for Solana Request Requiring Signature + rect rgb(245, 245, 255) + DApp->>MetaMask: CAIP-27 Request (scope: sol:1, method: sendTransaction) + MetaMask->>RouterSnapSOL: Forward CAIP-27 Request + RouterSnapSOL->>AccountSnapSOL: Route Request to Account Snap + AccountSnapSOL->>RouterSnapSOL: Return Signed Transaction + RouterSnapSOL->>SOLNode: Broadcast Signed Transaction + RouterSnapSOL->>MetaMask: Forward Result + MetaMask->>DApp: Return Result + end + + %% CAIP-27 Flow for Solana Request Not Requiring Signature + rect rgb(245, 245, 255) + DApp->>MetaMask: CAIP-27 Request (scope: sol:1, method: getAccountInfo) + MetaMask->>RouterSnapSOL: Forward CAIP-27 Request + RouterSnapSOL->>SOLNode: Send Direct Request + SOLNode->>RouterSnapSOL: Return Result + RouterSnapSOL->>MetaMask: Forward Result + MetaMask->>DApp: Return Result + end ``` ## Backwards Compatibility From 547067433df0064a870ee95ec0165bfdfe44a028 Mon Sep 17 00:00:00 2001 From: Alex Date: Sat, 10 Aug 2024 19:44:11 -0700 Subject: [PATCH 3/8] more tweaking --- SIPS/sip-x.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/SIPS/sip-x.md b/SIPS/sip-x.md index 1ddc55c1..4ec38ccf 100644 --- a/SIPS/sip-x.md +++ b/SIPS/sip-x.md @@ -10,17 +10,19 @@ created: 2024-07-29 ## Abstract -This SIP proposes a standard interface for RPC router Snaps, which will act as intermediaries between the MetaMask wallet and account Snaps serving various blockchain networks. These routing Snaps will handle registration of account Snaps and interpret incoming CAIP-27 requests, routing them to the appropriate account Snap for signature or processing, and broadcasting the signed transactions to the respective blockchain network. +This SIP proposes a minimum standard interface for RPC router 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 router 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). +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 router 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 requests require signatures or, for methods that do require signatures, which parameters correspond to the account that should sign a transaction, the RPC router Snap will provide logic for interpreting and routing these requests accordingly. + +This SIP outlines the key responsibilities and minimum interface requirements for RPC router Snaps, enabling developers to build and deploy routing Snaps for specific blockchain networks. ## Specification ### Overview -RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, registering themselves with MetaMask and managing account Snap registrations for their respective networks. They will interpret CAIP-27 requests, route network-specific RPC requests, facilitate user-specified account Snap options for signing requests, and broadcast signed transactions to the network. +RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, registering themselves with MetaMask and managing account Snap registrations for their respective networks. They will interpret non-EVM CAIP-27 requests made to their registred CAIP-2 identifier, route these requests, facilitate user-specified account Snap options for signing requests, and broadcast signed transactions to the network. ### Key Responsibilities @@ -33,8 +35,9 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r 3. **Handling CAIP-27 Requests**: - RPC router Snaps will interpret incoming CAIP-27 requests, identify the network-specific RPC request format, and route to the appropriate account Snap. - - They must provide an option for users to specify the account Snap for signing requests. - - They will broadcast the signed transactions to the respective blockchain network. + - If the request does not specify an account the router snap must provide UI for users to select from among the eligible signer Snaps for signing the request. + - They will broadcast the signed transactions to the respective blockchain network and return the result to MetaMask. + - They will also handle requests that do not require signatures by sending them directly to the network and returning the result to MetaMask. ### Minimum Interface for Routing Snaps @@ -70,7 +73,7 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r const { requiresSignature, account } = identifySignatureMethods(method, params); if (requiresSignature) { - const accountSnap = findAccountSnap(scope, method); + const accountSnap = await findOrUserSelectAccountSnap(scope, method); if (accountSnap) { const signedTransaction = await accountSnap.handleRequest(request); return await broadcastTransaction(signedTransaction); @@ -184,8 +187,8 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r 1. **Receive Request**: MetaMask receives a CAIP-27 request to send Solana (`method: sendTransaction`). 2. **Identify Method**: The RPC router Snap identifies that the `sendTransaction` method requires a signature. -3. **Route to Account Snap**: The RPC router Snap routes the request to the appropriate Solana account Snap. -4. **Account Snap Signs**: The account Snap signs the transaction. +3. **Route to Account Snap**: The RPC router Snap identifies that the CAIP-27 request does not identify an account to sign and prompts the user to select an account to sign and routes the request to the appropriate Solana account Snap. +4. **Account Snap Signs**: The account Snap signs the transaction and sends the signed transaction back to the RPC router Snap. 5. **Broadcast Transaction**: The RPC router Snap broadcasts the signed transaction to the Solana network. 6. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. From 351b1bb688c184115fabd0ab17aaefb34a87b8c2 Mon Sep 17 00:00:00 2001 From: Alex Date: Mon, 12 Aug 2024 12:50:20 -0700 Subject: [PATCH 4/8] further tweaks --- SIPS/sip-x.md | 56 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 44 insertions(+), 12 deletions(-) diff --git a/SIPS/sip-x.md b/SIPS/sip-x.md index 4ec38ccf..bd7eaf5d 100644 --- a/SIPS/sip-x.md +++ b/SIPS/sip-x.md @@ -12,10 +12,13 @@ created: 2024-07-29 This SIP proposes a minimum standard interface for RPC router 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 router 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 requests require signatures or, for methods that do require signatures, which parameters correspond to the account that should sign a transaction, the RPC router 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 router Snaps, enabling developers to build and deploy routing Snaps for specific blockchain networks. ## Specification @@ -67,15 +70,24 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r - `scope`: The CAIP-2 identifier of the target chain. - `request`: The JSON-RPC request object. - **Example Implementation**: - ```javascript - async function handleCaip27Request(scope, request) { + ```typescript + interface JsonRpcRequest { + method: string; + params: any[]; + } + + interface AccountSnap { + handleRequest(request: JsonRpcRequest): Promise; + } + + async function handleCaip27Request(scope: string, request: JsonRpcRequest): Promise { const { method, params } = request; const { requiresSignature, account } = identifySignatureMethods(method, params); if (requiresSignature) { - const accountSnap = await findOrUserSelectAccountSnap(scope, method); + const accountSnap: AccountSnap | null = await findOrUserSelectAccountSnap(scope, method); if (accountSnap) { - const signedTransaction = await accountSnap.handleRequest(request); + const signedTransaction: string = await accountSnap.handleRequest(request); return await broadcastTransaction(signedTransaction); } else { throw new Error(`No account Snap found for scope: ${scope} and method: ${method}`); @@ -85,6 +97,7 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r } } ``` +- **Error Handling**: The method should include appropriate error handling and return clear error messages for scenarios such as unsupported methods, network issues, or signature failures. ### Detailed Functionality @@ -114,19 +127,23 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r - `account`: The account to be used for signing, if specified. - **Example Implementation**: - ```javascript - function identifySignatureMethods(method, params) { - const signatureMethods = ["sendtoaddress", "sendmany", "signrawtransactionwithkey"]; - const requiresSignature = signatureMethods.includes(method); - let account = null; + ```typescript + interface SignatureMethodResult { + requiresSignature: boolean; + account: string | null; + } + + function identifySignatureMethods(method: string, params: any[]): SignatureMethodResult { + const signatureMethods: string[] = ["sendtoaddress", "sendmany", "signrawtransactionwithkey"]; + const requiresSignature: boolean = signatureMethods.includes(method); + let account: string | null = null; if (requiresSignature && params.length > 0) { - account = params[0]; // Example for extracting the account from parameters + account = params[0] as string; // Example for extracting the account from parameters } return { requiresSignature, account }; } - ``` ### Example Workflow for Handling Requests @@ -159,6 +176,8 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r } ``` +**Note:** Implementing proper security measures, such as validating the origin of requests and ensuring secure communication between Snaps, is crucial for maintaining the integrity of the system. + #### Request Not Requiring Signature 1. **Receive Request**: MetaMask receives a CAIP-27 request to get the blockchain info (`method: getblockchaininfo`). @@ -327,7 +346,20 @@ sequenceDiagram ## Backwards Compatibility -This proposal introduces new Snap interfaces and does not break existing functionality. It builds upon the CAIP-25 and CAIP-27 standards, ensuring seamless integration with the MultiChain API. +This proposal introduces new Snap interfaces and does not break existing functionality. It builds upon the CAIP-25 and CAIP-27 standards, ensuring seamless integration with the MultiChain API. Existing dApps and Snaps that do not utilize these new interfaces will continue to function as before. + + +## Security Considerations + +Implementing this RPC router Snap interface introduces new security considerations: + +1. Proper validation of incoming requests to prevent malicious actions. +2. Secure communication between MetaMask, router Snaps, and account Snaps. +3. Careful management of permissions to prevent unauthorized access to accounts or sensitive operations. +4. Robust error handling to prevent information leakage or system instability. + +Developers implementing these interfaces should conduct thorough security audits and follow best practices for secure coding and key management. + ## Copyright From 89dd8907879364a6dc376198382d1955db3bf471 Mon Sep 17 00:00:00 2001 From: Alex Date: Mon, 12 Aug 2024 14:32:46 -0700 Subject: [PATCH 5/8] cleanup --- SIPS/sip-x.md | 198 ++++++++++++-------------------------------------- 1 file changed, 45 insertions(+), 153 deletions(-) diff --git a/SIPS/sip-x.md b/SIPS/sip-x.md index bd7eaf5d..139dac08 100644 --- a/SIPS/sip-x.md +++ b/SIPS/sip-x.md @@ -1,7 +1,7 @@ --- sip: x -title: Standard Interface for RPC Router Snaps +title: Standard Interface for RPC routing Snaps status: Draft discussions-to: TBD author: Alex Donesky (@adonesky1) @@ -10,35 +10,35 @@ created: 2024-07-29 ## Abstract -This SIP proposes a minimum standard interface for RPC router 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. +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](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-27.md) 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 router 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 requests require signatures or, for methods that do require signatures, which parameters correspond to the account that should sign a transaction, the RPC router Snap will provide logic for interpreting and routing these requests accordingly. +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 router Snaps, enabling developers to build and deploy routing Snaps for specific blockchain networks. +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. ## Specification ### Overview -RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, registering themselves with MetaMask and managing account Snap registrations for their respective networks. They will interpret non-EVM CAIP-27 requests made to their registred CAIP-2 identifier, route these requests, facilitate user-specified account Snap options for signing requests, and broadcast signed transactions to the network. +RPC routing Snaps will serve as intermediaries for specific [CAIP-2](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-2.md) identifiers, registering themselves with MetaMask and managing account Snap registrations for their respective networks. They will interpret CAIP-27 requests targeting non-EVM networks made to their registered CAIP-2 identifier, route these requests, facilitate user-specified account Snap options for signing requests, and broadcast signed transactions to the network. ### Key Responsibilities 1. **Registration with MetaMask**: - - RPC router Snaps must register with MetaMask for the CAIP-2 identifiers they can serve. + - RPC routing Snaps must register with MetaMask for the CAIP-2 identifiers they can serve. 2. **Account Snap Registration**: - - RPC router Snaps will expose an interface for account Snaps to register themselves based on matching CAIP-2 identifiers. - - Account Snaps must declare the signing methods they support with the router Snap. + - RPC routing Snaps will expose an interface for account Snaps which serve the same CAIP-2 identifier to register themselves with the routing Snap. + - Account Snaps must declare the signing methods they support with the routing Snap. 3. **Handling CAIP-27 Requests**: - - RPC router 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 router snap must provide UI for users to select from among the eligible signer Snaps for signing the request. + - 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. - They will broadcast the signed transactions to the respective blockchain network and return the result to MetaMask. - They will also handle requests that do not require signatures by sending them directly to the network and returning the result to MetaMask. @@ -46,26 +46,26 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r #### Registration with MetaMask -- **Method**: `rpcRouter_register` -- **Description**: Registers the routing Snap with MetaMask for a specific CAIP-2 identifier, specifying the methods and events it can handle. +- **Method**: `routingSnap_register` +- **Description**: Registers the routing Snap with MetaMask for a specific CAIP-2 identifier(s), specifying the methods and events it can handle. - **Parameters**: - - `caip2`: The CAIP-2 identifier the Snap can handle. - - `methods`: A list of JSON-RPC methods the Snap supports. - - `events`: A list of events the Snap can handle. + - `chains`: An array of CAIP-2 identifiers the Snap can handle. + - `methods`: An array JSON-RPC methods the Snap supports. + - `events`: An array of events the Snap can handle. #### Registering Account Snaps - **Method**: `accountSnap_register` -- **Description**: Allows account Snaps to register with the routing Snap, specifying the CAIP-2 identifier and the methods and events they support. +- **Description**: Allows account Snaps to register with the routing Snap, specifying the CAIP-2(s) identifier and the methods and events they support. - **Parameters**: - - `caip2`: The CAIP-2 identifier the account Snap can handle. - - `methods`: A list of JSON-RPC methods the account Snap supports. - - `events`: A list of events the account Snap can handle. + - `caip2`: An array of CAIP-2 identifiers the Snap can handle + - `methods`: An array of JSON-RPC methods the account Snap supports. + - `events`: An array of events the account Snap can handle. #### Handling Requests - **Method**: `handleCaip27Request` -- **Description**: Interprets and routes CAIP-27 requests to the appropriate account Snap based on the CAIP-2 identifier and method. +- **Description**: Interprets and routes CAIP-27 requests to an appropriate account Snap based on the CAIP-2 identifier and method. - **Parameters**: - `scope`: The CAIP-2 identifier of the target chain. - `request`: The JSON-RPC request object. @@ -101,60 +101,32 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r ### Detailed Functionality -1. **RPC Router Snap Registration**: - - RPC router Snaps register with MetaMask via `rpcRouter_register`, specifying the CAIP-2 identifiers they can handle and the methods/events they support. - - MetaMask maintains a registry of all RPC router Snaps and their capabilities. +1. **RPC routing Snap Registration**: + - RPC routing Snaps register with MetaMask via `routingSnap_register`, + specifying the CAIP-2 identifier(s) they can handle and the methods/events + they support. + - MetaMask maintains a registry of all RPC routing Snaps and their capabilities. 2. **Account Snap Registration**: - - Account Snaps register with RPC router Snaps using `accountSnap_register`, declaring their supported CAIP-2 identifiers, methods, and events. - - RPC router Snaps maintain a registry of account Snaps and their capabilities. + - 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. 3. **Handling CAIP-27 Requests**: - - When MetaMask receives a CAIP-27 request, it validates the request and forwards it to the appropriate RPC router Snap based on the CAIP-2 identifier. - - The RPC router Snap interprets the request and routes it to the appropriate account Snap. - - If the request requires a signature, the RPC router Snap either forwards the request to the appropriate account Snap or allows the user to specify which account Snap should handle the request. - - The signed transaction is then broadcast to the respective blockchain network by the RPC router Snap. - -### Identifying Methods Requiring Signatures - -- **Method**: `identifySignatureMethods` -- **Description**: Identifies which JSON-RPC methods require user signatures and routes these requests to the appropriate account Snap. -- **Parameters**: - - `method`: The JSON-RPC method being requested. - - `params`: The parameters of the JSON-RPC request. -- **Returns**: - - `requiresSignature`: A boolean indicating whether the method requires a signature. - - `account`: The account to be used for signing, if specified. - -- **Example Implementation**: - ```typescript - interface SignatureMethodResult { - requiresSignature: boolean; - account: string | null; - } - - function identifySignatureMethods(method: string, params: any[]): SignatureMethodResult { - const signatureMethods: string[] = ["sendtoaddress", "sendmany", "signrawtransactionwithkey"]; - const requiresSignature: boolean = signatureMethods.includes(method); - let account: string | null = null; - - if (requiresSignature && params.length > 0) { - account = params[0] as string; // Example for extracting the account from parameters - } - - return { requiresSignature, account }; - } + - When MetaMask receives a CAIP-27 request, it validates the request and forwards it to the appropriate RPC routing Snap based on the CAIP-2 identifier. + - The RPC routing Snap interprets the request and routes it to the appropriate account Snap. + - If the request requires a signature, the RPC routing Snap either forwards the request to the appropriate account Snap or allows the user to specify which account Snap should handle the request. + - The signed transaction is then broadcast to the respective blockchain network by the RPC routing Snap. ### Example Workflow for Handling Requests #### Request Requiring Signature 1. **Receive Request**: MetaMask receives a CAIP-27 request to send Bitcoin (`method: sendtoaddress`). -2. **Identify Method**: The RPC router Snap identifies that the `sendtoaddress` method requires a signature. -3. **Route to Account Snap**: The RPC router Snap routes the request to the appropriate Bitcoin account Snap. -4. **Account Snap Signs**: The account Snap signs the transaction. -5. **Broadcast Transaction**: The RPC router Snap broadcasts the signed transaction to the Bitcoin network. -6. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. +2. **Identify Method**: The RPC routing Snap identifies that the `sendtoaddress` method requires a signature and doesn't contain the address from which the send should occur. +3. **Route to Account Snap**: The RPC routing Snap routes the request to an eligible Bitcoin account Snap. +4. **Account Snap Signs**: The account Snap signs the transaction and sends the signed transaction back to the RPC routing Snap. +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 { @@ -181,9 +153,9 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r #### Request Not Requiring Signature 1. **Receive Request**: MetaMask receives a CAIP-27 request to get the blockchain info (`method: getblockchaininfo`). -2. **Identify Method**: The RPC router Snap identifies that the `getblockchaininfo` method does not require a signature. -3. **Send Direct Request**: The RPC router Snap sends the request directly to the Bitcoin node. -4. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. +2. **Identify Method**: The RPC routing Snap identifies that the `getblockchaininfo` method does not require a signature. +3. **Send Direct Request**: The RPC routing Snap sends the request directly to the Bitcoin node. +4. **Return Result**: The RPC routing Snap returns the result to MetaMask, which forwards it to the dApp. ```json { @@ -200,104 +172,24 @@ RPC router Snaps will serve as intermediaries for specific CAIP-2 identifiers, r } ``` -### Example Workflow for Solana - -#### Request Requiring Signature - -1. **Receive Request**: MetaMask receives a CAIP-27 request to send Solana (`method: sendTransaction`). -2. **Identify Method**: The RPC router Snap identifies that the `sendTransaction` method requires a signature. -3. **Route to Account Snap**: The RPC router Snap identifies that the CAIP-27 request does not identify an account to sign and prompts the user to select an account to sign and routes the request to the appropriate Solana account Snap. -4. **Account Snap Signs**: The account Snap signs the transaction and sends the signed transaction back to the RPC router Snap. -5. **Broadcast Transaction**: The RPC router Snap broadcasts the signed transaction to the Solana network. -6. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. - -```json -{ - "id": 1, - "jsonrpc": "2.0", - "method": "wallet_invokeMethod", - "params": { - "scope": "sol:1", // Solana Mainnet - "request": { - "method": "sendTransaction", - "params": [ - { - "recentBlockhash": "5eykt4UsFv8P8NJdTRE4Rkk4L - -77eC1HbDRHUfW8rQJxa", - "signatures": [ - { - "publicKey": "3No4UR3oHPAbSmQZo3CTsN3tFN6pQ8QyDpXdbFTc6cw2", - "signature": null - } - ], - "instructions": [ - { - "programId": "11111111111111111111111111111111", - "data": "3BxsTbNvQBsMdFNV", - "keys": [ - { - "pubkey": "3No4UR3oHPAbSmQZo3CTsN3tFN6pQ8QyDpXdbFTc6cw2", - "isSigner": true, - "isWritable": true - }, - { - "pubkey": "4No4UR3oHPAbSmQZo3CTsN3tFN6pQ8QyDpXdbFTc6cw2", - "isSigner": false, - "isWritable": false - } - ] - } - ] - } - ] - } - } -} -``` - -#### Request Not Requiring Signature - -1. **Receive Request**: MetaMask receives a CAIP-27 request to get the Solana account info (`method: getAccountInfo`). -2. **Identify Method**: The RPC router Snap identifies that the `getAccountInfo` method does not require a signature. -3. **Send Direct Request**: The RPC router Snap sends the request directly to the Solana node. -4. **Return Result**: The RPC router Snap returns the result to MetaMask, which forwards it to the dApp. - -```json -{ - "id": 1, - "jsonrpc": "2.0", - "method": "wallet_invokeMethod", - "params": { - "scope": "sol:1", // Solana Mainnet - "request": { - "method": "getAccountInfo", - "params": [ - "3No4UR3oHPAbSmQZo3CTsN3tFN6pQ8QyDpXdbFTc6cw2" - ] - } - } -} -``` - ### Diagram ```mermaid sequenceDiagram participant DApp as DApp participant MetaMask as MetaMask - participant RouterSnapBTC as Bitcoin Router Snap + participant RouterSnapBTC as Bitcoin routing Snap participant AccountSnapBTC as Bitcoin Account Snap - participant RouterSnapSOL as Solana Router Snap + participant RouterSnapSOL as Solana routing Snap participant AccountSnapSOL as Solana Account Snap participant BTCNode as Bitcoin Node participant SOLNode as Solana Node %% Registration Flow rect rgb(255, 245, 245) - RouterSnapBTC->>MetaMask: rpcRouter_register(bip122:000000000019d6689c085ae165831e93, methods, events) + RouterSnapBTC->>MetaMask: routingSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) AccountSnapBTC->>RouterSnapBTC: accountSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) - RouterSnapSOL->>MetaMask: rpcRouter_register(sol:1, methods, events) + RouterSnapSOL->>MetaMask: routingSnap_register(sol:1, methods, events) AccountSnapSOL->>RouterSnapSOL: accountSnap_register(sol:1, methods, events) end @@ -351,10 +243,10 @@ This proposal introduces new Snap interfaces and does not break existing functio ## Security Considerations -Implementing this RPC router Snap interface introduces new security considerations: +Implementing this RPC routing Snap interface introduces new security considerations: 1. Proper validation of incoming requests to prevent malicious actions. -2. Secure communication between MetaMask, router Snaps, and account Snaps. +2. Secure communication between MetaMask, routing Snaps, and account Snaps. 3. Careful management of permissions to prevent unauthorized access to accounts or sensitive operations. 4. Robust error handling to prevent information leakage or system instability. From 81b424dc415514c1d64a1975bb2dec48970889ca Mon Sep 17 00:00:00 2001 From: Alex Date: Mon, 12 Aug 2024 14:34:20 -0700 Subject: [PATCH 6/8] cleanup/improve diagram --- SIPS/sip-x.md | 72 +++++++++++++++++++-------------------------------- 1 file changed, 26 insertions(+), 46 deletions(-) diff --git a/SIPS/sip-x.md b/SIPS/sip-x.md index 139dac08..b090523c 100644 --- a/SIPS/sip-x.md +++ b/SIPS/sip-x.md @@ -177,62 +177,42 @@ RPC routing Snaps will serve as intermediaries for specific [CAIP-2](https://git ```mermaid sequenceDiagram participant DApp as DApp + participant SnapsUI as Snaps UI participant MetaMask as MetaMask participant RouterSnapBTC as Bitcoin routing Snap - participant AccountSnapBTC as Bitcoin Account Snap - participant RouterSnapSOL as Solana routing Snap - participant AccountSnapSOL as Solana Account Snap + participant AccountSnapBTC1 as Bitcoin Account Snap 1 + participant AccountSnapBTC2 as Bitcoin Account Snap 2 participant BTCNode as Bitcoin Node - participant SOLNode as Solana Node - %% Registration Flow rect rgb(255, 245, 245) - RouterSnapBTC->>MetaMask: routingSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) - AccountSnapBTC->>RouterSnapBTC: accountSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) - RouterSnapSOL->>MetaMask: routingSnap_register(sol:1, methods, events) - AccountSnapSOL->>RouterSnapSOL: accountSnap_register(sol:1, methods, events) + Note over RouterSnapBTC,AccountSnapBTC2: Registration Flow + RouterSnapBTC->>MetaMask: routingSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) + AccountSnapBTC1->>RouterSnapBTC: accountSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) + AccountSnapBTC2->>RouterSnapBTC: accountSnap_register(bip122:000000000019d6689c085ae165831e93, methods, events) end - %% CAIP-27 Flow for Bitcoin Request Requiring Signature rect rgb(245, 245, 255) - DApp->>MetaMask: CAIP-27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: sendtoaddress) - MetaMask->>RouterSnapBTC: Forward CAIP-27 Request - RouterSnapBTC->>AccountSnapBTC: Route Request to Account Snap - AccountSnapBTC->>RouterSnapBTC: Return Signed Transaction - RouterSnapBTC->>BTCNode: Broadcast Signed Transaction - RouterSnapBTC->>MetaMask: Forward Result - MetaMask->>DApp: Return Result + Note over DApp,MetaMask: CAIP-27 Flow: Bitcoin Request Requiring Signature (with user selection) + DApp->>MetaMask: CAIP-27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: sendtoaddress) + MetaMask->>RouterSnapBTC: Forward CAIP-27 Request + RouterSnapBTC->>SnapsUI: Prompt to select Account Snap + SnapsUI->>RouterSnapBTC: Select Account Snap (AccountSnapBTC1) + RouterSnapBTC->>AccountSnapBTC1: Route Request to Selected Account Snap + AccountSnapBTC1->>RouterSnapBTC: Return Signed Transaction + RouterSnapBTC->>BTCNode: Broadcast Signed Transaction + BTCNode->>RouterSnapBTC: Return Transaction Result + RouterSnapBTC->>MetaMask: Forward Result + MetaMask->>DApp: Return Result end - %% CAIP-27 Flow for Bitcoin Request Not Requiring Signature - rect rgb(245, 245, 255) - DApp->>MetaMask: CAIP-27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: getblockchaininfo) - MetaMask->>RouterSnapBTC: Forward CAIP-27 Request - RouterSnapBTC->>BTCNode: Send Direct Request - BTCNode->>RouterSnapBTC: Return Result - RouterSnapBTC->>MetaMask: Forward Result - MetaMask->>DApp: Return Result - end - - %% CAIP-27 Flow for Solana Request Requiring Signature - rect rgb(245, 245, 255) - DApp->>MetaMask: CAIP-27 Request (scope: sol:1, method: sendTransaction) - MetaMask->>RouterSnapSOL: Forward CAIP-27 Request - RouterSnapSOL->>AccountSnapSOL: Route Request to Account Snap - AccountSnapSOL->>RouterSnapSOL: Return Signed Transaction - RouterSnapSOL->>SOLNode: Broadcast Signed Transaction - RouterSnapSOL->>MetaMask: Forward Result - MetaMask->>DApp: Return Result - end - - %% CAIP-27 Flow for Solana Request Not Requiring Signature - rect rgb(245, 245, 255) - DApp->>MetaMask: CAIP-27 Request (scope: sol:1, method: getAccountInfo) - MetaMask->>RouterSnapSOL: Forward CAIP-27 Request - RouterSnapSOL->>SOLNode: Send Direct Request - SOLNode->>RouterSnapSOL: Return Result - RouterSnapSOL->>MetaMask: Forward Result - MetaMask->>DApp: Return Result + rect rgb(225, 225, 255) + Note over DApp,MetaMask: CAIP-27 Flow: Bitcoin Request Not Requiring Signature + DApp->>MetaMask: CAIP-27 Request (scope: bip122:000000000019d6689c085ae165831e93, method: getblockchaininfo) + MetaMask->>RouterSnapBTC: Forward CAIP-27 Request + RouterSnapBTC->>BTCNode: Forward BTC Request directly to BTC Node + BTCNode->>RouterSnapBTC: Return Query Result + RouterSnapBTC->>MetaMask: Forward Result + MetaMask->>DApp: Return Result end ``` From 61a6547d1711e670202b92e7ce9674a3d3c10293 Mon Sep 17 00:00:00 2001 From: Alex Date: Mon, 12 Aug 2024 14:35:15 -0700 Subject: [PATCH 7/8] cleanup --- SIPS/sip-x.md | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/SIPS/sip-x.md b/SIPS/sip-x.md index b090523c..a4aa2bcc 100644 --- a/SIPS/sip-x.md +++ b/SIPS/sip-x.md @@ -220,19 +220,6 @@ sequenceDiagram This proposal introduces new Snap interfaces and does not break existing functionality. It builds upon the CAIP-25 and CAIP-27 standards, ensuring seamless integration with the MultiChain API. Existing dApps and Snaps that do not utilize these new interfaces will continue to function as before. - -## Security Considerations - -Implementing this RPC routing Snap interface introduces new security considerations: - -1. Proper validation of incoming requests to prevent malicious actions. -2. Secure communication between MetaMask, routing Snaps, and account Snaps. -3. Careful management of permissions to prevent unauthorized access to accounts or sensitive operations. -4. Robust error handling to prevent information leakage or system instability. - -Developers implementing these interfaces should conduct thorough security audits and follow best practices for secure coding and key management. - - ## Copyright Copyright and related rights waived via [CC0](../LICENSE). From 5db9e0d23fa225cb060a899680951f4f7966ae0c Mon Sep 17 00:00:00 2001 From: Alex Date: Mon, 12 Aug 2024 14:39:51 -0700 Subject: [PATCH 8/8] add sip number --- SIPS/{sip-x.md => sip-25.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename SIPS/{sip-x.md => sip-25.md} (99%) diff --git a/SIPS/sip-x.md b/SIPS/sip-25.md similarity index 99% rename from SIPS/sip-x.md rename to SIPS/sip-25.md index a4aa2bcc..62c854c0 100644 --- a/SIPS/sip-x.md +++ b/SIPS/sip-25.md @@ -1,9 +1,9 @@ --- -sip: x +sip: 25 title: Standard Interface for RPC routing Snaps status: Draft -discussions-to: TBD +discussions-to: https://github.com/MetaMask/SIPs/discussions/145 author: Alex Donesky (@adonesky1) created: 2024-07-29 ---