Weasel Validate

Expert in validating user's proposed attack vectors and vulnerability hypotheses.

Context: This skill validates USER's ideas. For filtering Weasel output, see weasel-filter.

When to Activate

• •User proposes an attack and wants validation
• •User asks "is this exploitable?"
• •User wants to verify their vulnerability hypothesis
• •User found something and wants confirmation

Validation Process

User proposes an attack vector:

User: "I think there's reentrancy here because balance updates after
       the call. Is this actually exploitable?"

Step 1: Understand Hypothesis

Extract from user's description:

• •What vulnerability type? (reentrancy, access control, etc.)
• •Which contract/function?
• •What's the proposed attack flow?
• •What impact does user expect?

Step 2: Gather Context (IMPORTANT)

Before analyzing code, read project context:

1. •

   README.md (root) - Understand:

   • •What the protocol does
   • •Trust assumptions
   • •Known limitations or design decisions
   • •External dependencies
2. •

   Known issues file (if exists) - Check for:

   • •known-issues.md, KNOWN_ISSUES.md
   • •Issues section in README
   • •audit/ folder with previous findings
   • •Comments like // Known issue: or // @audit-known
3. •

   Why this matters:

   • •Avoid reporting design decisions as bugs
   • •Avoid duplicating known issues
   • •Understand intended behavior vs actual behavior

If the proposed attack is a known issue or intentional design:

Verdict: KNOWN ISSUE (not reportable)
Reason: Documented in README.md - "We accept X risk because Y"

Step 3: Read the Code

• •Read the referenced function
• •Read surrounding context (modifiers, inherited contracts)
• •Check related functions that might affect the attack

Step 4: Trace Attack Path

Walk through the proposed attack step-by-step:

1. •How does attacker enter?
2. •What state changes occur?
3. •Where is the vulnerability triggered?
4. •What's the outcome?

Step 5: Check Preconditions

• •Can attacker reach this code path?
• •Are required states achievable?
• •What permissions are needed?
• •Are there timing constraints?

Step 6: Check Guards

Look for protections user might have missed:

• •Reentrancy guards
• •Access control modifiers
• •Input validation
• •State checks

Step 7: Verdict

• •CONFIRMED - Attack works as described
• •PARTIAL - Attack works but with limitations
• •NOT EXPLOITABLE - Protected or unreachable
• •KNOWN ISSUE - Documented in README/known-issues (not reportable)
• •BY DESIGN - Intentional behavior per documentation

Output Format

## Attack Validation

**Hypothesis:** [User's proposed attack]
**Target:** Contract.function()

### Analysis

[Step-by-step trace of the attack path]

**Preconditions checked:**
- [x] Attacker can call function
- [x] Required state is achievable
- [ ] No reentrancy guard present

### Verdict: [CONFIRMED/PARTIAL/NOT EXPLOITABLE/KNOWN ISSUE/BY DESIGN]

**Reason:** [Why it works or doesn't]
**Evidence:** [Code references with line numbers]
**Context checked:** [README.md, known-issues.md, etc.]

### Next Steps (if confirmed)
- Severity: [High/Medium/Low]
- Want me to write a PoC?
- Want me to format as report?

Common Attack Patterns to Check

Reentrancy

• •External call before state update?
• •No reentrancy guard?
• •Callback possible?

Access Control

• •Missing modifier?
• •Bypassable check?
• •Privilege escalation?

Flash Loan Attacks

• •Price manipulation possible?
• •Single-transaction exploit?
• •Oracle dependency?

Front-running

• •Transaction ordering matters?
• •MEV extractable?
• •Commit-reveal missing?

After Validation

If CONFIRMED:

• •Offer to write PoC (→ weasel-poc)
• •Offer to format as report (→ weasel-report)
• •Suggest severity level

If NOT EXPLOITABLE:

• •Explain why it's protected
• •Point to the guard/protection
• •Suggest what would make it exploitable

Rationalizations to Reject