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