# CAIPs: standards for the parts of a wallet that are not chain specific

> Chain Agnostic Improvement Proposals describe standards that sit above any single blockchain, covering assets, contracts and accounts rather than one chain's protocol. The proposals are read and referenced at chainagnostic.org, and the Git repository exists to hold their source and history rather than to be the place you read them.

**ChainAgnostic/CAIPs** — Chain Agnostic Improvement Proposals

- Repository: https://github.com/ChainAgnostic/CAIPs
- Website: https://chainagnostic.org
- Stars: 642 · Forks: 235
- Language: HTML
- License: CC0-1.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/chainagnostic-caips

## What sits above a single chain, and what a CAIP is not

Chain Agnostic Improvement Proposals describe standards for blockchain projects that are not specific to a single chain. The short description of the repository says exactly that, and the topic tags make the lineage clear with bip, eip, bitcoin, ethereum and cosmos alongside blockchain and improvement-proposal.

So the scope is deliberately narrow. A CAIP is not a consensus specification, not a token standard and not a description of how a particular chain reaches finality. It covers the layer that a wallet, a bridge or a dapp has to agree on before it can talk to several chains at once: how an asset is named and identified, how a contract is addressed, how an account is referred to, and the related handshakes and encodings that make those identifiers mean the same thing everywhere.

The naming follows the convention the other ecosystems established, with a CAIP number standing in for a BIP or an EIP. The difference in scope is the important part, not the difference in the numbering. A BIP describes how Bitcoin works. An EIP describes how Ethereum works. A CAIP describes how to talk to assets, contracts and accounts when the chain underneath can be one of many.

The repository is a Jekyll site, not a code project, and the top level entries show it: _config.yml, _data, _includes, _layouts, assets, index.html, 404.html, a CNAME file for the custom domain, a Gemfile and Gemfile.lock, and a CAIPs/ directory holding the proposals themselves. The primary language recorded for the repository is HTML, which fits a documentation site rather than an implementation.

## Read the proposals on the site, not in the git repository

The README is explicit about where these documents are meant to be consumed. The CAIPs are intended to be viewed and referenced at chainagnostic.org rather than on the current public git repository, and to contribute you follow the Contributing file.

That single sentence changes how you should treat the repository. It is the source and the history, not the reading surface. If you are looking for the current text of a proposal, the canonical location is the site, and for the index specifically the README says to visit chainagnostic.org for the up to date index of all CAIPs listed by status. The up-to-date index is a moving target because a proposal can change status at any time, and the git repository cannot tell you the current status of a document without you reading its history.

The template file in the repository root, caip-template.md, is what a new proposal starts from. Keeping the template and the rendered site in the same repository is what makes the git history meaningful: a reader who wants to know why a wording changed can go back through the commits rather than being handed a document with no visible history.

For anyone writing tooling over these standards, the practical sequence is to read the site, note the status of the document you are depending on, and treat the repository as where the change happens rather than where the answer lives.

## Three status terms, and what each one promises

CAIPs move through three defined states, and the definitions are short enough to be worth quoting exactly because the middle one contains a timing condition.

Draft is an CAIP that is undergoing rapid iteration and changes. There is no compatibility expectation at all at this stage, and a document that changes without warning is the expected behaviour rather than a defect.

Review is an CAIP that is done with its initial iteration and ready for review by a wide audience. The wording matters: ready for review is not the same as stable. A proposal in Review can still change, because review is exactly the phase where a wide audience is expected to find problems with it.

Accepted is a core CAIP that has been in Review for at least 2 weeks and any technical changes that were requested have been addressed by the author. This is the only status with a stability implication, and even then the guarantee is bounded: the condition is time in review plus a response to feedback, not a promise that the content will never change again.

The two week minimum in the Accepted definition is a real design choice rather than boilerplate. It gives authors a window to absorb feedback before a proposal becomes a core standard, and it prevents a document from freezing on the day it is opened to review. If you are building on a proposal, the status term is the piece of metadata that tells you how much risk you are taking on.

## Namespaces took over from the CAIPs that used to cover them

One part of the README describes a migration that already happened, and it is easy to read past.

