「我把票委托给老张，老张把他的票委托给了一个大机构，那我的票是不是也跟着到了大机构手里？」这是委托治理里最常见的一个直觉错误。多数主流实现里，答案恰恰是否定的：委托关系不会自动传递，链上的票权归属只认一个规则——每个账户的余额算在该账户当前设定的受托人名下，仅此一跳，不再往下接。
把规则说透。以常见的投票权模型为例：任何地址在合约里都有一个「我把票给谁」的记录，默认指向自己。合约计算某个代表名下有多少票时，做法是把这些「记录指向该代表」的地址的余额全部加起来。你的地址记录的是老张，你的余额就进老张的池子；老张自己的地址记录的是某个大机构，那老张自己的币进大机构的池子。你的票权不会出现在大机构名下，因为合约从头到尾没有「受托人的受托人」这个概念——它查的永远是每个账户自己的那一条记录，而不是沿着链条往下追。
为什么这样设计。如果委托可以层层叠加传递，会出现两个工程与权力结构上的麻烦。其一是归属模糊：链条越深，普通持有人越难知道自己的票此刻正在被谁使用，一个转手链条的末端可能是个从不亮相的地址。其二是更新风暴：转委托链上任何一环改了主意，整条链下游所有人的票权同时搬家，而多数持有人根本不会收到提示。单层实现把关系压成「一对一、随时可改、改即生效于下一快照」，复杂度低，问责路径短：票在谁名下，就是谁的行为，找不到中间环节可以甩锅。
但单层模型也有它自己的坑，最常见的是把委托理解成「加入某个组织」。你委托给老张，老张随后把自己的币卖光并转委托给别人，你在合约里看到老张名下的总票数缩了，很容易误以为自己的票丢了。其实你的那一份一直都在，缩掉的是老张自己的部分。两个方向都容易看错，所以核对应从链上原始读数出发：对任意地址查 delegate 接口，能确认它当前的票权指向；对某个代表查 getCurrentVotes 之类的读数，能确认此刻计在他名下的总票权。两边交叉，才能判断「我的票到底算在谁头上」，而不是靠对社区身份的想象。
第二类坑来自时间。委托记录改了，票权却不一定立刻改。多数计票实现按历史快照工作：投票从某个区块开始计票，此后你改委托，影响的是下一次快照，不是这一场正在投的票。于是出现一种让人困惑的场面——你明明上午十点撤销了对代表的委托，下午他投出你不赞成的票，而且用的是你的那份权重。原因是提案的快照点在你撤销之前。委托关系是实时的，计票权重是刻舟求剑的，两者各自诚实，合在一起就像出了 bug。参与关键投票之前，先把快照区块号查出来、和你要不要先改委托放在一起决定，是委托治理里少有的、纯靠细心就能占到的便宜。
第三类情形更特殊：确实存在允许「代表转委托」的变体实现，也就是受托人有权把他名下的部分票权再分配给第三方，同时保留或放弃自己那一票的投法。这类系统的语义与默认代币模型不同，且转委托后的计票规则千差万别：有的只转移计票数量不转移实际投票人，有的连投票权一起移交。判断自己身处哪种模型，最可靠的办法是读项目官方治理文档里对委托语义的定义，再到治理界面上验证一次：给代表委托一笔测试量，看第三方名下的读数有没有同步变化。读不懂文档就不要在权重大的提案上依赖委托，这条保守纪律在高价值投票里成本几乎为零。
实操层面还有三件小事值得养成。第一，改完委托后去浏览器里看一眼委托事件确实写进了链，而不是只信前端弹窗；第二，在钱包或表格里维护一张「地址—当前受托人—变更日期」的清单，地址多了以后凭记忆必然出错；第三，若你的持仓分布在多个地址，逐一核对每个地址的委托指向，漏掉一个未委托的地址，等于那一票永远缺席。委托是链上治理里最轻的操作，也最容易因为太轻而被做错。票权归属的最终事实只存在于合约状态里，本文讲的判定规则以主流实现为例，具体协议以官方文档和合约为准；参与治理不涉及资产损益承诺，也不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。