提案不再只是一段文字：ERC-5247 的可执行提案接口长什么样

链上治理最常见的一类事故是“投票通过了什么没人说得清”：论坛里写的是 A，执行脚本里做的是 B，中间隔着人工翻译。ERC-5247 创建于 2022 年 7 月 13 日，仓库记录状态为 Review，给出的解法简单直接：提案本身必须登记为一组可执行的调用，投票的对象和执行的对象是同一份数据。

提案的数据结构

接口叫 IERC5247。createProposal 接收一组平行数组：targets 是每条调用要进的合约地址，values 是每条调用随附的 ETH 金额，gasLimits 是每条调用的 gas 上限，calldatas 是每条调用的编码后参数，另有一个 extraParams 给合约自用的附加信息，返回注册出的提案编号。换句话说，一个合格提案的全部要素在提交那一刻就被完整序列化进链上数据，任何节点都能重放它“若通过会做什么”。提交成功发出 ProposalCreated 事件，字段与入参一一对应，索引了提案人和提案编号，事件流本身就是提案登记簿。

执行与治理的边界

标准刻意只定义登记，不定义投票。executeProposal 接收提案编号和附加参数，原文说明它应由投票通过后的治理合约调用，或者在无需投票的场景由调用者触发。执行成功触发 ProposalExecuted。这套边界划出三方分工：治理合约负责“是否通过”，5247 提案合约负责“提案是什么、执行是什么”，被调用的目标合约负责具体资金与权限动作。好处是可验证性——比较两个治理系统时，不用比宣传语，直接比较提案事件的数组结构和执行路径是否一致。风险也被同样照亮：calldatas 是不可读的字节串，普通投票者需要解码器或模拟工具才能看懂每条调用，标准的透明度只对有工具的人透明。

与论坛型治理的对照

传统治理合约的投票对象经常是一个哈希：提案正文放在论坛，帖子内容哈希写进链上，防止的是事后改帖，防不了投票内容和执行内容脱节。5247 路线把顺序反过来——先有可执行数组，后附文字说明，论坛帖只是数组的人类可读注释。两条路线的审计重点也随之不同：哈希路线要核对帖子与脚本，数组路线要解码 calldatas 里每一条调用的函数签名与参数。社区工具链的职责由此清晰：块浏览器要给提案事件做解码器，钱包要在签名前展示“这笔投票通过后会自动执行哪几次调用”。对观察者而言判断标准也简单：一个治理系统的提案若无法在链上映射出完整调用清单，无论前端多精致，它仍是哈希路线的系统，透明度承诺要按哈希路线的标准评估。

编号与执行的边角

提案编号的分配也值得注意：createProposal 自带编号入参，同时返回注册后的实际编号，两者不保证相同——同一合约可能承载多个治理周期或多种提案类型，编号空间由合约自定。核对提案时以事件里的 proposalId 为唯一真相，页面上的展示编号只是转译。extraParams 同理：它给质押门槛、快照块号这类附加参数留了插槽，但也意味着同一提案编号在不同合约里的含义可以完全不同，跨系统比较提案时必须连合约地址一起比较，孤立谈某个编号毫无意义。

阅读治理系统的三条实操线

第一条线查提案登记：一个 DAO 若声称支持可执行提案，链上应能看到与 ProposalCreated 同构的事件，事件里的数组若恒为空或全部指向同一个代理，说明提案执行仍靠人工脚本。第二条线查执行权限：executeProposal 谁能调，应当只有一个治理合约地址，如果任何地址都能触发执行，通过与否的门槛名存实亡。第三条线查 gas 策略：gasLimits 由提案人自定，一条设置过低的调用会在执行时半途失败，把多步提案变成部分生效的半成品，这是可执行提案特有的执行风险，审阅提案时顺手核对每条调用的上限是否留了余量。

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