CAIP-2: Blockchain ID Specification

Metadata

Status: FinalStandardCreated: 2019-12-05

Authors

Simon Warta (@webmaster128), ligi (ligi@ligi.de), Pedro Gomes (@pedrouid), Antoine Herzog (@antoineherzog)

Links

GitHub page Discussion on Ethereum Magicians

Simple Summary

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

Abstract

Often you need to reference a blockchain, for example when you want to state where some asset or smart contract is located. In Ethereum the EIP155 chain ID is used most of the time. But with an Ethereum chain ID you cannot reference e.g. a Bitcoin or Cosmos chain.

Motivation

The final trigger to create this CAIP (and the CAIP process itself) was a discussion around [EIP2256] at Ethereum-Magicians. Independently, the Universal Chain Registry was created that needs properly specified chain identifiers at its core. A discussion about the network ID format brought this group together with ChainAgnostic.

Specification

The blockchain ID (short "chain ID") is a string designed to uniquely identify blockchains in a developer-friendly fashion.

Syntax

The chain_id is a case-sensitive string in the form

Semantics

Each namespace covers a class of similar blockchains. Usually it describes an ecosystem or standard, such as e.g. cosmos or eip155. One namespace should refer to one resolution method to resolve the chain's reference. A reference is a way to identify a blockchain within a given namespace. The semantics as well as the more granular syntax which are delegated to each namespace specification shall be defined in separate CAIPs describing resolution methods.

Rationale

The goals of the general chain ID format is:

Uniqueness within the entire blockchain ecosystem
To some degree human-readable and helps for basic debugging
Restricted in a way that it can be stored on chain
Character set basic enough to display in hardware wallets as part of a transaction content

The following secondary goals can easily be achieved:

Can be used unescaped in URL paths
Can be used as filename in a case-sensitive UNIX file system (Linux/git).

These secondary goals have been given up along the way:

Can be used as filename in a case-insensitive UNIX file system (macOS).
Can be used as filename in a Windows file system.

Test Cases

This is a list of manually composed examples