There were previously specific CAIPs for what is now referred to as namespaces. Chain Agnostic Namespaces describe a blockchain ecosystem or set of ecosystems as a namespace, relying as much as possible on the CAIP specifications to minimise the research needed to interact with assets, contracts and accounts in that namespace. Where a namespace has been accepted by the editors, the former CAIPs have been superseded and ongoing specification should be continued there.

The logic of the split is that a namespace is a different kind of object. The CAIPs describe the mechanism, a namespace describes a place. A wallet implementing the asset and account specifications still needs to know which chains are in scope and how they differ, and that is what the namespace document carries. Superseding the old CAIPs once a namespace is accepted keeps one place to look for a given ecosystem rather than scattering the detail across several proposals.

Two practical consequences follow for a reader. First, if you encounter an older CAIP covering what is now a namespace, it is not stale by accident, it was replaced on purpose, and the namespace repository is where the current text lives. Second, the namespace list is where the per chain differences are collected, so the amount of research you have to do yourself falls as more namespaces are accepted. The supersession is done by editors, and the condition is that the namespace has been accepted by them.

## A spec repository with no releases and a licence that treats the words as public domain

The mechanics of this repository are unusual, and they are worth understanding before you depend on it.

There are no GitHub releases. The proposal numbers are the version identifiers, in the same way a BIP or EIP number is, and the last push was on 2026-08-18. The recent releases list is empty, so there is no tag history to walk and no changelog. What you have instead is per document status, which is the versioning system for this project.

The licence is CC0-1.0, which is a public domain dedication rather than a conventional permissive licence. For a set of standards documents that is a sensible choice: the text can be reused, quoted and incorporated into other specifications without attribution obligations or share-alike conditions, and you are not asked to track a separate licence of the source repository. The LICENSE file is in the repository root alongside the FUNDING.json file and the .github directory.

There is a funding file, which tells you the project accepts sponsorship, and an .editorconfig for consistent whitespace across contributors. The repository is small in terms of tooling, which is expected for a document set, and the practical risk is low in a way it would not be for a code dependency. What you are consuming is a set of words, and the main way to get hurt is not a broken build but a proposal you assumed was Accepted when it was still in Review.

## Conclusion

CAIPs suit a wallet or dapp developer who needs a shared vocabulary for assets, accounts and contracts across several chains, and who would otherwise invent a private naming scheme that no other tool understands. It does not suit a developer working inside a single chain with a well established specification of its own, since the whole point of these documents is to cover what is common rather than what is specific. Before you implement against one, read it on chainagnostic.org rather than in the repository, check the status term the document carries, and note that a CAIP still marked Draft is expected to change without notice.

## FAQ

### What is a CAIP?

A CAIP is a Chain Agnostic Improvement Proposal, describing a standard for blockchain projects that is not specific to a single chain, covering things like assets, contracts and accounts so that tools can work across several chains consistently.

### Where should I read CAIPs?

The README states the CAIPs are intended to be viewed and referenced at chainagnostic.org rather than on the public git repository. The site also carries the up-to-date index of all CAIPs listed by status.

### What do the Draft, Review and Accepted CAIP statuses mean?

Draft means the proposal is undergoing rapid iteration and changes. Review means it has finished its initial iteration and is ready for review by a wide audience. Accepted means it is a core CAIP that has been in Review for at least 2 weeks and has addressed requested technical changes.

### What are Chain Agnostic Namespaces and how do they relate to CAIPs?

Namespaces describe a blockchain ecosystem or a set of ecosystems as a namespace, relying as much as possible on the CAIP specifications. There used to be specific CAIPs covering what are now namespaces, and where a namespace has been accepted by the editors, those former CAIPs have been superseded and ongoing specification continues in the namespace repository.

## Sources

- [ChainAgnostic/CAIPs on GitHub](https://github.com/ChainAgnostic/CAIPs)
- [Issues](https://github.com/ChainAgnostic/CAIPs/issues)
- [License: CC0-1.0](https://github.com/ChainAgnostic/CAIPs/blob/main/LICENSE)
- [Project website](https://chainagnostic.org)
- [README](https://github.com/ChainAgnostic/CAIPs/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chainagnostic-caips