Aragon 持有治理代币却不能投票：核对快照、委托与投票模式
链小知 · 进阶 · 核验 · 依官方文档整理
用已有提案 ID、插件合约和投票账户查明票权缺口，按 v1.3 block 快照或 v1.4 token clock 分支读取，避免用当前代币余额判断历史票权。
开始前准备
- 准备 DAO 所在网络、DAO 地址、Token Voting 插件地址、已有 proposal ID 和待核对的完整投票账户地址；可从 DAO 页面、提案创建事件或既有合约记录取得。
- 使用区块浏览器的 Read Contract、DAO 应用已有只读信息或已导出的 ABI 查询结果；不输入恢复秘密。没有只读入口或匹配 ABI 时保留字段未知，不调用 vote/createProposal/execute。
- 本教程的 v1.3 源码固定为30b1218…，v1.4 为5bf1ead…；先确认部署版本。文档核验不代表已验证某个实时 DAO 的票权。
1. 先锁定链、插件和真实提案
在 DAO 应用或区块浏览器打开插件完整地址，核对网络和提案创建记录中的 proposal ID。用匹配 ABI 的 getProposal(id) 读取 parameters、open、executed 和 tally；ID 是此插件内的整数标识，不能把交易 hash、另一个 DAO 的编号直接填入。
v1.3 的 getProposal 可返回默认字段，并不单独证明编号存在。若没有对应创建记录，或 canVote/canExecute 返回 NonexistentProposal，回查地址和编号，不把一组零值解释为“还没开始”。
检查结果：网络、插件、提案创建记录与 ID 一致；缺失或错误编号已排除。
2. 确定快照使用块高还是时间
查看目标插件版本及该提案 parameters。确认 v1.3 时读取 snapshotBlock：创建时取前一块，后续买入不能修改这个快照。v1.4 固定源码使用 snapshotTimepoint；只有确认部署 ABI 和 tokenIndexedByTimestamp 后，才决定它是前一秒还是前一块。
1.x 导入代币帮助页写仅支持 block 快照，而新版源码增加 CLOCK_MODE/clock 检查。这是版本差异；不要把 Unix 秒填入旧版 snapshotBlock，也不要按块高换算 timestamp token。部署版本未知时，先取得正确 ABI 和插件版本记录。
检查结果：快照原始值与单位已注明，并有目标版本依据；未知版本不推算票权。
3. 读取治理代币的历史票权
用 getVotingToken() 确认插件实际治理代币地址，打开该地址的只读方法。以投票账户和上一步快照调用 getPastVotes(account,timepoint)，对照 getPastTotalSupply(timepoint) 或插件 totalVotingPower(timepoint) 的已有结果；保留完整原始整数。
钱包里同名币、底层币或当前 balanceOf 都不能替代这笔历史票权。票权为零时检查提案创建前是否已委托、是否持有正确包装治理代币，以及代币是否具备 Votes 接口。无需为了排查先包装、转币或发送 delegate 交易；若历史委托/包装记录不存在，原因保留待查。
检查结果：票权来自正确 token、正确账户与正确时间点；余额、包装资产和历史委托没有混用。
4. 排除投票时段和重复投票
读取 parameters.startDate/endDate、open 和 executed，对照网络当前时间或已有链上记录时间。v1.3 的开放条件是 startDate≤链上时间<endDate 且尚未执行；因此 open=false 还可能是未开始、已结束或已执行。
再用 getVoteOption(id,account) 看已有选择，并核对提案保存的 votingMode。Standard（页面称 Normal）或 EarlyExecution 不允许把已有票随意覆盖；VoteReplacement 才允许替换。None 只表示没有记录选项，不能证明账户一定有票权；不根据电脑本地倒计时单独判定开放。
检查结果：时段、执行状态、模式和历史投票分别记录，已投与无资格不再混为一项。
5. 用明确选项核对 canVote
在只读接口输入同一 id、账户和期望选项调用 canVote：v1.3 枚举1=Abstain、2=Yes、3=No，0=None 不是可投选项。true 是该读取状态下的资格判断；false 时按快照零票权、关闭时段、已投且不可替换逐项回查。
把输入、输出、网络、读取时间与版本写在同一记录。合约调用报错或 ABI 解码失败不能补成 false；更不能把 canVote=true 写成“已经投票成功”。若使用新版或定制插件，枚举和判断须依其 ABI/实现重新确认。
检查结果：有可复核的输入和资格结果；错误、false、尚未投票三种状态明确分开。
6. 确认排查结论与后续动作边界
将结论写成具体缺口，例如“当前余额有币，但该 proposal 快照 getPastVotes 为零”或“已有 Yes，Standard（Normal）模式不能替换”，并附支持它的历史记录。若问题只涉及创建提案权限，另查 CREATE_PROPOSAL_PERMISSION；这不等于投票资格。
如需实际投票、委托或包装，应在对应 DAO 的可信应用中重新核对网络、方法和 gas 报价，并检查最终投票记录。本排查流程的完成依据是字段与原因对应，不能以模拟或 canVote 代替签名/投票回执。
检查结果：结果列明已证原因、缺失资料及下一步需核对的方法；尚无交易回执不标已投。
怎样确认完成
- 形成链、插件、proposal ID、账户、token、快照单位、历史票权、时段、模式和 canVote 结果的核对记录。
- 无法取得目标部署 ABI、历史记录或实时读数的字段保持未知。来源为官方文档与固定源码；未实测钱包投票、委托或包装。
常见错误与边界
- 拿现在的余额或创建提案权限当历史投票资格。
- 把 v1.4 源码的 timestamp clock 推到 v1.3 部署，或混淆块高与 Unix 秒。
- 将 None/false/调用错误都解释为没有投票权；只读 true 也不代表已投。