advanced

Verification Protocol - Advanced Reference (Aptos Move)

> Part of the Aptos Verification Protocol skill. Read `SKILL.md` for the core workflow first.

RAG Queries Before PoC (MANDATORY for HIGH/CRITICAL)

Before writing PoC tests for HIGH/CRITICAL findings, query the vulnerability database:

Step 1: Get Attack Vectors

mcp__unified-vuln-db__get_attack_vectors(bug_class="{category}")

Returns step-by-step attack strategies from real exploits.

Step 2: Get PoC Templates

mcp__unified-vuln-db__get_poc_template(bug_class="{category}", framework="move_test")

Returns example test structures for this vulnerability type.

Step 3: Get Similar Exploit Code

mcp__unified-vuln-db__get_similar_findings(pattern="{vulnerability description}")

Returns similar historical findings with code examples.

Step 4: Validate Before Committing

mcp__unified-vuln-db__validate_hypothesis(hypothesis="{your finding summary}")

Returns supporting/contradicting evidence from historical exploits.

RAG Integration Rules

| RAG Result | Impact on Verification | |------------|----------------------| | Attack vector found | Use documented steps as test basis | | PoC template available | Adapt template to this protocol | | Similar exploit exists | Extract key attack pattern | | No similar findings | Proceed with manual analysis, note uncertainty |

Document RAG Evidence

In the verification output, add:

### RAG Evidence
- **Attack Vectors Consulted**: [list bug classes queried]
- **Similar Exploits Found**: [count and brief descriptions]
- **PoC Template Used**: [yes/no, which template]
- **Historical Precedent**: [describe any matching historical vulnerabilities]

---

Exchange Rate Finding Severity (MANDATORY)

> **CRITICAL**: Before assigning severity to ANY finding affecting share/asset ratios or exchange rates, you MUST complete this quantitative analysis. Do NOT use qualitative terms without numbers.

Required Quantitative Analysis

For findings affecting exchange rates, fill in this table:

| Metric | Value | Source | |--------|-------|--------| | Protocol TVL | [X APT or USD] | Production or documented estimate | | Attack cost | [Y] | Calculated from attack steps (gas, tokens, opportunity) | | Attacker profit | [Z] | Calculated (extraction - cost) | | Victim loss per user | [W] | Calculated per affected user | | Affected user count | [N] | one / some / all | | Profit ratio | [Z/Y] | Attacker profit / attack cost |

Severity Calculation

**Step 1**: Calculate total impact = W * N (victim loss * affected users)

**Step 2**: Calculate profitability = Z/Y (attacker profit / cost)

**Step 3**: Apply severity matrix:

| Total Impact | Profitability > 2x | Profitability 1-2x | Profitability < 1x | |--------------|-------------------|-------------------|-------------------| | > $100,000 | CRITICAL | HIGH | HIGH | | $10,000 - $100,000 | HIGH | HIGH | MEDIUM | | $1,000 - $10,000 | HIGH | MEDIUM | MEDIUM | | < $1,000 | MEDIUM | LOW | LOW |

What NOT to Do

• "This enables MEV-style extraction" (qualitative, no numbers)
• "Attacker can profit significantly" (undefined)
• "Loss of funds possible" (unquantified)
• "Medium severity due to complexity" (no calculation)

What TO Do

• "Attacker profits 100,000 APT ($50,000) from 1,000 APT ($500) investment"
• "Each victim loses up to 1% of deposit value, affecting all users"
• "Total extractable value: $50,000 with 100x profit ratio -> HIGH"

---

Design Flaw Severity Escalation

When a finding is classified as a "design flaw" or "accounting inaccuracy" rather than an exploit, apply this escalation check:

| Criterion | YES/NO | |-----------|--------| | Risk-free for the attacker (no capital at risk, or attacker profits even if partial) | | | Repeatable (can be executed on every occurrence of a triggering event) | | | Scales with protocol usage (impact grows with TVL, user count, or time) | | | No mitigation without code change (off-chain monitoring cannot prevent, only detect) | |

**If ALL 4 criteria are YES**: Severity floor = MEDIUM (cannot be rated LOW or Informational) **If 3 of 4 criteria are YES**: Recheck -- the remaining criterion may not actually block the attack at scale

**Rationale**: Design flaws that are risk-free, repeatable, scaling, and unmitigable are effectively permanent value extraction channels. Even if per-event profit is small, cumulative impact over protocol lifetime is significant. "Attacker loses money" is only a valid downgrade if the loss is CERTAIN and PROPORTIONAL -- not if the attacker can structure the trade to break even or profit.

---

Bidirectional Role Analysis (MANDATORY)

> **CRITICAL**: Semi-trusted role findings CANNOT be marked REFUTED unless BOTH directions are analyzed.

HALT CONDITIONS for Semi-Trusted Role Findings

Before marking ANY finding involving BOT/KEEPER/OPERATOR roles as REFUTED:

• [ ] **Direction 1 analyzed**: ROLE -> USER harm scenarios (Steps 1-4 of SEMI_TRUSTED_ROLES.md)
• [ ] **Direction 2 analyzed**: USER -> ROLE exploitation (Steps 5-6 of SEMI_TRUSTED_ROLES.md)
• [ ] **Precondition Griefability table completed**: All role function preconditions checked
• [ ] **User exploitation scenarios documented**: Scenarios D, E, F from skill

Direction 2 Enforcement

If Direction 2 (USER -> ROLE) is NOT analyzed:

• CANNOT return REFUTED
• MUST return CONTESTED with note: "Direction 2 not analyzed"
• Finding flagged for depth review

**Example**:

## Finding [SR-3]: Keeper timing abuse

**Verdict**: CONTESTED (not REFUTED)
**Reason**: Only Direction 1 (keeper->user) analyzed. Direction 2 (user->keeper) not analyzed.

### Missing Analysis
- [ ] Can users predict keeper timing?
- [ ] Can users manipulate preconditions to block keeper?
- [ ] What is system degradation if keeper is blocked?

**Step Execution**: check1,2,3,4 | x5,6(not analyzed) -> INCOMPLETE

---

RAG Confidence Override

> **PURPOSE**: Prevent di