合约状态与资产流转
按范围检查状态变化、外部调用、记账、领取、费用与失败条件。
围绕确定发布版本的合约审查
审查团队准备发布的，那个合约版本。
按约定范围评估合约逻辑、管理权限、升级方式和业务状态变化。把问题与复测结果对应到确定代码版本，为发布决策保留清楚的证据。
01
可以检查哪些部分？
在工作说明书中明确代码版本、合约、目标环境、检查方法和不包含的工作。
角色、升级与紧急操作
梳理管理账户、所有权变更、代理与紧急控制，并按范围检查存储布局和升级假设。
应用与交易边界
钱包操作、API 权限和索引假设，仅在审查范围明确包含对应组件时纳入。
02
让工程团队能够处理的问题记录
事先约定报告格式，以及修复和发布检查需要的证据。
带代码引用的问题
说明受影响版本、问题条件、影响、复现或测试证据，并给出修复建议。
处理优先级与未解决风险
将提出的改动对应到具体问题，记录接受的限制、未解决事项和负责人。
补丁验证记录
记录复测提交版本、相关测试与结果，区分已验证修复、仍未解决和范围外的问题。
03
审查为发布决策提供依据
生产发布批准和管理账户操作，由客户确认与负责。
范围审查不是安全保证
审查针对约定版本、方法与环境，不能证明不存在任何漏洞，也不能代替后续代码变更的检查。
工具辅助有证据的判断
自动化检查与 AI 辅助分类可帮助发现待核查事项，工具输出经评估并对应证据后，才形成问题结论。
持续支持另行约定
监控、事件响应、独立认证和未来版本的持续审查，只有明确写入范围才包含。
DappWeb 自有产品参考
先查看公开材料，再讨论与项目范围有关的证据。
开发与合作常见问题
沟通范围与报价前，先了解交付方式。
审查可以保证协议安全吗？
不能。报告记录约定范围、代码版本、问题、复测结果和限制。公开网站或部署本身不等于独立安全认证。
修复后可以复测吗？
可将补丁复测纳入范围，明确更新后的提交版本、重复检查项，以及每个问题关闭或保留所需的记录。
询价前需要提供什么？
提供代码仓库与确定提交版本、合约清单、目标链、已部署地址、管理权限、升级方式和发布目标，不要发送凭证。
把需求变成清楚的开发范围
告诉我们业务流程、现有系统和时间安排，开始评估。