Hi Tom,
I agree with the extension idea. A BCMR + named optional extensions, I like it and this is what was proposed for NFT CashMint. It solves the real problem of wallets implementing different subsets of v2 and authors not knowing what will actually render. But I want to push back on two things, the framing that unused features should be removed, and the decision to make v3 a breaking change.
On removals, a lot of the features you’re cutting aren’t used because nobody wrote good guides for them. History, tags, chains, snapshots, these have real use cases. Still, an author looking at v2 has no clear documentation that has a step-by-step guide and examples telling them when to use history, what a working example looks like, or how wallets will render it. The fix for underused features is better docs and worked examples, not deletion. If we drop them now we lose the option to revive them later with proper guides. If we keep them as optional fields in their existing v2 locations, the cost is near zero and the door stays open. As for license, yeah idk whats that doing😅
On breaking changes, I think you can get everything you want without breaking v2 compatibility. Keep v2 outer structure with the identities map at the root, many identities per file, this matters for registries like OpenTokenRegistry that track many tokens in one JSON, and one identity per file just pushes complexity onto whoever has to list and fetch them all. Inside each identity, shrink the required fields down to a small base of name and URIs. Everything else from v2 like history, tags, chains, status, splitId stays valid JSON exactly where v2 puts it, just optional.
That way existing v2 parsers read v3 files without errors, so we don’t need an indexer translation layer. Authors who only need the base write tiny files, and authors who need more reach for an optional field that already has a defined home, or for a documented named extension instead of inventing custom keys nobody parses.
On naming, to avoid confusion it can be just BCMR v3 with extensions documented inside it. Not BCMR-base + BCMR-tokens + BCMR-history, that reads like a dependency list and proliferates fast. One spec name, one extensions section, a registry of documented extension names like cashmint. Wallets say they support BCMR with extensions X and Y. Cleaner for everyone.
One thing v3 should fix while keeping v2 compatibility, the current extensions schema only allows strings, flat string maps, or two-level string maps. No nested objects with mixed types, or integers. This forces every serious extension into ugly string-flattening workarounds. Cashmint is the first to hit this wall and won’t be the last. v3 should loosen this rule to allow proper nested JSON inside extensions.
So let’s try to use v2 with the feature that would be removed in v3 and include cashmint as the first registered extension. This file validates against the current v2 schema today and would still work under the v3 schema
{
"$schema": "https://cashtokens.org/bcmr-v2.schema.json",
"version": { "major": 1, "minor": 0, "patch": 0 },
"latestRevision": "2026-05-22T00:00:00.000Z",
"registryIdentity": "1aa14f72dc4a6e8fce7932ae9ba0c1731cf80508a3d4148c2bfd8fe4c60cf6d2",
"license": "CC0-1.0",
"defaultChain": "0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce",
"chains": {
"0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce": {
"2009-01-03T18:15:05.000Z": {
"name": "Bitcoin Cash",
"description": "The BCH side of the BCH/XEC split (mainnet).",
"token": { "symbol": "BCH", "decimals": 8 },
"uris": {
"icon": "https://bitcoincash.org/logo.svg",
"web": "https://bitcoincash.org"
}
}
},
"00000000040ba9641ba98a37b2e5ceead38e4e2930ac8f145c8094f94c708727": {
"2022-11-15T12:00:00.000Z": {
"name": "Chipnet",
"description": "Test network on which CHIPs are activated 6 months before mainnet.",
"token": { "symbol": "tBCH", "decimals": 8 }
}
}
},
"tags": {
"collectable": {
"name": "Collectable",
"description": "Identities issuing NFTs intended for collecting.",
"uris": {
"icon": "https://gurus.cash/tags/collectable.svg",
"web": "https://gurus.cash/tags/collectable"
}
},
"art": {
"name": "Art",
"description": "Hand-drawn or designed visual art collections."
},
"audited": {
"name": "Audited by ACME",
"description": "Smart contracts and minting policy reviewed by ACME Audits Ltd.",
"uris": {
"icon": "https://acmeaudits.example/badge.svg",
"registry": "https://acmeaudits.example/.well-known/bitcoin-cash-metadata-registry.json"
}
}
},
"identities": {
"1aa14f72dc4a6e8fce7932ae9ba0c1731cf80508a3d4148c2bfd8fe4c60cf6d2": {
"2024-01-15T00:00:00.000Z": {
"name": "BCH Guru (beta)",
"description": "Beta release of the BCH Guru NFT collection. Superseded by the mainnet collection on 2026-05-22.",
"status": "inactive",
"tags": ["collectable"],
"splitId": "00000000040ba9641ba98a37b2e5ceead38e4e2930ac8f145c8094f94c708727",
"uris": {
"icon": "https://gurus.cash/logo-beta.svg",
"web": "https://gurus.cash",
"image": "https://gurus.cash/hero-beta.png",
"migrate": "https://gurus.cash/migrate-from-beta",
"blog": "https://gurus.cash/blog",
"chat": "https://t.me/gurusbeta",
"forum": "https://bitcoincashresearch.org/t/bch-gurus",
"support": "https://gurus.cash/support",
"registry": "https://gurus.cash/.well-known/bitcoin-cash-metadata-registry.json",
"twitter": "https://twitter.com/bchgurus",
"github": "https://github.com/bchgurus"
}
},
"2026-05-22T00:00:00.000Z": {
"name": "BCH Gurus",
"description": "Mainnet BCH Guru NFT collection.",
"status": "active",
"tags": ["collectable", "art", "audited"],
"splitId": "0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce",
"migrated": "2026-06-22T00:00:00.000Z",
"uris": {
"icon": "https://gurus.cash/logo.svg",
"icon-intro": "https://gurus.cash/logo-intro.webp",
"web": "https://gurus.cash",
"image": "https://gurus.cash/hero.png",
"blog": "https://gurus.cash/blog",
"chat": "https://t.me/bchgurus",
"forum": "https://bitcoincashresearch.org/t/bch-gurus",
"support": "https://gurus.cash/support",
"registry": "https://gurus.cash/.well-known/bitcoin-cash-metadata-registry.json",
"twitter": "https://twitter.com/bchgurus",
"github": "https://github.com/bchgurus",
"discord": "https://discord.gg/bchgurus"
},
"token": {
"category": "1aa14f72dc4a6e8fce7932ae9ba0c1731cf80508a3d4148c2bfd8fe4c60cf6d2",
"symbol": "GURU",
"decimals": 0,
"nfts": {
"description": "Hand-drawn collectable Guru characters with traits encoded per token.",
"fields": {
"serial": {
"name": "Serial",
"description": "Unique serial number for this Guru.",
"encoding": { "type": "number" }
}
},
"parse": {
"bytecode": "00d2517f7c6b",
"types": {
"00": {
"name": "Standard Guru",
"description": "Default Guru NFT type.",
"fields": ["serial"]
}
}
}
}
},
"extensions": {
"cashmint": {
"cms_version": "1.0",
"max_supply": "10000",
"minting_policy": "fixed",
"metadata_uri_pattern": "ipfs://QmCollectionFolder/{serial}.json",
"royalty_bps": "500",
"royalty_address": "bitcoincash:qr7fzmep8g7h7ymfxy74lgc0v950j3r2959lhtxxsl",
"commitment_format": "sequential",
"commitment_serial_bytes": "2"
},
"contact": {
"email": "hello@gurus.cash",
"postal-address": "Guru HQ, 123 Cash Street, BCH City"
}
}
}
}
},
"locales": {
"es": {
"identities": {
"1aa14f72dc4a6e8fce7932ae9ba0c1731cf80508a3d4148c2bfd8fe4c60cf6d2": {
"2026-05-22T00:00:00.000Z": {
"name": "BCH Gurus",
"description": "Mainnet BCH Guru NFT collection.",
"status": "active",
"tags": ["collectable", "art", "audited"],
"splitId": "0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce",
"migrated": "2026-06-22T00:00:00.000Z",
"uris": {
"icon": "https://gurus.cash/logo.svg",
"web": "https://gurus.cash"
},
"token": {
"category": "1aa14f72dc4a6e8fce7932ae9ba0c1731cf80508a3d4148c2bfd8fe4c60cf6d2",
"symbol": "GURU",
"decimals": 0
}
}
}
},
"tags": {
"art": {
"name": "Art",
"description": "Hand-drawn or designed visual art collections."
}
}
}
}
}
This file uses everything you proposed removing, all working together. Version with major/minor/patch, multiple identities supported via the map (only one shown), two timestamp-keyed snapshots with the older marked inactive and the newer active, a separate token.category, the full standardized URI list (image, migrate, icon-intro, support, forum, blog, chat, registry) plus custom social ones, latestRevision, the $schema reference, NFT parse bytecode for VM-encoded type matching, status fields, splitId on both snapshots and a full chains map with mainnet and chipnet, license at the top, three tags that identities reference, the migrated timestamp for gradual transition, and locales for Spanish translation.
The cashmint extension shows the first registered extension working inside v2 existing extensions namespace. Per-token metadata lives off-chain at metadata_uri_pattern with serial substitution, so a 10,000-token collection doesn’t bloat the BCMR file. Royalty and commitment_encoding are flattened to flat string keys because v2 extensions schema requires it, which is the constraint I’d want v3 to relax so cashmint can use its preferred nested shape.
A wallet that only supports base BCMR reads name, URIs, and token, ignoring extensions, history snapshots, and tags. With cashmint support, it additionally reads extensions.cashmint and renders per-token metadata, royalty info, and supply caps. History support shows the rename and beta-to-mainnet timeline. Chain support warns users about split-relevant tokens. Nothing breaks at any level, and nothing has to be deleted. Thanks for putting this together, the discussion was needed.
