Add bsv namespace (BSV Blockchain)

[sirdeggen]

Summary

Adds a new namespace, bsv, for the BSV Blockchain, with a complete README.md and CAIP-2 profile. Registers four Chain IDs:

• bsv:mainnet — BSV main network
• bsv:testnet — BSV public test network
• bsv:ttn — Teranode Test Net (public Teranode scaling test network / Teratestnet)
• bsv:tstn — Teranode Scaling Test Net (private, per-deployment scaling test network)

Approach and rationale

BSV descends from the original Bitcoin protocol and shares Satoshi's genesis block with BTC and BCH. I want to be upfront that bip122 can represent BSV: it disambiguates forks by the first post-fork block hash (as it does for Bitcoin Cash, bip122:000000000000000000651ef99cb9fcbe), and a BSV entry could be built the same way from its fork block.

This namespace uses the human-readable network name as the CAIP-2 reference instead, following the casper precedent (a Chain ID that "should not be confused with the genesis_hash"). The reason is that the BSV application layer — BRC-100 wallets, overlay services, ARC broadcasters, SPV clients — universally identifies a network by name, never by fork-block hash. A BRC-100 wallet self-reports via getNetwork → mainnet/testnet (and ttn/tstn on Teranode deployments); SV Node's getblockchaininfo.chain returns main/test. Cross-chain tooling (e.g. the x402 payment protocol, CAIP-10/CAIP-19 references) can then map directly onto identifiers applications already exchange without a full-node round-trip. The two schemes can coexist — a hash-based bip122 BSV entry and this name-based one occupy different namespaces.

ttn and tstn are registered up front so high-throughput payment protocols can target Teranode test environments without overloading bsv:testnet or inventing ad-hoc names that later need client migration. Clients MUST NOT treat a genesis-only bip122 identifier as a BSV network — that reference is ambiguous across the BTC/BCH/BSV split.

Resolution mechanics, syntax (bsv:(mainnet|testnet|ttn|tstn)), and test cases are in bsv/caip2.md.

Context

This registration supports adding BSV as a payment mechanism to the x402 protocol, where the design discussion for these identifiers is ongoing. Happy to adjust the reference scheme (including moving to bip122) based on editor guidance.

Author: @sirdeggen (BSV Association).

[andyrowe]

I maintain a live implementation of the x402 exact scheme for BSV payments (bsv.cx), and this namespace gap is a concrete blocker for it.

Today the only CAIP-2 identifier available for BSV is bip122: — but that's ambiguous: BSV shares Satoshi's genesis block with BTC (and BCH), so a bip122: reference alone can't distinguish the three. My implementation currently works around this by pairing the bip122: network id with a non-standard extra.chain: "bsv" field plus asset: "BSV", and refusing to settle a payment whenever a Bitcoin-family network id arrives without that disambiguator. It works, but it's a workaround for a missing standard identifier.

Registering the bsv namespace here (bsv:mainnet / bsv:testnet) would let conforming implementations reference the chain unambiguously and drop the custom disambiguation. Is there anything currently blocking review, or something I could contribute to help it along — extra CAIP-2 profile detail, an implementer reference, test vectors? Happy to help however's useful.

[bumblefudge]

This seems fine, but I took a glance at BRC-100 and it looks to me like you should probably wrote at least a CAIP-10 profile as well, it looks like BSV breaks a LOT of assumptions people might smuggle over from BTC and/or BCH unless they're warned!

[Ruthheasman]

The only checks that have run on this PR are labeler and check-verified-commits — the test workflows haven't been triggered, since PRs from forks need a maintainer to approve workflow runs. Could someone approve the run so we can see actual CI status here? Hard to review a 43-file PR that's never been tested.
Also worth noting the CAIP-2 dependency is now cleared — bsv namespace merged in #190.

[sirdeggen]

Follow-up for the CAIP-10 request in #190 (review): opened #202 with a BRC-100 identity-key profile (not Bitcoin addresses), including the BTC/BCH assumptions that do not carry over.

[bumblefudge]

Hard to review a 43-file PR that's never been tested.

@Ruthheasman maybe you intended this comment for a different PR?

[Ruthheasman]

Not critiquing - just trying to support the process of getting it tested and then added. Ruth Heasman

…

On Mon, 7 Sep 2026 at 15:47, Bumblefudge ***@***.***> wrote: *bumblefudge* left a comment (ChainAgnostic/namespaces#190) <#190 (comment)> Hard to review a 43-file PR that's never been tested. @Ruthheasman <https://github.com/Ruthheasman> maybe you intended this comment for a different PR? — Reply to this email directly, view it on GitHub <#190?email_source=notifications&email_token=ANAHDK5ZIQN5WZILGPXCVT35N3DAFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXGIZTGMZUGAY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5572333401>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANAHDK6OPQXSUV5TMBMOEPD5N3DAFAVCNFSNUABFKJSXA33TNF2G64TZHM2DINZWG4YTCNBRHNEXG43VMU5TIOJQGQZDGMJXGE42C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ANAHDK6PN6PWOG2554N4YNT5N3DAFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXGIZTGMZUGAY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ANAHDK2OQE56OXCRF7NWSRL5N3DAFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXGIZTGMZUGAY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[bumblefudge]

@Ruthheasman this not a 43-file PR and there is no CI to run or any code to test?!