适用范围：钱包界面与治理规则不同
讨论tp钱包里的投票管理有哪些常见问题，需要先区分钱包连接界面与项目治理合约。以下解释适用于通过钱包访问的相关链上治理应用，不确认TP钱包存在某个固定入口，也不涵盖所有节点投票或其他投票模式。具体资格、计票和执行规则应以对应项目的合约为准。
有代币为什么不一定有投票权
OpenZeppelin的治理文档展示了历史快照和投票委托机制。在采用ERC20Votes的系统中，当前余额不能直接代表某项提案的有效票权，还需考虑委托及快照时点。快照之后余额或委托关系的变化，不能直接据此推定该提案票权随之改变。
理解这一问题时，应把“现在持有多少”“快照时记录多少票权”和“哪个地址行使票权”分开。钱包显示资产余额，不能单独证明连接地址具备本次投票资格。
为什么提案可见却不能投票
提案创建后可能存在投票延迟，正式投票也有截止时间。治理系统的时钟可以按区块编号或时间戳运行；发起提案还可能要求达到票权门槛。
因此，看到提案不代表投票窗口已经开放，有权参与投票也不代表有权创建提案。判断界面提示时，需要区分提案状态、投票资格与提案发起资格。
赞成票较多为什么仍未通过
通过条件与法定参与量是不同指标。例如OpenZeppelin的GovernorCountingSimple提供赞成、反对和弃权选项，其中赞成与弃权计入法定参与量。这只是特定模块的规则，不能推广到所有治理项目。
票数比较回答的是意见倾向，参与量门槛回答的是参与是否充分；只观察赞成票是否领先，可能遗漏另一项必要条件。
签名完成为什么仍没有投票记录
以太坊交易文档说明，交易需要广播并被纳入区块，执行合约还涉及Gas费用。钱包完成签名、生成交易哈希与合约成功记录投票是不同阶段；交易已打包也仍需区分执行成功或失败。
排查时可分别核对连接网络、签名地址、目标合约及交易回执。页面没有更新本身不能证明投票失败，交易哈希存在也不能证明投票成功。
提案通过后为什么没有立即生效
部分Governor系统使用时间锁，将投票通过与后续执行分开。通过代表满足治理表决条件，不一定意味着提案中的合约操作已经完成。
“已通过”“等待执行”和“已执行”应分别理解。确认结果需要同时关注治理状态与实际执行记录，不能只凭钱包弹窗或页面上的单个成功提示判断全过程结束。