Solo BuildHackathonAgent PaymentsAlgorand2026

ValidPay — pay only for valid responses

Problem: Plain x402 — the open standard that lets AI agents pay per API call — settles the payment before anyone knows if the response is valid. Bad response, money already gone.
Solution: Validate, then settle. A contract fail withholds the charge — the buyer pays $0 on chain.
Result: Solo build, settling on Algorand Mainnet. Selected for the judged mentoring round — one of 22 teams.

When an AI agent buys an API call, quality is unknown until the response arrives — but with plain x402 pay-per-call, the money settles first. Bad response, empty payload, upstream error: the buyer already paid.

ValidPay flips the order: valid response → valid payment. A seller puts the gateway in front of their HTTP API and declares a response contract per route; the gateway calls the upstream, checks the payload against the contract, and settles USDC on Algorand only when it passes. Fails? The charge is withheld — the buyer pays nothing, on-chain. Buyers change nothing: any standard x402 client works. Built solo for the Brainwave 2026 x402 track, settling on Algorand Mainnet, and selected for the judged mentoring round — one of 22 teams.

Buyer side, seller side, and the receipt:

The buyer installs nothing — a normal x402 client against a paid URL.
v1 contracts are mechanical (JSON shape, required fields, reject-on-error) — no LLM judging quality. Deterministic checks first; judgment later, if ever.
Every settlement is publicly provable — the receipt links to the real Mainnet transaction.

Same payment, different outcome

The whole product is one reordering. Plain x402: agent pays, USDC settles, then the response arrives — and if it's bad or empty, the money is already gone. ValidPay: agent pays, the gateway validates the payload against the seller's contract, and settlement happens only if the check passes. A failed call costs the buyer $0 on chain.

Two flows side by side — plain x402: agent pays, USDC settles, bad or empty response, money already gone; ValidPay: agent pays, payload validated, settle only if valid, fail means zero dollars on chain — The one reordering that is the product · validate, then settle

The seller sees money and misses, live

The console itself survived a reversal: the first version was a buyer-facing dashboard, and halfway through I asked who the screen was for. In our own narrative, buyers never know ValidPay exists. It existed to impress judges, so I killed it and rebuilt the surface for the seller, the one party who watches settlements.

The seller console reports the three numbers a seller actually cares about: settled charges (USDC received after the contract passed), withheld charges (the response failed your contract — buyer not charged on chain), and upstream errors (your API was unreachable or returned non-JSON). Under them, a live feed pairs every event with its reason — contract passed, handler failed, reject-on-error — and links each settlement to the transaction itself.

ValidPay seller console on a dark surface — Settled 6, Withheld 4, Upstream errors 0, and a live feed pairing settlements and withheld charges with their contract-check reasons and transaction links — The seller console · settled vs withheld with reasons, every settlement linked to its transaction

The receipt is a public blockchain transaction

Click any settlement in the feed and you land on the Algorand Mainnet explorer — sender, receiver, 0.001 USDC, block number. The receipt is a public record, so a buyer can check for themselves that a charge held to the seller's contract.

Algorand Mainnet block explorer showing the real settlement transaction — an asset transfer of 0.001 USDC with sender, receiver, block number and group — A settlement in the public Mainnet explorer · 0.001 USDC, sender, receiver, block number

The buyer's view: reject costs nothing, valid settles

The demo agent buys a weather forecast through the gateway twice. Invalid coordinates: the contract's reject-on-error rule fires, status rejected, nothing settles. Valid Berlin coordinates: a real forecast comes back, the receipt reads paid · validation_passed, and the x402 settlement block carries the payer, the transaction ID and the network — the same transaction the seller's console links to.

Buyer terminal running the weather demo — an invalid-latitude call returns status rejected with reason reject_if:error and no charge, a Berlin forecast returns paid with validation_passed and an x402 settlement block naming the Mainnet transaction — One demo, both outcomes · rejected costs nothing; valid settles and names its transaction

Where it stands

A solo hackathon build, live on Algorand Mainnet with a public repo, a runnable judge demo, and mechanical v1 contracts. The contract language is JSON shape and rules — no marketplace, no LLM quality judge — because withholding money needs a check both sides can predict.