Chain Agnostic Improvement Proposals

CAIP stands for Chain Agnostic Improvement Proposal. A CAIP is a design document providing information to the community or describing a standard to be used across multiple chains. To be more precise, a CAIP may describe capabilities applicable to any sequential orderings of cryptographically hashed commitments, including non-blockchain systems that can interoperate with blockchains productively, s

#1

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.

#2

This document is about the details of the EIP155 namespace and reference for CAIP-2.

#3

This document is about the details of the BIP122 namespace and reference for CAIP-2.

#4

This document is about the details of the Cosmos namespaces and references for CAIP-2.

#5

This document is about the details of the LIP9 namespace and reference for CAIP-2.

#6

This document is about the details of the EOSIO namespaces and references for CAIP-2.

#7

CAIP-10 defines a way to identify an account in any blockchain specified by CAIP-2 blockchain id.

#10

This document is about the details of the Polkadot namespace and reference for CAIP-2.

#13

CAIP-19 defines a way to identify a type of asset (e.g. Bitcoin, Ether, ATOM) with an optional asset identifier suffix (for individually-addressable tokens like NFTs) in a human-readable, developer- and transaction-friendly way.

#19

This document is about the details of the SLIP44 asset namespace and reference for CAIP-19.

#20

This document is about the details of the ERC20 asset namespace and reference for CAIP-19.

#21

This document is about the details of the ERC721 asset namespace and reference for CAIP-19.

#22

This document is about the details of the Filecoin network namespace and reference for CAIP-2.

#23

CAIP-25 defines an authorization procedure for a chain agnostic provider to interface with a wallet as part of their initialization and/or "handshake" protocol.

#25

This document is about the details of the Tezos namespaces and references for CAIP-2.

#26

CAIP-27 defines a JSON-RPC method for a decentralized application to invoke a targeted JSON-RPC method, marked for a specified target previously authorized by a valid [scopeObject][CAIP-217], and tagged with a [sessionId][CAIP-171] for maintaining session continuity if applicable.

#27

This CAIP defines the Stellar network namespace and reference for CAIP-2.

#28

This document is about the details of the ERC1155 asset namespace and reference for CAIP-19. This specification is derived from the work done for [CAIP-19](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md) by Antoine Herzog (@antoineherzog), Pedro Gomes (@pedrouid), Joel Thorstensson (@oed).

#29

This document is about the details of the Solana namespace and reference for CAIP-2.

#30

CAIP-50 defines a way to identify blockchain account addresses uniquely across multiple blockchains

#50

Represent a chain-agnostic Object Capability (OCAP), created using [CAIP-122], as an [IPLD](https://ipld.io) object.

#74

This document is about the details of the Hedera account address for CAIP-10.

#76

Previously, the specifics of blockchain ecosystems and namespaces were defined in single stand-alone CAIPs alongside cross-chain CAIPs. Now, as the system has matured and expanded, it has become clear that namespaces are more complex and multi-dimensional than can be efficiently governed over time in the current CAIP single-document structure; instead, a Namespace Reference is proposed that splits

#104

Sign in With X describes how blockchain accounts should authenticate and authorize with off-chain services by signing a chain-agnostic message parameterized by scope, session details, and security mechanisms (e.g. a nonce). The goal of this specification is to define a chain-agnostic data model. When accompanied with chain-specific message forms and signing algorithms, along with chain-agnostic s

#122

Historically the web platform has had a notion of “powerful” APIs like [geolocation][w3c-geolocation] and [camera and microphone usage][w3c-mediastreams], which are subject to additional security restrictions such as those defined by [secure contexts][w3c-secure-contexts]. Since the Web3 Provider APIs allow dApp websites to request access to sensitive user data and to request use of user funds, ne

#154

Create and verify IPLD based blockchain timestamp proofs.

#168

<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.--> A common interface for decentralized applications and cryptocurrency wallets (or other key management applications described in future CASA namespaces and CAIPs) to communicate about and pass Verifiable Credentials and Verifiable Presentations is needed

#169

This CAIP defines an common identifier for representing an open session with a wallet, including both in-browser session tokens and API-based connection IDs.

#171

A Chain Agnostic CApability Object, or CACAO, is an [IPLD](https://ipld.io) representation of an object-capability.

#196

Standard API Routes for Blockchain explorers

#200

The establishment of a connection between a decentralized application (web-based or otherwise) and a wallet or other authenticator (browser-based or otherwise) requires a shared understanding of capabilities and target networks as well as mutual trust. This specification gives wallets and decentralized applications a way of signalling to one another, in CAIP-25 or in other session-initiation cerem

#211

This CAIP defines a simple syntax for scopes of authorization between applications (e.g. dapps) and user-agents (e.g. "wallets" or signers). These are expressed as JSON objects as a building block across multiple protocols and mechanisms, for example: - A JSON-RPC protocol for persisting and synchronizing authorized sessions ([CAIP-25][]) - Routing individual RPC commands to an authorized networ

#217

This CAIP defines a JSON-RPC method to authenticate wallet ownership/control of one or more blockchain account(s), on one or more specific chains.

#222

This specification introduces a data framework to explicitly represent trust assertions among peers, facilitating the development of a scalable and interoperable web of trust.

#261

The Domain Wallet Authentication describes a method for linking a crypto domain with authentication methods or providers by adding an authenticator: JSON/URL field to the metadata of a crypto domain NFT. The standard also describes a method for application developers and web3 login modal providers to enable users to login with their domain name.

#275

CAIP-282 defines a standardized interface for browser wallet discovery

#282

CAIP-285 introduces the `wallet_revokeSession` method for fully revoking the authorizations and properties of an active [CAIP-25][] session.

#285

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

#288

CAIP-294 defines a standardized messaging transport for browser extension wallets.

#294

CAIP-295 defines a standardized messaging transport for browser iframe wallets.

#295

CAIP-311 introduces the `wallet_sessionChanged` event for notifying callers party to an active [CAIP-25][] session of updates to session authorizations made by users directly in the wallet.

#311

CAIP-312 introduces the `wallet_getSession` method for retrieving authorizations from an active [CAIP-25][] initiated session.

#312

This overview compares new and old forms of [CAIP-25][] connection flow to ensure safe and well-informed implementation of either or both. [CAIP-311][] and [CAIP-312][] extended [CAIP-25][] by defining new JSON-RPC methods for managing the lifecycle of authorizations within a session. These methods allow dapps and wallets to dynamically adjust authorizations, providing more granular control and be

#316

CAIP-319 defines a JSON-RPC method for a wallet to send notifications to a caller in a context authorized by or in a valid [scopeObject][CAIP-217] and, optionally, tagged with a [sessionId][CAIP-171] for maintaining session continuity if applicable.

#319

CAIP-341 defines the Extension ID type as a valid target type for establishing connections with browser extension wallets via the [CAIP-294] `wallet_announce` wallet discovery event.

#341

<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the CAIP.--> Handling of wallet JSON-RPC requests by wallet-provided HTTP endpoint.

#345

This standard, when profiled down for each namespace, describes a unified and general purpose method for serializing chain-specified addresses into the Interoperable Address format specified in [ERC-7930].

#350

A standard for enabling one-interaction cryptocurrency payment flows across wallets and dapps, allowing all payment information to be transmitted in a single round-trip.

#358

This CAIP extends CAIP-2 and CAIP-10 by reserving the `_` character as a wildcard reference for "all chain IDs" within a CAIP-2 namespace. This enables wallets and applications to represent account identity across all chains of a given namespace. This CAIP makes no assumptions about how the address is derived or whether it is valid across all chains in the namespace. The use of `_` simply denotes

#363