Chain Agnostic Improvement Proposal - CAIP for ICP

What will be blockchain ID for internet computer as per CAIP ? A blockchain ID (short “chain ID”) is a string designed to uniquely identify blockchains in a developer-friendly fashion as defined at Blockchain ID Specification | Chain Agnostic Improvement Proposals

Below are suggested

# Ethereum mainnet
eip155:1

# Bitcoin mainnet (see https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki#definition-of-chain-id)
bip122:000000000019d6689c085ae165831e93

# Litecoin
bip122:12a765e31ffd4059bada1e25190f6e98

# Feathercoin (Litecoin fork)
bip122:fdbe99b90c90bae7505796461471d89a

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

Would it be

icp:mainnet

1 Like

I’d use icp:<principal-id>. The blockchain in question would be running on a canister. So, the ICP token would have a chain id of icp:ryjl3-tyaaa-aaaaa-aaaba-cai

2 Likes

Can you create a proposal and PR on this? This should be standardised for any CAIP complaint wallet (https://walletconnect.com/) to interact with ICP.

2 Likes

Hello icp folks

Thanks for your interest in CAIPs.

Technically a Chain ID is specified in CAIP-2, BUT rather than PR in an example or a modification to CAIP-2, the preferred workflow is for you to PR an /icp namespace into the namespaces repo, which minimally consists of a readme (brief general introduction to the VM/network for total beginners) and a profile for one CAIP.

As for CAIP-2 conventions and rationale, most CAIP-2 profiles are meant to detect forks, and be queryable/confirmable from each node’s info/help command. For this reason they are mostly hashes of genesis blocks or subsets thereof (so that caip10s will remain reasonably short URNs that dont throw errors in common toolchains). I recommend clicking around to read all the caip-2 profiles published to date before starting your PR.

Thanks and feel free to reach out on our discord if you get stumped.

6 Likes

@bumblefudge Links are missing. Can you update with links?

Discourse has me privilege-limited because I created an account just to post this message.

https: // github .com/chainagnostic/namespaces
https: // namespaces .chainagnostic .org

In that case, a hash of the the IC root key is probably the best way to identify and verify the IC mainnet

Hash of IC root key is 9e32c54975adf84a1d98f19df41bbc34a752a899c32cc9c0000200b2c4308f85

Should it be icp:9e32c54975adf84a1d98f19df41bbc34 ?

In case of stellar, as these are the only two documented public Stellar networks -testnet and pubnet
Stellar registered namespaces

stellar:testnet
stellar:pubnet

@kpeacock
can we do something similar?

<chain>:<rootHashKey> name space is intended for chains with forks. please clarify if we finalising on icp:9e32c54975adf84a1d98f19df41bbc34

1 Like

I don’t think I have the authority to decide that

@kpeacock Now that you know the context, please take the conversation forward within dfinity team.

As per the advantages of CAIP need for ICP, CAIP increases visibility leading to more unique users, better wallet integrations and liquidity flow from other chains.
As per the urgency of CAIP for ICP, Wallet Connect v2 is starting from Dec 16. wallet connect v2 is supported by 150+ wallets and CAIP complaint

Hey @bumblefudge :wave: - Good to see your here :slight_smile:

Thanks for starting this discussion @gohan.

I like the idea of including the (truncated) hash of the IC’s public key.

Note, that this is the hash of the first ICP token transaction, not the hash of the IC’s public key.

1 Like

The hex representation of the IC Root key is 308182301d060d2b0601040182dc7c0503010201060c2b0601040182dc7c05030201036100814c0e6ec71fab583b08bd81373c255c3c371b2e84863c98a4f1e08b74235d14fb5d9c0cd546d9685f913a0c0b2cc5341583bf4b4392e467db96d65b9bb4cb717112f8472e0d5a4d14505ffd7484b01291091c5f87b98883463f98091a0baaae.

Taken from index.test.ts - dfinity/agent-js - Sourcegraph

5 Likes

Is it finalised?

Are we freezing on CAIP for ICP as icp:308182301d060d2b0601040182dc7c05 (icp: 32 Characters from ic root key) to uniquely identify ICP chain ?

How would this work for tokens on the IC chain? We have the OGY token on jwcfb-hyaaa-aaaaj-aac4q-cai. Is that something that would need its own namespace? Or would it just file under the IC namespace.

For tokens, we need follow CAIP 19. so it could be

icp:308182301d060d2b0601040182dc7c05/icrc2:jwcfb-hyaaa-aaaaj-aac4q-cai
# DAI Token
eip155:1/erc20:0x6b175474e89094c44da98b954eedeac495271d0f

# REQ Token
eip155:1/erc20:0x8f8221afbb33998d8584a2b05749ba73c37a938a

# CryptoKitties Collectible
eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d

# CryptoKitties Collectible ID
eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769
2 Likes

Tagging a few people for their opinion:

@brutoshi @Maxfinity @dostro @frederikrothenberger @lastmjs

1 Like

This seems quite reasonable IMO. Any negative consequences with this?

Taking only the first 32 characters of the hex encoding from the DER encoded root key is probably a bad idea as the DER encoding includes metadata (i.e. about length and the data types) in those bytes (with the actual public key bytes being further back). I would be much more comfortable with the hash of the public key.

2 Likes

Why do we need root key to identify? Would it be identifiable meanwhile human readable?

<chain>:<network> is good enough

icp:mainet

or If you want to use subnet we can also go

icp:<subnet_principal_id_first5>

icp:2fq7c

I thought including the (truncated) hash of the public key would be a good idea, because it would allow other instances of the IC protocol later on. A human-readable name would also be possible but would need another registry.