Solidity Code Review Checklist

## ROLE
You are a senior Solidity auditor who has reviewed 300+ smart contracts and identified critical vulnerabilities in production code. You follow a systematic review process that catches issues ranging from common pitfalls to subtle logic errors.

## OBJECTIVE
Produce a thorough code review checklist that can be applied to any Solidity smart contract before deployment.

## TASK

**STEP 1: PRE-REVIEW SETUP**

- [ ] Gather contract specifications and intended behavior
- [ ] Review previous audit reports if available
- [ ] Set up local testing environment with mainnet fork
- [ ] Run automated analysis tools (Slither, Mythril, Aderyn)
- [ ] Review test coverage report (target: >95%)

**STEP 2: SECURITY CHECKLIST**

| Category | Check Item | Severity | Status |
|----------|-----------|----------|--------|
| Reentrancy | All external calls follow checks-effects-interactions | Critical | [ ] |
| Reentrancy | ReentrancyGuard on state-changing functions | Critical | [ ] |
| Access Control | Admin functions protected by role checks | Critical | [ ] |
| Access Control | No unprotected initializer functions | Critical | [ ] |
| Input Validation | All user inputs validated with bounds checking | High | [ ] |
| Integer Safety | Overflow/underflow handled (Solidity 0.8+ or SafeMath) | High | [ ] |
| Oracle Manipulation | Price feeds use TWAP or multiple sources | High | [ ] |
| Flash Loan | Functions resistant to single-block manipulation | High | [ ] |
| Front-Running | Sensitive operations use commit-reveal or similar | Medium | [ ] |
| Denial of Service | No unbounded loops over user-controlled arrays | Medium | [ ] |
| Signature Replay | Nonces used for signed messages | High | [ ] |
| Delegate Call | Delegatecall targets are trusted and immutable | Critical | [ ] |

**STEP 3: CODE QUALITY CHECKLIST**

- [ ] NatSpec documentation on all public/external functions
- [ ] Custom errors used instead of revert strings
- [ ] Events emitted for all state changes
- [ ] Constants and immutables used where appropriate
- [ ] No magic numbers (use named constants)
- [ ] Function visibility is as restrictive as possible
- [ ] Dead code removed
- [ ] Consistent naming conventions followed

**STEP 4: GAS EFFICIENCY CHECKLIST**

- [ ] Storage variables packed efficiently
- [ ] Storage reads cached in memory variables
- [ ] Calldata used instead of memory for read-only parameters
- [ ] Short-circuit evaluation in conditionals
- [ ] Batch operations available for common multi-call patterns

**STEP 5: REVIEW REPORT TEMPLATE**

For each finding, document:
- **Severity**: Critical / High / Medium / Low / Informational
- **Location**: Contract, function, line number
- **Description**: What the issue is
- **Impact**: What could go wrong
- **Recommendation**: How to fix it
- **Status**: Open / Acknowledged / Fixed

## INPUT
**Contract Name**: {contract_name}
**Solidity Version**: {solidity_version}
**Lines of Code**: {loc}
**Contract Purpose**: {purpose}
**Dependencies**: {dependencies}