Adding Radix to the x402 payment standard and the CAIP namespaces registry

Developers
1

Temperature Check

TL;DR — I’m proposing that we, as a community, back an effort to (1) register Radix in the Chain Agnostic (CAIP) namespaces registry and (2) add Radix as a supported network in the x402 open payment standard. A non-binding Temperature Check vote will follow this thread so XRD holders can signal support which will be used to support both submissions to the relevant orgs.

What is x402?

x402 is an open, Apache-2.0 licensed payment standard built around the HTTP 402 Payment Required status code. It lets any API or web service charge for access directly over HTTP — no accounts, no sessions, no card details. A client requests a resource, the server replies with payment requirements, the client signs a payment, and the server verifies and settles it on-chain. It is designed for machine-to-machine payments and micropayments, which makes it one of the main emerging standards for AI agents paying for services autonomously.

x402 is governed by the x402 Foundation and is deliberately network-agnostic: EVM chains, Solana, Stellar, Aptos, TON, Algorand, NEAR, XRPL, Hedera and others are already specified or supported. Radix is not — yet.

Why this matters for Radix

  • Agentic payments are becoming a real market. If AI agents settle payments over x402, the networks listed in the standard are the networks that traffic flows to. Radix’s transaction model is genuinely well-suited to this: subintents let a user sign exactly the payment and nothing else, and fee sponsorship means the payer never needs XRD for gas.

  • Every fungible resource on Radix becomes usable. x402 facilitators support networks, not tokens — once Radix is in, any Radix stablecoin or token can be used for payments by any x402-compatible service.

  • Standards visibility. The CAIP registry (chainagnostic.org) is the reference used by wallets, dapps, and cross-chain tooling to identify chains, accounts, and assets unambiguously. Radix currently has no registered namespace there, which means every cross-chain tool that touches Radix invents its own identifiers.

What has been done already

A complete draft specification for the x402 exact payment scheme on Radix has been written against the current upstream x402 repo — you can read it here:

The spec covers two settlement modes:

  1. Sponsored (recommended): the client signs a payment subintent; the facilitator wraps it in a root transaction and pays fees — the payer needs zero XRD.

  2. Non-sponsored: the client signs a complete transaction including fees.

It defines the full verification and settlement rules a facilitator must enforce (exact-amount matching, replay protection, facilitator-safety checks, preview/simulation requirements), and follows the same conventions as the recently merged Starknet, XRPL, and NEAR specs. The fork is kept in sync with the upstream x402 repo, so what you’re reading reflects the current state of the standard.

The plan

Step 1 — CAIP namespaces registration. Submit a PR to ChainAgnostic/namespaces registering the radix namespace with three profiles:

  • CAIP-2 (Blockchain IDs): chain identifiers, e.g. radix:mainnet and radix:stokenet, with the mapping to Radix network IDs and address HRPs.

  • CAIP-10 (Account IDs): the bech32m account address format (account_rdx1...).

  • CAIP-19 (Asset IDs): resource addresses (resource_rdx1...) so tokens can be referenced unambiguously cross-chain.

This is a documentation PR reviewed by the CASA editors — no fee, no token listing, no protocol change. It benefits the whole ecosystem beyond x402 (wallets, bridges, WalletConnect-style tooling all key off CAIP identifiers).

Step 2 — x402 specification PR. Submit the Radix exact scheme spec (linked above) to the x402 Foundation repo. Their process for a new chain family is spec first, then a reference SDK implementation, then further SDK ports — each a separate PR with Foundation review.

Step 3 — Reference implementation and facilitator. After spec approval, implement the Radix mechanism in one of the x402 SDKs (TypeScript or Python) with the required unit/integration/e2e tests, and stand up a public facilitator on Stokenet so anyone can test end-to-end before mainnet use.

Why a Temperature Check?

None of the above technically requires a governance vote — anyone can submit these PRs. But I want to do this with visible community backing, for two reasons:

  1. Credibility upstream. Both the x402 Foundation and the CAIP editors look for evidence that a submission represents an ecosystem, not one individual. A supportive community signal materially strengthens both PRs.

  2. Shared identifiers are forever. The CAIP-2/10/19 profiles define how the outside world refers to Radix networks, accounts, and assets. That deserves community eyes before it’s locked in — for example, whether chain references should be named (radix:mainnet) or numeric (radix:1).

The Temperature Check is a non-binding signal vote for XRD holders. It asks one question:

*Should the community support registering Radix in the CAIP namespaces registry (CAIP-2, CAIP-10, CAIP-19) and submitting Radix for inclusion in the x402 payment standard?

In support of this Temperature check, the intention will be to register these two namespaces*
radix:mainnet
radix:stokenet

( the alternative is radix:1 and radix:2 but the former options are more descriptive)

A positive result does not commit anyone to anything or spend any funds — it gauges sentiment before this potentially proceeds to a full governance vote (for instance, if the community later wants ecosystem funding for the facilitator or SDK maintenance). A negative or mixed result tells us to rework the approach here first.

What I’m asking from you

  • Read the draft spec and critique the approach — especially the CAIP-2 reference format question (named vs. numeric chain references) and anything in the payment flow you think is unsafe or un-Radix-like.

  • If you build wallets, tooling, or dapps on Radix: does the CAIP profile shape work for you? Your feedback belongs in the registration PR’s discussion thread.

  • Vote in the Temperature Check when it opens, whichever way you lean.

References

2

I would add a diagram to Protocol Flow

3

Great idea!!
Thanks for stepping up and taking care of that!

4

Temp Check Vote is live now!

5

There is a diagram showing the typical flow here. Is that what you are looking for?

image
image4224×2720 398 KB