Add Radix (radix) namespace: CAIP-2, CAIP-10, CAIP-19

radix/README.md

@@ -0,0 +1,83 @@
+---
+namespace-identifier: radix
+title: Radix DLT
+author: ["Avaunt (@AVaunt-consulting)"]
+discussions-to: https://github.com/ChainAgnostic/namespaces/pull/198
+status: Draft
+type: Informational
+created: 2026-07-28
+requires: ["CAIP-2", "CAIP-10", "CAIP-19"]
+---
+
+# Namespace for Radix DLT
+
+Radix is a layer-1 network purpose-built for decentralized finance, currently
+running the "Babylon" protocol generation (live since September 2023). It is
+not EVM-compatible: transactions execute in the Radix Engine, an
+asset-oriented execution environment in which tokens ("resources") are native
+primitives held in accounts rather than balances inside contract storage.
+Transactions are expressed as human-readable "transaction manifests" over an
+intent-based transaction model, and are signed by zero or more signatories
+before being notarized and submitted.
+
+Radix uses deterministic finality (HotStuff-style BFT): committed transactions
+are final, and there are no probabilistic forks. The ledger is a stream of
+transactions broken into epochs of roughly five minutes rather than blocks.
+
+All Radix entity addresses (accounts, resources, components, packages) are
+bech32m-encoded strings whose human-readable part (HRP) is the concatenation
+of an *entity specifier* (e.g. `account_`, `resource_`) and a *network
+specifier* (`rdx` for mainnet, `tdx_2_` for the Stokenet public testnet),
+making every address self-describing and network-bound.
+
+## Rationale
+
+The namespace identifier `radix` is the network's common name, used across its
+documentation, tooling, and deep links (e.g. the `radix:<address>` deposit QR
+convention). Networks in this namespace are the Radix Babylon networks: one
+production mainnet and a small, governed set of test networks, each defined by
+a numeric network ID, a logical name, and an address HRP suffix:
+
+| Network  | Network ID | Logical name | HRP network specifier |
+| -------- | ---------- | ------------ | --------------------- |
+| Mainnet  | `1`        | `mainnet`    | `rdx`                 |
+| Stokenet | `2`        | `stokenet`   | `tdx_2_`              |
+
+The earlier "Olympia" network generation (2021–2023) was retired when its end
+state was migrated into Babylon's genesis; Olympia used different address
+encodings and is out of scope for this namespace.
+
+## Governance
+
+The Radix protocol and its reference node implementation were originally developed by RDX Works and stewarded by the Radix Foundation. RDX Works has since disbanded and protocol changes are now governed and maintained by the Radix Foundation. Note: As of 3rd August 2026 a Marshall Islands DAO is currently being created with the intention of the Radix Foundation handing over IP, Crypto assets and relevant accounts to the Marshall Islands DAO. The creation of the DAO is expected to be completed before the end of 2026.
+Protocol changes ship as named "protocol updates" (e.g. "Anemone", "Bottlenose", "Cuttlefish") which are
+enacted at epoch boundaries once a supermajority of validator stake signals
+readiness. There is no on-chain permissionless improvement-proposal process;
+specifications and integrator guidance are published in the official
+documentation and the open-source node and toolkit repositories.
+
+## References
+
+- [Radix Documentation][] - official developer and integrator documentation.
+- [Radix Integrator Concepts][] - addresses, networks, transactions, and API guidance for integrators.
+- [Well-Known Addresses][] - canonical registry of native addresses (XRD, badges, packages) per network, including each network's ID and HRP suffix.
+- [Address Concepts][] - bech32m address structure: entity specifier, network specifier, and 30-byte payload.
+- [Babylon Node][] - reference node implementation (Java/Rust).
+- [Radix Engine Toolkit][] - offline transaction construction and address derivation/validation library (Rust core; TypeScript, Python and other bindings).
+- [Gateway API][] - indexed network API used by wallets and dashboards.
+- [Core API][] - node-local API for integrators running their own node.
+- [Radix Dashboard][] - the network explorer.
+
+[Radix Documentation]: https://docs.radixdlt.com/
+[Radix Integrator Concepts]: https://docs.radixdlt.com/docs/concepts
+[Well-Known Addresses]: https://docs.radixdlt.com/docs/well-known-addresses
+[Address Concepts]: https://docs.radixdlt.com/docs/concepts
+[Babylon Node]: https://github.com/radixdlt/babylon-node
+[Radix Engine Toolkit]: https://github.com/radixdlt/radix-engine-toolkit
+[Gateway API]: https://radix-babylon-gateway-api.redoc.ly/
+[Core API]: https://radix-babylon-core-api.redoc.ly/
+[Radix Dashboard]: https://dashboard.radixdlt.com/
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

