CAIP-10: Account ID Specification

[pedrouid]

Proposing a specification for chain-agnostic account id's

Examples

# Ethereum mainnet
0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1

# Bitcoin mainnet 
128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6@bip122:000000000019d6689c085ae165831e93

# Cosmos Hub (Tendermint + Cosmos SDK)
cosmos1t2uflqwqe0fsj0shcfkrvpukewcw40yjj6hdc0@cosmos:cosmoshub-3

[pedrouid]

I would love your feedback on this! 🙏
cc @ligi @webmaster128

[ligi]

Thanks for this PR! I think this is a great idea. Just 2 comments after a first read:

• I think it should be turned around account@chain instead of chain@account as the account is on the chain and the chain is not on the account
• Perhaps the CAIP should mention use-case(s).

[pedrouid]

I was also leaning towards having them reversed but my only reason for not doing it is that it would make more sense if the order of CAIP-2 chain_id followed the same pattern

Similar example would be the email addresses.

<address>@<domain>.<tld>

If this pattern would be applied to this CAIP, it would be weirdly ordered

<account_address>@<namespace>:<reference>

[ligi]

If this pattern would be applied to this CAIP, it would be weirdly ordered

I think it would be less weird actually. Hoping to get some more input/signaling from others

[pedrouid]

Programmatically speaking it's a very simple change. Example:

const parseAccounts = (accounts: string[]) => {
  const accountMap = accounts.map((account: string) => {
    const params = account.split("@");
    return {
      address: params[0],
      chain: params[1]
    };
  };
};

Thus this is simply a human readability preference

[pedrouid]

I've asked @oed and he also signaled preference to reverse. I'm happy to make this change! 👍

[ligi]

Great! Will merge after the change

[pedrouid]

Done! 👍

[ligi]

That was fast. Just one more thought: do we want to enforce ERC-55? I think this could make sense here as it would enforce uniqueness.

[pedrouid]

I think that CAIP-10 is more analogous to CAIP-2 while the ECR-55 requirement would be more analogous to CAIP-3 where it define Account Address specification for CAIP-3 chains requiring CAIP-10

[pedrouid]

Good to merge @ligi ?

[ligi]

done - thanks for the ping

[MicahZoltu]

Should this specification assert that CRC checked addresses is required? Seems like a good opportunity to start enforcing that.

[greenlucid]

This standard should make clear if CRC is optional, disallowed or enforced.

[greenlucid]

This is being used here
https://github.com/kleros/gtcr/blob/master/src/utils/rich-address.ts
What other alternatives are there to this standard, though? Safe uses strings like gno:0xc0fec0fe...c0fec0fe, eth:0xde4dde4d...d4edd4ed

[GriffGreen]

GM! I would like to make an extension to CAIP-10

I would love to see ChainID 0 reserved for EOAs, so that we can treat EOAs in a special way.

EOAs live on many chains, so requiring chain specification is redundant, and in many cases, costly!

If we extend CAIP-10 to treat ChainID 0 as EOAs we can make many processes (e.g. forward resolution of ENS names on L2s) 10x more efficient.

WDYT?

[MicahZoltu]

I would love to see ChainID 0 reserved for EOAs, so that we can treat EOAs in a special way.

Wouldn't we need to constrain to "chains that use the same address derivation algorithm"? Even Bitcoin and Ethereum, which both use secp256k1, have different address derivation mechanisms so one address won't work for both.

[oed]

@GriffGreen I think what you meant to say is to reserve 0 for EOAs in the "eip155" namespace for caip-10?

[GriffGreen]

Wouldn't we need to constrain to "chains that use the same address derivation algorithm"? Even Bitcoin and Ethereum, which both use secp256k1, have different address derivation mechanisms so one address won't work for both.

Yes, I should have been more clear as Joel said

@GriffGreen I think what you meant to say is to reserve 0 for EOAs in the "eip155" namespace for caip-10?

# EOA that works on most EVM Chains
eip155:0:0x839395e20bbB182fa440d08F850E6c7A8f6F0780

This would save everyone a lot of work IMO

Otherwise, to use EOAs in multiple chains with this standard you have to make many redundant records.