先报价后签字再交割：ERC-7968 两阶段授权转账与兜底取款

想让完全不懂链的部门用代币付款，最大阻力不是钱包而是信任：资产交给谁？私钥谁管？ERC-7968 给出了一个折中模型：资产放在用户名下的存储合约里，转账由支付服务商发起提议，用户只负责在链下看一眼、签个字，手续费由服务商垫付。标准文档记录的状态为 Draft，创建于 2025 年 6 月 11 日，现状以标准仓库为准。它把”托管”拆成了保管权与执行权两层，本文逐层拆。

两个阶段、一个哈希

流程第一步叫提议：支付服务商调用存储合约的 proposeTransaction，报出代币地址、数量和收款地址，合约把这三要素存下并生成一个唯一的提议哈希，发出 TransactionProposed 事件。第二步叫确认：用户在链下（邮件、工单、App 推送，渠道不限）读到这份提议，核对无误后对提议哈希签名，签名传回服务商调用 completeTransaction(hash, signature)；合约验签名确实来自资产持有人，验过才把代币从存储合约打到提议中的收款地址，发出 TransactionCompleted 事件。每份提议自带明确过期时间，窗口内没等到签名就作废，不必链上撤销。设计意图在服务侧很清楚：不碰私钥、不碰资产保管，只提供报价、垫付 gas 与提交劳动，服务费在线下结算。

兜底函数：服务商失联怎么办

这套流程最独特的一块是 sendFundsToOwner(tokenAddress)：持有人随时可调用，把存储合约里该类型代币全额打回自己地址，并发出 FallbackScenarioExecuted 事件。它是整个信任结构的保险丝——服务商失联、行为异常、gas 行情突变导致报价不再合理，用户都能把资产直接接回自己钱包，不需要与任何人协商。规范建议此函数应可在无需服务商配合的情况下生效；评估任何具体实现时，第一件事就是读源码确认兜底路径是否真无前置条件、是否被某种管理员开关架空。配套还有 verifySignature：合约暴露纯函数让用户或服务方先行验证签名与提议参数是否匹配，减少提交后的扯皮。

与相邻机制的分界线

它常被和签名授权转账混谈，分工其实不同：ERC-3009 一系是”用户先签、服务后代提交”，授权书直接包含转账要素；7968 是”服务先提议、用户后签字”，签名对象只是合约内已登记的提议哈希，且资产始终沉淀在用户专属存储合约而非各交易对手处。对合规与风控，这一差别意味着资产位置固定、每笔流出必有链上提议事件加用户签名对应，审计链是双段的。对恶意行为者也多一道现实约束：没有用户签名，任何提议都动不了资产——反过来说，用户侧的签名纪律就是整条链的安全阀，不看内容就签，等于把两阶段设计降格成一阶段。

使用前的自检清单

接入这类服务前值得逐项确认：存储合约是否已验证、是否真按接口把持有人设为唯一收款路径；提议事件能否在浏览器按地址检索，避免”提议发生在黑箱”；过期时间的量级是否合理（太长放大泄露窗口，太短可能被抢跑挤掉）；兜底函数在你持有的每种代币上实测过小额提取。日常纪律只有两条：签字前把提议哈希还原成人能读懂的内容核对金额、收款地址与有效期；对”先签字后补内容”的请求一律拒绝。

本文只讲机制与安全实践，不构成投资建议；文中提案状态以标准仓库当前记录为准。任何冒用”授权代付”名义索要私钥或助记词的渠道都是钓鱼，与本协议无关。