radix/caip10.md

@@ -0,0 +1,154 @@
+---
+namespace-identifier: radix-caip10
+title: Radix DLT Namespace - Accounts
+author: ["Avaunt (@AVaunt-consulting)"]
+discussions-to: https://github.com/ChainAgnostic/namespaces/pull/198
+status: Draft
+type: Standard
+created: 2026-08-01
+requires: ["CAIP-2", "CAIP-10"]
+---
+
+# CAIP-10
+
+*For context, see the [CAIP-10][] specification.*
+
+## Introduction
+
+Radix accounts are on-ledger components with a native address, not raw public
+keys. Most accounts begin as **virtual accounts**: an address is derived
+offline from an Ed25519 or Secp256k1 public key and can receive deposits
+before anything exists on-ledger; the account component is instantiated on
+first interaction. Account ownership is mutable — an account that started as
+a key-derived virtual account may later be controlled by different keys or by
+multi-factor access rules ("smart accounts") — so the address, not any public
+key, is the stable identifier.
+
+## Specification
+
+### Semantics
+
+An account address is a bech32m string ([BIP-350][]) composed of:
+
+- **HRP**: the entity specifier `account_` concatenated with the network
+  specifier of the target network (`rdx` for mainnet, `tdx_2_` for Stokenet);
+- the bech32m separator `1`;
+- **data**: 48 base32 characters encoding 30 bytes — 1 entity-type byte
+  (e.g. `0x51` for a virtual Ed25519 account, `0xd1` for a virtual Secp256k1
+  account, or the type byte of a ledger-allocated account) followed by 29
+  address bytes (for virtual accounts, the last 29 bytes of the Blake2b-256
+  hash of the controlling public key);
+- a 6-character checksum computed over the HRP and data.
+
+Because the checksum covers the HRP, an account address is only valid on the
+network named in its HRP, and that network MUST match the [CAIP-2][] segment
+of the CAIP-10 identifier (`radix:mainnet` addresses carry `account_rdx`;
+`radix:stokenet` addresses carry `account_tdx_2_`).
+
+### Syntax
+
+The `account_id` is formed of the CAIP-2 identifier followed by the native
+account address verbatim:
+
+```
+account_id:        chain_id + ":" + account_address
+chain_id:          radix:[a-z0-9]{1,32} (see the [CAIP-2 Profile][])
+account_address:   account_ + hrp_suffix + "1" + [02-9ac-hj-np-z]{54}
+hrp_suffix:        rdx | tdx_2_ | (other registered network specifiers)
+```
+
+Per-network validation regular expressions:
+
+```
+# Mainnet
+radix:mainnet:account_rdx1[02-9ac-hj-np-z]{54}
+
+# Stokenet
+radix:stokenet:account_tdx_2_1[02-9ac-hj-np-z]{54}
+```
+
+The 54 characters after the separator are 48 data characters plus the
+6-character checksum, drawn from the bech32 charset (which excludes `1`,
+`b`, `i`, `o`).
+
+#### Canonicalization
+
+Addresses MUST be written in lowercase. Bech32m is case-insensitive at decode
+time and forbids mixed case entirely; the canonical, and only conformant,
+CAIP-10 form for this namespace is the lowercase encoding, so consumers can
+compare identifiers by exact string equality.
+
+### Resolution Mechanics
+
+An address can be validated offline (bech32m checksum + HRP inspection),
+e.g. with the [Radix Engine Toolkit][], which also derives virtual account
+addresses from public keys. On-ledger state, if any, can be queried via the
+Gateway API:
+
+```
+POST /state/entity/details
+{ "addresses": ["account_rdx129a9wuey40lducsne6r8e5q7xmt07068gcede0x0nrwtsnehss5d52"] }
+```
+
+A valid virtual-account address that has not yet been instantiated will
+report no on-ledger state; it is still a correct CAIP-10 identifier and can
+receive deposits.
+
+## Rationale
+
+The native bech32m address is used verbatim (rather than re-encoded) because
+it is self-describing (entity and network specifiers), checksummed, and the
+only account identifier Radix users, wallets, and APIs exchange. Public keys
+are unsuitable identifiers because account ownership is mutable.
+
+### Backwards Compatibility
+
+Olympia-era account addresses (bech32, ending before September 2023) are a
+retired format and are not valid in this namespace. The [Radix Engine
+Toolkit][] can map an Olympia Secp256k1 account address to its Babylon
+equivalent where historical continuity is needed.
+
+## Test Cases
+
+This is a list of manually composed and checksum-validated examples:
+
+```
+# Mainnet virtual Ed25519 account
+radix:mainnet:account_rdx129a9wuey40lducsne6r8e5q7xmt07068gcede0x0nrwtsnehss5d52
+
+# Stokenet virtual Ed25519 account (same underlying key-hash bytes, different
+# network — note the different HRP and checksum)
+radix:stokenet:account_tdx_2_129a9wuey40lducsne6r8e5q7xmt07068gcede0x0nrwtsnehrlel8s
+```
+
+## Additional Considerations
+
+Radix addresses contain underscore (`_`) characters in their HRP. The
+[CAIP-10][] account-address charset (`[-.%a-zA-Z0-9]{1,128}`) predates this
+namespace and does not include `_`; this profile nevertheless uses the native
+format verbatim for fidelity and usability, following the precedent of other
+namespaces whose native identifiers include underscores (e.g. the `stacks`
+CAIP-19 profile). Consumers requiring strict CAIP-10 charset conformance MAY
+percent-encode underscores as `%5F` per [RFC 3986][]; implementations in this
+namespace SHOULD accept both and emit the unencoded form.
+
+## References
+
+- [Radix Accounts][] - account model, virtual accounts, and deposit rules.
+- [Address Concepts][] - bech32m address structure: entity specifier, network specifier, 30-byte payload.
+- [Radix Engine Toolkit][] - offline address derivation and validation.
+- [Gateway API][] - `/state/entity/details` endpoint documentation.
+
+[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
+[CAIP-2 Profile]: ./caip2.md
+[CAIP-10]: https://chainagnostic.org/CAIPs/caip-10
+[BIP-350]: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
+[RFC 3986]: https://www.rfc-editor.org/rfc/rfc3986#section-2.1
+[Radix Accounts]: https://docs.radixdlt.com/docs/account
+[Address Concepts]: https://docs.radixdlt.com/docs/concepts
+[Radix Engine Toolkit]: https://github.com/radixdlt/radix-engine-toolkit
+[Gateway API]: https://radix-babylon-gateway-api.redoc.ly/
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

radix/caip19.md

@@ -0,0 +1,156 @@
+---
+namespace-identifier: radix-caip19
+title: Radix DLT Namespace - Assets
+author: ["Avaunt (@AVaunt-consulting)"]
+discussions-to: https://github.com/ChainAgnostic/namespaces/pull/198
+status: Draft
+type: Standard
+created: 2026-08-01
+requires: ["CAIP-2", "CAIP-19"]
+---
+
+# CAIP-19
+
+*For context, see the [CAIP-19][] specification.*
+
+## Introduction
+
+On Radix, tokens are **resources**: native ledger primitives created through
+the Radix Engine's resource system rather than balances inside deployed
+contracts. Every resource — fungible or non-fungible, including the native
+token XRD — is identified by a global resource address with the entity
+specifier `resource_`. There is no special-cased "native currency"
+identifier: XRD is simply the well-known resource
+`resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd` on
+mainnet.
+
+Fungible resources have a divisibility of 0–18 decimal places and balances
+are expressed as `Decimal` quantities. Non-fungible resources additionally
+contain individual non-fungible units distinguished by a local ID.
+
+## Specification
+
+### Semantics
+
+#### Asset Namespace
+
+This profile defines a single asset namespace, `resource` (case-sensitive),
+covering both fungible and non-fungible resources. Fungibility is a property
+of the resource manager, discoverable on-ledger; it is not encoded in the
+address string (the entity-type byte inside the address differs between
+fungible and non-fungible resource managers, e.g. `0x5d` vs `0x9a`).
+
+#### Asset Reference
+
+The asset reference is the native bech32m resource address, verbatim. Its
+structure mirrors account addresses (see the [CAIP-10 Profile][]): the HRP is
+`resource_` + the network specifier (`rdx`, `tdx_2_`), followed by the
+separator `1`, 48 data characters (1 entity-type byte + 29 address bytes) and
+a 6-character checksum. The HRP's network specifier MUST match the [CAIP-2][]
+segment of the identifier.
+
+### Syntax
+
+```
+asset_type:        chain_id + "/" + asset_namespace + ":" + asset_reference
+chain_id:          radix:[a-z0-9]{1,32} (see the [CAIP-2 Profile][])
+asset_namespace:   resource
+asset_reference:   resource_ + hrp_suffix + "1" + [02-9ac-hj-np-z]{54}
+hrp_suffix:        rdx | tdx_2_ | (other registered network specifiers)
+```
+
+Per-network validation regular expressions:
+
+```
+# Mainnet
+radix:mainnet/resource:resource_rdx1[02-9ac-hj-np-z]{54}
+
+# Stokenet
+radix:stokenet/resource:resource_tdx_2_1[02-9ac-hj-np-z]{54}
+```
+
+Addresses MUST be lowercase (see Canonicalization in the [CAIP-10
+Profile][]).
+
+### Resolution Mechanics
+
+Resource metadata (symbol, name, divisibility, fungibility, total supply) can
+be queried from the Gateway API:
+
+```
+POST /state/entity/details
+{ "addresses": ["resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd"] }
+```
+
+Well-known native resources (XRD, system badges) for each network are
+published in the official [Well-Known Addresses][] registry.
+
+## Rationale
+
+The resource address is the canonical asset identifier across all Radix APIs,
+wallets, and tooling, and is self-describing in the same way as account
+addresses (checksummed, network-bound, entity-typed). A single `resource`
+asset namespace reflects the ledger's own model, where fungible and
+non-fungible resources share one address space and their fungibility is an
+on-ledger property rather than a syntactic distinction.
+
+### Backwards Compatibility
+
+Olympia-era resource identifiers ("RRIs", e.g. `xrd_rr1...`) are a retired
+format and are not valid in this namespace.
+
+## Test Cases
+
+This is a list of manually composed examples using officially published
+well-known addresses:
+
+```
+# XRD (native token, fungible) on mainnet
+radix:mainnet/resource:resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd
+
+# XRD on Stokenet
+radix:stokenet/resource:resource_tdx_2_1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxtfd2jc
+
+# Ed25519 signature virtual badge (a non-fungible resource) on mainnet
+radix:mainnet/resource:resource_rdx1nfxxxxxxxxxxed25sgxxxxxxxxx002236757237xxxxxxxxxed25sg
+```
+
+## Additional Considerations
+
+### Individual non-fungible units
+
+Radix non-fungible local IDs come in four types whose native delimiters
+(`#123#`, `<name>`, `[hex]`, `{uuid}`) fall outside the CAIP-19 token-ID
+charset. Identification of individual non-fungible units (as opposed to the
+non-fungible resource as a collection) is therefore out of scope for this
+initial profile and may be specified in a future revision, e.g. by
+percent-encoding the native local-ID representation.
+
+### Underscores
+
+As with CAIP-10 identifiers in this namespace, asset references contain
+underscore (`_`) characters from the native HRP, which the formal CAIP-19
+reference charset predating this namespace does not include. The same
+handling applies: native form is canonical, `%5F` percent-encoding is
+acceptable for strict-conformance consumers (see the [CAIP-10 Profile][] for
+details and precedent).
+
+## References
+
+- [Radix Resources][] - the resource model for fungible and non-fungible assets.
+- [Well-Known Addresses][] - canonical registry of native resources per network.
+- [Gateway API][] - `/state/entity/details` endpoint documentation.
+- [Radix Dashboard][] - explorer showing resource metadata and holders.
+
+[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
+[CAIP-2 Profile]: ./caip2.md
+[CAIP-10 Profile]: ./caip10.md
+[CAIP-19]: https://chainagnostic.org/CAIPs/caip-19
+[Radix Resources]: https://docs.radixdlt.com/docs/resources
+[Well-Known Addresses]: https://docs.radixdlt.com/docs/well-known-addresses
+[Gateway API]: https://radix-babylon-gateway-api.redoc.ly/
+[Radix Dashboard]: https://dashboard.radixdlt.com/
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).