CAIP-320 wallet switch chain JSON-RPC #344
Conversation
|
|
||
| The JSON-RPC method is labeled as `wallet_switchChain` and expects two parameters, **two of them required**: | ||
|
|
||
| - **sessionId** (conditional) - [CAIP-171][] `SessionId` disambiguates an open session in a multi-session actor; it is required in some sessions, such as [CAIP-25][] sessions created by a response containing one, and SHOULD be omitted in other sessions, such as [CAIP-25] sessions created by a response not containing one (see [CAIP-316]). |
There was a problem hiding this comment.
But is this assuming a CAIP-25 session? Because within a CAIP-25 session, you could just use CAIP-27 and each namespace's specific "switchChain"-equivalent, so I'm unclear on the usecase for a generic multiChain one unless the wallet is volunteering to translate/abstract that namespace-specific syntax.
If a CAIP-25 is assumed, which namespace is the switchChain "targeted" towards? I.e., if a CAIP-25 session is live with 2 different eip155 scopes, which one should switch active chain? If anything, CAIP-25 moves away from "active chain" as a concept, and organizes/partitions the wallet's per-dapp state differently...
If a CAIP-25 connection is not assumed, what should the wallet do if it receives this RPC with a sessionId it doesn't recognize/already know?
Similarly, if a CAIP-25 session (with a sessionId) is already established, but this RPC comes without a sessionId, what is the expected behavior?
|
Hey, this is an interesting addition to the repertoire here! I think I understand the use-case fairly well, but just for my understanding and to get this closer to mergeable, could you maybe sketch out for me an end-to-end example? Ideally, a detailed example, i.e., involving a multi-namespace dapp, and a multi-namespace wallet creating a session, and a realistic example, i.e. involving two namespaces that already use an "active chain" concept and have native RPCs to switch active chains, maybe eip155 and solana? and show why wallet and/or dapps want this, versus using each namespace's native RPCs via CAIP-27 over a CAIP-25 connection? |
| --- | ||
| # Every document starts with a front matter in YAML enclosed by triple dashes. | ||
| # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. | ||
| caip: 320 |
There was a problem hiding this comment.
| caip: 320 | |
| caip: 344 |
Nit: the PR that adds the CAIP gives its number to the CAIP :D
|
|
||
| <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the CAIP.--> | ||
|
|
||
| CAIP-320 introduces the wallet_switchChain method for a chain agnostic wallet to switch the current active chain of the wallet using the id specified in CAIP-2. |
There was a problem hiding this comment.
| CAIP-320 introduces the wallet_switchChain method for a chain agnostic wallet to switch the current active chain of the wallet using the id specified in CAIP-2. | |
| CAIP-344 introduces the wallet_switchChain method for a chain agnostic wallet to switch the current active chain of the wallet using the id specified in CAIP-2. |
|
|
||
| ### Validation | ||
|
|
||
| 1. A respondent SHOULD check the `scope` against active session's `scopeObject`s before executing or responding to such a request, and SHOULD invalidate a request for a scope not previously authorized. |
There was a problem hiding this comment.
but how does it disambiguate if there are two different scopes that it could apply, e.g. eip155 and eip155:1? Or are you assuming a use-case where the scopes eip155:1 and eip155:10 have been authorized, and those are the only two values which can be valid for chainId?
| More informative error messages MAY be sent in trusted-counterparty circumstances. | ||
| The core error messages over trusted connections are as follows: | ||
|
|
||
| The valid error messages codes are the following: |
There was a problem hiding this comment.
Once I'm clearer on the answers above, I may have to return to this section, it's still a little unclear to me if I should be evaluating these error codes as a subset of CAIP-25 errors applicable/valid for this method, or as an alternate set of errors that would be applicable if this were called outside of a CAIP-25 connection!
This CAIP defines a JSON-RPC method for a chain agnostic wallet to switch the current active chain of the wallet using the id specified in CAIP-2.