RADIX WikiRADIX Wiki

Introduction

AI agents are becoming first-class consumers of on-chain services: reading ledger state, building transactions, and – increasingly – paying for the data and APIs they use. Radix is being positioned as a settlement layer for this agentic economy, combining asset-oriented programming, ROLA authentication, and the throughput of Hyperscale. This page collects the developer-facing pieces: the x402 payment standard, agent wallets, and the Model Context Protocol (MCP) tooling that lets coding and consumer agents work with Radix.

What is x402?

x402 is an open standard that activates the long-dormant HTTP 402 Payment Required status code as a real payment mechanism. A client – a browser, an app, or an AI agent – requests a resource; the server replies with a price; the client authorizes a stablecoin (or token) payment; the resource is delivered. One HTTP round-trip, with no accounts, subscriptions, or API keys. It was introduced by Coinbase in 2025 and is now stewarded by the x402 Foundation alongside Cloudflare, Google, and Visa.

A key role in the protocol is the facilitator, which abstracts blockchain complexity – fee handling, transaction submission, and network selection – while remaining non-custodial: the agent controls what is paid, the facilitator handles how it settles. This separation is what makes x402 usable by clients with no blockchain knowledge.

Why Radix for Agentic Payments

Agentic commerce is fundamentally a high-volume micropayment problem: millions of small, machine-to-machine payments for content, compute, and API calls. That workload only settles on a ledger that can scale horizontally without sacrificing atomic composability – which is the explicit goal of Hyperscale (Xi’an), where shards reconfigure with usage so capacity follows demand.

Beyond raw throughput, Radix brings primitives that suit programmable agent payments: native asset-oriented resources, transaction manifests that make intent explicit, and subintents for partial, multi-party flows. Builders should note the trade-offs surfaced during Hyperscale testing – subintents currently cost roughly 2× a plain transfer and hit the 256-event limit at around 30 subintents per transaction (versus 127 plain transfers) – so high-frequency micropayments generally need to be bundled.

Building x402 on Radix

The x402 reference implementation is multi-chain and split into composable packages, with middleware for common server frameworks:

  • x402 (implementation) – the protocol repo, with a TypeScript SDK (@x402/core, plus framework adapters such as @x402/express, @x402/hono, @x402/next, and @x402/fetch) and chain implementations. Radix support is in active development.

  • x402 Protocol Spec – the wire format and payment flow.

  • Coinbase x402 Docs – the original reference documentation.

  • radix-web3.js – an Effect-native TypeScript toolkit useful for constructing and submitting the Radix transactions an x402 facilitator settles.

A minimal x402 server gates a route behind a payment requirement:

app.use(paymentMiddleware({
  "GET /weather": {
    accepts: [/* networks / schemes you support */],
    description: "Weather data",
  },
}));

AI Agent Tooling on Radix

