How to represent multi-chain accounts?

[ntn-x2]

I am not sure this is the right repo, or if I should open an issue on the CAIP repo.

I know there's an open ticket for updating the CAIP-2 and CAIP-10 for Polkadot based on the new XCM v3 format.
Nevertheless, we are currently working on a cross-chain identity solution where we would need to rely on the Polkadot feature that lets users use the same account on multiple chain, by simply encoding the public key differently. Specifically, there is a "generic Substrate address" which always starts with the number 5, e.g., 5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr. This means that given a public key, it could be encoded in a lot of different ways, but also always to something that starts with 5.

This goes beyond the concept of a CAIP-10 identifier being "anchored" to a CAIP-2 chain, and I was wondering if there is discussion in this direction already, given the increasing popularity of cross-chain interactions.

I guess a blockchain account would still have to be bounded somehow, but I would rather see it bound to a namespace, than to a specific chain ID. For instance, while a specific Polkadot blockchain account could still be identified by a CAIP-10, anchoring it to a specific chain and nowhere else, it must also be possible NOT to anchor it to a specific chain. Do you think making the reference component of a chain ID optional would be a way? Or would this call for a new CAIP that indicates "a group of related chains"? Something like polkadot:<account> would include any chain-specific account that can be encoded from the starting account, on any Polkadot chain, while a polkadot:<chain_reference>:<account>, would still refer to a specific chain, for which the discussion was opened in the ticket linked above.

[bumblefudge]

we went back and forth for months on the pros and con's of a CAIP-10wide wildcard and ultimately ended up rejecting it, making
chain_reference a mandatory element to simplify the heirarchical parsing for scaling reasons as well as DX corner cases. That said, any given namespace could have a "special case" <chain_reference> for the non-chain-hashed public-key (the S... address) defined in polkadot/caip10.md, i.e. polkadot:pubkey:<account> or polkadot:substrate:orpolkadot:00101010b:` if we wanted to make a little hex joke (it's still the wrong length so manually noticeable if one sneaks into a list or a log of chain-transformed addresses).

do you think that would work for your use-case, to have a "special" chain_reference instead of no chain_reference?

[ntn-x2]

Yes, a special reference for the polkadot namespace will do it. I wanted to touch base as to whether this would justify a new CAIP or not, and it's clear it's not. How would then this fit into the current namespace-based structure? We would define two different CAIP-10? Or would we update the polkadot CAIP-10 spec to include chain-specific and chain-agnostic variants?

Or since it's the CAIP-2 part that we want to change, would this be a change to the CAIP-2 polkadot definition? Or an entirely new CAIP for chain-agnostic accounts, while we keep the CAIP-10 for chain-bound ones?

[bumblefudge]

the latter -- just add a section to the polkadot/caip10.md between syntax and test cases with a ### header instead of a ## header! this is exciting, i was hoping someone would propose something like this. Add Closes #105 to the PR description and try to tag people who might have relevant opinions or experience from other polkadot projects in the thread! :D