任务报酬锁进合约等验收:ERC-1081 标准赏金的发行、交付与接受三步 图 1
任务报酬锁进合约等验收:ERC-1081 标准赏金的发行、交付与接受三步 · 图 1

任务报酬锁进合约等验收:ERC-1081 标准赏金的发行、交付与接受三步

“做完事再付款”在链上怎么表达?ERC-1081 给任务型报酬定了一套合约接口,把自己叫作标准赏金。它的文件头记录创建于 2018 年 5 月 14 日,仓库记录状态为 Stagnant,声明依赖 ERC-20。作者的出发点写在摘要里:让赏金跨平台可互操作,也方便追踪声誉指标——比如一个发单方是否按期付款、交付方的作品是否常被接受。

三步骨架

规范说,研究了数千年的赏金实践并在主网处理了三百多单之后,总结出每个赏金都逃不开三步:发行,由 issuer 写清任务要求和报酬;交付,fulfiller 提交成果,成果哈希应当不可篡改地存在链上,作为事后凭证;接受,由 issuer 或仲裁方 arbiter 选定一份或多份交付,同时把报酬释放给交付方、把成果所有权转给发行方。注意第三种角色:仲裁方可以不是发单方本人,这是整套机制里信任设计的关键位。

任务报酬锁进合约等验收:ERC-1081 标准赏金的发行、交付与接受三步 图 2
任务报酬锁进合约等验收:ERC-1081 标准赏金的发行、交付与接受三步 · 图 2

三个核心函数

发行环节是 initializeBounty(address _issuer, address _arbiter, string _data, uint _deadline)。它在新合约部署时调用,规范特别说明它在代理模式下特别有用——代理模式没法在构造函数里完成初始化。data 字段约定为一个指向 IPFS 上 JSON 的哈希,格式遵循标准里的 schema。

交付环节是 fulfillBounty(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data)。这里藏着一个设计演化:最初交付只能由单人提交,但用户反复表达协作需求,于是接口改成信用可以分给多方——每位交付者的份额用分子数组和公共分母表示,钱沿这条线拆。规范还直白地提到,赏金平台可以把自己也算进协作方,从中收取一小笔撮合费。

接受环节是 acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts),由 issuer 或 arbiter 调用,用一组代币和一组金额把这笔交付结清。规范强调这个结构允许赏金余额随入金浮动,也允许一个赏金的余额拆给多份交付。相关的还有 drainBounty,让发行方在必要时把合约里的钱撤走。

围绕这些还有 changeBounty、changeIssuer、changeArbiter、changeData、changeDeadline 一组改字段的函数,权限都归 issuer——换句话说,任务要求与截止期在交付进行中是可以被发单方改的,这一点买卖双方都应当事先看清。

可选函数解决两个现实问题

acceptAndFulfill 让发行方替交付方一次性完成“提交并接受”。动机写得很具体:新交付者不想先掏 Gas 干活,由 issuer 代签代付,链上仍然不可篡改地记录了代币与成果的交换,但交付者无需在拿到收入前先持有 ETH。

另一对是 refundableContributerefundContribution:注资者给赏金捐钱时可以带上“可退”选项——如果赏金过期仍未向任何正确交付付款,注资者可以把钱取回。非退还的注资则只需把代币直接转进赏金地址。

动手核实的四个点

把这份规范变成尽调动作,清单是四条。一核合约形状:在浏览器里比对函数列表是否与 initializeBounty、fulfillBounty、acceptFulfillment 这套签名一致,形似神不似的包装要警惕。二核 arbiter:仲裁地址是个人钱包、多签还是又一个合约,它单方面决定钱最终给谁。三核 data 指向的链下文件:验收标准、交付格式、争议处理都写在那份文件里,链上只留哈希。四核余额与变更历史:changeBounty 一族函数意味着任务要求和截止期可以被发行方改动,事件日志里谁在什么时候改过什么,全部可查。四项都不需要权限,读公开数据即可完成。

与托管、与 NFT 的边界

赏金合约本质上是一种带验收逻辑的托管:钱先进合约,验收通过后释放。它和一次性托管的区别在仲裁角色与交付凭证结构;和 NFT 质押、版税这些机制则完全没有交集,只是因为都涉及“合约里的资产等条件成立”而容易被混谈。看任何自称实现 ERC-1081 的合约时,值得核对的是:合约代码是否真是这套函数形状、arbiter 地址是谁、data 指向的 IPFS JSON 写了什么验收标准——链上只保证资金与交付哈希的交换过程,交付质量本身仍然落在合约外的 schema 和仲裁判断里。

最后是状态:Stagnant 意味着这份标准在仓库记录中已长期停滞,当年的参考实现当年也自述未经审计、不鼓励在主网承载资金。今天读它,更多是理解“任务报酬上链”这一类结构的最早几种答案长什么样,而不是把它当作当前部署的推荐选项。本文为机制说明,不构成任何投资建议。