You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The relationship between accounts and CAIP-25 is, for lack of a better word, strange. The stated motivation of the specification is to define how "to expose accounts and define the expected JSON-RPC methods to be used by an application through a provider connecting to a wallet." Yet, it has very little to say about what accounts are, what the dapp must do to ask for them, and how they are approved by the user.
To see why this may be a problem, consider the only existing CAIP-25 implementation, WalletConnectV2. Per @ganchoradkov and @bkrem, WCv2 will reject caip_handshake requests if eth_accounts is not in the methods array for the eip155 namespace, or if the user does not select any accounts to expose. This is a perfectly reasonable design if you are familiar with Ethereum applications, but you could in no way predict this behavior from the text of CAIP-25.
During the 2022-09-15 CASA gathering, participants suggested that:
The request for accounts should be explicit in the caip_handshake request in order for accounts to be selected and returned.
That accounts should not be returned as part of the result at all.
That requesting accounts should always be optional.
(This was my point.)
Whatever the case, the concept and behavior of "accounts" in CAIP-25 merits further definition.
The text was updated successfully, but these errors were encountered:
Ref: #138
Problem
The relationship between accounts and CAIP-25 is, for lack of a better word, strange. The stated motivation of the specification is to define how "to expose accounts and define the expected JSON-RPC methods to be used by an application through a provider connecting to a wallet." Yet, it has very little to say about what accounts are, what the dapp must do to ask for them, and how they are approved by the user.
To see why this may be a problem, consider the only existing CAIP-25 implementation, WalletConnectV2. Per @ganchoradkov and @bkrem, WCv2 will reject
caip_handshake
requests ifeth_accounts
is not in themethods
array for theeip155
namespace, or if the user does not select any accounts to expose. This is a perfectly reasonable design if you are familiar with Ethereum applications, but you could in no way predict this behavior from the text of CAIP-25.During the 2022-09-15 CASA gathering, participants suggested that:
caip_handshake
request in order for accounts to be selected and returned.Whatever the case, the concept and behavior of "accounts" in CAIP-25 merits further definition.
The text was updated successfully, but these errors were encountered: