• Open #92 for CAIP-92 (defines namespaces)
  • Add namespace template (by analogy to CAIP template)
• Create an entry in /namespace/ for each of the blockchain-specific CAIPs { 3, 4, 5, 6, 7, 13, 23, 24, 25, 26, 28, 30, [75], 76, [77, 78] }, linking to commit-specific (archival) links to each superceded CAIP as they will later be "deleted" at their simple URLs
  • EIP155 + ERC20 + ERC721 + ERC1155 {3, 21, 22, 29} - in review
  • BIP122 {4} - in review
  • Cosmos {5} - in review
  • LIP9 {6}
  • EOSIO {7} - in review
  • Polkadot {13} - in review
  • Filecoin {23}
  • Tezos {26}
  • Stellar {28}
  • Solana {30}
  • Hedera {76, #75 , #78 , #79 }
  • GPG and Radicle [#66 and #53] deferred until scope of CASA defined more explicitly
• "Delete" each CAIP listed above from CAIPs repo (closes #68)
• Update table of contents

This is ticket is about the details of the Ethereum interface for #2.

Interface name

The name of this interface should either be "ethereum", referring to the wider Ethereum ecosystem.

Reference definition

The definition is delegated to EIP155. The reference format is eip155-%d, where %d is an unsigned integer in decimal represenation and corresponds to CHAIN_ID of EIP155.

Note: due to length restrictions of the reference field, the largest supported CHAIN_ID is 9999999999999999999999999999999999999999.

Examples

# Ethereum mainnet
ethereum:eip155-1

# Görli
ethereum:eip155-5

# Auxilium Network Mainnet
ethereum:eip155-28945486

Open questions:

• Do we want interface name ethereum or evm? ethereum, see #3 (comment)
• Should we drop the "eip155-" prefix? No, see #3 (comment)

Where do Merkle-DAGs, DAGs, Ceramic fit?
Where do GPG(+VKS), Radicle, etc fit?
Where does Eth2 sharding fit in?

An editorial PR to define which crypto systems are in scope for this group; "sequential ordering of hashed commitments" would include git systems, disjoint/sharded chains, and DAGs...
cc @wyc @oed @pedrouid @ligi will tag all in review

From discussions at CASA Berlin, MetaMask is deprecating eth encrypt / decrypt https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686

More generally, as a CAIP, we believe it would be useful to document a secure way for blockchain key material to be used for encryption and decryption.

This is sort of a CAIP-25 method, but is very much not chain specific as it can be accomplished with just wallet client interaction, without having to connect to an online blockchain.

This is issue is an "intent to write a CAIP". If you are interested in participating in the process, please leave a comment as we organize calls and a working group.

This has been previously discussed and something that should be done asap

CAIP-2 should require namespaces to reference how to resolve chain references from its node endpoints

moved from ethereum-lists/chains#135

This is ticket is about the details of the Bitcoin interface for #2.

Interface name

The name of this interface should be "bitcoin", referring to the wider Bitcoin ecosystem, including multiple forks of the chain and the code.

Reference definition

The definition is delegated to BIP122. The reference format is bip122-%s, where %s is a 32 character prefix of the block hash from BIP122 (lower case hex).

Blockchains in this interface

• Bitcoin + chain forks
• Litecoin + chain forks (e.g. Feathercoin)

Blockchains not in this interface

• ZCash: BIP122 excluded explicitely by zcash/zips#87 (comment). Further research may be necessary to understand why and if there is an alternative blockchain ID specification.

Examples

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

# Litecoin
bitcoin:bip122-12a765e31ffd4059bada1e25190f6e98

# Feathercoin (Litecoin fork)
bitcoin:bip122-fdbe99b90c90bae7505796461471d89a

Open questions:

• Should we drop the "bip122-" prefix?
• How to find a list of important blockchains that can be covered by this interface? What about e.g. Bitcoin Cash, Monero, Zcash, …

For any evm-compatible chain, by generating the data necessary to execute a JSON-RPC "eth_call", combined with a block number, this may yield a unique identity.

Say in block x+1 I commit the following contract on-chain

contract {
  function foo(uint8 bar) public returns (uint8) {
    return bar + 1;
  }
}

then I by hashing the function signature:

bytes4(sha3("foo(uint8)"))

I can generate the commonly known 4 byte function signature. But with the help of the contract abi specification I can also generate a specific call signature that combines the function signature with actual inputs. In a library of mine, I'm doing this using web3-eth-abi.

So e.g. combining the result of bytes4(sha3("foo(uint8)")) and a uint8 5 yields another hash that uniquely identifies calling an on-chain function with a certain value.

That in itself isn't interesting yet as this type of identifier can change depending on when you call the RPC endpoint as e.g. new blocks could alter the outcome of the call. However, if you were to make this call towards a specific confirmed block, then you'd always get the same deterministic outcome, which means that "eth_call" signature and block number are a unique identifier for a datum on an evm chain.

If e.g. I wanted to know the price of a Uniswap pool pair e.g. ETH/USDC 2 weeks ago (or x blocks ago), if we had a CAIP identifier, we could start identifying the exact price using a CAIP ID. E.g. we could use a similar structure as CAIP-22

eip155:1/contractAddress/blockNumber/callSignature

Additionally, this would translate nicely into JSON RPC calls too.

This is a refinement of #1 and especially #1 (comment) and kudos go to everyone envolved.

The goals of the general chain ID format is:

1. Uniqueness within the entire blockchain ecosystem
2. To some degree human readable and helps for basic debugging
3. Restricted in a way that it can be stored on chain
4. Character set basic enough to display in hardware wallets as part of a transaction content
5. Maybe: Can be used unescaped in URL paths
6. Maybe: Can be used as filename in a case-sensitive UNIX file system (Linux/git).
7. Maybe: Can be used as filename in a case-insensitive UNIX file system (macOS).
8. Maybe: Can be used as filename in a Windows file system (that one is going to be fun).

5.-8. are open questions to me and I'd love to hear feedback on those. Especially the requirement for a case-insensitive format seems seems to limit the implementation of reference.

chain_id     = a case-sensitive string in the form: interface + ":" + reference
interface    = a case-sensitive string in the form: [-a-z]{3,16}
reference    = a case-sensitive string in the form: [-a-zA-Z0-9]{3,47}

where interface identifies a document describing how reference is composed.

The interface typically corresponds to a class of blockchains and allows delegation of
the reference format to an ecosystem-specific standard.
Example interfaces are "ethereum" for all the blockchains that can be identified by EIP-155,
"bitcoin" for Bitcoin and closely related projects as Litecoin, or "cosmos" for projects that
build on top of Tendermint.

reference should strive for uniqieness within the interface. For user-choosen chain IDs
(e.g. EIP-155 or Tendermint chain ID), uniqueness cannot be guaranteed and it is reponsibility
of registries and communities to resolve collisions.

Examples

# Ethereum mainnet
ethereum:eip155-1

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

# Litecoin
bitcoin:bip122-12a765e31ffd4059bada1e25190f6e98

# Feathercoin (Litecoin fork)
bitcoin:bip122-fdbe99b90c90bae7505796461471d89a

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

# Binance chain (Tendermint + Cosmos SDK; see https://dataseed5.defibit.io/genesis)
cosmos:Binance-Chain-Tigris

# IOV Mainnet (Tendermint + weave)
cosmos:iov-mainnet

# Lisk Mainnet (LIP-0009; see https://github.com/LiskHQ/lips/blob/master/proposals/lip-0009.md)
lisk:lip9-9ee11e9df416b18b

# Random max length (16+1+47 = 64 chars/bytes)
blockchain1-hash:xip3343-8c3444cf8970a9e41a706fab93e7a6c4-xxxyyy

Open questions

• Is there a very good reason for a case-insensitive format?
• Is 100 ASCII chars a resonable max length?
• What about whitelisting _ as an alternative separator in reference?

Thoughts?

• add change.sh
• update run-a-testnet-validator-node.md, add change tendermint/config.toml default values step.

relevant issue 479

Originally posted by @zTgx in FindoraNetwork/findora-wiki#29

Over the last weeks, I've been busy figuring out

• #119
• and #87

But now the more I think about it, the better it'd be if we had a unique identifier for blocks.

So far, in CAIP19 and the #119, I had proposed adding a #123 (aka #<block number) fragment to the identifier. But really, the block number isn't just a place in time like e.g. 2022-07-08. A block number plus a network name also refers to a piece of data on a blockchain. And a block number by itself, e.g. "123" isn't all that useful without the respective network.

In #119, I did a survey for how block numbers on different networks look like and it suggests that it's a natural & incrementing number. Similar to CAIP-19 on asset types/ids, should we have a block number?

# Ether Token
eip155:1#block:123

# Bitcoin Token
bip122:000000000019d6689c085ae165831e93#block:123

# ATOM Token
cosmos:cosmoshub-3#block:123

So that people can know that it exists.

Referring to: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md

The following claim is made:

The following secondary goals can easily be achieved:

• Can be used unescaped in URL paths

with e.g. an identifier like

eip155:1/slip44:60

However, I doubt this claim. If e.g. I was to design a RESTful HTTP API that'd allow users to query for chain-agnostic ERC721 tokens, I'd probably design the endpoint as

/api/v1/nfts/:caip-22id:

and a user would then fill in the :caip-22id portion themselves with e.g. eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d. So combined, it'd look like this:

/api/v1/nfts/eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d

However, going back to the original claim that CAIP-19 ids can be used unescaped in URL paths, I doubt this is the case as between eip155:1 and erc721:, a slash / interferes with the routing scheme on the hypothetical API.

This would allow on-chain assets to be referenced in a chain-agnostic way! 🚀

Some blockchains such as NEAR uses names such as abc.near or abc.testnet for account ids. See https://docs.near.org/docs/concepts/account.

ENS is another example, such as abc.eth.

It would be desirable to allow such account ids with CAIP-10.

The required change is to relax the regexp for account_address ( [a-zA-Z0-9]{1,64}). It should allow characters such as . and _.

Hello! I work at Okta/Auth0, am an advisor to Dynamic, and maintain various Node.js packages for identity-related functionality (Passport.js, OAuth2orize, etc.)

I've put together a proposal on how to represent blockchain accounts and assets in a JWT. As off-chain applications adopt Web3 technologies, through specifications such as CAIP-122, this allows services to have a common way to do authorization based on accounts or assets owned (token-gating).

I'd love to get this communities feedback on the proposal. If there's interest, I will submit a PR to this repo consideration as a CAIP. Thanks!

https://github.com/jaredhanson/id-blockchain-claims-in-jwt

Hello people!

We at KILT, a digital identity infrastructure, are undertaking a big effort in trying to build a trust layer for assets by leveraging our existing trusted identity infrastructure. In short, we allow attesters to issue digital verifiable credentials to people that request them, with everyone being identified by a KILT Decentralized Identifier (DID).

We are now trying to move into the asset world, where entities might not necessarily be active (i.e., capable of interacting themselves with other entities). And since we define an identity as the combination of an identifier and some information attached to such identifier (the aforementioned credentials), we are trying to come up with a way to define unique and global asset identifiers.

CAIP-19 represents a very good starting point for this purpose, but we think that it lacks the "last mile" effort, being CAIP-19 just identifier that does not define any way to get useful information from such identifier.

As we are more or less deep into DIDs and Verifiable Credentials (VC), we are trying to come up with a DID definition representing a thin wrapper around CAIP-19 identifiers, but that would provide all the capabilities DIDs provide, including a standardised resolution process, a uniform representation, and the flexibility of JSON-LD. An example of that would be the possibility to resolve an Asset DID at a given block hash, without having to make the block hash part of the identifier (as there is an ongoing discussion about the subject). Another potential advantage, would be the possibility to use information specified in the DID specification, such as the alsoKnownAs, canonicalId, and equivalentId properties, to link multiple CAIP19-based assets together and support inter-chain asset teleports, where needed.

I am therefore asking the CAIP community to provide (no rush 😃) feedback to our ongoing standardisation effort for the new Asset DID method, of which a draft (still a PR) can be found here -> https://github.com/KILTprotocol/specifications/blob/76f66d8f8ef75fbdc6999914056bb7a7b18c5340/docs/did/asset-did-spec.md. Not sure if this is the best place, but I am willing to move the conversation over some other channel, if needed.

The initial version of the spec is willingly basic, because we want to avoid making it KILT-centric and would love this to be a community effort to write something that is extensible and flexible enough to accommodate multiple resolvers and multiple use cases.

Thanks in advanced for any feedback!

As pointed out from this PR ceramicnetwork/specs#12, there is no standard way currently to reference polkadot chains so I thought it would be best to start a discussion for a new CAIP to tackle this.

From the suggestion of @joshua-mir and @shawntabrizi on the PR mentioned above, the best way to reference Polkadot chains would be to use the genesis-hash similar to how Bitcoin namespace uses BIP122 as a reference for chainId.

I will start a draft for this proposal using CAIP-4 as a template.

Hey,

we are currently working on implementing the CAIP-2 and CAIP-19 standards at the ITSA.global.

I realized that it is difficult to find out, which chainIds are actually community-approved and which are not.

Could we brainstorm on how to list those standards? We were also not sure about the case-sensitive spelling. For example: is it EIP155 or is it eip155 like in the examples?

When we can agree on a process to approve this and, more importantly, on a place to list the chainIds, the ITSA could reference and circulate this.

I started a Rust implementation of CAIP, currently supporting CAIP-2 and 19: https://github.com/public-awesome/rs-caip. Before I publish the crate, I wanted to check if the code should live in this organization instead of Public Awesome.

The current specification for Ethereum NFTs (both CAIP-22 and CAIP-29) silently assumes that token id can be represented as integer, like eip155:1/erc1155:0x28959Cf125ccB051E70711D0924a62FB28EAF186/0 or eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769. It is worth noting that token id in the respective ERCs are uint256 which exceeds usual number representation of almost every programming language.

In order to parse large token id, one has to rely on some sort of big integer support, be it a library or language-provided feature. For JS, which is the predominant language and platform to interoperate with blockchains, this requires either ES2020 (which is a big pain for library authors, because of deficient bundlers used downstream) for native BigInt or using some heavy library like BigNumber.js. At the same time, if the token id is passed as hex-string, i.e. 0xbc6b9 for 771769, there is no need for the dangerous tricks. Moreover, it seems, like hex representation for token id is already commonly used in applications.

So, here is a request for comments. Let's adjust the specifications for EIP1155 and EIP721, so that token id is represented as a hex-string.

CC @mikehroth, @oed

This ticket is about the details of the GPG interface

Abstract

The idea behind this CAIP is that we should be able to define e.g. in a agnostic way a GPG fingerprint or other GPG primitives of a user.

Interface name

The name of this interface should be "gpg", referring to the GNU Privacy Guard (aka GnuPG or GPG).

Reference definition

I would suggest to use the different primitives as reference definitions.

Examples

# GPG fingeprint
gpg:fpr

Readme is out of date and doesn't contain all current CAIPs.

Began discussing this topic within the document for the Interchain UX working group here.

Basically CAIP-19 identifies an asset by its origin but doesn't include anything about whether the asset is being accessed in it's native setting or in a new setting, reached via bridges or IBC. An ATOM that is on the Cosmos Hub is similar but fundamentally different from an ATOM that has been moved to Kava via IBC. It is also different from an ATOM which has been moved to Terra after being moved to Kava. There will likely be multiple bridges to the Cosmos ecosystem from Bitcoin and Ethereum, which means there will be different versions of Eth and BTC that have different features and security assumptions based on the path they took.

This information is important for a user to understand for the sake of valuing the assets properly, but also for client software to understand how to interact with the assets.

Should CAIP-19 be extended to contain asset path information? Should there be a new CAIP for asset path resolution? What should be the recommended method for resolving an asset's path? What should be the recommended method for user interfaces to display the different varieties of non-native assets?

Currently the index of CAIPs in the readme frequently get out of date. It would be great if we had a github action that updated the index after a PR is merged or something like that.

Following the upcoming scheduled merge, having clear CAIP-2 blockchain identifiers can be greatly beneficial for navigating the ambiguities for both the humans and the machines involved in this space.

What will be the CAIP-2 identifier for:

1. ETH1
2. ETH2
3. ETC

Best,
Oren

This is just a note that some parallel or overlapping work might be going on in W3C CCG: https://github.com/w3c-ccg/blockchain-links.

I created a Github issue here: w3c-ccg/blockchain-links#1 to raise awareness in W3C CCG and avoid duplicative work in either of these groups. Note, I'm not part of blockchain-links.

zkSync has the same chain id as Ethereum(Mainnet:1, Ropsten:3), how will the Blockchain ID of zkSync be defined?

Possible examples:

# zkSync Mainnet
zksync:1

• see here:

  CAIPs/CAIPs/caip-19.md

  Line 50 in 6beec4d

  token_id: [-a-zA-Z0-9]{1,78}

• here's a random NFT and you can call tokenURI(0): https://etherscan.io/address/0x9CB7712C6A91506e69E8751fcb08e72e1256477D#readContract

from EIP-721: https://eips.ethereum.org/EIPS/eip-721

NFT Identifiers

Every NFT is identified by a unique uint256 ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair (contract address, uint256 tokenId) will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a “black box”. Also note that NFTs MAY become invalid (be destroyed). Please see the enumeration functions for a supported enumeration interface.

Both Hedera and Hive encode heirarchies and/or checksums into their native addressing schemes with . and/or - characters-- should CAIP-10 be upgraded at some point to expand their regex to include those two characters for more straight-forward support of Hedera, Hive, and perhaps other chains I know nothing about? (note to self: old regex should go into Backwards Compat section if so!)

See #95 and the hedera/caip10.md file

At starname.me, we are happy to use CAIP-25 to get the list of all accounts of a wallets to synchronise wallet addresses into a starname in a very smooth way (https://docs.starname.me/for-wallets/integration-with-wallet-connect-and-the-starname-manager). However two things pops into my mind:

• it would be great to be able to get the list of accounts of a wallet without specifying the list of chain-id (CAIP-2) the wallet is currently supporting, otherwise you need to know on advance which chain-id to query for each wallet. How to solve this issue with CAIP-25? or Should we create another CAIP to query a wallet and get the list of the chain-id the wallet support?

• to synchronise accounts into a starname, we don't need any method permission so we would have "method" set to an empty array like []. We just want to get the list of accounts that the wallet supports and being returned as a result by CAIP-25.

What do you think @pedrouid ?

On solana, all contracts are stateless and state is instead represented using "accounts". More specifically, all fungible and non-fungible tokens are using the same instance of token contracts and for each token:

• 1 single global "mint" account instance is used for the global data like "total supply"
• each token account represent an account balance belong to a certain address

And the difference between fungible token and non-fungible token is that non-fungible token mint has a total supply of 1 and zero decimal place.
So maybe we could use mint address and account address for solana here. Based on CAIP-19 and CAIP-30

note Solana support semi-fungible token where 1 mints have multiple token account
As a reference OpenSea beta is also using mint as "token ID" :
https://opensea.io/assets/solana/3Fif3sYuL7vfVifb3gDYQym8THCfaU3DQo1ctuXMu7dz

eg.

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

# One Solana Mainnet NFT
solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ/spl-mint:{the-token-mint-address}/{the-token-account-address}

This is ticket is about the details of the EOSIO interface for #2.

Interface name

The name of this interface is "eosio", referring to the EOSIO open-source blockchain platform.

Reference Definition

The definition is delegated to the EOSIO Transactions Protocol Documentation, the Chain API Plugin Documentation of the EOSIO Developers Manual and the pull request that implemented its generation Chain ID generation implementation pull request.
The Chain ID, as defined by EOSIO, is the SHA256 hash of the genesis state of the chain, represented as lower case hexadecimal number of 64 digits. In order to fit the reference restrictions, the format is a 32 character prefix of the Chain ID.

Blockchains in this interface

All blockchains using the EOSIO blockchain platform.

Examples

This is a list of manually composed examples

# EOS Mainnet
eosio:aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906

# Jungle Testnet
eosio:e70aaab8997e1dfce58fbfac80cbbb8fecec7b99cf982a9444273cbc64c41473

# Telos Mainnet
eosio:4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11

# Telos Testnet
eosio:1eaa0824707c8c16bd25145493bf062aecddfeb56c736f6ba6397f3195f33c9f

Hive and Hedera both use .s and -s in their native addresses-- there may also be corner-cases or testnets or checksums or other places where CAIP-10 is too constrictive. Would be worth discussing:

• needs for and pro's of less constrictive CAIP-10
• costs and breakage to existing CAIP-10 tooling (did:pkh, didkit, walletconnect, etc)

It would be good to discuss this at our next meeting!

See #95 and the hedera/caip10.md file

As discussed on CASA Meeting 2 we are going to register on IANA our own URI scheme under a single scheme caip: which will then be described under our standard to identify how to part different identifiers

In order to register on IANA we need to include the following

• URI Scheme
• Template
• Description
• Status
• Reference

I propose that we create a CAIP standard for describing all of these which can then be linked on IANA as a Reference

This is ticket is about the details of the Cosmos interface for #2.

Interface name

The name of this interface is "cosmos", referring to the wider Cosmos ecosystem.

Reference definition

The reference uses the Tendermint chain_id from the genesis file directly (a JSON-compatible unicode string), assuming it matches the case-sensitive pattern [-a-zA-Z0-9]{3,47}. Otherwise the Cosmos Hash interface must be used.

Blockchains in this interface

• Cosmos SDK blockchains with a chain ID matching [-a-zA-Z0-9]{3,47}: Cosmoshub, Binance, Cosmos Testnets, …
• IOV blockchains (Tendermint + weave)

Related challenges

Changing chain IDs

During the development of this chain ID definition, we came across changing chain IDs for Cosmos Hub (cosmoshub-1, cosmoshub-2, cosmoshub-3). A new chain ID is assigned every time Cosmos Hub dumps the current blockchain state and creates a new genesis from the old state. Technicalls this leads to different blockchains and can (and maybe should) treated as such. For this specification, we treat them as different blockchains. It is responsibility of a higher level application to interprete some chains as sequels of each other or create equality sets.

Examples

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

# Binance chain (Tendermint + Cosmos SDK; see https://dataseed5.defibit.io/genesis)
cosmos:Binance-Chain-Tigris

# IOV Mainnet (Tendermint + weave)
cosmos:iov-mainnet

Open questions:

• Should characters other than [-a-zA-Z0-9] be whitelisted (see also #2)

CAIP-10 has received a lot of feedback within the last year including some criticisms over its structure. Many Twitter and Discord threads have been written about what would constitute an ideal multi-chain account identifier from which it has also generated new CAIP proposals (#50).

A lot of feedback has also been generated recently in an Ethereum Magicians thread: https://ethereum-magicians.org/t/chain-specific-addresses/6449

Additionally some polls were also created on Twitter:
Poll 1 - https://twitter.com/SchorLukas/status/1404831686714613769
Poll 2 - https://twitter.com/pedrouid/status/1404869512512606218

From my perspective there is essentially a division between 3 main identifiers:

A - "0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1" (current CAIP-10)
B - "evm:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb" (updated CAIP-10)
C - "zUJWDxUnc5gJJSWFzxyKkmLp1dgyxiPYT3BrT4" (proposed CAIP-50)

From both polls and also from the Ethereum Magicians thread, the majority supports the identifier with format B.

This would mean that it would require the following changes:

1. change of endianness of CAIP-10 and using the same separator as CAIP-2

specific@generic:middle → generic:middle:specific

2. update CAIP-2 namespaces to shorter and more recognizable names

bip122 → btc
eip155 → evm
cosmos → cosm
polkadot → dot

I propose that we make these changes to respective CAIP standards which are in DRAFT status with two separate PRs for each change and follow up with discussions for each.

This is ticket is about the details of the Lisk interface for #2.

Interface name

The name of this interface should be "lisk", referring to the wider Lisk ecosystem.

Reference definition

The definition is delegated to LIP9. The reference format is lip9-%s, where %s is a 16 character prefix of the hash from LIP9 (lower case hex).

Blockchains in this interface

• Lisk Mainnet and Testnet
• Forks
• Side chains

Examples

# Lisk Mainnet (https://github.com/LiskHQ/lips/blob/master/proposals/lip-0009.md#appendix-example)
lisk:lip9-9ee11e9df416b18b

# Lisk Testnet (echo -n "da3ed6a45429278bac2666961289ca17ad86595d33b31037615d4b8e8f158bbaLisk" | sha256sum | head -c 16)
lisk:lip9-e48feb88db5b5cf5

Open questions:

• Should we drop the "lip9-" prefix?

This is ticket is about the details of the Algorand interface for #2.

Interface name

The name of this interface should be "algorand", referring to the algorand blockchain networks.

Reference definition

The Chain ID, as defined by Algorand, is the genesis hash of the respective Algorand network.

Blockchains in this interface

The MainNet, TestNet, and BetaNet Algorand networks.

Examples

# Algorand MainNet
algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=

# Algorand TestNet
algorand:SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI=

# Algorand BetaNet
algorand:mFgazF+2uRS1tMiL9dsj01hJGySEmPN28B/TjjvpVW0=

This is ticket is about the details of the Cosmos Hash interface for #2.

Interface name

The name of this interface is "cosmos-hash", where "cosmos" refers to the wider Cosmos ecosystem and "hash" to the fact that native chain IDs are hashed in order to fit in the general format.

Reference definition

The reference uses the format hex(sha256(utf8(chain_id))), with

• the Tendermint chain_id from the genesis file (a JSON-compatible unicode string)
• utf8 being the UTF-8 encoding
• sha256 being the the SHA256 hash function
• hex being a lowecase hex encoder

Blockchains in this interface

• Tendermint-based blockchains with a chain ID matching not matching [-a-zA-Z0-9]{3,47}: no real world example known yet

Blockchains not in this interface

• If the chain_id is compatible to the Cosmos interface, that one must be used.

Examples

# Example chain with chain_id "wonderland🧝"
cosmos-hash:843d2fc87f40eeb9198e0c2416be28a6c31a01eb9cc32499b030723d662c006f

Open questions:

• Do we need to define unicode normalization?

There's been a bit of grumbling around DIF github repos [edit: and now on the re-charter repo of the VC WG] and slack lately about how to handle the recovery bit in ES256K-R - it seems it was never registered publicly? the COSE working group at IETF registered regular ES256K, but no one attempted to register it. Is there interest in the CASA community to do this, or is there interest to set up a grant through gitcoin or DIF or any other grant-managing org to outsource it? if so, we might want to sketch such a grant in pencil before amsterdam!

I'm working on a go implementation of CAIP i'd love to contribute to the organization if you are interested: https://github.com/tarrencev/go-caip

cc @bumblefudge

I would like to refer to bridges in a similar way to how CAIP-2 refers to chains. A naive way to refer to a bridge may be to refer to it's contract address on the chain the contract is deployed. But, this lacks important information about how to interpret the data.

Is there an effort to name bridges? If not, is that something that would be worth pursuing here as a CAIP? Does anyone have opinions on things that would need to be considered?

This is ticket is about the details of the Radicle interface for #53

Interface name
The name of this interface should be "radicle", referring to the radicle code collaboration protocol.

Reference definition
The definition is delegated to Radicle. The format corresponds to the commonly used abbreviation for each VCS that will be supported by the Radicle protocol.

Examples

# git
rad:git

# Mercurial 
rad:mercurial

# pijul
rad:pijul

Hi @ligi
I wrote a message on the chain agnostic discord. Can we create a repo to onboard new members of the chainagnostic initiative?
Adli and Myself propose to help to get more blockchains member particularly to get their namespace for CAIP-2 and also we can structure a little bit the different working groups.
I did that as a draft that we could put in a chain agnostic repo:
https://github.com/antoineherzog/casa
Maybe we can organize a quick call to talk about it :)

Suggestion by @oed to index existing CAIPs on the README and make it requirement to update it for new CAIPs before merging

I'd like to highlight an issue with the current CAIP-2 chain identification format. There may be room for another such chain identification schema to be created, possibly as a CAIP-2 compatible extension (via a new prefix).

The issue is that the current schema treats chains as singletons, but without appreciation for the possibility of forks. The power of hard fork is an incredibly powerful social tool that is only present if the tooling all the way up and down the stack allows users to easily participate in exercising their own fork preference.

The current schema, for example, ensures that by encoding ethereum as eip155:1, if there is any contentious hard-fork on ethereum, it is unclear what identifier would apply to which end of the fork, and this can result in a variety of issues:

• Failure in replay-protection strategies for any layer-2 strategies that rely on this schema.
• Creation of increasing ambiguity around any chain or account reference.

There are many other reasons to make fork-friendly software, and I think I put off writing this post in part because I never felt ready to make the full case, and here I will just accept that I have not made the full case, but instead claim that this is valuable, and if you disagree then I or others can continue to explain why. I'm not sure if it's a contentious point.

Historically chain_id assignment has gone to the stronger chain claims the prior identifier, and the smaller chain then hard-forks to give itself replay protection, but maybe we could design a solution that does not require squatting identifiers, but instead identifies chains by their ongoing uniqueness?

I don't have a simple solution to this, but I have seen approaches, and so I'd like to start this thread to discuss possible fork-friendly chain identifiers: Chain identifiers that can retain as much specificity as possible in a fork-tolerant world.

An example of this I've seen is the truffle blockchain-utils library, which proposed an ethereum-chain identifying schema that identifies a chain by both its genesis block and a later block, like: blockchain://<genesis hash>/block/<latest block at uri creation> (Credit to @timcoulter)

A limitation of this strategy is that a parser needs to be aware of any block that may be used as <latest block at uri creation>, but I could imagine an optimized version where the second block-hash referenced is the block after a contentious fork.

Anyways, looking forward to seeing how others might imagine identifying chains in fork-tolerant architecture.

Hi there,

Taken from CAIP-2: "CAIP-2 defines a way to identify a blockchain (e.g. Ethereum Mainnet, Görli, Bitcoin, Cosmos Hub) in a human readably, developer friendly and transaction-friendly way."

I could not find any reference on how to link to a transaction on a specific blockchain. I can imagine in most cases a CAIP-2 blockchain definition is used, a reference to one or multiple transactions is relevant as well.

Would be great to define a CAIP standard for Arweave. @ceramicnetwork would use this CAIP standard to link an Arweave address to a DID using an account-link document. @samcamwilliams