CAIP-25: The behavior regarding accounts is confusing
rekmarks opened this issue · comments
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 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.
One quick fix would be to change the language from
The accounts returned as a result should match the requested `chainId`s and
should be an array of CAIP-10 compliant `accountId`s.
to
The accounts returned as a result should match the requested `chainId`s and
should be an array of zero or more CAIP-10 compliant `accountId`s.
But that doesn't really solve the problem of how a dapp communicates to the wallet whether an empty array is acceptable or not!
- Should an optional parameter be added to the request?
- Should an error message be added if the dapp requests 1 or more accounts and the user chooses not to give any?