ERC-6506 托管治理激励：先用真金白银赌你投票，再凭投票记录来取

DAO 治理有一种灰色玩法：大户拿钱收买投票方向，投票结束、钱货两讫，链下承诺不留痕迹。2023 年 2 月 15 日创建的 ERC-6506 反手把这种结构搬上了链：想激励谁按某个方向投票，先把资金托管进合约，投票完成后凭可验证的投票记录来领，对结果有疑问还能发起链上争议。这份标准现在的状态是 Stagnant，本文按原文拆它的七函数结构。

承诺与揭晓：激励先押进合约

接口叫 IEscrowedGovIncentive。起点是 incentive 函数——更准确说是 incentivize，带一个 bytes32 的激励编号和一段激励信息，可支付：承诺方把资金连同激励条款（激励哪个提案、什么投票方向、金额多少）锁进合约，编号是整场游戏的句柄。领取走 claimIncentive，参数里的 reveal 是揭晓数据，标准明文要求：reveal 内容与激励编号所承诺的数据不一致就必须回退；资金到不了账也必须回退。这里还有个细节例子：Alice 向 Bob 承诺一百美元激励，Bob 授权 Eve 代领、分成百分之五，函数只检查 Bob 与 Eve 合计收到不低于一百美元，不要求 Bob 本人独享全额——代领关系通过 modifyClaimer 建立，claimIncentive 的权限检查同时认本人和被授权者。没人来领怎么办？承诺方可以用 reclaimIncentive 按规则收回，同样要提交揭晓数据。

验证与争议：把“他真投了吗”写成函数

整套机制的支点是一个视图函数 verifyVote：传入激励编号与投票信息，返回这条投票是否可验证、附带证明数据。投票方向、投票权重这些事实要能从目标治理系统里读出来，claimIncentive 会调用这类验证，验不过且没有定义争议流程时直接回退。争议通道是 beginDispute 与 resolveDispute：任何符合条件的参与方可以支付发起争议，解决函数返回争议是否被驳回，驳回与否决定资金最终流向领取人还是退回承诺人。原文在接口注释里给争议解决机制留了参数位，具体裁决逻辑——交给预言机、法庭类合约还是委员会——由实现方注入。

承诺与揭晓各守一头

接口参数全是承诺—揭晓结构：激励编号是一个哈希承诺，领取时的 reveal 数据必须与承诺内容吻合，否则函数直接回退。承诺先写进链上，激励条款——对应哪个提案、什么方向、多少钱——在揭晓前就被钉死，承诺方不能在开票后临场改口；条款细节又不到揭晓不落全公开，双方都不能从公开的链上参数里提前反推。争议函数可支付地发起，说明设计者预期轻率争议要有成本，而裁决依据交给实现方注入，预言机、法庭合约还是委员会，标准刻意保持中立。

Stagnant 状态为何仍值得读

按 ercs 仓库记录，这份标准停在 Stagnant，几乎没有人部署过它。它值钱的地方在思路：治理投票一直是链上事实、激励一直是链下默契，两者中间那段空窗养出了收买与赖账两个物种。ERC-6506 把这段空窗压成三段代码——承诺即托管、领取即验证、分歧即仲裁——给“花钱投票”这件灰色事务装上了可审计的透明壳。这个设计同时把代价摊在桌面上：投票方向的资金激励被链上公示后，游说从私聊变成明码标价的市场，这对治理究竟是净化还是拍卖，标准不回答，现实也没给出样本。读者从这份停滞提案里能带走一个核查视角：任何承诺投票回报的机制，先问资金托管在哪、投票验证接的是哪个数据源、争议裁决权在谁手里。三个问题若都落在链上合约，它就值得当作机制读；若答案散落在社群公告和私聊记录里，它更接近旧世界的收买剧本，只是换了句术语。

本文为机制说明，不构成任何投资建议。