Show HN: Verify-before-release x402 gateway for AI agent transactions
2 comments
Interesting approach. We run 124 x402 endpoints at httpay.xyz and the "verify work was done" problem is real — especially for compute-heavy tasks like image generation or LLM inference where the response time varies.
Currently we handle this by only settling after the response is delivered, but that puts trust on the server side. A third-party verification layer could work for higher-value transactions.
What's the latency overhead of the verification step? For micropayments ($0.001-$0.01 per call), adding even 500ms of verification latency might not be worth it. But for higher-value agent tasks ($1+), escrow + verify makes a lot of sense.
Currently we handle this by only settling after the response is delivered, but that puts trust on the server side. A third-party verification layer could work for higher-value transactions.
What's the latency overhead of the verification step? For micropayments ($0.001-$0.01 per call), adding even 500ms of verification latency might not be worth it. But for higher-value agent tasks ($1+), escrow + verify makes a lot of sense.
Interesting to see verification moving into the agent payment layer.
are you seeing more risk from “incorrect execution” vs “unauthorized execution”. Feels like both problems are emerging at the same time as agents start touching money.
I built Settld because I kept running into the same problem: AI agents can call APIs, pay for services, and hire other agents - but there's no way to prove the work was actually done before the money moves.
The problem in one sentence: x402 tells you "payment was sent". Settld tells you "the work was worth paying for".
What it does
Settld sits between your agent and the APIs/agents it pays. It:
1. Intercepts HTTP 402 (Payment Required) responses 2. Creates an escrow hold instead of paying immediately 3. Collects evidence that the work was completed 4. Runs deterministic verification (same evidence + same terms = same payout, every time) 5. Releases payment only after verification passes 6. Issues a cryptographically verifiable receipt
If verification fails or the work is disputed, the hold is refunded. The agent gets a receipt either way - a permanent, auditable record of what happened.
Why this matters now
We're at a weird inflection point. Coinbase shipped x402 (50M+ transactions). Google shipped A2A. Anthropic shipped MCP. Agents can discover each other, communicate, and pay each other.
But nobody built the layer that answers: "was the work actually done correctly, and how much should the payout be?"
That's the gap. Right now, every agent-to-agent transaction is either "trust and hope" or "don't transact." Neither scales.
The x402 gateway (the fastest way to try it)
We ship a drop-in reverse proxy that you put in front of any API:
docker run -e UPSTREAM_URL=https://your-api.com \ -e SETTLD_API_URL=https://api.settld.dev \ -e SETTLD_API_KEY=sk_... \ -p 8402:8402 \ settld/x402-gateway
Everything flows through normally - except 402 responses get intercepted, escrowed, verified, and settled. Your agent gets a receipt with a hash-chained proof of what happened.
What's under the hood
The settlement kernel is the interesting part (and where we spent most of our time):
- Deterministic policy evaluation - machine-readable agreements with release rates based on verification status (green/amber/red). No ambiguity. - Hash-chained event log - every event in a settlement is chained with Ed25519 signatures. Tamper-evident, offline-verifiable. - Escrow with holdback windows - configurable holdback basis points + dispute windows. Funds auto-release if unchallenged. - Dispute → arbitration → verdict → adjustment - full dispute resolution pipeline, not just "flag for human review." - Append-only reputation events - every settlement produces a reputation event (approved, rejected, disputed, etc.). Agents build verifiable economic track records. - Compositional settlement - agents can delegate work to sub-agents with linked agreements. If a downstream agent fails, refunds cascade deterministically back up the chain.
The whole protocol is spec'd with JSON schemas, conformance vectors, and a portable oracle: https://github.com/aidenlippert/settld/blob/main/docs/spec/R...
What this is NOT
- Not a payment processor - we don't move money. We decide "if" and "how much" money should move, then your existing rails (Stripe, x402, wire) execute it. - Not a blockchain - deterministic receipts and hash chains, but no consensus mechanism or token. Just cryptographic proofs. - Not an agent framework - we don't care if you use LangChain, CrewAI, AutoGen, or raw API calls. We're a protocol layer.
Tech stack
Node.js, PostgreSQL (or in-memory for dev), Ed25519 signatures, SHA-256 hashing, RFC 8785 canonical JSON. ~107 core modules, 494 tests passing.
What I want from HN
Honest feedback on whether this problem resonates. If you're building agent workflows that involve money, I want to know: what breaks? What's missing? What would make you actually install this?
GitHub: https://github.com/aidenlippert/settld Docs: https://docs.settld.work/ Quickstart (10 min): https://docs.settld.work/quickstart