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