CAIP-300: Wallet Connect JSON-RPC Method

[lukaisailovic]

This CAIP defines a JSON-RPC method to request a batch of RPC methods to be resolved when connecting a wallet in a single roundtrip.

[KannuSingh]

How will the standard handle the request if one of the rpc method requested via wallet_connect is not supported by the wallet and how in the case where account selected by user for approving the wallet_connect request don't support one of the request in the requested batch?

[pedrouid]

Then the wallet must reject it with 7001 code for invalid method

Or partially reject it with an error message in the batch

[jxom]

Can we consider adding wallet_disconnect to this proposal? Few reasons:

• Just like wallet_connect has been a missing RPC method for years, so has a way to programmatically "disconnect" or "remove a host" from the wallet without the user having to do this in the wallet itself.
• Adding a wallet_disconnect RPC method will further provide strengthened symmetry of this proposal.
• The absense of programmatic disconnect has been a painpoint in Ethereum libraries which interface Dapps to Wallets for years (have had to "polyfill" the behavior on client-side).
• EIP-1193 provides "connect" and "disconnect" events, so having both wallet_connect and wallet_disconnect makes sense.

[bumblefudge]

@lukaisailovic i'm seeing a commit adding jake as author but not one adding a _disconnect method (or for that matter, pointing to the _disconnect method added by the still-open CAIP-285 PR) 😅

holler at me when there's an approval from jake so we can get this merged and visible on the website 😎

[pedrouid]

@jxom there is only one concern with introducing wallet_disconnect here... the different payloads have different purposes

So is the intention to batch them together as a batch "disconnection"... for example you have wallet_authenticate and wallet_createSession... the former is providing a SIWE signature while the latter is enabling a live session with the wallet... are you disconnecting both??

Also regarding ERC-7715 would the wallet_disconnect perform a wallet_revokePermissions??

Definitely agree that the absence of disconnect as a pain-point for Ethereum but I want to make sure we understand the expected behavior for CAIP-300 since it's batching multiple requests

[bumblefudge]

i've lost the plot a bit, what are next steps here, @pedrouid ? this looks complete but I vaguely remember this being blocked on some of the non-DOM connection flows or something? Totally fine to switch it to draft if you're waiting for other implementers or open research questions to finish it.

[glitch-txs]

Some general comments:

• The CAIP could use a chain specification to support requests for different chains.

• It would be nice to add support for transaction requests. Although Smart Sessions allow the user to trigger transactions on the go, a faster approach (for some scenarios and specific contexts) would be for the dapp to request a series of transactions to be executed immediately. In some cases, this simplification could even eliminate the need for a connection altogether.

[glitch-txs]

how does the wallet know which chain is being targeted for each specific method?

Do you think we should add a CAIP-10 Chain reference variable? or am I missing something 😄

Maybe something like this:

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "wallet_connect",
  "params": [{
    "method" : "<method_name>",
    "params": { ...params },
    "namespace": "<chain_id without reference e.g. eip155:1>"
      }]
}

[glitch-txs]

Suggested change

	This proposal enables a one-click experience to fulfill several RPC requests in parallel during the connection approval when it's established when the user is requested to connect its wallet. It gives the ability for a wallet to not only establish a session, but also authenticate the user, expose capabilities or features, define some onchain permissions, etc.
	This proposal enables a one-click experience to fulfill several RPC requests in parallel during the connection approval when it's established when the user is requested to connect its wallet. It gives the ability for a wallet to not only establish a session, but also authenticate the user, expose capabilities or features, define some onchain permissions, execute transactions, etc.