Kaspa Namespace - Chains

CAIP-2

For context, see the CAIP-2 specification.

Rationale

In CAIP-2 a general blockchain identification scheme is defined. This is the implementation of CAIP-2 for Kaspa. Blockchains in the kaspa namespace are identified by the network names defined by the Rusty Kaspa NetworkId implementation. The Rusty Kaspa full-node implementation exposes the same identifier through RPC with a kaspa- prefix.

Kaspa has its own GHOSTDAG consensus, node RPC, and native network identification. It does not use the Bitcoin-family resolution method defined by the BIP-122 Namespace.

Syntax

The namespace kaspa refers to the Kaspa open-source blockchain platform.

Reference Definition

The initial references are:

Only the references listed in this profile are conformant. Local simnet and devnet names are not included because they do not identify globally unique public networks. A future public network can be added with a distinct reference and genesis block. Kaspa has no central authority that assigns public network identifiers. Future references are registered through updates to this CASA profile and should be supported by a distinct genesis block, implementation evidence, and public Kaspa community review. The change controllers for this profile are Luke Dunshea (@elldeeone) and representatives of the kaspanet GitHub organization.

The registered genesis hashes are:

Resolution Method

To resolve a blockchain reference for the Kaspa namespace, call getBlockDagInfo through a supported Kaspa node RPC transport. Clients can use the Rusty Kaspa Resolver to discover a community-operated public node or connect directly to a self-hosted node. Endpoint selection is operational and does not form part of the CAIP-2 identifier.

Example Request

const rpc = new RpcClient({
  networkId: "testnet-10",
  encoding: Encoding.Borsh,
  resolver: new Resolver(),
});

await rpc.connect();
const response = await rpc.getBlockDagInfo();

Example Response (partial)

{
  "network": "testnet-10"
}

The returned network value is a native NetworkId and maps directly to the corresponding entry in the reference table. For example, testnet-10 resolves to kaspa:testnet-10.

The network identifier is self-reported by the connected node. Applications requiring authenticated network identification SHOULD use a trusted or self-hosted node. The genesis hashes above document the registered networks; they are not returned by getBlockDagInfo, and this RPC call does not independently prove chain ancestry.

Backwards Compatibility

Not applicable.

Test Cases

This is a list of manually composed examples:

# Kaspa mainnet
kaspa:mainnet

# Kaspa public testnet 10
kaspa:testnet-10

References

• Network ID Implementation - Native network parsing and serialization
• Network Parameters - Public-network parameter selection
• Genesis Configuration - Mainnet and testnet genesis constants
• Kaspa RPC Protocol - gRPC getBlockDagInfo protocol definition
• Kaspa Integration Guide - SDK connection and getBlockDagInfo examples
• Kaspa Node Connectivity - Public-node discovery and self-hosted endpoint guidance
• Rusty Kaspa - Kaspa full-node implementation and related SDK libraries
• BIP-122 Namespace - CASA namespace profile for Bitcoin-family chains

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Luke Dunshea, "namespaces/kaspa-caip2: Kaspa Namespace - Chains [DRAFT]," Chain Agnostic Namespaces, kaspa-caip2, July 2026 / . [Online serial]. Available: https://github.com/ChainAgnostic/namespaces/kaspa-caip2.md