链上投票也想过标准接口：ERC-1417 的 Poll 草案

每种治理都在重新发明投票按钮

看十个协议的治理前端，会看到十套”投票”的读法：有的把选项写进合约枚举，有的把结果挪到链下签名统计，有的把权重挂在 ERC-20 余额上，有的靠快照。第三方仪表盘、审计脚本、钱包提示要为每个项目写一套适配。ERC-1417（Poll Standard）在 2018 年 9 月起草，目标是给”投票合约”定一门公共语言：无论背后规则多不同，外面的人至少能用同一组函数问到名字、计票、领先项。

接口清单

标准合约必须同时实现 ERC-165 的接口探测，接口标识为 0x4fad898b。核心函数可以按三组读。读状态的一组：getName 取投票名称、getPollType 取类型描述、getProposals 列出选项名称（规范注释为实务原因把选项数压在 32 个以内）、winningProposal 给出当前领先项。查资格与计票的一组：canVote 判断某地址此刻能否投票、calculateVoteWeight 计算个体权重、getVoteTally 与 getVoterCount 分别给累计权重与投票人数——两个数分开是关键设计，一个衡量”票数重量”、一个衡量”参与人头”。动作的一组：vote 按选项编号投票、revokeVote 撤回自己的票。

事件同样分三类：CastVote 记录成功投票，RevokedVote 记录撤回，TriedToVote 专门记录”想投但被拒”。最后一个事件是审计利器：若管理员事后移除投票资格，观察者仍能凭 TriedToVote 重放”若无移除，结果会如何”。配合按地址挂属性的 ERC-1261 做资格判定，是这个草案的推荐搭配。

为什么停在 Stagnant

标准想统一的是按钮形状，而治理创新恰恰发生在规则层。后来几年的主流演化方向是：代理投票、分区投票、延后揭示、把计票挪到签名聚合与快照里——每一项都让”vote 函数即投票”这个抽象更名不副实。再加上治理界面快速品牌化，项目方没有为兼容性牺牲差异化的动力。于是 ERC-1417 的接口留在文档里，状态标注为 Stagnant——一种长期无人推进但也未正式否决的中间态。

对用户仍然有用

即便没有落地成通用标准，这套接口清单是一份极好的尽调提纲。一个成熟的链上投票合约，应当能回答五个问题：谁有资格（canVote 的逻辑是什么、快照点在哪）、一人多少票（calculateVoteWeight 用余额还是质押还是属性）、能否反悔（revokeVote 会不会留痕）、失败尝试是否可见（TriedToVote 之类）、领先项怎么定义（winningProposal 的判定规则）。读不到答案的治理，比读到陌生接口的治理更值得警惕。

一个具体到接口层的例子

假设两个协议分别部署了投票合约，你作为普通持有人想确认”我的票到底有没有算上”。协议甲的合约暴露 votesOf(address)，协议乙的只记录事件不存查询函数——前者一条链上读调用就能验证，后者要你自己扫全链日志重建账本。ERC-1417 想消灭的正是这种体验差：哪怕计票规则千差万别，“查询当前领先项""查询我能否投票”这两个动作的函数名和返回值形状先统一，区块浏览器和钱包就能给所有治理项目写同一套投票面板。类比现实：接口规范类产品从来不规定设备做什么，只规定插头长什么样——统一的是接触面，不是功能。

顺带一个实操细节：投票合约地址通常由项目方的治理页面给出，把它抄进区块浏览器逐函数看一遍，比读十篇项目解读更能看清规则——canVote 依赖哪个快照、calculateVoteWeight 读的是哪个代币的余额，都在函数体或它引用的存储里写得明明白白，而前端页面往往只把最顺眼的一句留给你。

状态提醒

Stagnant 意味着这套接口不是任何钱包或协议的前置条件；看到某个工具声称”遵循投票标准”时，应该去查它实现的是哪组函数、哪些字段是真在链上、哪些只是前端展示。本文只讨论协议机制，不构成任何投资建议。