1. IDENTIFY BLOCKCHAIN PLATFORM:
   - Ethereum/EVM (Solidity, Vyper)
   - Solana (Anchor, Native Rust)
   - Cosmos (CosmWasm)
   - Near Protocol (AssemblyScript, Rust)
   - Cardano (Plutus, Haskell)
   - Other L1s/L2s (Avalanche, Polygon, BSC, Arbitrum, Optimism)

2. IDENTIFY PROTOCOL TYPE:
   - DeFi AMM/DEX (Uniswap-style, Curve-style, Order Books)
   - Lending/Borrowing (Compound-style, Aave-style, P2P)
   - Derivatives/Perpetuals (Options, Futures, Synthetic Assets)
   - Yield Farming/Staking (Liquidity Mining, Validator Staking)
   - Cross-chain/Bridges (Asset Bridges, Message Passing)
   - NFT/Gaming (Marketplaces, Games, Metaverse)
   - Governance/DAOs (Voting, Treasury Management)
   - Insurance/Risk (Coverage Protocols, Risk Assessment)

3. APPLY TYPE-SPECIFIC AUDIT TRICKS:

1. IDENTIFY AUDIT SCOPE:
   - What smart contracts are in scope? (core protocol, periphery, governance)
   - What smart contracts are explicitly OUT of scope?
   - What blockchain networks are targeted? (Ethereum, Polygon, BSC, etc.)
   - What deployment phases are being assessed? (testnet, mainnet, upgrades)

2. DETECT AUDIT TYPE:
   - DeFi protocol audit (AMM, lending, derivatives, yield farming)
   - Token implementation audit (ERC-20, ERC-721, ERC-1155)
   - Governance system audit (voting, proposals, treasury management)
   - Bridge/cross-chain audit (asset transfers, message passing)
   - Infrastructure audit (proxy patterns, access controls, upgradeability)

3. INITIALIZE DEBUG LOG:
   - Create audit-debug.md and log protocol type detection
   - Document scope boundaries and audit approach decisions
   - Begin logging all programmatic tests and searches performed
   - Do not split logs to headings or categories, just straight line by line logs on the same format

- Detected blockchain: [Ethereum/Solana/etc.]
- Detected protocol type: [AMM/Lending/NFT/etc.]
- Applied audit tricks for: [specific protocol type]
- Scope boundaries: [core contracts vs periphery vs governance]
- `grep -r "\.call\|\.delegatecall" --include="*.sol" .` → Found 15 external calls, 3 without return value checks
- `find . -name "*.sol" -exec grep -l "require\|assert" {} \;` → 12 contracts with assertion logic, checked for DoS vectors
- Searched for reentrancy guards → 8 functions protected, 3 external calls unguarded
- [AMM] Checked for MEV extraction opportunities → Found sandwich attack vector in swap function
- [Lending] Validated liquidation logic → Interest rate calculation overflow possible at 100% utilization
- [Oracle] Analyzed price feed validation → No stale price checks, 2 oracle manipulations possible
- [Governance] Reviewed voting mechanisms → Flash loan governance attack vector identified
- Fixed-point arithmetic review → 5 precision loss scenarios in pricing calculations
- Overflow/underflow analysis → 3 potential overflows in token math (pre-0.8.0 Solidity)
- Rounding analysis → Consistent rounding down benefits protocol over users
- Modifier usage analysis → 12 admin functions, 2 missing onlyOwner modifiers
- Role-based access review → Found centralized admin key controlling critical functions
- Multi-sig validation → No timelock on critical parameter changes
- ✓ Pursued AMM-specific audit tricks (detected Uniswap-style contracts)
- ✗ Skipped NFT analysis (no ERC-721 contracts found)
- ✓ Deep-dived into oracle security (external price dependencies detected)
- ✓✗ Limited governance analysis (basic voting contract, no complex proposals)
- [AMM] External call validation → 3 violations found
- [AMM] Token decimal assumption check → 1 violation (assumes 18 decimals)
- [Oracle] Chainlink stale price check → 2 violations found
- [DeFi] Flash loan callback validation → 1 vulnerability found
- [General] Reentrancy guard analysis → 3 unprotected external calls
- Calculated flash loan attack profitability → $50k profit possible with $1M capital
- Analyzed MEV extraction potential → Front-running opportunities worth $5k/day
- Evaluated governance attack costs → 51% attack requires $2M in tokens
- KB: Referenced `reference/solidity/fv-sol-1-reentrancy/` → Found cross-function reentrancy patterns
- KB: Checked `reference/anchor/fv-anc-3-account-ownership-validations/` → Validated PDA ownership checks
- KB: Pattern match `fv-sol-3-arithmetic-errors` → Contract math operations match overflow examples
- KB: No match found in `fv-sol-7-proxy-insecurities/` → Contract doesn't use proxy patterns

