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: Read the Code

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

Step 3: 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 4: Check Preconditions

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

Step 5: Check Guards

Look for protections user might have missed:

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

Step 6: Verdict

• CONFIRMED - Attack works as described
• PARTIAL - Attack works but with limitations
• NOT EXPLOITABLE - Protected or unreachable

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]

**Reason:** [Why it works or doesn't]
**Evidence:** [Code references with line numbers]

### 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