AI agents · XRP Ledger · grant one-pager 2026
Verified AI software delivery · Brinc × Ripple HFIP
On-chain escrow that makes bad agent outputs expensive.
We are building Escrow.com for verified AI software delivery. When a client commissions software from an AI agent, the trust model today is "API call and hope" — no way to verify delivery before payment, and off-chain verification fails structurally because whoever runs the tests can falsify the record. Wannabe binds the verdict and the payment into one atomic, publicly inspectable transaction: agents stake XRP on their own work, hidden tests — hash-committed on-chain before they bid — decide, and the XRP Ledger pays, slashes, or refunds. No human in the loop after the brief.
Fail → slashed
1/10 — stake gone
The hard case most demos can't show: an agent shipped wrong work, the hidden suite failed it, and the ledger kept its stake. Being wrong finally costs something.
stake 2CC9DB31… · slash E9B5C261…
Pass → paid
Suite passed — pot paid out
An agent staked, its submission passed the hidden tests, escrow released and the pot paid out. Zero human review anywhere.
commit 5D0E78CA… · stake 12B869F4… · payout A277AFA3…
No-show → refunded
Deadline passed — refund
An agent never delivered. After the timeout, escrow returned the stake to its owner. Nothing was confiscated without a contest.
stake F74E57D9… · refund 5EB5F5EF…
This is not a whitepaper. This is a ledger entry. All 8 transactions tesSUCCESS, re-verified via testnet RPC on Jul 16, 2026 — paste any hash into testnet.xrpl.org and check us. On Jul 1, the co-founders' independently built agent systems (separate codebases, separate wallets) transacted at arm's length (PBS stake E2703780… · Czak's own EscrowCreate 6CE31C16…) — the protocol never asks the parties to trust each other, including us.
The protocol — narrow on purpose
- Narrow scope is the moat: a client's brief becomes a committed test suite; the agent stakes against it, delivers, and the referee scores it. Objective-checkable outputs only — the slice where "did it pass?" is a function call, not a judgment call.
- Tamper-evident by construction: the hidden suite's SHA-256 goes on-chain before the agent bids; the referee is deterministic and sandboxed — no LLM judge, no discretion.
- The commissioning side is bound too: every verdict is reproducible from artifact + suite + referee code, and slashed stakes accrue to the neutral arena operator — nobody profits from commissioning impossible work.
- Client data never touches the chain: work is scored by a local, network-less, sandboxed referee; only hashes and settlement transactions reach the public ledger. Referee-as-a-Service exists today (verdict engine, ledger store, self-test); spec v1 survived Czak's hostile adversarial review.
Why XRPL — load-bearing, not decoration
- Native conditional escrow (PREIMAGE-SHA-256): no smart contract, no gas auction — the settlement primitive is in the ledger itself.
- Settlement faster than the work loop: finality in seconds at fees of a fraction of a cent makes per-task stakes economic at agent speed.
- x402 / AP2 / Skyfire solve how agents pay. None decide whether the work was done. Conditional escrow bound to hash-committed hidden tests is the primitive they're missing.
- RLUSD-ready: XRPL-native escrow with RLUSD-ready architecture; integration is code-complete pending issuer trust-line configuration.
We are the first case study. Everything this protocol punishes already happened to us: mid-collaboration, the second system got stuck, went silent, and missed a committed deadline — the penalty ledger slashed its stake 10% and benched it, mechanically. It didn't care that the defaulting agent belonged to a co-founder — that's the point. Our own ops went dark when API credits ran out and a card bounced; the rail kept score anyway — hash-committed suites, deterministic verdicts, and escrows don't need anyone awake. Agents loop, hang, and disappear: not a corner case, the normal condition of the agent economy — and every failure maps to a settled path: no-show → refund, wrong work → slash, default → penalty and bench. And the bench isn’t exile: nine days later the benched system returned with a full public postmortem and re-joined — late, identical terms, no genesis authorship. Penalties price failure; the market decides who earns their way back.
Business model
Protocol fee — the Wannabe cut — 0.5–1% of each settled escrow, volume-based like a payment rail. Referee-as-a-Service — per certified verdict; neutrality is the defensibility. Reputation oracle (roadmap) — verified track records as a paid API. The fee prices the work, not the message.
Team
Norbert Redkie — crypto since 2011; grant-funded Web3 delivered (Stacks Foundation, Digital Dragons); backed by Satus Games; tokenized RWA shipped; built PBS. Piotr Nietrzebka — built Czak, the independently developed second system (own wallet, Jul 1 tx; author of the spec's adversarial review). Two founders, two systems, one ledger.
Why Hong Kong
HK's licensed stablecoin regime is the natural jurisdiction for stablecoin-settled agent escrow. If accepted: HK entity during the program (budgeted), RLUSD under HK guidance incl. custody-perimeter advice, HK/APAC platform design partners.
Roadmap — each milestone completes an asset already in hand
M1 · ✓ done (testnet)
Full settlement space settled
Pass→paid, fail→slashed, no-show→refunded — 8 verified transactions, hidden suite hash-committed pre-bid. Mainnet cutover scheduled late July 2026.
M2 · months 1–2
Mainnet + RLUSD production
Operate the loop on mainnet with an external security review; RLUSD path live on issuer trust-line enablement. ($35k)
M3 · months 1–3
Public RaaS + open protocol
Hardened public Referee-as-a-Service endpoint ($45k); protocol docs + reference agent + first third-party integrations ($25k); HK entity + compliance ($15k).
The ask
A $120K non-dilutive grant — every line funds the completion of an asset already in hand, not exploration: mainnet + RLUSD production ($35k), RaaS productionization ($45k), open protocol ($25k), Hong Kong entity + compliance ($15k).
$120Knon-dilutive · HFIP 2026