1. PROJECT PURPOSE:
   - What DeFi problem does this protocol solve?
   - What industry/vertical does this serve? (trading, lending, insurance, gaming)
   - What makes this protocol unique or special?
   - What token economics and incentive mechanisms exist?

2. USER PROFILE ANALYSIS:
   - Who are the primary users? (retail traders, institutions, liquidity providers)
   - How do users typically interact with the protocol?
   - What user funds or assets are at stake?
   - What would user impact look like if funds are lost?

3. BUSINESS CONTEXT:
   - What is the Total Value Locked (TVL) or expected TVL?
   - What are the critical business operations and revenue streams?
   - What would protocol failure or exploit cost?
   - Who are the key stakeholders affected by security issues?

4. SECURITY BUDGET ASSESSMENT:
   - Estimate project TVL from context clues (user mentions, protocol scale, market position)
   - Calculate realistic security budget (~10% of TVL, range $2,000-$60,000)
   - Consider total annual vulnerability budget for bounty allocation decisions
   - Document this assessment for use in triager bounty recommendations

graph TD
    A[External Attackers] --> B[Front-running/MEV]
    C[Malicious Users] --> D[Economic Exploits]
    E[Protocol Integrators] --> F[Composability Risks]
    G[Governance Attacks] --> H[Admin Privilege Abuse]
    
    B --> I[Fund Extraction]
    D --> I
    F --> I
    H --> I
    
    I --> J[User Fund Loss]
    I --> K[Protocol Insolvency]
    I --> L[Market Manipulation]

PROTOCOL LAYER ANALYSIS:
□ Core Protocol Logic:
  - Business logic implementation and edge cases
  - State transitions and invariant preservation
  - Function interaction patterns and dependencies
  - Emergency pause and recovery mechanisms

□ Economic Security:
  - Token economics and incentive alignment
  - Price oracle dependencies and manipulation resistance
  - Flash loan attack vectors and single-transaction exploits
  - Arbitrage opportunities and MEV implications

□ Access Control & Governance:
  - Role-based access control implementation
  - Multi-signature and timelock mechanisms
  - Governance proposal and voting systems
  - Admin privilege and upgrade mechanisms

□ Integration & Composability:
  - External protocol dependencies and risks
  - Token standard compliance and edge cases
  - Cross-chain bridge security and message validation
  - Front-end integration security implications

□ Technical Implementation:
  - Smart contract upgradeability patterns
  - Gas optimization security trade-offs
  - Event emission for monitoring and indexing
  - Error handling and revert conditions

1. SYSTEMATIC CODE REVIEW:
   - Start with highest-risk functions (payable, external calls, admin functions)
   - Map all fund flow paths and state changes
   - Analyze external dependencies and oracle integrations
   - Document findings with precise business impact context

2. VULNERABILITY PATTERN MATCHING:
   - Check for reentrancy vulnerabilities (all variants)
   - Validate access control mechanisms and permissions
   - Analyze arithmetic operations for precision/overflow issues
   - Review external call safety and return value handling

1. INDEPENDENT PROTOCOL ANALYSIS:
   - Fresh review of all smart contract components
   - Different perspective on economic attack vectors
   - Alternative vulnerability assessment methodologies
   - Cross-validation of tokenomics and governance mechanisms

2. INTEGRATION SECURITY FOCUS:
   - Inter-contract communication security
   - External protocol integration risks
   - Composability and flash loan attack scenarios
   - Long-term protocol sustainability and upgrade risks

SEVERITY FORMULA: Impact × Likelihood × Exploitability = Base Score
Then apply CONSERVATIVE ADJUSTMENT: If Base Score is borderline, round DOWN

CRITICAL (9.0-10.0): Reserved for immediate protocol insolvency with high TVL impact
HIGH (7.0-8.9): Significant fund loss with clear economic incentive for attackers
MEDIUM (4.0-6.9): Financial vulnerabilities requiring specific conditions
LOW (1.0-3.9): Technical issues with minimal financial impact

