Field Notes on Radix

Settle Authority on Radix

The AI can live anywhere. The institution it belongs to can live on Radix.

June 2026 With commentary from Gary, Radix Telegram

Most arguments for putting AI agents on a blockchain fail at the first honest question: why this chain specifically? The agent doesn't care about decentralisation as an ideology. It cares about whether the operation it needs to perform is possible, cheap, and legible. That question has a cleaner answer on Radix than most of its advocates have articulated — and a community member named Gary has articulated it more precisely than any published piece in this series.

His framing, offered in the Radix Telegram in June 2026, is the organising argument for everything that follows.


The positioning ladder

Every major L1 has a function that it performs better than the others because its architecture was shaped around that function from the start. Gary's formulation:

Bitcoin
Store of value. Money that cannot be debased or seized.
Solana
Payment rail. High throughput, low cost, fast finality for value transfer.
NEAR
AI application layer. Developer-friendly, account abstraction, chain signatures.
Radix
Settlement and authority rail. Who owns what, who has permission, what was authorised, whether settlement happened.
"The positioning I would push relentlessly: Bitcoin = money. Solana = payment rail. NEAR = AI application layer. Radix = settlement and authority rail." — Gary, Radix Telegram, June 2026

The distinction between a payment rail and a settlement and authority rail is not subtle. A payment rail moves value from A to B. A settlement and authority rail also records who owns what, who has permission to act, what budget was pre-authorised, how revenue is split, and whether the agent doing the work was permitted to do it. Those are different functions. Conflating them is why most agent-on-chain proposals feel underpowered: they use a payment rail to do settlement and authority work, and the mismatch shows.


Why human trust infrastructure fails at agent scale

Gary extended the argument in a subsequent message that reframes the entire question of why decentralisation matters for AI — and arrives at a different answer than most blockchain advocates give:

Gary, Radix Telegram, June 2026

"Humans tolerate trusted intermediaries because we have contracts, courts, banks, and customer support. If my bank makes a mistake, I can call someone. If Stripe freezes my account, there is a legal process."

"Autonomous AI agents don't have that luxury. They may be transacting with thousands of unknown agents globally, 24/7, without lawyers or human oversight. Continuously negotiating trust relationships with every counterparty is expensive and inefficient."

"A neutral settlement layer solves that. The AI can operate on private rails for 99% of its work, then use a trustless system like Radix for the moments where ownership, permissions, revenue sharing, escrows, budgets, and payments must be objectively enforced."

This is the structural argument that most blockchain-for-AI pieces miss. The case for a neutral settlement layer is not ideological — it is operational. Human trust infrastructure works at human scale because it has recourse mechanisms: legal process, dispute resolution, customer support. Those mechanisms operate at human speed and human cost. An AI agent processing thousands of transactions per day with unknown counterparties globally cannot use Stripe's dispute resolution process. The economics don't work. The latency doesn't work.

The implication Gary draws is significant: decentralisation is not primarily for humans. It becomes infrastructure for machines. And crucially, an AI agent evaluating infrastructure choices has no emotional attachment to existing providers. It can compare the cost of trusting a private company against the cost of using a neutral protocol with deterministic rules — and simply pick the cheaper, more reliable option. The rational-actor argument is fully true once agents are making infrastructure choices autonomously. That is Phase 3 and Phase 4 territory in the adoption curve below — but it is the destination the architecture is designed for.

"So I don't think decentralisation is primarily for humans. I think it becomes infrastructure for machines." — Gary, Radix Telegram, June 2026

What stays off-chain

The other half of Gary's argument is equally important — and it is the half that most blockchain advocates get wrong by omission. He is explicit about what does not need to move on-chain:

Gary's architecture, verbatim

"The AI can operate across the whole internet, but settle authority on Radix. They do not need to move their whole app onto Radix. They can keep: AI reasoning off-chain. Web app off-chain. Database off-chain. Search/offers/ranking off-chain. Messaging off-chain. Product catalog off-chain. Delivery/logistics off-chain."

"And use Radix only for the parts where shared trust matters: who owns what, who has permission, what budget exists, what payment was made, how revenue is split, whether an agent is allowed to act, whether settlement happened."

This is the correct architecture for a different reason than it might first appear. The argument is not just pragmatic — "don't put things on-chain that don't need to be." It is structural. The things Gary lists as staying off-chain are things where a single party's database is sufficient: the AI model's own reasoning, the application's product catalog, the logistics provider's delivery status. No shared trust is required. The things he puts on-chain are things where multiple parties need to agree on a record that none of them controls: ownership, permission, payment, authorisation. That is precisely the problem a shared ledger solves. Everything else is overhead.


The institution layer

Gary's worked example of the production architecture makes the settlement and authority rail concrete:

AI finds product
negotiates
checks inventory
chooses seller
triggers payment on Radix
off-chain throughout → single on-chain settlement event

The single on-chain settlement event then enforces the full multi-party split in one atomic transaction:

