Rialo · Agent Payments + Task Marketplace · Testnet

Payments
for Autonomous
Agents.

Give autonomous software a wallet, define how it can pay, and let Rialo settle the transaction on-chain. Post work in the task marketplace, review the evidence, then pay — or reject without moving a single token.

Launch App → Explore Marketplace → Read Docs →
Checking AgentPay service Checking Rialo RPC

01 · The Premise

AI can act.
Now it can pay.

Agents already browse, negotiate, buy compute and call APIs. What they could not do was settle — hold a real wallet and move real value under rules their operator controls. AgentPay closes that gap: an identity-bound wallet, programmable payment policy, and on-chain settlement on Rialo.

01Wallet

Agent Wallet

Each agent gets a Rialo payment identity, with transaction signing isolated behind a hardened signer boundary.

Identity-bound Live
02Policy

Programmable
Payments

Payments are defined as rules: who may be paid, how much, under what condition. The policy, not a human, sits between the agent and the chain.

Direct transfer Live
03Chain

On-chain
Settlement

Approved payments settle through the Rialo network — final, signed transactions, not ledger entries inside a closed system.

Rialo Testnet Live
04Proof

Verifiable
Activity

Every settlement returns a real transaction signature. Activity is provable against the chain — auditable by anyone, trustable by machines.

Signatures Live

02 · How It Works

Five steps
from agent to settlement.

The operator configures once. After that, the agent acts and Rialo settles — without a human in the transaction path.

01

Create

Connect MetaMask, OKX Wallet, or Rabby to authenticate the owner and open an AgentPay session.

EVM wallet → Session
02

Fund

Create the agent and fund its wallet. Agent wallets are operator-funded — no faucet for them.

Wallet · Fund
03

Define

Set the payment policy: recipients, amounts, conditions the agent must satisfy.

Policy rules
04

Execute

The agent triggers a payment when its condition is met — autonomously, via API.

POST /api/agents/triggers/payments
05

Settle

Rialo finalizes the transaction on-chain and returns the signature as proof.

Signature · Receipt

03 · Task Marketplace

Work gets done.
Payment follows proof.

The marketplace closes the loop between a human who needs work and a worker who can do it. The owner posts a reward, the worker claims and submits evidence, and the owner releases payment on-chain only after reviewing it. Reject the work and no payment is made.

01Owner

Post a task

Set the brief, the acceptance criteria, the reward in RLO, and the agent that will pay on approval.

reward reserved
02Worker

Claim the work

A different account claims the open task and chooses the Rialo payout address the owner will see before approving.

one worker at a time
03Evidence

Submit proof

Add notes and attach deliverables — text, PDF, images, archives, or any other browser-readable file type. Only the two parties can read them.

text + any file
04Owner

Approve or reject

Approve to release the reward on-chain and return the transaction signature. Reject to close the task with no transfer and no payout.

payment follows approval
See open tasks → Verify a payment →

04 · Architecture

Identity in.
Signature out.

Everything on this page is pinned to the system as it ships today: the real flow from EVM wallet identity to user-held Rialo signing, the core route groups behind each page, and every page it actually serves. No placeholders, no simulated data.

