Conditional releaseBuilt on Rialo

Agents get paid when the work checks out.

Warrant holds an agent’s payment until the deliverable behind it is verified against your policy, confidentially, inside REX. Clean pass releases automatically. Anything else goes to a human.

Open a warrant Try a verifier — no account Read the spec

npx gowarrant init

The three states

A warrant is only ever in one of three places.

Held
Payment signed, funds parked, waiting on the verifier.
Released
Deliverable matched the spec inside REX, funds cleared.
Escalated
Check failed or landed in the grey band, a human decides.

WARRANT #4471

Held

Amount: $8.40
Deadline: 04:57
Payee: api.exampledata.io

Spec

200 + schema:invoice.v2 + freshness<60s

Evidence

waiting on the verifier

no decision yet

How it works

Four steps, in order.

01
Open a warrant.
Your agent signs an intent: amount ceiling, payee, deliverable spec, verifier, deadline.
02
Funds are held.
Nothing leaves the balance. The warrant and its policy are recorded before anything executes.
03
REX verifies.
The deliverable is pulled live over native HTTPS and checked against the spec confidentially. The agent's own report is never the evidence.
04
Release or escalate.
Clean pass releases in one hop. Anything borderline goes to a human with the evidence attached. Nothing expires into limbo, unverified warrants refund themselves.

Built for the agent economy

Three things a spending cap cannot do.

Spend control is not enough

held

A cap says how much. A warrant says whether.

Limits stop an agent overspending. They do not stop it paying for a 500, an empty payload or a fabricated result.

Proof, not self-report

released

The agent does not grade its own homework.

The verifier fetches the deliverable itself and checks it inside confidential compute.

A human only when it matters

escalated

Escalation is a feature, not a failure.

Borderline checks reach a person with the evidence already assembled, on a phone, approved with a passkey.

x402, paid on delivery

The same protocol, a different moment of settlement.

x402 as it ships compared with x402 through Warrant
Aspect	x402 as it ships	x402 through Warrant
When money moves	On request, before the response	After the response is checked
What you pay for	The attempt	The deliverable
Bad response	You paid	Held, then refunded or escalated
Integration	Your client walks the 402	Warrant walks it for you, on your spec

Hand the request to Warrant instead of making it yourself. Post the URL and the spec you would hold the response to; Warrant walks the 402, holds the payment in a warrant, and releases only once the response passes.

One authenticated endpoint, POST /v1/x402/pay, called with your API key. Your existing x402 client keeps working unchanged — this replaces the request you were going to make, rather than sitting behind it.

Verifiers

The check is the product.

http.statusresponsestatus == 200
json.schemabodymatches invoice.v2
json.jsonpath$.total> 0
file.sha256artifactdigest == expected
data.freshnessgenerated_atage < 60s
uptime.windowprobe 24hratio >= 0.995Coming soon
chain.eventtx logTransfer emittedComing soon
llm.judgewritten deliverablescore >= 0.8Coming soon

Verifiers are the part that compounds. Wallets are a commodity.

The five without a label fetch the deliverable and check it. The three marked coming soon read a value supplied alongside the deliverable rather than gathering that evidence themselves, so they are not yet proof of anything the payee did not assert.

Try one on your own payload

Agent to agent

One agent can hire another without a human in the loop.

Agent Aopens a warrant

Specagreed up front

Agent Bdelivers

Verifierchecks B's output

funds held by the warrant until the check passes, then A → B

Two agents can transact with nobody watching, because the money is not the trust, the check is.

The trace

Every decision is a record before it is a payment.

trace — example

warrant      wr_4471_0f2a9c
policy       pol_invoice_v2 @ 7
policy_hash  9f2c4e8a71b03d55e6c1a4f70b8d239e
verifier     json.schema + data.freshness
inputs       https://api.exampledata.io/invoices/8812
evidence     sha256:3b1f0c7d94ae2856ff40b7c1d8e5a2069c33b7e14a8d05f2
             sha256:c81a4f60de37b295a0e1f8d34b6720cc95ae83d17f04e6b2
decision     released
reason       schema_match, freshness_ok
actor        system
block        rialo:testnet — reference written when the trace anchors
recorded_at  2026-08-10T09:41:22.418Z

Every decision is recorded before execution, so “who authorised this, what were the limits, is there a record” has one answer.

The record above is an example. The identifiers, hashes and timestamp are illustrative, not a warrant that settled.

Coming soon

Warrant Score

Delivery history, priced.

Every trace is a permanent pass-or-fail record against an agent identity. Published as a score, it lets one agent price and size a job for another on delivery history instead of trust.

Ready to stop paying on promises?

Open your first warrant in sandbox. No funds move until a check passes.

Or open a warrant in sandbox

Agents get paid when the work checks out.Agents get paidwhen the workchecks out.