Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions CAIPs/caip-25.md
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,10 @@ Example:
"methods": ["get_balance"],
"notifications": ["accountsChanged", "chainChanged"]
},
"wallet": {

@bumblefudge bumblefudge Apr 13, 2023

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unclear, are these methods:

  1. execution API methods defined in an eip155 namespace with empty scopes and empty chains or
  2. a new namespace named wallet for chainagnostic methods that needs to be created based on the wallet_-prefixed subset of eip155 methods, with CAIP-169 thrown in for good measure?

If you meant this as (2), I would be glad to open a PR in namespaces, and if it's (1), it might also double as a convenient example of when scopes and accounts are both empty by design:

Suggested change
"wallet": {
"eip155": {
"scopes":[],
"acounts":[],

Either way, give me a little more context here and I'll see if this helps us get over the line on consensus with 217!

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO the biggest advantage to renaming "namespaces" to "scopes" is that we get to define a set of methods and notifications which are not necessarily associated with a given chain or namespace

Many of these methods exist today in production (wallet_addEthereumChain, wallet_switchEthereumChain, wallet_watchAsset, wallet_getPermissions and wallet_requestPermisions) yet they are generic wallet methods which are not directly related to any chain

Plus it gets even more powerful once you add CAIP-169 methods ("wallet_creds_store", "wallet_creds_verify", "wallet_creds_issue" and "wallet_creds_present") which are also generic wallet methods that are not directly related to any chain

In my understanding, this PR describes an example that complies with CAIP-217 and CAIP-25 but I thought it was really important to showcase in the spec to share how powerful scopes are

@bumblefudge bumblefudge Apr 13, 2023

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK that sounds more like interpretation # 2 -- I was mostly just thinking ahead to how this relates to the OpenRPC/CAIP-211 stuff (i.e. what the implicit rpcDocuments are for the wallets namespace!), but happy to open a PR on namespaces (I like all examples to be currently-conformant at time of merge haha)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"methods": ["wallet_getPermissions", "wallet_switchEthereumChain", "wallet_creds_store", "wallet_creds_verify", "wallet_creds_issue", "wallet_creds_present"],
"notifications": []
},
"cosmos": {
...
}
Expand Down Expand Up @@ -192,6 +196,10 @@ An example of a successful response follows:
"notifications": ["accountsChanged", "chainChanged"],
"accounts":["eip155:42161:0x0910e12C68d02B561a34569E1367c9AAb42bd810"]
},
"wallet": {
"methods": ["wallet_getPermissions", "wallet_switchEthereumChain", "wallet_creds_store", "wallet_creds_verify", "wallet_creds_issue", "wallet_creds_present"],
"notifications": []
},
"cosmos": {
...
}
Expand Down