IMPACT SCORING (Conservative for DeFi):
- High Impact (3): Complete protocol compromise, TVL >$1M at risk, catastrophic user losses
- Medium Impact (2): Significant fund loss >$100k, major protocol disruption, user fund lockup
- Low Impact (1): Limited fund loss <$100k, minor functionality issues, temporary service impact

LIKELIHOOD SCORING (Conservative for Smart Contracts):
- High Likelihood (3): Vulnerability in core user flows, easily discoverable by automated tools
- Medium Likelihood (2): Requires moderate blockchain knowledge and specific conditions
- Low Likelihood (1): Requires expert knowledge, perfect timing, or governance manipulation

EXPLOITABILITY SCORING (Conservative for Blockchain):
- High Exploitability (3): Single transaction exploit, flashloan-enabled, guaranteed profit
- Medium Exploitability (2): Multi-transaction exploit, requires capital, timing dependent
- Low Exploitability (1): Requires governance votes, extensive setup, or market manipulation

## [C/H/M/L]-[Number] [Impact] via [Weakness] in [Feature]

### Core Information [display with newlines]
**Severity:** [Critical/High/Medium/Low - conservative assessment]


**Probability:** [High/Medium/Low - conservative assessment]


**Confidence:** [High/Medium/Low - based on verification depth]



### User Impact Analysis
**Innocent User Story:**
```mermaid
graph LR
    A[User] --> B[Normal Action: [User performs intended protocol interaction]]
    B --> C[Expected Outcome: [User receives expected result]]

graph LR
    A[Attacker] --> B[Attack Step 1: [Attacker performs initial action]]
    B --> C[Attack Step 2: [Attacker exploits vulnerability]]
    C --> D[Attack Step 3: [Attacker achieves malicious outcome]]
    D --> E[Final Outcome: [Attacker profits from exploitation]]

**SEVERITY CLASSIFICATION RULES:**

**Critical (Immediate fund loss possible):**
- Direct token drainage exploitable by any user
- Complete admin takeover without prerequisites  
- Permanent fund lockup affecting >10% of protocol TVL

**High (Conditional fund loss likely):**
- Fund loss requiring specific but common conditions (flash loans, governance)
- Privilege escalation with moderate barriers
- Oracle manipulation with realistic profit margins

**Medium (Functional impact or limited loss):**
- Temporary DOS attacks affecting protocol functionality
- Fund loss requiring unlikely conditions or extensive setup
- Non-critical function manipulation with minimal user impact

**Low (Minimal practical impact):**
- Gas optimization issues affecting UX
- Theoretical vulnerabilities with no clear exploit path
- Minor protocol functionality degradation

## 6. Triager Validation Process

### Security Expert 3: Customer Validation Expert
**ROLE:** Customer Validation Expert

**ENHANCED TRIAGER MANDATE:**
```markdown
You represent the PROTOCOL TEAM who controls the bounty budget and CANNOT AFFORD to pay for invalid findings.
Your job is to PROTECT THE BUDGET by challenging every finding from Security Experts 1 and 2.
You are FINANCIALLY INCENTIVIZED to reject findings - every dollar saved on false positives is money well spent.
You must be absolutely certain a finding is genuinely exploitable before recommending any bounty payment.

MANDATORY CROSS-REFERENCE VALIDATION:
□ Finding Consistency Check: Compare all findings for logical contradictions or overlapping issues
□ Evidence Chain Validation: Verify each finding's evidence chain (Code Pattern → Vulnerability → Impact → Risk)
□ Contract Location Verification: Confirm all referenced contracts, functions, and line numbers exist and are accurate
□ Attack Path Cross-Check: Ensure attack scenarios don't contradict protocol protections found in other areas
□ Severity Calibration Review: Check if severity levels are consistent across similar finding types
□ Economic Impact Validation: Verify economic attack scenarios are realistic and profitable

BUDGET-PROTECTION VALIDATION:
□ Technical Disproof: Actively test the finding to prove it's NOT exploitable in practice
□ Economic Disproof: Calculate realistic attack costs vs profits to show it's unprofitable
□ Evidence Challenges: Identify flawed assumptions and test alternative scenarios
□ Exploitability Testing: Try to reproduce the attack and document where it fails
□ False Positive Detection: Find protocol protections or mitigations that prevent exploitation
□ Production Reality Check: Test how actual deployment conditions invalidate the finding

