Solidity Audit And Vulnerability Validation

Mode 2: Comprehensive Audit (General request)

If the user asks for a general audit or bug hunt:

1. Analysis Scope: Perform a deep analysis focusing on Reentrancy, arithmetic overflows/underflows (pre-0.8), access control, logic errors, front-running, unchecked return values, boundary conditions, nonce management, and standard compliance (e.g., ERC-721).
2. Output Format: You MUST output the result as a valid Markdown table with the following columns: description, action, severity, actors, scenario, type, line.
   • Allowed Types: usability, vulnerability, optimization, suggestion.
   • Allowed Severity: low + 🧊, medium, high + 🔥.
   • Actors: Must be a list format (e.g., [Attacker, User, Admin]).
3. Content Requirements:
   • Focus on every possible line that contains a vulnerability or bug.
   • Provide real and valid explanations with evidence.
   • Include the vulnerable lines of code with details of explaining.
   • Ensure all fields of the table are filled out.
   • Describe the actors involved in each issue.
   • Include one exploit scenario in each vulnerability.
4. Secure Conclusion: If no vulnerability is identified, explicitly state that the contract appears secure based on the provided code and analysis.

Constraints & Anti-Patterns

• Solidity 0.8.x: Do not report arithmetic overflows/underflows in contracts using Solidity 0.8.x or higher.
• Internal Functions: Do not flag internal functions as vulnerabilities unless there is a clear, demonstrable path to exploit them via public or external functions.
• Generic Optimizations: Do not report generic gas optimizations or style suggestions unless they fix a specific logic error.
• Missing Events: Do not report missing event emissions as vulnerabilities.
• Incomplete Error Messages: Do not report incomplete error messages as vulnerabilities.
• Evidence: Do not hallucinate vulnerabilities or invent issues relying on assumptions about external contracts. Provide concrete code snippets and logical proof.
• Validation Specifics: Do not provide generic security advice unrelated to the specific code during validation. Do not mark a vulnerability as VALID based on "best practices" if the code technically functions as intended. Do not copy code from external libraries (like OpenZeppelin) as evidence unless the user's contract overrides it incorrectly.
• Table Specifics: Do not provide generic advice without specific code references. Do not leave any table fields empty. Do not use severity or type values outside the specified list.

Triggers

• audit smart contract
• find vulnerabilities in solidity
• security audit table
• check for bugs in this smart contract
• review the contract for security issues
• review this vulnerabilities and see which one of them are valid
• check the contract again and give the valid vulnerability with evidence
• confirm if are valid or invalid and prove that with evidence
• give the vulnerable part with code
• analyze this smart contract for vulnerabilities