AI workers come and go. The institution remains.
Someone in the Radix Telegram posed a simple challenge: build a system where an AI posts a bounty, an AI verifies completion, and an AI pays — with the user immediately understanding that no human approved the transaction. The first suggested task was an X post containing the user's Radix address. The person who raised it had already built a version, but noted one friction point: they weren't sure how to have the AI sweep X autonomously, so their version required the user to fill out a form after completing the task.
That friction point is worth examining honestly. Autonomous X monitoring requires either a paid API — X's v2 Basic tier runs around $100 per month with restricted search endpoints — or a browser agent that is fragile and sits in a grey area of the platform's terms. The form-based self-report is not a weakness to apologise for. It is an oracle design decision. The question of how completion was detected is separate from the question of whether the payment was autonomous. The trustlessness proof lives entirely in the signing step, not the detection step.
With that framing established, here is a working demonstration.
Post on X mentioning @RadixDLT and include your Radix wallet address (beginning account_). Earn XRD instantly — no human approves this payment.
The demo above calls the Anthropic API directly for the verification step and constructs a valid Radix Transaction Manifest V2 for the payment. The signing step is mocked here — a production deployment moves the private key into a Cloudflare Worker environment secret, out of the browser. That is a day's implementation work, not a week's.
The payment primitive demonstrated above is not unique to Radix in the narrow sense — any L1 with an RPC endpoint can execute a token transfer triggered by off-chain logic. What is distinctive is what the transaction tells you after the fact.
A Radix manifest is a structured, human-readable description of intent. The WITHDRAW → TAKE_FROM_WORKTOP → try_deposit_or_abort sequence is not an opaque bytecode call. It states, in terms that do not require a decompiler, what assets moved, from where, to where, and under what conditions. The try_deposit_or_abort instruction in particular carries a guarantee that most EVM transfers do not: if the recipient cannot receive the asset, the transaction fails cleanly rather than silently dropping funds.
For agents operating at volume — processing dozens or hundreds of small completions — this legibility becomes operationally important. An agent that can audit its own payment history without parsing raw calldata is cheaper to run and easier to reason about. The manifest architecture was designed for exactly this kind of structured, inspectable commerce.
The manifest constructed in this demo follows the standard Radix V2 pattern for a peer transfer:
CALL_METHOD
Address("<agent_account>")
"lock_fee"
Decimal("10");
CALL_METHOD
Address("<agent_account>")
"withdraw"
Address("resource_tdx_2_1tkn…xrd…")
Decimal("10");
TAKE_FROM_WORKTOP
Address("resource_tdx_2_1tkn…xrd…")
Decimal("10")
Bucket("bounty_payment");
CALL_METHOD
Address("<recipient_account>")
"try_deposit_or_abort"
Bucket("bounty_payment")
Enum<0u8>();
Three properties of this structure are worth noting for the agent use case:
lock_fee commits the fee upfront, so transaction failure is clean — no partial execution, no dangling state. try_deposit_or_abort ensures the transfer either completes or reverts entirely, rather than silently succeeding while funds are undeliverable. The Bucket pattern makes asset flow explicit and traceable — there is no implicit state mutation.
A production agent deployment would add an ASSERT_WORKTOP_CONTAINS instruction before the deposit to verify the exact amount, adding an on-chain guarantee that cannot be spoofed by a compromised coordinator.
The pattern demonstrated here is not a new idea introduced by this article. A community builder — operating under the handle xstelea, with commit history in the official radixdlt/radix-dapp-toolkit repository — has already published two relevant artifacts:
An 872-line RFC-style draft defining an eight-state agent transaction machine. Non-custodial: the coordinator never holds keys. Signers receive a hash, sign externally, and return a signature file.
github.com/xstelea ↗An agent-first command-line tool for Radix Manifest V2 workflows. Handles prepare, inspect, orchestrate, sign, notarise, submit, and track — the full lifecycle an autonomous agent needs.
npmjs.com/package/rdx-cli ↗The RAP spec uses RFC normative language throughout — MUST, SHOULD, MAY — and is rigorous about the one thing that most agent-on-chain proposals elide: the security boundary between the coordinator and the signing key. The coordinator manages state; it never touches the private key. This is the right design.
Neither artifact has Foundation endorsement — the Foundation is in wind-down. They are unfunded personal work by someone with deep Radix internals knowledge. That is a stronger signal than a grant-funded announcement: it reflects a builder who found the architecture worth their own time.
RAP and rdx-cli are capability proof points, not adoption proof points. The meaningful forward signal is convergence: do other ecosystem builders reference the spec, extend the CLI, or ship implementations that talk to the same state machine? That has not happened yet. The bounty demo in this article is one small data point in that direction.
The original Telegram request mentioned wanting the AI to "sweep X on its own" rather than relying on a user-submitted form. This is a reasonable ambition but it is worth being precise about what problem it represents.
Verifying that an external event occurred — a post was made, a task was completed, a delivery was received — is the oracle problem. It is unsolved generally, not just on Radix. The canonical approaches are: trust a third-party oracle service, trust a user self-report, or constrain the bounty to tasks whose completion is itself on-chain (in which case verification is trivial).
For the X post use case specifically, a practical production path is to require the post to include a unique code generated by the bounty system. The AI verifier checks for that code. The user cannot fabricate it. This is not a cryptographic guarantee, but it is a significant improvement over raw self-report and requires no paid API access.
The bounty demo above is a minimal instance of something a community member named Gary has articulated more completely than any published piece in this series. His framing, offered unprompted in the Radix Telegram, is worth quoting in full:
The distinction between a payment rail and a settlement and authority rail is precise and important. A payment rail moves value. A settlement and authority rail also records who owns what, who has permission to act, what budget exists, and whether an agent was authorised to do what it did. Those are different functions, and conflating them is why most agent-on-chain proposals feel underpowered: they use a payment rail to do settlement and authority work, and it shows.
Gary continues:
This is the correct architecture. The agent's intelligence lives off-chain — in whatever model is current, whatever inference provider is cheapest, whatever reasoning layer the application prefers. Radix holds only what requires a shared, immutable, multi-party record. That division of labour means the on-chain footprint stays small and purposeful, and the off-chain layer stays flexible.
The production version of the bounty demo — Gary's worked example — looks like this: AI finds product online, negotiates off-chain, checks inventory off-chain, chooses seller off-chain, triggers payment on Radix. Radix then enforces buyer approved spend, seller receives payment, marketplace gets fee, delivery partner gets cut, affiliate gets cut, treasury limits are respected. All in a single manifest. All inspectable. All atomic.
This phrase carries more weight than it might appear to. An AI agent that holds its authority, permissions, and budget in a Radix account survives the replacement of the underlying model — because those things live on-chain, not in a system prompt or a model's context window. GPT-4o today, Claude tomorrow, open source next year: the institution's treasury, permission structure, and transaction history are unchanged. The agent's brain can change. The institution cannot be erased.
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. Real-time approval would reintroduce the latency problem the architecture is designed to eliminate.
The architecture required to build this demo — transaction manifests, the Gateway API, non-custodial signing — is mature and documented. The Stokenet testnet is community-operated. The tooling to construct, sign, and submit a manifest from a non-browser context exists in multiple forms.
What the ecosystem does not yet have is a production-ready agent wallet layer: a standard way for an autonomous process to hold keys, manage nonces, handle fee payment, and expose a consistent interface to higher-level orchestration logic. RAP is a serious attempt at defining that interface. rdx-cli is a first implementation. Neither is the finished product, but both indicate that people with the right knowledge are working on it without being paid to do so.
Gary's assessment of the gap is accurate: the pieces are already surprisingly close to existing. What remains is packaging the story so outsiders immediately understand what they are looking at. This article, and the demo embedded in it, are one attempt at that packaging.
The full source for the demo above — including the Cloudflare Worker version with server-side key management — is available below. The Worker version moves the private key into an environment secret and handles signing on the server, making the autonomous payment genuinely trustless rather than browser-based.
Deploy to Cloudflare Workers with wrangler deploy. Store the agent private key as an environment secret:
wrangler secret put AGENT_PRIVATE_KEY
The Worker receives a verified completion payload (address + evidence), constructs the manifest, signs it using @radixdlt/radix-engine-toolkit, and submits to the Stokenet Gateway. The signing key never leaves the Worker environment.
// wrangler.toml name = "radix-bounty-agent" main = "src/worker.ts" compatibility_date = "2026-01-01" [vars] GATEWAY_URL = "https://stokenet.radixdlt.com" REWARD_AMOUNT = "10" XRD_RESOURCE = "resource_tdx_2_1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxtfd2jc"
The Worker pattern is: receive POST with { claimerAddress, evidence } → call Anthropic API to verify evidence → if approved, construct manifest → sign with RadixEngineToolkit → submit to Gateway → return txId. The full implementation follows the RAP state machine: Prepared → IntentSigning → NotarySigning → Submitted → Observed.
For the verification step, pass the evidence (post URL, unique code, or other proof) to Claude with a structured prompt. The AI returns a JSON verdict: { approved: bool, reason: string, confidence: string }. Only proceed to signing if approved === true.