EVM Wallet Identity
Server-issued nonce + domain-bound signature. The EVM address is verified before a session is issued.
/auth/wallet/nonce
AgentPay Session
Session-scoped user + wallet state. The browser never holds key material.
GET /api/me
Your Rialo Wallet
User-held Ed25519 wallet. The recovery phrase stays in the browser and is never sent to the server; the legacy signer wallet is separate.
self-custody · per user
Your Agents
Separate entities owned by your account. Each receives an isolated signing identity; private keys stay behind a hardened signer boundary. Metadata mirrors only the public address. Lifecycle, policy, and payment gates are enforced server-side.
isolated signer identity
Payment Policy
Versioned limits (per-transaction, daily) plus recipient and action allow-lists. Every unset limit and empty list denies — policy is read-only data checked before any transfer.
deny-by-contract
Rialo
The settlement layer: balances, direct transfers, and the deployed Venus payment program — the program path stays disabled behind an explicit operator cap. One RPC configuration; one CLI signing path. Agent payments may optionally pass through an opt-in, env-configured Latch transport/policy gate in front of that same CLI-signed path — it never replaces the signing path, never holds key material, and stays fully inactive unless explicitly enabled.
testnet RPC · Venus
Recipient
Any Rialo address: another agent, a service, or a human wallet. Every settlement returns a real transaction signature.
32–44 char address
Core route map — the groups behind every page
GET /auth/wallet/nonce
Issue a domain-bound EVM wallet challenge.
GET /auth/wallet/verify
Verify the EVM signature server-side and issue the session.
POST /auth/logout
Clear session + cookie.
POST /auth/wallet-recover
Explicit recovery for a missing-key wallet with zero balance; never a silent replacement.
GET /api/me
Session, wallet address, balance with explicit status.
POST /api/faucet
Request a 1 RLO Testnet airdrop to the session wallet.
POST /api/payment
Legacy signer route — not used by the new direct-wallet UI; inactive until a verified rail exists.
GET /api/program/status
Venus program readiness snapshot; submits no transaction.
POST /api/payment/program/*
Program-mediated payments — disabled until an operator sets an explicit cap.
GET /api/health
AgentPay + Rialo RPC probe.
GET·POST /api/agents
List own agents / create a draft agent with its own isolated signing identity.
GET·PATCH·DELETE /api/agents/{id}
Read one own agent, rename, or delete a draft. Missing and foreign both answer not-found.
GET /api/agents/{id}/balance
Real chain balance — ok / unavailable / no_wallet, never a fake zero.
PATCH /api/agents/{id}/status
Lifecycle transitions under a strict server-side state machine.
GET·PATCH /api/agents/{id}/policy
Versioned payment policy: limits + recipient/action allow-lists.
POST /api/agents/{id}/payments
Explicit payment from the agent's isolated signing identity, full gate chain.
POST /api/tasks
Create a task with its reward, acceptance criteria, and paying agent. GET /api/tasks/open is the public board.
GET /api/tasks/{id}
Task detail for the owner or the assigned worker; anonymous access is not found.
POST /api/tasks/{id}/claim · /submit · /review · /cancel
Role-gated lifecycle: claim with a payout address, submit notes + any file type, approve/reject as owner, cancel when allowed.
POST /api/tasks/{id}/payout/reconcile
Read-only recovery of a committed payout verdict; never transfers twice.
POST /api/agents/triggers/payments
Credential lane: X-Agent-Credential authenticates the agent principal.
POST /api/agents/{id}/payments/reconcile
Read-only reconciliation of unknown outcomes (owner lane).
POST /api/agents/triggers/payments/reconcile
Credential-lane reconciliation — deterministic evidence only.
GET /api/agents/leaderboard
Confirmed-volume ranking; ordering owned by the server.
GET /api/agents/stats
Owner statistics — single read, zero query parameters.
GET /api/agents/{id}/stats
Single-agent statistics — owner-scoped single read.
GET /api/agents/{id}/activity
Per-agent replay ledger, paginated, server-ordered.
GET /api/agents/triggers/payments/activity
Credential lane: read its own agent's ledger.
GET /api/public/agents/{id}/proofs
Per-agent public proofs — no session, no credentials.
GET /api/public/verify
Public signature verification against the chain — sessionless.
GET /api/agents/triggers/payments/stats
Credential-lane statistics — owner- and parameter-free.
GET /api/schema
Public schema view — credential storage format definition.
GET /auth/dev-login
Local development only; mounted when DEV_LOGIN_USER_ID is set.

Pages this system ships — each one real and reachable

01

Wallet

Your balance from the live RPC, your wallet address, the Testnet faucet, and the direct payment form — the signature returns right here on the page.

/wallet.html Live
02

Dashboard

Live account, network, and program state in one place — block height, RPC probe, and the Venus program readiness snapshot with its safety-cap state.

/dashboard.html Live
03

Agents

The owner-scoped registry: create agents, move their lifecycle, read their real chain balances, and edit their payment policy — all against the API above.

/agents.html Live
04

Activity

The per-agent replay ledger — every payment intent with its state, in the server's deterministic order, with state, principal, recipient, amount, and time filters.

/activity.html Live
05

Leaderboard

Your agents ranked by confirmed payment volume — the order is owned by the server and never re-ranked client-side. Empty until real confirmed payments exist.

/leaderboard.html Live
06

Verify

Public, sessionless proof: paste any Testnet transaction signature and the chain answers with its on-chain record, no_status, or a typed error. Nothing inferred.

/verify.html Live
07

Marketplace

The two-sided task board: post a rewarded task, claim it as a different account, submit notes and file evidence, then approve and pay on-chain — or reject with no payment.

/marketplace Live

Honest state  Every page above is shipped in this frontend, and the route groups above are registered in the server today. Task, agent, policy, and activity records are read from the production Postgres store; wallet keys remain server-side and are never sent to the browser.

05 · Live Network

Real state —
or nothing at all.

Every value below is fetched from the AgentPay backend and its Rialo RPC probe. When a source is unreachable, the field shows — NOT AVAILABLE instead of a plausible number. This is the product rule, not a loading state.

AgentPay Service Checking GET /api/health · agentpay
Rialo RPC · Block Height — GET /api/health · awaiting probe
Venus Payment Program Checking GET /api/program/status · awaiting probe
Last checked — Auto-refresh 30s · no simulated updates

06 · Leaderboard

Your agents
by verified activity.

No Verified Agent Activity Yet

This public page shows no rankings by design: the live leaderboard is owner-scoped — after EVM wallet sign-in each account sees only its own agents, ranked server-side by confirmed payment volume. There is no global public board, so this section stays empty rather than showing invented rankings.

Owner-scoped Live at /leaderboard.html after login

07 · Recent Activity

Settlements,
as they land.

Time Signature From To Amount (RLO) Status
NO VERIFIED ACTIVITY YET
This public section would be a global settlement feed — one that does not exist. The live ledger is per-agent and owner-scoped (/activity.html after login). No sample hashes, no simulated rows — payments you make return their signature directly as proof.

Global feed: not implemented · per-agent ledger live at /activity.html (owner-scoped)

08 · Why Rialo

A settlement layer
machines can use.

Not a claim of superiority — a description of the properties AgentPay actually relies on today.

01

—Fast Settlement

Transfers confirm in seconds on the Rialo network AgentPay runs against, keeping agent workflows synchronous: request → settle → continue.

02

—Programmable

Rialo hosts Venus on-chain programs. AgentPay already ships a deployed Venus escrow program and its readiness probe — that specific PDA-escrow path is gated behind an explicit operator cap. Agent policy lanes remain separate; the direct-wallet rail is disabled until verified.

03

—On-chain

Value moves through real signed transactions against persistent keypairs — not internal ledger rows that only the platform can see.

04

—Verifiable

Every payment returns its transaction signature, and network state is exposed through read-only probes — this page itself consumes them.

09 · Use Cases

What agents
will pay for.

Product directions AgentPay is designed for. These are intended use cases, not claims of current adoption volume.

U-01

AI Research Agents

An agent that pays per result — unlocking datasets, unlocking a scraped document, or settling a micro-fee for a research API — and only continues when the source actually responds.

Pay-per-result
U-02

Autonomous Services

Software that runs a business loop unattended: it uses its funded payment identity to pay for what it consumes, bounded by the policy its operator defined.

Self-sustaining
U-03

Agent-to-Agent Payments

Machine-to-machine coordination: a paying agent settles with any Rialo recipient per completed task. The recipient can verify the settlement on-chain via the transaction signature.

Machine ↔ machine
U-04

Automated Treasury

Funds that follow rules instead of approvals: distribution schedules, spending caps, and recipient allowlists enforced at the policy layer before any transaction is submitted.

Rule-bound
U-05

API · Compute Payments

Metered machine services — GPU time, inference, data streams — paid per call with on-chain proof of what was spent, replacing subscription keys and monthly invoices.

Metered access

10 · FAQ

What is real,
what is next.

AgentPay is a payment layer for autonomous software, with a two-sided task marketplace on top. A human identity (verified by MetaMask, OKX Wallet, or Rabby) gets a persistent Rialo wallet; agents created under that account each receive an isolated signing identity, and can initiate payments through AgentPay's API that settle on-chain. In the marketplace, an owner posts a rewarded task, a worker submits evidence, and the owner approves the payout — or rejects it with no transfer. Today it runs on Rialo Testnet.
On first login, AgentPay provisions one Rialo keypair bound to your EVM identity and stores it server-side with restricted file permissions. Your wallet address is visible at all times; your balance is read live from the Rialo RPC. If the RPC is down, the wallet shows an explicit "unavailable" state — it never invents a zero.
The new direct-wallet UI is disabled on Rialo Testnet because no verified EVM transaction rail exists. It never calls the legacy /api/payment route or the Rust signer. Agent payment lanes and the Venus program path remain separate, gated features; they are not exercised by the new direct-wallet UI.
Rialo is the blockchain AgentPay settles on. It exposes a standard node RPC (block height, balances, transfers) and executes PolkaVM programs written in the Venus workflow language — the layer AgentPay's program-mediated payments target.
Agents can initiate real payments today through the documented API endpoints — owner-initiated via the session, or credential-authenticated via the trigger lane. Policy enforcement is live on every payment: lifecycle gate, recipient and action allow-lists, per-transaction and daily limits — all deny-by-default, checked before any transfer. Each agent has a distinct isolated signing identity, funded by its owner; there is no automatic funding path — a 0-balance agent stays INSUFFICIENT_FUNDS until funded.
EVM wallet identity and sessions, your user-held Rialo wallet, the Testnet faucet (your wallet), direct on-chain payments with returned signatures, agent payments with the full policy gate chain (owner- or credential-initiated), each agent's isolated signing identity, reconciliation, per-agent activity and owner statistics, the owner-scoped leaderboard, public verification with per-agent proof listings, read-only health/program probes, and the live task marketplace — claim, submission with notes and any file type, owner review, approve-and-pay, reject-without-payment, and in-page outcome notifications for the worker. The Live Network section on this page reports those states from real endpoints.
Program-mediated payments (built, deployed, and verified — but disabled behind the explicit operator safety cap); credential issuance remains an operator act through the store module (authentication, rotation, and revocation are enabled over the thresholded ops endpoint). Notifications are in-page only — there is no email, push, or after-page-close delivery, and no global public transaction feed. A missing wallet key is recovered only through the explicit zero-balance recovery path; a funded wallet is never silently replaced. The Leaderboard and Recent Activity sections on this page keep their honest empty states: the owner-scoped leaderboard and per-agent activity are live at /leaderboard.html and /activity.html, but a shared public feed does not exist — no placeholder agents, no sample transactions.

11 · Start

Give your agents
an economic layer.

Connect an EVM wallet, create or restore your user-held Rialo wallet, and review every native payment before anything is signed.

Open Wallet → Architecture →