Treasury
Holds assets. Agent cannot exceed approved budget.
Permissions
Defines what each agent role can do. Enforced on-chain before execution.
Budgets
Daily, per-transaction, and total limits. Cannot be overridden.
Revenue sharing
Seller, marketplace, delivery, affiliate — all in one manifest.
Memberships
Roles and access managed via badges. No centralised admin.
Governance rules
Guardrails the institution sets. Radix enforces them.

The multi-party revenue split — buyer spend, seller receipt, marketplace fee, delivery cut, affiliate cut, treasury limits respected — is not a special case requiring custom contract logic. It is the standard Radix manifest worktop pattern: each recipient gets a named bucket, each bucket has an exact amount, the transaction either completes all of them atomically or fails entirely. You cannot accidentally pay the wrong party or wrong amount without the manifest rejecting the transaction.

"The AI can live anywhere. But the institution it belongs to — the treasury, the rules, the permissions, and the shared ownership — can live on Radix." — Gary, Radix Telegram, June 2026

Surviving model replacement

"The first project that demonstrates a real AI institution operating on-chain — creating work, verifying work, paying for work, managing permissions, and surviving model replacement — has a chance to make that positioning stick." — Gary, Radix Telegram, June 2026

The phrase names the property that distinguishes an AI institution from an AI application.

An AI application is a model plus a system prompt plus a database. Replace the model, and the application changes — potentially breaks. Its "identity" is inseparable from the inference layer powering it.

An AI institution holds its authority, permissions, budget, and transaction history on-chain. Replace the model, and the institution is unchanged. GPT-4o today, Claude tomorrow, open-source next year: the treasury balance, the permission structure, the complete payment record — none of it moves. The agent's brain can change. The institution cannot be erased.

This is not an abstract property. It has practical implications for any organisation building with AI agents over a horizon longer than one model generation, which is now measured in months. An institution whose permissions and budget live in a Radix account is robust to the churn in the underlying AI layer in a way that no off-chain architecture can match.

One precision worth adding

"Buyer approved spend" in Gary's framework is a pre-authorised spending envelope the buyer signs before the agent acts — not a real-time confirmation at execution. The agent operates within it. Radix's subintent architecture supports exactly this pattern: a buyer signs a spending subintent once, and the agent can execute within its limits without returning for approval on each transaction.

Real-time approval would reintroduce the latency problem the architecture is designed to eliminate. The pre-authorisation pattern is both faster and more trustless: the buyer's intent is cryptographically committed, not verbally agreed.


Four phases of adoption

Gary also articulated the natural adoption progression — the path by which an organisation that starts with a single Radix transaction ends up operating primarily on-chain. This is a more useful framing than "why Radix" because it describes a journey rather than demanding a destination:

1
AI → Radix → withdraw immediately
The agent uses Radix for a single settlement event, then moves value off-chain. Minimum commitment. Proves the primitive works. The bounty demo in this series is a Phase 1 instance.
live today
2
AI → Radix → keep working capital on Radix
The agent stops immediately withdrawing. It holds a working balance on-chain and transacts from it. Budget limits become enforceable. Multi-agent oversight becomes possible. The institution begins to form.
3
AI → Radix → keep treasury on Radix
The organisation's primary financial layer is on-chain. Revenue sharing, governance, and permission structures are enforced by the ledger rather than by internal policy. Model replacement becomes survivable.
4
Entire AI-native organisations operate primarily on Radix
The institution is the on-chain structure. AI workers are swappable, upgradeable, replaceable. The institution persists. This phase has not been demonstrated yet on any L1 — but the architecture that makes it possible exists on Radix today.

Each phase follows naturally from the previous one once you have taken the first step. An organisation that has settled one payment on Radix has already solved the hardest integration problem. Keeping working capital there is a treasury decision, not a technical one. Moving the full treasury is a governance decision. Phase 4 is Phase 3 at scale.

The gap between Phase 1 and Phase 4 is not primarily technical. The Radix architecture that makes Phase 4 possible — account-based permissions, badge ownership, vault structure, manifest atomicity, subintent pre-authorisation — exists today. The gap is in demonstrated use and the ecosystem density that attracts organisations to take the first step.


Where the ecosystem is now

Honest assessment of current state against the four phases:

The honest gap

Gary identified it precisely: "The remaining gap is mostly packaging the story so outsiders immediately understand what they are looking at." The architecture is the right shape. The primitives are real. What the ecosystem needs is a demonstration that moves from Phase 1 to Phase 2 publicly, with enough legibility that outsiders can follow the logic without being Radix-native.

That demonstration does not require a new protocol. It requires someone to leave working capital on Radix, operate an agent against it, and document what happened.

References
  1. Gary, Commentary on Radix agent architecture and adoption phases, Radix Telegram, June 2026. Quoted with permission.
  2. Field Notes on Radix, The Agent Paid, radix-autonomous-bounty.michaeltzu.workers.dev, June 2026
  3. xstelea, Radix Agent Protocol (RAP) V1, github.com/xstelea/radix-web3.js, 2026
  4. Radix DLT, Transaction Manifest V2 specification, docs.radixdlt.com