How to Review a Smart Contract Finding

Authorized scope: Use this checklist only for code you own or have permission to review. It is for defensive review and does not describe how to exploit a live contract.

1. Confirm exactly what was reviewed

Record the repository, branch or release, commit, compiler version and relevant build settings. If the deployed system uses a proxy, identify the implementation and upgrade path included in the authorized scope. A valid observation about an older version may not apply to the current deployment.

2. Check the evidence behind the alert

Exact locationDoes the report identify the same function and lines in the submitted version?

Code pathCan a reviewer follow how input and state reach the flagged operation?

Required conditionsWhich permissions, state, timing or external behavior must be present?

ReachabilityCan an in-scope caller reach that path under a realistic state?

Concrete impactWhat property could fail, and which users or assets could be affected?

Coverage limitsWhich contracts, dependencies, configurations or paths were not checked?

3. Separate confidence from severity

Confidence describes how well the evidence supports the claim. Severity describes the potential impact if the claim is true. Keep both explicit: a high-impact theory with weak evidence still needs validation, while a well-proven issue may have limited impact.

4. Validate safely and reproducibly

Use a local test environment or a controlled fork where permitted. Keep the test tied to the reviewed commit, document assumptions, and avoid transactions or changes to live systems. Another reviewer should be able to understand the test and reach the same conclusion.

5. Write a report that another person can check

State the reviewed commit, scope and tool versions.
Link each claim to a file, function and code location.
Explain the preconditions, reasoning and practical impact in plain language.
Label items as unverified, confirmed, rejected or outside scope.
List important assumptions, untested areas and recommended defensive fixes.

A clean report is not proof of safety. Automated checks can miss issues and produce false positives. State coverage limits and seek an independent review for high-impact systems.