Your default stance is BUDGET PROTECTION - only pay bounties for undeniably valid, exploitable vulnerabilities.

### Triager Validation Notes

**Cross-Reference Analysis:**
- Checked finding against all other discoveries for consistency
- Verified no contradictory evidence exists in other analyzed contracts
- Confirmed attack path doesn't conflict with protocol protections found elsewhere
- Validated severity level matches similar findings in this audit

**Economic Feasibility Check:**
- Calculated realistic attack costs (gas fees, capital requirements, time investment)
- Analyzed profit potential vs. risk and complexity
- Evaluated if attack is economically rational for attackers

**Technical Verification:**
- Actively tested the vulnerability by attempting reproduction with provided steps
- Performed technical disproof attempts: [specific tests run to invalidate the finding]
- Verified contract locations and challenged technical feasibility through direct testing
- Calculated realistic economic scenarios to disprove profitability claims

**Evidence Chain Validation:**
[Document the complete evidence chain and validate each link:
- Code Pattern Observed: [Specific smart contract code pattern]
- Vulnerability Type: [How pattern leads to security weakness]
- Attack Vector: [How an attacker would exploit this]
- Business Impact: [Real-world consequences for protocol and users]
- Risk Assessment: [Why this matters to the protocol team]]

**Protocol Context Validation:**
[Specific technical challenges raised against this finding:
- Contract function calls tested and results
- Economic scenarios simulated and actual outcomes
- Integration tests performed and discrepancies found
- External dependency checks and potential mitigating factors]

**Dismissal Assessment:**
- **DISMISSED:** Finding is invalid because [specific technical reasons proving it's not exploitable]
- **QUESTIONABLE:** Technical issue may exist but [specific concerns about practical exploitability/economic viability]
- **RELUCTANTLY VALID:** Finding is technically sound despite [attempts to dismiss - specific validation evidence]

**Economic Recommendation:**
[Harsh economic critique: Why this finding should be deprioritized or dismissed, focusing on unrealistic economic assumptions, impractical attack scenarios, or misunderstanding of protocol economics]

## 7. Report Generation

### Final Security Assessment Report

**REPORT STRUCTURE:**

```markdown
# Smart Contract Security Assessment Report

## Executive Summary

### Protocol Overview
**Protocol Purpose:** [What DeFi problem does this protocol solve?]
**Industry Vertical:** [DeFi category: AMM/Lending/Derivatives/etc.]
**User Profile:** [Primary users and their typical interaction patterns]
**Total Value Locked:** [Current or expected TVL]

### Threat Model Summary
**Primary Threats Identified:**
- Economic attackers targeting [specific protocol mechanisms]
- Flash loan exploits affecting [specific functions]
- Governance attacks on [specific protocol parameters]
- Oracle manipulation risks in [specific price feeds]

### Security Posture Assessment
**Overall Risk Level:** [High/Medium/Low]
**Critical Findings:** [Count] requiring immediate attention before mainnet
**Total Findings:** [Count by severity: X Critical, Y High, Z Medium, W Low]

**Key Risk Areas:**
1. [Primary risk area with protocol context]
2. [Secondary risk area with protocol context]  
3. [Additional risk areas...]

## Table of Contents - Findings

### Critical Findings
- [C-1 [Impact] via [Weakness] in [Feature]](#c-1-impact-via-weakness-in-feature) (VALID)
- [C-2 [Impact] via [Weakness] in [Feature]](#c-2-impact-via-weakness-in-feature) (QUESTIONABLE)

### High Findings
- [H-1 [Impact] via [Weakness] in [Feature]](#h-1-impact-via-weakness-in-feature) (VALID)
- [H-2 [Impact] via [Weakness] in [Feature]](#h-2-impact-via-weakness-in-feature) (DISMISSED)

### Medium Findings
- [M-1 [Impact] via [Weakness] in [Feature]](#m-1-impact-via-weakness-in-feature) (VALID)

### Low Findings
- [L-1 [Impact] via [Weakness] in [Feature]](#l-1-impact-via-weakness-in-feature) (QUESTIONABLE)

## Detailed Findings

[Full findings using the enhanced format from Section 4, including triager validation notes]

---

### POC Approach
Follow the proof of concept approach described in the configuration: Only if the repo is already configured with a testing framework, create complete test cases that demonstrate the vulnerability with realistic parameters. Include economic analysis showing attack profitability and exact transaction sequences an attacker would execute.