A growing toolset lets AI agents read Radix, build transactions, and act on a user's behalf:

  • RadixScan Agent Layer – a keyless MCP server (mcp.ai.radixscan.io) that lets agents read the ledger and build, validate, and simulate manifests, then request a signature non-custodially (the server holds no keys; signing happens in the user's wallet). Transports: /mcp (HTTP) and /sse.

  • Awesome Radix MCP Servers – a curated index of MCP servers in the Radix ecosystem.

  • Radix Context for AI Agents – 19 curated context files (radix-context) that teach coding agents how to build on Radix.

  • Radix Skills – installable agent skills for Radix dApp, manifest, Scrypto, and Gateway work (skills.sh).

  • AI Agent Wallet – an open-source, natural-language wallet SDK for agents that can interact with Radix DEXs, lending (WEFT), and staking.

To connect an MCP-capable coding agent (e.g. Claude Code) to the RadixScan server, add it to your project's .mcp.json:

{
  "mcpServers": {
    "radixscan": {
      "type": "http",
      "url": "https://mcp.ai.radixscan.io/mcp"
    }
  }
}

Standardising Radix for x402 and CAIP

For an agent’s tooling to pay on Radix without special-casing it, Radix has to be nameable in the standards those tools already read. On the 30th of July, 2026, Avaunt opened a temperature check on Radix Talk proposing two submissions be made on the community’s behalf: registering Radix in the Chain Agnostic (CAIP) namespaces registry, and adding Radix as a supported network in x402.

The CAIP half covers three profiles: CAIP-2 blockchain identifiers (a canonical radix:mainnet rather than the differing strings cross-chain tools currently invent), CAIP-10 account addresses, and CAIP-19 asset identifiers for Radix resources. The x402 half would make any Radix token usable at x402-compatible services rather than only those a facilitator has been built for; the proposal argues Radix suits the workload because subintents and fee sponsorship let a third party fund and settle an agent’s payment inside one atomic transaction.

A draft specification already exists, covering both sponsored and non-sponsored settlement and following the verification rules used in the recent Starknet, XRPL and NEAR submissions. The vote itself is non-binding – it exists so XRD holders can signal support that the submissions can then cite. If it carries, the stated next steps are a spec review, a reference SDK implementation, and a public Stokenet facilitator to test against.

On the 1st of August, 2026, the proposal opened for voting as Temperature Check 6 on the Radix Accountability Council’s consultation platform, where XRD-weighted, non-custodial voting ran for five days. The submission drafts were published alongside it, ahead of the vote closing: the CAIP profiles – README.md, caip2.md, caip10.md and caip19.md – sit in the radix directory of a namespaces fork, and the x402 work, a fork of xStelea’s original realigned with upstream, carries the Radix exact scheme beside the generic one. The x402 side was planned as three pull requests – the spec addition, a reference implementation (TypeScript proposed, with the choice put to the developer channel), and an additional SDK implementation. Both submissions have since been filed upstream; the section below records what carried and what was actually sent.

The vote, and both submissions upstream

Temperature Check 6 closed on the 6th of August 2026 at 09:28 UTC, five days after it opened, and it carried without a vote against. The governance component holds 58 votes, all of them For. Recomputing the weight behind them from the voting accounts’ holdings gives 557,142,796 XRD – about 138% of the 402,876,916 quorum written into a Temperature Check. Liquid XRD is the smaller part of that: 99,802,255, with the other 457,340,541 held as stake units and converted back at each validator’s current exchange rate, and five of the 58 accounts hold no liquid XRD at all. No single account carries more than about an eighth of the total. (Balances were read on the 10th of August 2026 rather than at the snapshot the dApp weights against, so the figures are indicative; the margin is wide enough that the direction is not in doubt.)

The submissions then left the fork. The CAIP half went up as ChainAgnostic/namespaces#198, “Add Radix (radix) namespace: CAIP-2, CAIP-10, CAIP-19”, opened on the 6th of August at 09:10 UTC – eighteen minutes before the vote it cites closed. It adds four files and 512 lines: a README.md written to CAIP-104 covering the network model and Radix’s bech32m address encoding, then caip2.md registering the logical network names radix:mainnet and radix:stokenet (resolved through the network-configuration endpoints rather than a chain ID), caip10.md for account_… addresses, and caip19.md for fungible and non-fungible resource addresses.

The x402 half followed on the 10th of August at 15:38 UTC as x402-foundation/x402#3112, “feat(specs): add Radix exact scheme”: two files, 741 lines added, one removed – the scheme document specs/schemes/exact/scheme_exact_radix.md plus a Radix row in the Critical Validation Requirements table of the generic scheme_exact.md. Per the project’s spec-first process it carries the specification only; the SDK implementation is stated to follow once the spec is approved. Neither pull request had drawn a review by the 10th of August, and the submitter’s own note in the Radix developer channel is that the namespaces repository has a backlog of pull requests reaching back to April, so the CAIP half is unlikely to move quickly.

The scheme itself is where the Radix-specific design shows. It defines two settlement modes. In the sponsored mode, which the spec recommends, the paying client signs only a subintent and the facilitator wraps it in a root transaction and pays the network fee – so an agent can pay for a resource without ever holding XRD. In the non-sponsored mode the client signs a complete notarized transaction itself. Because a sponsored subintent is a bearer payload, the spec binds it with VERIFY_PARENT, which restricts which facilitator is able to consume it and closes the obvious front-running route. Verification on the facilitator side is written as a requirement rather than a suggestion: strict instruction-sequence validation, fee-payer isolation, expiry mapped from the protocol’s maxTimeoutSeconds onto the transaction’s timestamp bounds, replay protection, and a preview that must return CommitSuccess with the exact balance deltas before anything is submitted. Its network identifiers are the CAIP-2 radix names, which is what couples the two submissions: the payment scheme names networks the namespaces registry has not yet registered.

HydrateLast updated 6d agov2.3.07 revisionsVerified Aug 10, 2026