ChainAgnostic · elldeeone · Jul 27, 2026 · Jul 27, 2026 · Jul 27, 2026 · Jul 27, 2026
diff --git a/kaspa/README.md b/kaspa/README.md
@@ -0,0 +1,55 @@
+---
+namespace-identifier: kaspa
+title: Kaspa Ecosystem
+author: Luke Dunshea (@elldeeone)
+discussions-to: https://kas-smiths.org/t/kaspa-x402-pay-per-request-kas-payments-for-apis-and-ai-agents/15
+status: Draft
+type: Informational
+created: 2026-07-27
+requires: ["CAIP-2", "CAIP-10"]
+---
+
+# Namespace for Kaspa chains
+
+## Introduction
+
+Blockchains in the `kaspa` namespace are identified by the network names defined by the Rusty Kaspa `NetworkId` implementation.
+Kaspa is a proof-of-work Layer 1 with a native UTXO transaction model that uses GHOSTDAG consensus to order parallel blocks in a blockDAG.
+It has its own consensus protocol, RPC interfaces, transaction serialization, and address encoding.
+
+Although Kaspa uses UTXOs, it does not implement Bitcoin or the [BIP-122][] chain-identification method.
+The `kaspa` namespace therefore identifies Kaspa networks directly rather than placing them in the [BIP-122 Namespace][].
+
+## Syntax
+
+The namespace `kaspa` refers to the Kaspa open-source blockchain platform.
+The initial profiles cover Kaspa mainnet and the stable public testnet-10 network.
+
+## Governance
+
+Kaspa is a decentralized proof-of-work network with no single governing organization or authority.
+Protocol changes are developed openly and take effect through adoption by independent network participants, including node operators and miners.
+The resources referenced in this profile document the network and its implementation; they are not governing authorities.
+
+This namespace profile documents identifiers already used across the Kaspa ecosystem for interoperability.
+Changes to this profile are reviewed through the CASA namespace process and should be informed by public Kaspa community discussion and implementation evidence.
+
+## References
+
+- [Kaspa][] - Kaspa ecosystem website
+- [Kaspa Docs][] - Kaspa builder documentation
+- [Rusty Kaspa][] - Kaspa full-node implementation and related SDK libraries
+- [Kaspa Community Discussion][] - Community review of the identifier convention
+- [BIP-122][] - Bitcoin-family URI and chain-identification method
+- [BIP-122 Namespace][] - CASA namespace profile for BIP-122 chains
+
+[Kaspa]: https://kaspa.org/
+[Kaspa Docs]: https://docs.kaspa.org/
+[Rusty Kaspa]: https://github.com/kaspanet/rusty-kaspa
+[Kaspa Community Discussion]: https://kas-smiths.org/t/kaspa-x402-pay-per-request-kas-payments-for-apis-and-ai-agents/15
+[BIP-122]: https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki
+[BIP-122 Namespace]: https://namespaces.chainagnostic.org/bip122/README
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/kaspa/caip10.md b/kaspa/caip10.md
@@ -0,0 +1,147 @@
+---
+namespace-identifier: kaspa-caip10
+title: Kaspa Namespace - Addresses
+author: Luke Dunshea (@elldeeone)
+discussions-to: https://kas-smiths.org/t/kaspa-x402-pay-per-request-kas-payments-for-apis-and-ai-agents/15
+status: Draft
+type: Standard
+created: 2026-07-27
+requires: ["CAIP-2", "CAIP-10"]
+---
+
+# CAIP-10
+
+*For context, see the [CAIP-10][] specification.*
+
+## Rationale
+
+Kaspa uses a UTXO model rather than persistent balance-bearing accounts.
+For CAIP-10 purposes, a Kaspa account identifier represents a native recipient or locking address.
+
+Native Kaspa addresses use the form `<prefix>:<payload>`.
+The prefix identifies the network type, and the payload contains an address version, public key or script hash, and checksum.
+Because [CAIP-10][] does not allow `:` inside `account_address`, this profile uses the native payload without its prefix.
+The CAIP-2 portion already identifies the network.
+
+## Specification
+
+A Kaspa CAIP-10 account identifier MUST follow:
+
+```text
+kaspa:<reference>:<address_payload>
+```
+
+Where:
+
+- `kaspa` is the namespace
+- `<reference>` is defined by the Kaspa CAIP-2 profile
+- `<address_payload>` is the portion after the colon in a valid native Kaspa address
+
+The native prefix is determined by the CAIP-2 identifier:
+
+| CAIP-2 identifier | Native address prefix |
+|-------------------|-----------------------|
+| `kaspa:mainnet` | `kaspa` |
+| `kaspa:testnet-10` | `kaspatest` |
+
+### Address Format
+
+Kaspa defines the following address versions:
+
+| Version | Address type | Body length | Encoded payload length |
+|---------|--------------|-------------|------------------------|
+| `0` | Schnorr public key | 32 bytes | 61 characters |
+| `1` | ECDSA public key | 33 bytes | 63 characters |
+| `8` | Script hash | 32 bytes | 61 characters |
+
+The preliminary regular expression for an address payload is:
+
+```regex
+^(?:[qpzry9x8gf2tvdw0s3jn54khce6mua7l]{61}|[qpzry9x8gf2tvdw0s3jn54khce6mua7l]{63})$
+```
+
+A regular-expression match is necessary but not sufficient because the decoded version, body length, and checksum must also be valid.
+
+### Resolution
+
+To validate a Kaspa CAIP-10 identifier:
+
+1. Validate the CAIP-2 reference according to the [Kaspa CAIP-2 Profile][].
+2. Restore the native prefix associated with that reference.
+3. Decode the reconstructed native address.
+4. Validate the address version, body length, and prefix-dependent checksum.
+
+After validation, an implementation can use Kaspa node or SDK address utilities to derive the corresponding transaction script public key.
+Address validity does not depend on whether the address currently has unspent outputs.
+
+### Canonicalization
+
+Kaspa address encoders produce a canonical payload with zero-valued right-padding bits.
+Native decoders may accept alternative strings that differ only in unused padding bits while decoding to the same address.
+Implementations that compare, deduplicate, or store CAIP-10 identifiers SHOULD reconstruct the native address, decode it, and use the payload produced by re-encoding as the canonical form.
+
+### Backwards Compatibility
+
+Not applicable.
+
+## Security Considerations
+
+A regular-expression match alone does not establish that an address payload is valid.
+Implementations MUST decode the reconstructed native address and validate its version, body length, and checksum.
+
+The native prefix MUST be derived from the CAIP-2 reference rather than accepted as separate input.
+The checksum binds the payload to a native prefix class such as `kaspa` or `kaspatest`, not to the complete numbered testnet reference.
+Implementations MUST validate the CAIP-2 reference before deriving the native prefix.
+A payload paired with the wrong native prefix class fails the checksum and MUST be rejected.
+When displaying a native Kaspa address, applications SHOULD restore and display its network prefix to avoid ambiguity.
+
+A Kaspa address identifies a locking condition, not a persistent account, owner, or balance.
+Applications MUST NOT infer control of an address or the existence of spendable outputs from a valid CAIP-10 identifier.
+
+## Test Cases
+
+Valid:
+
+```text
+# Mainnet Schnorr public-key address
+kaspa:mainnet:qp0l70zd5x85ttwd6jv7g3s3a8llzj96d8dncn4zmhv4tlzx5k2jyqh70xmfj
+
+# Mainnet script-hash address
+kaspa:mainnet:pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqlmtfk4dg
+
+# Testnet-10 Schnorr public-key address
+kaspa:testnet-10:qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhqrxplya
+
+# Testnet-10 ECDSA public-key address
+kaspa:testnet-10:qxaqrlzlf6wes72en3568khahq66wf27tuhfxn5nytkd8tcep2c0vrse6gdmpks
+```
+
+Invalid:
+
+```text
+# Mainnet payload paired with testnet-10 (wrong native prefix class)
+kaspa:testnet-10:qp0l70zd5x85ttwd6jv7g3s3a8llzj96d8dncn4zmhv4tlzx5k2jyqh70xmfj
+
+# Native prefix incorrectly retained inside account_address
+kaspa:mainnet:kaspa:qp0l70zd5x85ttwd6jv7g3s3a8llzj96d8dncn4zmhv4tlzx5k2jyqh70xmfj
+
+# Unsupported CAIP-2 reference
+kaspa:testnet-11:qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhqrxplya
+```
+
+## References
+
+- [Address Implementation][] - Native prefixes, address versions, and payload lengths
+- [Address Encoding][] - Base32 alphabet and prefix-dependent checksum
+- [Rusty Kaspa][] - Kaspa full-node implementation and related SDK libraries
+
+[Kaspa CAIP-2 Profile]: ./caip2.md
+[Address Implementation]: https://github.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/crypto/addresses/src/lib.rs
+[Address Encoding]: https://github.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/crypto/addresses/src/bech32.rs
+[Rusty Kaspa]: https://github.com/kaspanet/rusty-kaspa
+[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
+[CAIP-10]: https://chainagnostic.org/CAIPs/caip-10
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/kaspa/caip2.md b/kaspa/caip2.md
@@ -0,0 +1,125 @@
+---
+namespace-identifier: kaspa-caip2
+title: Kaspa Namespace - Chains
+author: Luke Dunshea (@elldeeone)
+discussions-to: https://kas-smiths.org/t/kaspa-x402-pay-per-request-kas-payments-for-apis-and-ai-agents/15
+status: Draft
+type: Standard
+created: 2026-07-27
+requires: CAIP-2
+---
+
+# 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:
+
+| Network | Native `NetworkId` | RPC `networkName` | CAIP-2 identifier |
+|---------|--------------------|-------------------|-------------------|
+| Mainnet | `mainnet` | `kaspa-mainnet` | `kaspa:mainnet` |
+| Testnet 10 | `testnet-10` | `kaspa-testnet-10` | `kaspa:testnet-10` |
+
+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 registered genesis hashes are:
+
+| Network | Genesis block hash |
+|---------|--------------------|
+| Mainnet | `58c2d4199e21f910d1571d114969cecef48f09f934d42ccb6a281a15868f2999` |
+| Testnet 10 | `f896a3034873be1739fc4359236899fd3d65d2bc94f9780df0d0da3eb1cc4370` |
+
+### 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
+
+```javascript
+const rpc = new RpcClient({
+  networkId: "testnet-10",
+  encoding: Encoding.Borsh,
+  resolver: new Resolver(),
+});
+
+await rpc.connect();
+const response = await rpc.getBlockDagInfo();
+```
+
+#### Example Response (partial)
+
+```json
+{
+  "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:
+
+```text
+# 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
+
+[Network ID Implementation]: https://github.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/consensus/core/src/network.rs
+[Network Parameters]: https://github.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/consensus/core/src/config/params.rs
+[Genesis Configuration]: https://github.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/consensus/core/src/config/genesis.rs
+[Kaspa RPC Protocol]: https://github.com/kaspanet/rusty-kaspa/blob/78257f273a26c4be085bab0f79437dee99ca8835/rpc/grpc/core/proto/rpc.proto
+[Kaspa Integration Guide]: https://docs.kaspa.org/integrate/getting-started
+[Kaspa Node Connectivity]: https://docs.kaspa.org/references
+[Rusty Kaspa]: https://github.com/kaspanet/rusty-kaspa
+[BIP-122 Namespace]: https://namespaces.chainagnostic.org/bip122/README
+[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).