AI 智能体的支出治理层（覆盖所有花钱行为的场景）。 支付通道负责转移智能体的资金；SpendVeto 决定是否应允许智能体调动资金——政策检查、人工审批、委派预算上限，以及失控智能体紧急熔断，全部在任何付款发生之前执行。
最初是 web3 研究简报 中的“最小真实测试”；经过两轮研究驱动的功能迭代（GPT deep-research + 实战市场研究），已发展为一个受治理的 x402 + MCP 技术栈。资金定位和市场数据见 PITCH.md。
一个治理门禁，置于付费端点的目录之前，支持三种访问方式——CLI、委派子代理，以及任意 MCP 客户端：
agent (CLI / child wallet / Claude via MCP)
→ frozen? (manual kill switch, or auto-frozen by the runaway-burst detector)
→ policy check (per-call, hourly, rate, cascading delegation caps)
→ [maybe: human approval on the dashboard — fails closed on timeout]
→ pay $X USDC via x402 (simulate or Base Sepolia testnet)
→ GET /api/agent/<tool> → Claude does the task
→ everything lands in the ledger; blocked-spend dollars roll up on the dashboardRelated MCP server: evav-gateway
npm install
npm run server # terminal 1 — :8402, dashboard at http://localhost:8402
npm run call # terminal 2 — pays for "review" ($0.01), auto-approved
npm run call -- summarize # $0.02 — above the approval line: go approve/deny it on the dashboard
npm run call -- translate # $0.005运行 npm run verify 可无头执行全部流程——264 个端到端断言：目录状态、伪造签名拒绝、强制策略阻断、全部三种审批结果（批准 / 拒绝 / 超时即失败），委派上限（含 n 级级联），工具 + 链域作用域，多链结算（按链签名、按链余额、链白名单），失控爆发自动冻结，手动紧急开关，签名收据校验，CSV 导出，按工具 / 按钱包 / 按链分析，实时送达接收方的 webhook 告警，结构化自修正拒绝，无副作用的试运行，TTL 授权到期，一键审批链接，stats 端点，AP2 指令链偏移检测，无人在场授权钳制，受治理的 Bazaar 发现，ACP 共享支付令牌作用域，请求完整性绑定（包括授权后被替换的载荷），签名争议证据包及防篡改检测，OpenTelemetry 在进入的 trace 上下文下导出 span，以及一次真实的 MCP stdio JSON-RPC 往返验证。
关于数字： 全新克隆运行 264 条断言。另有 3 条针对 Basis 的真实跨项目集成测试，且仅当
../prediction-copilot检测为真时才运行——当其缺席时，测试套件会打印(skipped: cross-project Basis integration test …)。凡对外发布的数字都是 264，人人都可复现。
市场营销现售站点：npm run site 在 http://localhost:8403 提供一个可立即上线的落地页（Three.js 首屏，动画产品演示）；site/ 完全静态自包含，可直接部署到 Vercel/Netlify。内含一个交互式应用演示（site/playground.html），在浏览器端推理真实策略决策逻辑——设置预算，模拟智能体花钱，实时观察“通过 / 待审 / 阻止”三种结果——还有一页应用场景，基于真实的 2026 智能体支付场景。
三个基于 Claude 的真实工具，对应三个价位（shared-config.js）：
工具 | 价格 | 治理路径 |
| $0.005 | 自动认可 |
| $0.01 | 自动认可 |
| $0.02 | 暂停等待人工确认（> $0.015） |
mcp/server.js 向任何 MCP 客户端暴露付费目录。代理看到的是普通工具；每次调用都会在执行任务前静默运行完整的治理管道（策略 → 审批 → x402 支付）。被治理阻断的调用以工具错误返回，说明是哪些门禁拦住了它，并明确它们没有扣款。
# Register with Claude Code (server must be running: npm run server)
claude mcp add spendveto -- node ~/Desktop/spendveto/mcp/server.js或者在 Claude Desktop 的配置中：
{ "mcpServers": { "spendveto": { "command": "node", "args": ["/Users/you/Desktop/spendveto/mcp/server.js"] } } }此时会出现四个工具：review、summarize、translate（各自描述里标识了价格），以及 spendveto_status（免费——显示钱包、余额、策略、开备清单、待审批授权、可续预算）。向 Claude 询问 “我这个智能体的资金状态如何 ?”，然后 “帮我运行付费的 summarize 工具”，就能在控制台看到审批项。
父母钱包将一笔受上限约束的终身预算授给子智能体的钱包——而子级还能继续往下授予。限制会逐级传导：孙级支出同时计入本级上限和所有祖先集合的上限，因此一整个子代智能体团队无论如何也不会让顶部分支的预算超额。管道的每一层都在每次调用时执行接受方的策略检查；控制台实时显示层级树，用“支出 vs 预算”的进度条呈现。
npm run delegate -- 0.015 "team lead" # main wallet grants $0.015
npm run delegate -- 0.05 "intern" --parent "team lead" # team lead grants onward
npm run call -- review --child=intern # fine — fits both caps
npm run call -- review --child=intern # BLOCKED … granted to ancestor "team lead"
npm run delegate -- 0.02 "translator" --tools translate # scope, not just size
npm run call -- review --child=translator # BLOCKED … outside its delegated scope
npm run delegate -- 0.02 "base only" --chains base-sepolia # pin the settlement chain too
npm run call -- review --child="base only" --chain=polygon # BLOCKED … outside its delegated chain scope
npm run delegate -- 0.05 "flash task" --ttl 10m # time-boxed budget: self-expires随时撤销：POST /api/delegations/:id/revoke — 被撤销的委派会废除其整个下游分支。
每次模拟结算都能返回由服务端生成的带签名的、可独立验证的收据（receiptId / settlement.signature / signedBy），且现在可在里查询：GET /api/receipts/:id 用于查找，POST /api/receipts/verify 在服务端校验任意收据的签名（结果是篡改了价格就失败——测试可证明）。在策略里配置 alertSigningSecret 后，每个 webhook 都会携带 X-SpendVeto-Signature HMAC 头，让接收方能证明该通知确实来自你的 SpendVeto。完整交易日志可经 /api/export.csv 导出，按工具和按钱包的轻量汇总则位于 /api/analytics；如果你在 data/policy.json 中设置了 alertWebhookUrl，冻结、被阻断的调用、待审批都会实时 POST 到该地址（指向 Slack 的 incoming webhook 即可）。
任何钱包都可以从控制台（或调用 POST /api/freezes）被冻结；若某个钱包投递支付尝试的频率超过策略定义或设置的突发请求阈值（默认 10 秒内最多 10 次），会被系统自动冻结——失控的智能体循环会在脉冲爆发中即被拦截，而不是等到下个月账单才暴露。已冻结的钱包不仅会被自身的策略检查拒绝，也会在模拟支付 关卡处被拒绝，即便携带了正确签名的支付请求也会返回 403。等你搞清楚这个智能体到底在做什么之后，一键解冻就可以了。
npm run proxy（:8404) 改变了信任模型：智能代理全程不持有任何密钥。 它们只提交一条支出 意图；由代理保管密钥、冻结检查、运行全部管道（冻结 → 策略 → 分级额度 / 范围 → 解冻审批），只有这之后才签名并支付。/pipe 就算出一个恶意代理，它也不能绕过自己的策略检查——因为它根本没有任何可用来签名的东西。
curl -X POST localhost:8404/proxy/call -H 'Content-Type: application/json' \
-d '{"tool":"review"}' # custody wallet
-d '{"tool":"review","child":"intern"}' # spend as a delegated child, by label被拒绝的意图会返回 403，并包含阻断点、原因和结构化拒绝信息——不会签署任何东西，也不会转移任何资金。一个幂等键（header 或 body）配合“发送 Idempotency-Key”后，重试的意图会重放已存储的响应，而不是二次付款——一个循环循环崩溃的代理无法产生重复支出（已测试：相同键使用两次 → 账目中只记录一条）。
三项来自 July 2026 专项调研的功能（见 launch/DEEP_RESEARCH_PROMPTS.md）：
自纠错反馈 — 每次被拦截都携带一个机器可读取的 code 字段（per_call_cap、chain_scope、hourly_usd_cap、delegation_expired，…）以及一个可执行的 suggestion（如 “在一个允许的链上重试：base-sepolia, base” / “当前分支的剩余配额为 $0.0050 — 选择一个更便宜的工具”）。CLI 会把它打印成一个 Fix: 行，MCP 的 stream 流也会把提示包含在被工具返回的错误里，这样模型就能自纠错而不会陷入重试循环；代理也会把同一个字段放进 403 的响应体里。
直接跟踪 — npm run call -- summarize --dry-run（或是对代理发送 {"dryRun": true} 请求）会完整检查整条链——冻结、链生效、配额、委派层级、拉取即时审批阈值——并且报告结果是 会发起付款 / 会暂停等待批准 / 会被拦截 (并附带修复建议)，整个过程零副作用：不产生付款，不发送批准请求，不记录账本条目（这已通过测试验证）。
计费范围限制 — 所有授予都可以带 --ttl 90 / --ttl 10m / --ttl 2h 的过期时间：超过 expiresAt 后，它的权限便被废弃，和“撤销”一样不可用；而如果一个链上的祖先节点过期，分支下的整个后代都会随之失效。
一键确认 — 审批现在会在 webhook 里嵌上 approveUrl / denyUrl 两个链接；直接粘贴到 Slack，审批人就能在聊天里单击完成同意或拒绝。
rails/）每一条支付通道都通过后端 的通用短连接方式接入——{ id, name, status, pay({ tool, account, chain, baseUrl }) }——治理管线完全感知不到具体是哪个通道结算的。目前已有两条通道在线（x402-simulate、x402-live），后者在全局范围内根据 Layer2 的能力灵活适配。并且，Google AP2、OpenAI ACP 和 Stripe Machine Payments 都作为明确的适配层槽位存在，它们会诚实地告诉你“未实现（这是战略地图上的已立项开发项）”而不是假装可用。GET /api/rails 就是通道注册表；代理也会通过 /proxy/health 把它公布出去。这就是“面向智能体支出的 Stripe”，但不需要持牌手续：一个在我们下面的接口，多种通道都接进来，治理在上一层，最初在下层，结算在最底层。
除了 CLI 和 MCP 服务器，还有两个代码级集成入口：两者都零依赖，并且在 npm run verify 中都有端到端实际执行验证，而不仅仅是语法解析：
sdk/ —— 一个 Node 客户端（SpendVeto 类）：.pay()、 .dryRun()、 .chat()（用于治理的 LLM/API 费用）、 .registerAgent()、 .catalog()。用户被拒绝时会抛出带类型的 SpendVetoDenialError{code, suggestion, stage}，而不是静默吞掉。
integrations/langchain.js —— 把目录工具适配成 LangChain 风格的 { name, description, func } 对象，避免直接依赖 @langchain/core。拒绝信息会以结构化 code 中的一种抛出，这样智能体的下一步推理就可以自动纠错。
integrations/openai-agents.js —— 同样的受治理目录，适配为 OpenAI Agents SDK 风格的 { name, description, parameters, execute } 工具（符合 tool() 函数的逻辑），也不需要硬依赖 @openai/agents；它直接复用 LangChain 适配器，两者共享同一条处理管道。
两种集成都会要求经过 enforcement proxy，后者现在会对每个钱包的“决策+提交”单元（client/pay.js 中的 withWalletLock）做串行化——这修复了一个实际存在的竞态：对同一个钱包的并发调用可能各自读到相同的“已支出”快照，从而合并起来超过了原本为单个调用设的预算上限。我们用 6 个并发调用、并让预算只允许恰好 1 个通过来验证：无论怎么跑，最后都执行恰好一次通过。代码示例见 docs.html#sdk。
这两个页面把 API 原本就能做的事和真正可点击的人机界面补杆：市场面板可以发放绑定钱包的身份凭证，并从表单里展示市场工具（不需要翻使用 curl）；报表面板则回答“这段时间整体到底花了多少，治理又拦截了什么？”——后续支持 GET /api/report?days=7，并隐藏一个适用于直接贴进群聊的一句话汇总，分类别和按链展示费用分布，还把治理被触发的最常用原因也列出来。
四个当前主流玩家提供的关键能力点，SpendVeto 也同样真实具备，且都有对应测试：
代理身份（Skyfire 风格的“了解你的代理”）—— POST /proxy/agents {label, child} 铸造一个 bearer 令牌，可选地绑定到一个钱包。在没有任何身份时处于开放模式（零配置演示）；一旦第一个身份注册，代理意图就需要 Authorization: Bearer …，且绑定的令牌只能以其自己的钱包进行消费（已测试：body 中的 child 覆盖会被忽略）。GET /proxy/agents/:id/credential 就是 KYA 凭证本身——一次读取即可将该身份与其钱包的实时信任评分、冻结状态和委托范围（上限/工具/链/收款人）关联起来，因此对手方可以检查“这个代理实际上被允许做什么”，而无需手动交叉引用四个端点。
类别上限（Ramp 风格）——工具带有消费类别；策略中的 "categoryCapsUSD": {"content": 5} 按小时限制每个类别，根据账本自身的标签计算。
N 审批人规则（Safe 风格）—— "approversRequired": 2：拒绝是即时且最终的，但只有足够多的人类点击后批准才会生效（已测试：一次批准仍保持待处理状态）。
交易时间窗口 —— "allowedHoursUTC": {"start": 13, "end": 21}：在窗口之外，任何消费都不会发生。这是针对“我的机器人在凌晨 3 点交易”的控制，包含跨午夜窗口。
按代理限流 + 冻结（proxy/server.js）——钱包级预算上限仍然是资金的事实来源，但多个代理身份可以共享一个钱包（agents.json），因此单个行为异常或循环的代理需要能够在不冻结该钱包上所有其他代理的情况下被停止。每个身份都有自己的滑动窗口调用限制（PER_AGENT_CALLS_PER_MIN，默认 20）；连续 3 次触发限流会自动冻结该身份（POST /proxy/agents/:id/freeze / /unfreeze 也可用于手动控制）——在合成 agent:<id> 键下复用现有冻结存储，因此它仍然在仪表板上可见，并像任何其他冻结一样被告警。
签名同意记录（server/consents.js，Visa Trusted-Agent-Protocol 风格）——授予或撤销委托现在还会写入一条 ECDSA 签名的同意记录（与签署结算收据和 AP2 裁决的服务器密钥相同）—— GET /api/consent/:delegationId 用于查看轨迹，POST /api/consent/verify 用于独立检查任何记录的签名，而无需信任 JSON 文件。
代理型令牌（POST /api/agentic-token，Mastercard-Agent-Pay 风格）——一个薄而诚实的捆绑包，覆盖上述两个原语：一个范围限定为恰好一个商户收款人的委托及其签名同意，作为一个对象返回（GET /api/agentic-token/:id 可查询）。执行方式与每个委托已有的收款人白名单 + 上限检查相同。
AP2 裁决的可验证凭证导出（server/vc.js）—— POST /api/ap2/evaluate?format=vc 将相同的签名裁决重塑为 W3C-VC 形状的信封（AP2 本身构建在可验证凭证之上）。诚实标注：证明类型是 SpendVeto 自己的，不是注册的 DID 方法/证明套件——但 proof.message + proof.proofValue 与未包装端点已经返回的 ECDSA 签名完全相同，可使用 verifyMessage 或任何 ECDSA 库独立验证。
跨通道收据标准化（server/receipts.js）—— GET /api/receipts/normalized 将每一条账本条目（x402 加密结算、按量计费的 LLM/API 消费，以及接下来任何结算通道）投影为一种稳定的形状，因此客户端无需知道哪条通道产生了哪条条目。proof 仅为实际具有签名收据的条目填充——绝不会为没有收据的条目伪造。
自上一轮以来，两个协议变动改变了治理层必须覆盖的范围，两者都打开了一个按调用消费上限在结构上无法看到的缺口。
AP2 授权链——购物车还是意图吗？（server/ap2.js，POST /api/ap2/mandate-chain）——AP2 将购买建模为一条链：人类签署的 Intent Mandate，然后是代理组装的 Cart Mandate。/api/ap2/evaluate 只判断一个金额，因此它无法捕捉到这条链存在所要暴露的失败——一个完全在预算之内但仍然未经授权的购物车。此检查将购物车与其声称来源的意图进行核对：总额超过意图上限（cart_exceeds_intent）、声明的总额与其自身行项目矛盾（cart_total_mismatch——在任何上限之前检查，因为购物车无法证明的总额不是用来核对上限的数字）、意图从未授权的商户或类别（merchant_drift / category_drift）、一次授权被分散到超过意图允许的卖家数量（multi_merchant_spray——一种有记录的代理入侵特征）、过期意图，以及购物车附带了并非由其派生出的意图。确定性和局部性；没有模型来判断漂移。裁决与其他所有决策一样由 ECDSA 签名。
无人在场授权（同一端点）——AP2 v0.2.0 将代理在无人类可用时购买的流程正式化。在这些流程中，“暂停等待批准”不是暂停，而是一个无法回答的问题，将其视为暂停要么挂起流程，要么悄悄放行。SpendVeto 的规则：签名的意图授权就是人类的事先授权，因此在其声明的上限内调用继续（preAuthorizedByIntent: true，裁决也会说明）；超出上限——或当意图根本没有指定上限时——没有授权，也没有人可以询问，因此默认失败关闭（hnp_no_authority）。绝不会将超出意图的消费静默升级为允许。
受治理的 Bazaar 发现（server/discovery.js）——x402 v2 的 Bazaar 层让代理能够发现并支付一个它从未听说过的服务，无需预先构建的集成。这正是其意义所在，也是问题所在：在结算时查询的收款人白名单得知被提示注入的代理所选择的端点时，已经太晚，无法提供帮助。GET /api/discovery/resources 以 Bazaar 的 schema 发布 SpendVeto 自己的目录（CAIP-2 网络、USDC 基础单位，标记为 governed，以便买家知道价格是一个下限）。POST /api/discovery/govern 则反向运行——它在代理看到发现的目录之前，先通过实时策略对其进行过滤，因此一个永远不被允许支付的服务绝不会出现在其可选择的列表中，每次移除都会指明导致移除的规则和生效的策略版本。这是一个预过滤器，缩小了被入侵代理甚至能命名的范围；无论它最终选择了什么，在调用时仍会运行完整的流水线。
买方一侧迅速变得拥挤：Fireblocks 加入了 x402 Foundation，并正在为请求完整性和消费治理贡献一个安全扩展；AWS 预览了带消费限额的 Bedrock AgentCore Payments；Cloudflare 宣布了带消费控制的 Account Wallets；2026 年 Cloud Security Alliance 的一项调查显示，65% 运行代理的企业在十二个月内遭遇过一次或多次与代理相关的事件。那次扫描得出了四个缺口，每一个都是按调用上限在结构上无法做到的。
请求完整性——“这是我允许的消费吗？”（server/integrity.js，POST /api/integrity/bind → /api/integrity/verify）——这里的每项控制回答的都是这笔消费是否被允许。没有一项回答这是否是我允许的消费。策略针对一个被描述的请求运行；而执行的是别的东西。在这两者之间，一个被入侵或仅仅是有 bug 的代理可以更改负载——相同的付款人、相同的价格、相同的批准，但不同的商户或不同的商品——而所有基于金额的控制都会通过，因为金额从未变动。因此：对请求进行规范化摘要（递归排序键 SHA-256，因此键顺序无法改变答案），用签署收据和裁决的同一密钥对摘要签名，并在执行时当负载不再匹配时拒绝（request_integrity_mismatch）。绑定是单次使用的（binding_consumed——可重放的授权是优惠券，而不是绑定）、有 TTL 限制的（binding_expired），并且是代理作用域的（binding_agent_mismatch）。这是 Fireblocks 为 x402 贡献内容的买方侧对应物。
ACP 共享支付令牌范围（server/acp.js，POST /api/acp/checkout）——ACP 的 Delegated Payments Spec 签发一个 SPT：一个为某个金额、某个商户和某个时间窗口铸造的 bearer 凭证，让代理无需看到买家的卡即可完成结账。商户验证令牌。没有人验证购物内容——而一个限定在某商户 $200 的令牌会欣然为错误的商品清算 $200。这与上面的 AP2 漂移形状相同，因此得到相同的处理：spt_merchant_drift、session_exceeds_spt、spt_expired、spt_category_drift、session_total_mismatch（算术在上限之前检查，因为行项目无法证明的总额不是要测量的数字），以及 spt_currency_mismatch——SpendVeto 拒绝将一种货币的上限与另一种货币的收费进行比较，而不是猜测汇率。被允许的会话保持绑定到自己的字节；被拒绝的会话不会获得绑定。
争议证据包（server/disputes.js，GET /api/disputes/:entryHash/evidence）——当人类对一笔收费提出争议时，商户用设备指纹、IP、浏览会话、配送确认来辩护。代理购买不会产生这些中的任何一项，因此代理交易默认失败，商户付款。Visa TAP、Mastercard Agent Pay、AP2 和 Amex 的代理保护都描述了授权；还没有一个定义事后辩护文件。SpendVeto 已经拥有这些数据——没有捕获任何新内容。一个证据包将账本条目固定在其相邻哈希之间（防倒签论证）、生效中的策略哈希以及此后任何漂移披露而非隐藏、人类批准记录，以及付款人消费所依据的委托的签名同意——然后对整个捆绑包自身的摘要进行签名，因此在传输中被编辑的证据包将停止验证（pack_tampered）。每个证据包在工件内部携带一个 doesNotEstablish 列表：它绝不暗示配送、满意度或策略是好的——只暗示它当时生效并被应用。
OpenTelemetry 决策 span（server/otel.js，GET /api/otel/spans）——代理团队已经在追踪提示、工具调用和子代理，而在代理治理评估中反复出现的要求是 OTel 原生可见性：消费决策必须作为导致它的 trace 中的一个 span 出现，而不是在另一个系统中让人在凌晨 3 点按时间戳关联。OTLP/HTTP 是 JSON over POST，因此这是无依赖的——将 OpenTelemetry SDK 拉入那个职责是拒绝信任事物的组件，只会增加供应链攻击面而毫无收益。传入一个 W3C traceparent，拒绝就会落在试图消费的代理运行之下；span id 从条目哈希派生，因此重新导出不会在后端重复 span；格式错误的 header 会降级为独立追踪，而不会破坏决策面。被阻止的消费是状态 OK，而不是 ERROR——门禁完成了它的工作，将拒绝标成红色会训练团队忽略真正重要的颜色。
任何人都可以在门禁后面列出付费工具——目录是供给，而不是固定的演示：
curl -X POST localhost:8402/api/catalog/tools -H 'Content-Type: application/json' \
-d '{"id":"haiku","price":0.008,"label":"Haiku writer","upstreamUrl":"https://your-api.example/haiku"}'
npm run call -- haiku # any agent pays it through the full governed pipeline注册工具获得相同的 402 门禁（链作用域签名、收据、账本）；带有 upstreamUrl 时付费调用会被转发，没有则用预设的响应体回答。卖家列出，买家治理——代理商务的两侧都在一个栈中。
预算可以是额度——在滚动窗口内重新填充的上限，而不是永远耗尽：
npm run delegate -- 5 "shopping agent" --every 7d # $5 a week, self-refilling窗口内的支出计入上限；当它过期后，预算会自行补充（已用 2 秒窗口测试：支出 → 被阻止 → 自动补充 → 再次支出）。这就是"给智能体发周津贴"的原语——今天给团队用，明天给消费级智能体用。
模拟充值：POST /api/balances/topup {address, chain, amount} 在模拟模式下为每个链的余额充值（且仅在该模式下有效——链上余额来自真实水龙头，绝不来自 API）。
加密货币是轨道 #1，因为它在本地即可验证——但同一套管线也治理 LLM/API 支出，而这正是每个智能体团队今天烧钱的地方：
curl -X POST localhost:8404/proxy/llm -H 'Content-Type: application/json' \
-d '{"prompt":"summarize x402 in one line","maxTokens":200}'
-d '{"prompt":"…","maxTokens":20000}' # big estimate → pauses for human approval, FAILS CLOSED
-d '{"prompt":"…","child":"intern"}' # delegated budgets bind token spend too像真实支出平台一样的授权/捕获机制：最坏情况成本预先估算（LLM_RATE_IN_PER_M / LLM_RATE_OUT_PER_M，每百万 token 的美元价格——从你的提供商价格表设置），完整管线针对估算值运行（冻结 → 策略 → 级联预算 → 审批），上游调用仅在通过后才发生，而实际计量成本落入同一账本——作为自己的 api 桶与各链并列汇总。设置了 ANTHROPIC_API_KEY 时补全是真实的；未设置时，补全是模拟的，但治理和计量是真实的。智能体的 token、API 调用和 USDC 都由同一个策略引擎管辖。
shared-config.js 中注册了七条链（每条链都有其规范 USDC 合约和一个 RPC），通过 /api/chains 暴露。链是每笔支付的受治理维度，贯穿始终：
链级签名——链信息嵌入签名的支付消息中，因此为 Polygon 创建的授权永远无法在另一条链的余额上结算（已验证：polygon 签名的授权在 arbitrum 上被拒绝）。
每条链独立的余额——每个 (wallet, chain) 对都有自己独立的模拟 USDC 余额；在 Polygon 上支付只扣减 Polygon 的余额。
链白名单——data/policy.json 中的 "allowedChains": ["base-sepolia", "base"] 阻止智能体在其他链上结算；cautious 和 production 配置包内置了锁定的链。
链级委托——--chains base-sepolia 将子智能体的结算链固定，且（与工具作用域一样）每个祖先的链约束都绑定整个子树。
无处不在——--chain=polygon 的 call -- review、代理意图（{"tool":"review","chain":"arbitrum"}）、/api/analytics 上的按链汇总、CSV 导出中的按链列、仪表盘账本上的链标签。
适配器自适应的实时结算——在 testnet 模式下，网关在启动时询问其配置的 facilitator 能结算什么（/supported），并让它点名的每个注册链上线：按链注册方案，每个 402 响应中每个链一个接受条目，以针对各链规范合约的显式原子 USDC 金额定价。已用 mock facilitator 双向测试：宣告全部七个链则全部上线；宣告一个则恰好一个上线，其余在 /api/chains 上报告 settlement: "ready"。公共 facilitator 目前结算 Base Sepolia；将 SPENDVETO_FACILITATOR_URL 指向 CDP facilitator（使用 API 密钥）并为钱包注资，即可将其主网链上线——零代码更改——距离真正的主网支出只差一个密钥、一笔资金和一次安全审计，而非工程工作。
今天，链上结算已通过 x402 在 Base Sepolia 上运行；模拟模式下，七条链全部在完整管线中运行（真实的链级签名、本地结算）。每个链的 facilitator 适配器是已获资助的里程碑——治理层已经达到链级完备。
shared-config.js 中注册了七条链（每条链都有其规范 USDC 合约和 RPC），通过 /api/chains 暴露。链是每笔支付的受治理维度，贯穿始终：
链级签名——链信息内嵌于已签名的支付消息中，因此为 Polygon 创建的授权永远不会在另一条链的余额上结算（已测试：Polygon 签名的授权在 arbitrum 上被拒绝）。
每链余额——每个 (wallet, chain) 对都有自己的模拟 USDC 余额；在 Polygon 上支付不会触及 Arbitrum 余额。
链白名单——data/policy.json 中的 "allowedChains": ["base-sepolia", ...] 阻止智能体在未允许的链上结算；cautious 和 production 预设策略会固定链。
链级委托——"allowedChains" 作用于子智能体，绑定其由父级授权的结算链。
端到端贯穿——通过策略、预算轨迹图和仪表盘台账进行治理。
Facilitator 适配器——每条链通过 GET /chain-info 暴露可结算性、合约地址和代币精度；402 响应在 x402 头中携带支持的链。当前在 Base Sepolia 上通过 x402 真实结算；每个注册链均在模拟模式下运行完整管线并具备正确的链级签名。
所有链默认可用——data/policy.json 中的空 allowedChains 允许任何已注册链（在 shared-config.js 中）。精确且经过测试。
超过 requireApprovalAboveUSD（在 data/policy.json 中设置）的支出会暂停调用并发布到仪表盘的审批队列——批准/拒绝按钮，实时生效。三种结果：批准 → 支付；拒绝 → 不支付退出；30 秒内未决策 → 失败关闭（绝不未经签署就支出）。
|
| |
加密 | 真实 secp256k1 密钥对，真实 ECDSA 签名 + 验证（viem） | 真实 x402（EIP-191 over EIP-712，链上结算） |
结算 | 链下 | 通过 x402 在 Base Sepolia 上真实链上结算（CAIP-2 ids，原子 USDC 转移） |
配置 | 零配置 |
|
没有假装真实的成分——模拟模式也会验证真实签名（通过 @x402/sdk 的 verify）；它只是本地结算。链上模式则是与真实协议的真正集成。
策略引擎是确定的：给定相同的输入，两台服务器产生相同的决策——这对审计和复现至关重要。一个 Fediverse（@spendveto@botsin.space）和 RSS 提要以人类可读的形式广播每笔支出决策（"批准：向 0xabc 支付 0.5 USDC——预算 track_budget 剩余 $87.11"）。已签署的聚合证明可验证图表状态："本图表已包含交易 TX1…TXn"。
shared-config.js tool catalog (id/path/price), 7-chain registry (USDC contracts, RPCs), mode, port
server/
index.js Express app: catalog, ledger, stats, analytics, CSV export, policy, approvals, delegations, freezes APIs
simulate.js per-tool 402 gate factory: real signature verify, replay protection, freeze refusal, signed receipts
agent.js the paid tasks — one Claude call per tool, canned fallback without a key
ledger.js JSON ledger + simulated balances
approvals.js in-memory pending-approval store
delegations.js durable budget-grant store (caps + tool scopes)
freezes.js durable kill-switch store
anomaly.js runaway-burst detector → auto-freeze
alerts.js fire-and-forget webhook alerts (Slack-ready)
ap2.js AP2 mandate chains: cart-vs-intent drift + human-not-present authority
discovery.js x402 v2 Bazaar: publish the catalog, and policy-filter a discovered one
acp.js ACP shared-payment-token scope: is the session the purchase the token funds?
integrity.js request binding: is this the spend I allowed? (canonical digest, single-use)
disputes.js signed dispute evidence packs — the agent-chargeback defence file
otel.js OTLP decision spans; adopts an inbound W3C traceparent, blocked ≠ ERROR
client/
wallet.js parent keypair + delegated child wallets (pick by label)
policy.js the governance wedge: freezes, hard limits, approval threshold, cascading caps
pay.js shared governed pipeline: policy → approval → pay → log
pay-and-call.js CLI wrapper (--child, --child=<label-or-address>)
rails/
index.js rail registry: one pay() contract, x402 live, AP2/ACP/MPP as honest slots
x402-simulate.js zero-setup rail: real ECDSA, chain-scoped, local settlement
x402-testnet.js real on-chain rail: Base Sepolia via the public facilitator
mcp/
server.js MCP middleware: paid catalog + spendveto_status over stdio
proxy/
server.js enforcement proxy: key custody, agents POST intents (:8404)
dashboard/ the Console: 8 pages (overview, approvals, budgets, ledger, chains, analytics, trust, policy) with create/edit/freeze/apply controls
scripts/
delegate.mjs grant a capped budget (--parent for deeper levels, --tools for scope)
gen-wallets.mjs one-time testnet wallet generation
policy.mjs list/apply policy packs
site.mjs serves the marketing site on :8403
verify.mjs 264 end-to-end assertions incl. MCP stdio round trip + multichain + auto-freeze
data/
policy.json editable spend rules incl. anomaly burst threshold + alertWebhookUrl
policy-packs/ importable governance presets (cautious/standard/production)
ledger/balances/delegations/children/freezes.json runtime state (gitignored)
site/ deploy-ready landing page (Three.js hero, fully static)
PITCH.md funding pitch: TAM/SAM/SOM, competition, accelerator targets (all cited)
launch/ Show HN draft, 90-second demo script, ecosystem-listing blurbs
RESEARCH_PROMPT.md the deep-research prompt behind feature round 2人类在环审批：高于 requireApprovalAboveUSD（data/policy.json）的支出会暂停调用并推送到仪表板的审批队列——批准/拒绝按钮，实时生效。三种结果：批准→支付；拒绝→不支付退出；30 秒无决策→失败关闭（绝不自动支出）。
This server cannot be deployed
Pre-spend firewall for AI agents. Approves, blocks, flags transactions against policy rules.
Free spend guardrails for AI agents: approve/deny/ask_user, caps, dupes.
Meter, cap, and block AI agent spend before the provider is charged.
Governance and agentic-commerce policy tools for AI agents: spend, purchase and charter controls.
