DAO 投票也能标准化？ERC-1202 投票接口的核心与刻意留白

每个 DAO 的投票合约各写各的：有的用 Governor Bravo 那套，有的自定事件名。想做一个通用的投票仪表盘，就得逐协议适配。ERC-1202 想终结这种局面——2018 年 7 月 8 日创建，直到近年仍挂在 Review 状态推进中，按 ercs 仓库记录其 requires 一栏写着 ERC-5269。一份跨度近十年的标准，值得细读它收了什么、又刻意没收什么。

核心接口只有三加一

合规合约必须实现 IERC1202Core。castVote(proposalId, support, weight, reasonUri, extraParams) 投出一票：support 是选项编号，weight 携带投票权重，理由走链下 URI，extraParams 留扩展位； payable 标记意味着投票本身可以带钱进合约。castVoteFrom 让受权人代某地址投票——注意这是执行代投，与“把票权委托给别人”的委托机制不是一回事。execute(proposalId, extraParams) 在投票期结束后触发执行环节。VoteCast 事件把投票者、提案号、选项、权重、理由和附加参数一次记全，链上计票数据从此有了统一句式。要支持多选或排序复选，合约必须再实现 IERC1202MultiVote，把标量参数换成数组版本。

四大“不在范围内”

原文单列一节写明边界，语气是有意为之。委托：明确留给另开的 EIP。资格与权重算法：像快照计权、二次投票这类计算全部不管，标准要求接口足够灵活以容纳未来算法。提案本身：提案信息在链上还是链下、要不要可执行，一概不管，提案只以 proposalId 一个数字出现，文中指向 ERC-5247 这样的提案接口。签名聚合与背书：线下收签名再上链提交的模式排除在外，指向 ERC-5453。四道门都留了邻居门牌号，这不是含糊，而是把“投票动作”与“投票制度”切干净：本文件只管你按下按钮之后链上看到什么。

为什么 requires 里是 ERC-5269

合规合约被要求配合 ERC-5269 声明“我实现的是本标准的哪一版”。原因不难理解：一份跨了近十年还在 Review 的标准，不同年份的实现必然有差异，查询方需要一个机器可读的版本自述，而不是靠猜。这也提示所有复用旧接口编号的人：接口探测解决“认不认识我”，版本声明解决“你我是同一版”。

收益清单与用例清单：七年前画的那张饼

原文列的收益清单值得完整过一遍：统一的投票接口让更多通用界面和钱包能接入，降低参与门槛；委托投票、合约投票、自动投票皆可在其上构建；结果按标准格式上链，DAO 可以程序化地承认投票结果；与 ERC-20、ERC-777 乃至 ERC-721 兼容；为其他系统留出互操作空间；支持设置截止期限、单选或多选、是否强制投票顺序——标准自己也承认这份清单的代价是接口复杂度，策略是先做 ERC-20 式的极简核心、再走 ERC-777 式的高级扩展，也就是 core 与 MultiVote 两层的由来。用例那节更具体：决定是否发行新代币或子代币、决定是否创建某个 ERC-721 条目、选举某个地址或合约担任项目与子项目的受托负责人、审计结果归属与代理地址迁移。

把它和四大“不在范围内”并排看，会看到一种自觉的分层洁癖：动作层（castVote、execute）、身份层（谁有票、多重）、文本层（提案内容）被切成三份文件，本文件只签动作层。也解释了它为什么七年停在 Review——接口本身不难产，难的是等生态先统一身份层与文本层，否则通用界面拿到的只是半张图。对治理参与者，这份标准最实用的读法是反向的：查任何 DAO 的投票合约，凡是能被通用界面正确渲染的，说明三层至少动作层对齐；界面渲染不出来的 DAO，往往问题就出在权重口径与提案文本没锚定——那才是治理争议的高发地段，而不是按钮本身。

读这份标准能带走一个判断框架：看任何治理合约，先分清动作接口（投、执行）、身份与权重口径（谁有票、按什么算）、提案文本在哪三个平面——ERC-1202 只规范第一个平面，DAO 治理的真实风险往往藏在第二、三平面。本文为机制说明，不构成任何投资建议。