ERC-2767：把合约的“主人”从一把私钥换成一台投票机器

很多合约的安全边界，说到底就是“owner 权限在谁手里”。管理员密钥能提取资金、能改参数，用户必须相信它没被盗、没被滥用。ERC-2767 在 2020 年 7 月 4 日提出一种替换方案：把 ERC-173 式的所有者位交给一台以 ERC-20 代币计票的治理合约，并给这类治理合约定一个只有两个函数的最小接口。按 ercs 仓库记录，提案状态为 Stagnant，动因段落非常具体。

两个函数解决“工具各写各的”问题

规范接口 ERC2767 要求实现 quorumVotes()——达到共识所需的票数，以及 token()——治理代币的地址，同时要求实现 ERC-165 的 supportsInterface，接口 ID 为 0xd8b04e0e，让分析工具能自动认出“这是一台治理机”。动机部分点名了痛点：Compound、Uniswap、SushiSwap 的治理合约做的事几乎一样，API 却各不相同，用户想看治理数据必须挨个访问专用页面。原文打了个类比——就像如果 ERC-20 从未定稿，每个代币项目就得自建区块浏览器。标准化这两个函数的直接收益，是任何通用工具都能填充任意项目的治理信息；代币侧复用 ERC-20 查询，现有工具天然认识选票分布。quorumVotes() 被要求消耗少于三万 Gas，因为它会被工具高频扫。

从多签治理到代币治理的推力

提案明确写了它想推动什么：鼓励大项目从多签钱包（当时常见上限五十个签名人）转向代币加权治理；鼓励已有的 ERC-173 项目把 owner 转给治理合约，因为不再有自建界面的负担。它甚至给已有一套非标准治理逻辑的项目指了一条懒路：做一个转发合约，实现这两个函数、把调用转给现有治理合约即可挂上工具——代价是转发层自身的正确性要另做保证，提案坦率承认细节超出范围。关于 token() 还可以返回合约自身地址的说明，则给了把代币与治理焊在一个合约里的项目（原文提到可用 ERC-2535 钻石模式省体积）一条出路。

停摆之后，问题还在

这份提案没有铺开，原因可以从后来的历史倒推：各项目的治理参数远不止法定人数一项——提案门槛、锁定期、Timelock 时长、策略合约地址，两个函数装不下这么丰富的语义，于是各家继续用自定义 Governor 加前端的方式存在。但对读者的提醒历久弥新：评估一个协议是否“去中心化”，先看 ERC-173 意义上的 owner 槽指向哪里。地址是个人钱包、多签，还是一台能被 token() 与 quorumVotes() 说明白的治理机，代表三种完全不同的信任结构。查不到这两个函数也不说明什么，查到了也不等于安全，把 owner 槽当第一站去扫，才是这份 Stagnant 提案留给普通读者的实用遗产。

治理合约的三项现场核验

把提案视角落到一次真实核查上，动作可以很具体。第一步，读 ERC-173 语义的 owner 槽当前指向的地址，判断它是外部账户、多签合约还是治理合约，这一步定性；第二步，若是治理合约，查它引用的 token() 是哪枚代币、持币分布是否让法定票数形同虚设——前十大地址合计逼近法定人数时，代币投票更接近走过场；第三步，看法定人数之外那些不在这份接口里的参数：提案门槛、冷静期、时间锁时长、执行权限拆分，它们才是治理质量的分水岭。三项做完，一份协议的去中心化成色大致有了画面。这份 Stagnant 提案没有改变任何链上现实，但它提醒的因果链依旧锋利：治理的标准不在于有没有投票页面，而在于谁能绕过投票改代码。

顺带厘清一个常见误读：实现这份接口不等于治理已经去中心化。quorumVotes() 只回答需要多少票，投票门槛、提案创建资格、执行路径是否还要过人治关卡，都在接口之外；代币分布若高度集中，标准接口反而让集中的权力显得更体面。把两个函数当成观察起点而非结论，才是正确的用法——它们的作用是让不同项目能在同一张表格里被比较，比较之后依然要逐项追问。

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