CAIP-288: Best Practices for using CAIP 2 - Blockchain ID Specification

Author	Bumblefudge
Discussions-To	https://github.com/ChainAgnostic/namespaces/pull/107, https://github.com/ChainAgnostic/CASA/issues/107, https://github.com/ChainAgnostic/CAIPs/issues/22, https://github.com/ChainAgnostic/namespaces/issues/55
Status	Draft
Type	Informational
Created	2024-06-14
Updated	2024-06-14

Simple Summary

Since being finalized, CAIP-2 usage has expanded and has new caveats worth specifying publicly.

Motivation

CAIP-2 defined 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. It formed the basis first for CAIP-10 and [CAIP-19], which were later generalized into a more extensible and general URN framework first specified in CAIP-104. Adoption since finalizing the specification has surfaced corner cases, which led to terminological changes and new features.

Changes to CAIP-2 Usage

Language

Originally conceived as a translation layer between the identifier schemes for “chains” in different “blockchain communities,” there has been interest in writing [104] namespace documents for cryptographic systems that do not organize instances into “chains” but the more general sense of networks of nodes with data in common; for this reason, “network” is preferred as the referent for CAIP-2 identifiers, particularly when applied to DAGs, git-based systems, and other distributed systems not organized primarily around linked-list data structures.

Non-Uniqueness of Addressed Resources

As mentioned in CAIPs#22, a given network is assumed to be unique within a namespace, but not unique across all namespaces. Concretely, this means that a given network addressable by a specific CAIP-2 identifier in one namespace might also be addressable by the same or different identifiers in other namespaces.

Special Case for non-network identifer

Implementer feedback from the Ethereum community led to PR namespaces#107 describing an emerging pattern whereby a static identifier could be used to refer not to a specific entry in the eip155-defined namespace of networks, but to the wallet software itself as an actor outside of them, such as when a website communicates over direct RPC methods with a user-agent controlling an account (an “externally-owned account” or EOA in Ethereum parlance). This may be generalizable to other namespaces over time, or may be superseded by complementary or competing solutions such as a distinct wallet namespace. It is unclear if all namespaces have an equivalent or other non-network identifer needs.

References

Citation

Please cite this document as:

Bumblefudge, "CAIP-288: Best Practices for using CAIP 2 - Blockchain ID Specification [DRAFT]," Chain Agnostic Improvement Proposals, no. 288, June 2024. [Online serial]. Available: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-288.md