适用范围：积分记录不等于股东资格
“区块链积分股东系统”并非统一的技术标准。本文仅讨论使用智能合约记录积分、控制相关操作权限的系统。合约中的余额、角色和投票功能，是技术层面的状态与能力；不能仅凭系统名称或链上积分，认定持有人具有法律意义上的股东资格。
谁能增加、扣减或冻结积分
常见问题是前台限制了操作入口，合约却没有核验调用者权限。公开可调用的函数如果涉及积分增发等敏感行为，需要在合约内部进行授权检查，不能只依赖后台页面隐藏按钮。
以太坊智能合约安全文档强调访问控制、操作条件校验及多种测试手段。对应积分系统，应分别明确谁能发放积分、修改规则和处理异常，并检查越权调用是否会被拒绝。
管理员权限是否过于集中
OpenZeppelin访问控制文档区分单一所有者与角色授权，并提醒默认管理员具有较高风险；所有权交接可采用接收方确认机制，多签也可用于管理合约。
角色名称不同，不代表控制权已经分散。如果同一个账户能授予所有角色，它仍可能间接控制关键操作。评估时应关注角色的授予、撤销和管理关系，以及密钥失效后的交接安排。多签能够增加审批约束，但不能替代明确的职责划分。
规则完整，为什么仍会出现记账错误
业务规则需要转化成可检查的执行条件。例如，扣减是否允许超过余额，发放是否受总量约束，异常输入是否会被拒绝。这些属于设计检查项，不代表所有系统都存在对应缺陷。
还应区分单次操作正确与连续操作正确：一次发放测试通过，不足以证明重复调用、角色变更后调用或边界输入下仍然正确。关键约束应覆盖不同操作顺序，而不只是正常流程。
通过审计是否意味着没有风险
审计是额外的独立检查，不是安全保证。单元测试、随机输入测试和静态分析可以互相补充；形式化验证也只对明确建模的性质和假设提供证明，不能据此宣布整个业务系统没有问题。
上线后能否修改或停止运行
已部署合约不能像普通后台程序一样随意修改。是否支持升级、暂停或权限恢复，取决于预先设计的机制。具备这些机制的系统，需要说明谁能触发、影响哪些操作；不具备时，则要明确故障处置的限制。判断系统是否可靠，应看实际权限与执行规则，而不是仅看“上链”或“不可篡改”的宣传。