CHIP 2026-BCMR-v3
Title: Revitalize the BCMR JSON spec.
Type: Standards
Layer: Applications
Maintainer: Tom Zander
Initial Publication Date: 2026-05-22
Latest Revision Date:
Version: 0.1
Table of Contents
Introduction
The "Bitcoin Cash Metadata Repository" specification has a lot of genius ideas and the basic concept itself is great!
The actual document format has seen a less enthusiastic response from implementors and this document aims to take the lessons learned and do a better revision.
Deployment
The document is basically incompatible with previous versions, but the good news is that most consumers of these JSONs actually use one of the indexers, which may auto-convert to the old standard for clients that are not yet updated.
Motivation
The https://bitcoincashcode.org/BitcoinCash/chip-bcmr CHIP from 2022 is over complex with a large number of features that are not used in real life (details). This makes writing and maintaining the documents harder for all registry-owners, which is bad enough as it is. But the real issue is that all consumers (software) only implement partial support for the standard. And not always the same parts. This has a negative effect on the authors of the bcmr documents. They can't use all features if they want their coins or identities to show up in all wallets. And which features they can use is not well known. As a result many will keep it simple and skip most more complex features.
A simple base specification would be useful. Something that lists a specific number of tags that are going to cover a lot of usecases (they won't need more than the base) and the wallets and websites can then claim to support bcmrv3-base.
Extensions can be added in due time, based on need and popularity. JSON is easy to extend in that way. These extensions may be marked separately as supported: Acme Wallet Supports BCMR-base + BCMR-tokens.
This idea of going for a base is additionally meant to avoid the traditional problem of simply creating more standards to avoid having too many standards. We aim to keep it simple, with the option for future named extensions.
Technical Specification
Base
Like in the bcmr v2, we have an auth-chain and an auth-base. These follow the zeroth-output concept. The root of the chain is the oldest transaction and it's TXID is our identity.
The very basic 'base' is just the identity. As such:
{
"# a JSON for a single 'identity'.",
"# if you need more identities, you will create more than one JSON file.",
"identity": "1aa14f72dc4a6e8fce7932ae9ba0c1731cf80508a3d4148c2bfd8fe4c60cf6d2",
"name": "Sun Mictosystems",
"description": "something something text.\nDot stop.",
"# times likely apply mostly to natural-identies. When was Sun-Microsystems established",
"# when did this identity become defunct (in this case, got bought).",
"# Defunct is about the identity!! Sun Microsystems shut down in 2010",
"established": "1982-02-24",
"defunct": "2010-01-27",
"# the date of this update",
"date": "2023-05-13T00:00:00.000Z",
"# Images, logos, webpages etc.",
"# the hash is needed for cashing servers, allowing wallets to verify they didn't lie.",
"resources": {
"image": "https://gist.githubusercontent.com/mr-zwets/0e698a88323465686437b5e70a8ccf56/raw/Eo_circle_blue_hash.svg",
"image.sha1": "7968e8d899efd7fc0f142e332ec8973227ef318b`"
},
}
Resource names in order of preference:
- image
- website
- telegram
- X
- icon (typically smaller)
This list is not meant to be exhaustive.
Token extension
Most current users of the spec already support tokens, we have a lot of real life examples of tokens to make a decent spec from.
The extension point is simply the 'token' object to be added at the root of the base-json.
See the example JSON: base-with-token.json
This adds a missing feature, the hash validation of resources. An indexing server will end up cashing the resources for faster download and to ensure the resource stays online. To ensure that no man in the middle has changed the data for images and other resources, it is possible to provide a hash.