当我在 Pontmore 协议仓库打开 PR #12 时，我想回答一个问题：应用程序能否直接调用托管服务，而不必先经过一个交换状态机？答案是“能”，但从规范到可运行 POC，再到简化协议，这一路让我对互操作金融基础设施的设计有了超出预期的认知。

PIP-01（Pontmore 托管描述符）最初只承担一个窄用途：让代理发现适合法币到比特币交换的托管机制。它是发现工具，不是执行引擎。

PR #12 之前的描述符大概是这样的：

{ "version": 1, "escrow_type": "lightning_hold_invoice", "networks": ["bitcoin", "lightning"], "funding_rules": { "required_confirmation": "invoice_held" }, "release_rules": { "release_trigger": "counterparty_fiat_payment_confirmed" }, "dispute_rules": { "policy": "operator_resolved" } }

这段描述能告诉代理“存在这种托管，且兼容闪电网络的 hold invoice”，却不能告诉独立应用如何创建、注资、释放或取消托管。这些细节原本隐式地放在 PIP-02 的交换状态机里：想用托管，就必须先有一笔交换。没有任何路径让应用直接说：“我需要为两个人创建一个托管。”

PR #12 要解决的问题正是 Issue #11：“在 PIP-01 中定义托管服务调用方式。”解决方案是在描述符中加入一个可选的 service 块，告诉应用如何直接与托管服务通信，包括端点、认证、操作、资金模型以及释放决策格式。

由此形成的规范包含几个关键设计：传输层使用 https 作为标准传输，并预留扩展其他传输的空间；认证使用 nostr_http_auth（NIP-98），Nostr 公钥即身份，不需要 bearer token；标准操作包括 create、funding_instructions、fund_status、release、refund、split、cancel；资金模型则定义托管资金如何锁定与释放。

从发现到执行，最关键的一步是把原本只能“被看见”的托管服务变成“可调用”的服务。这让 PIP-01 不再依附于交换状态机，也让我意识到：金融基础设施的互操作性，不只是协议能发现彼此，更是协议能安全地命令彼此执行动作。