State Validation Auditor

When to Use

• •Auditing Solidity contracts for input validation and state management vulnerabilities
• •User mentions: ownership, transfer, validation, access control, array length, return value, initialize, onlyOwner, pause
• •Analyzing administrative functions, multi-step processes, array operations, access-controlled operations
• •Reviewing state transitions, ownership mechanisms, authorization checks

Audit Workflow

IMPORTANT: Announce skill usage at the start of analysis

Begin with: "I'm using the audit-state-validation skill to analyze this contract for state management and validation vulnerabilities..."

1. •

   Scan for validation-critical operations

   • •Search: transferOwnership, onlyOwner, initialize, function parameters (arrays, IDs, addresses), .call, .transfer, external function calls
   • •Focus: ownership transfers, access control modifiers, array operations, return value checks, pause mechanisms
2. •

   Check against vulnerability patterns

   • •Reference reference.md for complete checklist
   • •Compare code against example.md
3. •

   Validate exploitability

   • •Can attacker brick ownership or bypass access control?
   • •Can state be corrupted via invalid inputs?
   • •Verify no compensating validation in caller functions
4. •

   Generate report

   • •Use deliverable template below
   • •Include PoC for each finding
   • •Rank by severity

Core Vulnerability Patterns

See reference.md for full checklist. Key patterns:

1. •Unchecked 2-step ownership transfer → ownership bricked via address(0)
2. •Unexpected matching inputs → bypassed validation (swap(tokenA, tokenA))
3. •Unexpected empty inputs → bypassed logic (arrays/zero values)
4. •Unchecked return values → silent failures, state inconsistencies
5. •Non-existent ID manipulation → default values corrupt state
6. •Missing access control → unauthorized critical operations
7. •Inconsistent array length validation → OOB errors, state corruption
8. •Improper pause mechanism → users prevented from self-protection

Code examples: See example.md

Severity Criteria

Critical: Ownership bricking via address(0), missing access control on fund transfers/withdrawals, state corruption enabling fund extraction by non-privileged actors High: Unauthorized state manipulation by external actors, ID corruption, array length mismatches causing DoS or incorrect state updates, MUST be exploitable by non-privileged actors Medium: Input validation bypasses in edge cases, unchecked returns without immediate impact, pause mechanism issues, admin-only validation issues with cascading user impact Low: View function validation issues, documented design choices, admin-only parameter validation without user impact, no security impact

IMPORTANT: Admin-only setter functions (onlyOwner, onlyAdmin, onlyGovernance) with missing validation are MEDIUM or LOW severity unless:

• •Invalid parameters directly brick critical user functions
• •Missing validation enables admin to rug pull or extract funds (governance attack)
• •Error in admin function cascades to affect all users immediately

False Positives - Do NOT Flag

• •OpenZeppelin Ownable2Step (already secure 2-step implementation)
• •Identical input validation in wrapper/library functions with explicit comments
• •Unchecked returns in view/pure functions (no state change)
• •Admin-only setter functions (onlyAdmin, onlyOwner) with missing bounds checks unless they brick user operations
• •Admin-only parameter validation where admin is trusted and error doesn't affect users immediately
• •Intentional permissionless functions (explicitly no access control)
• •Array length checks in external caller functions (defense in depth acceptable)
• •Admin functions with trust assumptions documented in comments

Deliverable Format

MANDATORY: Before deliverable, verify each checklist.md item against codebase. Flag violations as findings.

Use template: templates/report-template.md

Each finding includes: severity, pattern #, file/lines, description, vulnerable code, impact analysis, PoC showing exploitation, remediation, gas impact.

Key Principles

• •Defense in depth - validate all inputs, check all returns
• •Explicit over implicit - require statements over assumptions
• •Fail-safe defaults - revert on invalid state rather than silent corruption
• •Access control everywhere - protect all state-changing functions appropriately

Output Guidelines

DO:

• •Reference specific lines and functions
• •Provide executable PoCs showing state corruption or unauthorized access
• •Quantify impact (funds at risk, protocol DoS)
• •Suggest specific modifiers (onlyOwner, onlyRole) but note generic pattern

DON'T:

• •Report style issues without exploit path
• •Flag intentional designs documented in comments
• •Use vague terms ("could be vulnerable")
• •Ignore context (caller validation, external protections)