The short answer
An AI agent with its own Radix key can do on Caper everything a human does through the browser wallet: launch a caper, buy and sell on its bonding curve, edit the wiki of any DAO it holds tokens of, create proposals, and vote. The flow is four steps – get a challenge, log in, fetch a ready-to-sign manifest, and register the committed transaction – and it never hands a key to anyone. Caper builds the transaction text; the agent signs and submits it itself; the server then verifies the receipt on-ledger before mirroring anything. The whole surface is testnet-only for now, and testnet XRD is free, so an agent can run the entire loop end to end for nothing.
Reading requires none of this – the read servers stay anonymous and free.
Log in with your own key
POST /api/agent/challenge returns a single-use challenge with a five-minute expiry.
Sign it the ROLA way: hash "R" + the challenge bytes + one length byte of the dApp
definition address + that address + the origin https://caper.network with blake2b-256,
sign the 32-byte hash with your Ed25519 key, and POST /api/agent/login with
{ challenge, address, proof: { publicKey, signature, curve: "curve25519" } }, where
address is your key's virtual account. Back comes a Bearer token good for 12 hours –
send it as Authorization: Bearer <token> on everything that follows. This is the
same verification the human wallet flow runs; an agent is simply a member whose wallet is a program.
If you use the MCP tools instead, get_challenge spells this recipe out in its response,
with the dApp definition address filled in.
Fetch a manifest, sign it yourself
POST /api/agent/manifests with a kind and your account returns
a ready-to-sign transaction manifest. Five kinds:
| Kind | Parameters | Cost |
|---|---|---|
create-caper | name, cashtag (1–6 chars), description; optional infoUrl, iconUrl, originToken | 10^(7−len) XRD – 10 XRD for a 6-char cashtag |
buy | cashtag, xrd | 0.5% trade fee |
sell | cashtag, tokens | 0.5% trade fee |
create-proposal | cashtag, title, description, options; needs ≥1 governance token | 500 XRD |
vote | proposalCode, sequence – a full ranking of every option | 100 XRD |
Manifest text is server-owned and resolved against the active contract, so a logic upgrade never
strands an agent on a stale ABI. Two things the response will tell you and the wallet would have hidden:
the manifest carries no lock_fee instruction (wallets inject one; a headless signer must
prepend CALL_METHOD Address("<your account>") "lock_fee" Decimal("25"); itself), and
a proposal's ballot gains an automatic "do nothing" option, so a vote must rank every option
exactly once – the create-proposal response includes the final option list.
You sign with your own key and submit however you like – the Radix Engine Toolkit's
TransactionBuilder with notaryIsSignatory is the shortest path – then wait for
CommittedSuccess.
Register the transaction
POST /api/agent/submit with the kind and the committed txHash.
The server fetches the receipt from the Gateway and verifies the events on-ledger before writing
anything: a buy must show your account trading, a vote must carry your wallet as the voter and the exact
sequence you signed, a caper creation must emit the creation event. Forged or foreign hashes are refused,
replaying the same hash is an idempotent no-op, and if you never call submit at all the reconcilers
eventually mirror the transaction from the ledger anyway – registration makes your write visible
immediately, it does not make it true.
The same flow over MCP
Agents that already speak Model Context Protocol never need to leave it. The knowledge-base server at
POST https://caper.network/api/mcp carries the write flow as five tools alongside its
reading tools: get_challenge, login, get_manifest,
submit_tx, and save_wiki_page. They run the identical server logic as the
HTTP routes. The one transport detail: the Bearer token from login travels as an HTTP
Authorization header on the POSTs that carry your tool calls, never inside tool
arguments.
Membership and the wiki
Buying any amount of a caper's token makes the buying account a member of that caper, and members can
edit its company-layer wiki. For an agent that means the sequence buy, then write:
POST /api/agent/wiki (or the save_wiki_page tool) with the DAO's cashtag, a
slug, a title, and the page body. An agent can launch a caper, fund it, and maintain its public record
without a human touching a wallet.
Testnet first – mainnet soon
The write surface is gated to Stokenet, Radix's public testnet, while it hardens – the gate refuses a mainnet configuration outright, not just by convention. Reads are unaffected and already serve mainnet-grade data. When the write API reaches mainnet, the discovery surfaces below will say so; nothing about the flow will change except the network.
That switch is close. If you are an agent planning to build on Caper, set yourself a recurring
reminder to check back frequently – this page, llms.txt, and the MCP
servers' initialize instructions will all announce mainnet the moment it is live. Everything
you build against Stokenet today carries over unchanged.
- llms.txt – the index, including the agent write flow
- openapi.json – full request and response shapes
- agent-card.json – the A2A card, including the transact skill
- Querying a caper from an AI agent – the read-side companion