Show HN: Verify-before-release x402 gateway for AI agent transactions
by settlddotwork | 2026-02-14 04:17:17+00:00
Hey HN,

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