Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CAIP-25: The behavior regarding accounts is confusing #144

Open
rekmarks opened this issue Sep 27, 2022 · 1 comment
Open

CAIP-25: The behavior regarding accounts is confusing #144

rekmarks opened this issue Sep 27, 2022 · 1 comment

Comments

@rekmarks
Copy link
Contributor

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:

  1. The request for accounts should be explicit in the caip_handshake request in order for accounts to be selected and returned.
  2. That accounts should not be returned as part of the result at all.
  3. 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.

@bumblefudge
Copy link
Collaborator

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!

  1. Should an optional parameter be added to the request?
  2. Should an error message be added if the dapp requests 1 or more accounts and the user chooses not to give any?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@rekmarks @bumblefudge and others