diff --git a/radix/README.md b/radix/README.md new file mode 100644 index 00000000..9baecae3 --- /dev/null +++ b/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:
` 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/). diff --git a/radix/caip10.md b/radix/caip10.md new file mode 100644 index 00000000..a54a2638 --- /dev/null +++ b/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/). diff --git a/radix/caip19.md b/radix/caip19.md new file mode 100644 index 00000000..59e2c080 --- /dev/null +++ b/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#`, ``, `[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/). diff --git a/radix/caip2.md b/radix/caip2.md new file mode 100644 index 00000000..f1085509 --- /dev/null +++ b/radix/caip2.md @@ -0,0 +1,119 @@ +--- +namespace-identifier: radix-caip2 +title: Radix DLT Namespace - Chains +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-2 + +*For context, see the [CAIP-2][] specification.* + +## Rationale + +Radix Babylon networks are few and centrally registered: one production +mainnet and a small set of persistent test networks. Each network is defined +in the node software by three coupled identifiers: a numeric **network ID** +(`1` for mainnet, `2` for Stokenet), a **logical name** (`mainnet`, +`stokenet`), and an **HRP network specifier** used inside every address on +that network (`rdx`, `tdx_2_`). + +This profile uses the **logical name** as the CAIP-2 reference. The logical +name is the identifier integrators already pass in the `network` field of +every Core API request, it is human-readable, and the set of networks is +small and governed, so collisions are not a practical concern (the same +reasoning used by the `hedera` and `stellar` namespaces). + +## Syntax + +The reference SHOULD be populated with one of the following enumerated +logical network names: + +- `mainnet` — Radix mainnet (network ID `1`) +- `stokenet` — the primary public testnet (network ID `2`) + +Other logical names defined by the node software (e.g. transient test +networks with HRP specifier `tdx__`, or `simulator` for the local +`resim` simulator, network ID `242`) follow the same pattern. + +A regular expression for validating any theoretically possible Radix +network reference is: + +``` +radix:[a-z0-9]{1,32} +``` + +### Resolution Method + +To resolve the network of a node or gateway, query its network configuration +endpoint and compare the returned logical name and network ID: + +- Gateway API: `POST /status/network-configuration` +- Core API (own node): `POST /core/status/network-configuration` + +Example response (mainnet gateway, abbreviated): + +```json +{ + "network_id": 1, + "network_name": "mainnet", + "well_known_addresses": { + "xrd": "resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd" + } +} +``` + +Addresses themselves are also network-bound: every bech32m address embeds the +network's HRP specifier (`rdx`, `tdx_2_`), and its 6-character checksum is +computed over the HRP, so an address valid on one network is invalid on every +other network. + +## Backwards Compatibility + +The retired Olympia network generation (2021–2023) used different address +formats and APIs; its end state was migrated into Babylon's genesis. Olympia +is not addressable in this namespace. + +## Test Cases + +This is a list of manually composed examples: + +``` +# Radix mainnet +radix:mainnet + +# Radix Stokenet (primary public testnet) +radix:stokenet +``` + +## Additional Considerations + +### Rejected idea: numeric network-ID references + +Using the numeric network ID as the reference (`radix:1`, `radix:2`) was +considered and rejected: the logical name is what Radix APIs accept in +request bodies, what node configuration files use, and what integrators see +in documentation, whereas the numeric ID appears mainly inside transaction +headers. Both identifiers are listed in the table in the +[namespace README](README.md) so either can be derived from the other. + +## References + +- [Radix Networks][] - network IDs, logical names, gateway URLs and native addresses per network. +- [Well-Known Addresses][] - canonical per-network address registry including `network_id` and `network_hrp_suffix`. +- [Gateway API][] - `/status/network-configuration` endpoint documentation. +- [Core API][] - node-local equivalent for integrators running their own node. + +[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2 +[Radix Networks]: https://docs.radixdlt.com/docs/network-setup +[Well-Known Addresses]: https://docs.radixdlt.com/docs/well-known-addresses +[Gateway API]: https://radix-babylon-gateway-api.redoc.ly/ +[Core API]: https://radix-babylon-core-api.redoc.ly/ + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).