-
Notifications
You must be signed in to change notification settings - Fork 162
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
Update CAIP-25 based on CASA Gathering in Amsterdam #108
Conversation
@pedrouid Would it make more sense to separate the chain from the id and change params from a list of Namespaces to a map like the one below? It'll help reduce having to repeat chain info like
|
I was in another session in parallel - just reading up on the notes- would be great to discuss this in the next call. While I see where this is coming from - IMHO it is a bit unfortunate that we manifest the statefulnes regarding chain/account even more. I think in an ideal world we should not have a "current account" / "current chain" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said: formally (from an editors point of view I approve this change)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved with one non-blocking suggestion. I'll follow up with some notes regarding the shape of the params.
} | ||
``` | ||
|
||
The JSON-RPC method is labelled as `caip_handshake` and expects two parameters: | ||
The JSON-RPC method is labelled as `caip_handshake` and expects an array with objects with three parameters: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The JSON-RPC method is labelled as `caip_handshake` and expects an array with objects with three parameters: | |
The JSON-RPC method is labelled as `caip_handshake` and expects an array with objects with three properties: |
@Talhaali00 I like that. Your format with some modifications: params: { // object instead of array
"eip155" : {
"chains": ["1"], // namespace omitted from chainId
"methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign"]
"events": ["accountsChanged", "chainChanged"]
},
"cosmos" : {
"chains": ["cosmoshub-4"], // namespace omitted from chainId
"methods": ["cosmos_signDirect", "cosmos_signAmino"],
"events": [],
}
} I'm agnostic as to whether we do this. I think it's maybe slightly more ergonomic to parse and write types for the above format, but at the end of the day we can live with either. What do you think @pedrouid? |
My concern with the above suggestion is that it doesn't allow supersets of namespaces Let's say an app wants to connect to 3 EVM chains: Ethereum Mainnet, Polygon and Optimism If all of then support the same methods then it's ok to use the above schema which keys by namespace However if one of them has an extra method or event then we can't specify it separately like the following example:
|
@pedrouid great point. Let's stick with the existing format! |
overtaken by events |
The proposed changes to CAIP-25 API for supporting multiple namespaces with separate scope for chains, methods and events as an array
The motivation is to separate methods and events for different chain sets which would not share the same methods
For example a chain with EIP155 namespace would use methods such as
personal_sign
andeth_sendTransaction
but if we added a chain with COSMOS namespace it would use methods likecosmos_signDirect
andcosmos_signAmino
which are not compatible with the latter.Hence you can have an array with separate scopes as follows
Additionally as part of this PR we have added
events
which weren't considered before as part of the spec but very relevant part of any asynchronous API