展示HN：用于AI代理交易的验证前发布x402网关
嘿，HN，
我创建了Settld，因为我不断遇到同样的问题：AI代理可以调用API、支付服务费用并雇佣其他代理，但在资金转移之前没有办法证明工作确实完成。
问题可以用一句话概括：x402告诉你“付款已发送”，而Settld告诉你“这项工作值得支付”。
### 它的功能
Settld位于你的代理和它所支付的API/代理之间。它：
1. 拦截HTTP 402（需要付款）响应
2. 创建一个托管保留，而不是立即付款
3. 收集工作完成的证据
4. 进行确定性验证（相同的证据 + 相同的条款 = 每次相同的付款）
5. 仅在验证通过后释放付款
6. 发放一个可加密验证的收据
如果验证失败或工作存在争议，保留款项将被退还。无论如何，代理都会收到收据——这是对发生事件的永久可审计记录。
### 为什么现在这很重要
我们正处于一个奇怪的拐点。Coinbase推出了x402（超过5000万笔交易）。Google推出了A2A。Anthropic推出了MCP。代理可以相互发现、沟通和支付。
但没有人建立一个层来回答：“工作是否确实完成，应该支付多少？”
这就是空白。目前，每个代理之间的交易要么是“信任和希望”，要么是“不交易”。两者都无法扩展。
### x402网关（尝试它的最快方式）
我们推出了一个可直接使用的反向代理，你可以将其放在任何API前面：
```bash
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
```
一切正常流动——除了402响应被拦截、托管、验证和结算。你的代理会收到一个带有哈希链证明的收据，证明发生了什么。
### 背后的技术
结算内核是最有趣的部分（也是我们花费最多时间的地方）：
- 确定性政策评估——机器可读的协议，释放率基于验证状态（绿色/黄色/红色）。没有模糊性。
- 哈希链事件日志——每个结算中的事件都用Ed25519签名链接。防篡改，离线可验证。
- 带有保留窗口的托管——可配置的保留基点 + 争议窗口。如果没有异议，资金会自动释放。
- 争议 → 仲裁 → 裁决 → 调整——完整的争议解决流程，而不仅仅是“标记以供人工审核”。
- 仅追加的声誉事件——每个结算都会产生一个声誉事件（批准、拒绝、争议等）。代理建立可验证的经济记录。
- 组合结算——代理可以将工作委托给子代理，并链接协议。如果下游代理失败，退款会确定性地向上级链条回溯。
整个协议使用JSON模式、符合性向量和可移植的预言机进行了规范： [GitHub链接](https://github.com/aidenlippert/settld/blob/main/docs/spec/README.md)
### 这不是
- 不是支付处理器——我们不移动资金。我们决定“是否”和“多少”资金应该移动，然后由你现有的支付渠道（Stripe、x402、电汇）来执行。
- 不是区块链——确定性收据和哈希链，但没有共识机制或代币。只有加密证明。
- 不是代理框架——我们不关心你使用LangChain、CrewAI、AutoGen还是原始API调用。我们是一个协议层。
### 技术栈
Node.js，PostgreSQL（或用于开发的内存），Ed25519签名，SHA-256哈希，RFC 8785规范JSON。约107个核心模块，494个测试通过。
### 我希望从HN得到什么
诚实的反馈，看看这个问题是否引起共鸣。如果你正在构建涉及资金的代理工作流，我想知道：什么地方出现了问题？缺少什么？什么会让你真正安装这个？
GitHub: [https://github.com/aidenlippert/settld](https://github.com/aidenlippert/settld)
文档: [https://docs.settld.work/](https://docs.settld.work/)
快速入门（10分钟）: [https://docs.settld.work/quickstart](https://docs.settld.work/quickstart)
查看原文
Hey HN,<p>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.<p>The problem in one sentence: x402 tells you "payment was sent". Settld tells you "the work was worth paying for".<p>What it does<p>Settld sits between your agent and the APIs/agents it pays. It:<p>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<p>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.<p>Why this matters now<p>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.<p>But nobody built the layer that answers: "was the work actually done correctly, and how much should the payout be?"<p>That's the gap. Right now, every agent-to-agent transaction is either "trust and hope" or "don't transact." Neither scales.<p>The x402 gateway (the fastest way to try it)<p>We ship a drop-in reverse proxy that you put in front of any API:<p>docker run -e UPSTREAM_URL=<a href="https://your-api.com" rel="nofollow">https://your-api.com</a> \
-e SETTLD_API_URL=<a href="https://api.settld.dev" rel="nofollow">https://api.settld.dev</a> \
-e SETTLD_API_KEY=sk_... \
-p 8402:8402 \
settld/x402-gateway<p>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.<p>What's under the hood<p>The settlement kernel is the interesting part (and where we spent most of our time):<p>- 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.<p>The whole protocol is spec'd with JSON schemas, conformance vectors, and a portable oracle: <a href="https://github.com/aidenlippert/settld/blob/main/docs/spec/README.md" rel="nofollow">https://github.com/aidenlippert/settld/blob/main/docs/spec/R...</a><p>What this is NOT<p>- 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.<p>Tech stack<p>Node.js, PostgreSQL (or in-memory for dev), Ed25519 signatures, SHA-256 hashing, RFC 8785 canonical JSON. ~107 core modules, 494 tests passing.<p>What I want from HN<p>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?<p>GitHub: <a href="https://github.com/aidenlippert/settld" rel="nofollow">https://github.com/aidenlippert/settld</a>
Docs: <a href="https://docs.settld.work/" rel="nofollow">https://docs.settld.work/</a>
Quickstart (10 min): <a href="https://docs.settld.work/quickstart" rel="nofollow">https://docs.settld.work/quickstart</a>