CAIPs — Merged

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

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.

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

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

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

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

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

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

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

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.

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

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

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

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

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.

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

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.

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

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).

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

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

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

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

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

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

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

Create and verify IPLD based blockchain timestamp proofs.

<!--"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

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.

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

Standard API Routes for Blockchain explorers

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

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

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.

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

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.

CAIP-282 defines a standardized interface for browser wallet discovery

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

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

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

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

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.

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

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

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.

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.

<!--"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.

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].

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.

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

CAIP-373 extends the [CAIP-10] Account ID Specification to reference specific data within EVM smart contracts fetched through "on-chain" function calls, enabling cross-application and cross-chain references to blockchain data.

Defines a JSON-RPC method, `wallet_signMessage`, to request cryptographic signatures on arbitrary messages from one or more wallet accounts, optionally tied to a session.

A canonical, chain-agnostic, wallet-signed envelope that applications validate once off-chain and can reference anywhere via a deterministic `qHash` anchor. Identities follow CAIP-10 (`did:pkh`) and chains follow CAIP-2.

A standardized JSON schema for retrieving and verifying off-chain metadata (profile, visual assets, and links) for crypto assets, with built-in support for cross-chain identity discovery.