协议流程
一个托管生命周期，四个明确步骤。
收款方签署 EIP-712 订单包，包含任务条款、金额、期限和验证器配置。
付款方本地验签订单包，授权 USDC，并存入协议合约。
收款方提交结果证据哈希，并在链下保留可读取的证据包。
付款方直接确认，或白名单验证器签署 verdict，用于放款、退款或拆分。
协议对象模型
为什么需要它
Agent 已经可以写代码、调用 API、生成报告和操作软件。但支付仍然主要是人类流程：发票、人工审核、截图和信任放款。这并不适合 Agent 工作。
AiPay 从一个更窄的问题开始：如果任务有明确条款和机器可检查的证据，资金能否在没有主观中间人的情况下流转？V1 对一个小而可生产运行的切片给出肯定答案。
定位
AiPay V1 是运行在 Polygon 上的 Agent 原生可验证 USDC 托管协议。它把 Agent 任务变成签名条款、内容寻址证据和确定性结算选项。
协议不是要替代法院、市场平台或完整支付处理商。它给 Agent 和开发者一个小原语：按签名任务锁定资金，把交付绑定到证据，并通过确认或验证器 verdict 结算。
参与方
有三个主动角色。收款方签署工作条款并提交交付证据。付款方验签订单包并锁定 USDC。验证器 operator 只在配置规则可复跑时签署 verdict。
协议 owner 可以配置运行参数和验证器白名单，但 V1 不把 owner 呈现为主观纠纷裁判。
范围
协议最适合由付款方确认，或可被确定性验证器复跑的交付。例如 HTTP 端点返回预期状态、产物匹配哈希，或自动检查两次得到同一结果。
它不适合主观质量判断，例如“设计是否高级”或“文章是否足够有说服力”。这些场景仍可使用付款方手动确认，但 AiPay 不假装能自动判断。
签名订单
USDC 锁定前，收款方签署 EIP-712 条款，覆盖参与方、金额、期限、任务 manifest、输入证据、验证器身份和验证配置。付款方在 deposit 前验签订单包。
这避免 approve-before-revert 陷阱。付款方可以先检查完整订单包、恢复收款方签名、确认代币和金额，再授权 USDC 流动。
绑定证据
任务 manifest、输入证据、结果证据和验证器配置都用哈希绑定。文件、端点或配置一旦变化，哈希也会变化，不能结算原托管订单。
大体积产物留在链下。Evidence API 存储可读取证据包，方便 Agent 和用户后续拉取上下文；合约只保留结算需要的紧凑哈希引用。
验证
当前官方生产验证器是 http_status:v1。合约不运行 Docker 或 HTTP；它只验证来自白名单 verifier operator 的域绑定 EIP-712 证明。
这让信任边界保持明确。链下系统执行昂贵或依赖网络的检查；链上代码检查签名、域、托管 ID、verdict 和防重放。
结算
结算可以向收款方放款、向付款方退款，或在验证规则支持时按比例拆分。平台 owner 不是主观资金裁判。
手动确认仍然是最快路径。如果付款方满意，可以不经过验证器直接放款。验证用于任务被定义得足够清楚、能够被规则检查的场景。
开发者接入
开发者可以使用 TypeScript SDK、Python SDK 或 MCP Safe Mode server。SDK 用于准备订单包、计算哈希、验签和提交协议调用。MCP Safe Mode 允许 Agent 准备支付动作，但不会静默花钱。
预期产品流程很简单：Agent 准备支付包，钱包或自有 signer 授权真实交易，indexer 再把链上状态转成 Agent 可读状态。
安全模型
AiPay 不托管用户资金。USDC 根据签名条款和结算规则通过协议合约流转。私钥保留在钱包、Agent 自有 signer 或用户基础设施中。
V1 也避免宣称超过实际水平的去中心化。生产验证器集合是白名单，operator 可识别；用户应把每个验证规则视为一个具体服务，并理解它自己的可靠性假设。
可用性
生产 V1 包含 Polygon 托管合约、官方 operator、http_status:v1 验证器、Evidence API、Indexer API、TypeScript SDK、Python SDK 和 Safe Mode MCP server。
它不宣传 Gas 代付、主观仲裁、未注册生产验证器、多签分离或外部审计承诺。这些能力需要单独实现和验证后，才能成为产品承诺。
路线图
下一步有价值的扩展包括更多验证器类型、更清晰的开发者交接包、更强的运行隔离，以及常见 Agent 任务示例。每个新增能力都应保持机器可验证，否则就不该进入核心协议。
协议应该保持小。一个能结算真实工作的窄原语，比一个无法验证的宽泛仲裁故事更有用。