CAIPs

[AlicanC]

We should consider what our CAIP identifiers will be.

The first step would be deciding on a CAIP-2 which consists of a namespace (type) and a reference (id).

Notes:

• Networks like Ethereum and Arbitrum uses the namespace EIP-155.
• An NFT on Polygon: eip155:137/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769
• An address on Arbitrum: eip155:42161:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb

From Slack:

@nfurfaro

Some chains are using ridiculously large numbers for their EIP-155 chain-id, ie: IPOS network: 1122334455 While not a concern for many/most use cases, I was working on embedding the chain-id in erc-721 token ids to prevent id-collision when bridging assets from L1-L2 & vice-versa. I only had enough free bits in our IDs to fit a uint16 but many chain's ids wouldn;t even fit in a uint32.

@AlicanC

I haven't seen any use of CAIPs in the wild other than in ENS avatars. All tools I've used only worked w/ EIP155 chains. We aren't EVM compatible, but it feels like using EIP155 could still have benefits because of that. One example is: I'm adding Fuel support to a side project. I have type Address = { chainId: number, address: string } which covers EIP155 well, but if Fuel won't be using EIP155 then I would need a refactor to type Address = { chain: { namespace: string, id: string }, address: string }. I actually tried this because I wanted to go full CAIP, but it got messy real fast because of all the checks and conversions it required. A one-byte EIP155 is LGTM if we aren't planning for the next 100 years :grin: (If we seriously are then BGP could be good inspiration.)