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

Supporting multiple chains with CAIP-122 #262

Open
pedrouid opened this issue Feb 7, 2024 · 2 comments
Open

Supporting multiple chains with CAIP-122 #262

pedrouid opened this issue Feb 7, 2024 · 2 comments

Comments

@pedrouid
Copy link
Member

pedrouid commented Feb 7, 2024

SIWx is a great standard but currently it only supports one chain per message signed

The multi-chain experience is now considered to be de facto standard for Web3 in general but SIWx is still designed for single-chain

This means that if you would like to authenticate yourself with SWIx for multiple chains then you need to sign multiple messages

The current Wallet UX does not support batch signing for messages and even if it did it would require a lot of inspection from users unless the UI would aggregate the common parts of the message

A much simpler approach would be to change CAIP-122 to support multiple chains

Instead of specifying a single chain per message then it could support a range of chains

This could be approach for example with the following options:

  1. We ignore chainId and just hardcode it to 1 then list chains in the resources as a ReCap
  2. We use an asterisk as a wildcard for chainId then list chains in the resources as a ReCap
  3. We use comma-separated values for chainId to list chains directly in the existing param

Each option has its own pros and cons:

  1. is backwards-compatible but then assumes its always Ethereum Mainnet
  2. is not backwards-compatible but it can be misused to assume all chains are valid
  3. is not backwards-compatible but its the only option that does not require ReCaps

Maybe there are options besides these ones above but I feel like something needs to be done address this

But the intended goal should be that if a user wants to authenticate for chain A, B and C then it should sign a single message rather than 3 messages

@oed
Copy link
Collaborator

oed commented Feb 8, 2024

This means that if you would like to authenticate yourself with SWIx for multiple chains then you need to sign multiple messages

Why is this the case?

  • If you have an EOA there isn't a meaningful difference between a signature for different chainIds. You can just treat 1 as any, or simply ignore the chainId
  • If you have a smart contract account and use eip1271 you need to have a unique signature for each chain regardless

**Can you provide an example of the problem you are trying to solve here? **
"I want to sign in with multiple chainids at once" is not a problem, it's a proposed solution.

If I were to take a guess on what problem you are trying to solve I think you need to give dapps access to call rpc methods for multiple chains? However, I'm not sure why SIWE is relevant for that?

@bumblefudge
Copy link
Collaborator

"Just ignore" is always a dicey way of specifying behavior; perhaps the best solution is an extension spec that specifies exactly how to ignore or override CAIP122 behavior if X and Y conditions are met (presumably, resource array members, since that's basically the only open-ended part of the spec)? Even if that extension CAIP is only applicable to eip155, it might still be worth writing in a generic way and profiling in eip155/caipXXX.md in case some almost-evm compatible L1 wants to use it the same way with slightly different recaps or recap-equivalent capability expression format...

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