Liquidation DoS Auditor

When to Use

• Auditing liquidation mechanisms for DoS vectors
• User mentions: liquidation DoS, unbounded loops, gas limits, front-run liquidation, callback attacks, reentrancy, token compatibility
• Analyzing liquidation griefing attacks, gas exhaustion, revert conditions
• Reviewing position enumeration, collateral seizure, token integrations

Audit Workflow

IMPORTANT: Announce skill usage at the start of analysis

Begin with: "I'm using the audit-liquidation-dos skill to analyze this contract for liquidation denial of service vulnerabilities..."

1. Scan for liquidation operations

   • Search: liquidate, seizeCollateral, for, while, onERC721Received, transfer, nonReentrant, positions, EnumerableSet
   • Focus: loops, callbacks, reentrancy guards, token transfers, balance checks

2. Check against vulnerability patterns

   • Reference reference.md for complete checklist
   • Compare code against example.md

3. Validate exploitability

   • Check access control first - grep for onlyOwner|onlyAdmin|onlyGovernance modifiers
   • Can non-privileged actors trigger liquidation DoS?
   • Can liquidation be blocked via gas exhaustion?
   • Can users front-run to prevent liquidation?
   • Can callbacks or hooks revert liquidation?
   • Can token incompatibilities block liquidation?
   • Verify no compensating protections exist
   • Downgrade severity if admin-only unless prevents all liquidations

4. Generate report

   • Use deliverable template below
   • Include PoC showing DoS condition
   • Rank by severity

Core Vulnerability Patterns

See reference.md for full checklist. Key patterns:

1. Unbounded loops over positions → OOG revert during liquidation
2. Data structure corruption → liquidation reverts on corrupted state
3. Front-run prevention → nonce change or self-liquidation blocks liquidator
4. Pending withdrawals → equal to balance causes revert
5. Malicious callbacks → ERC721/ERC20 hooks revert to prevent liquidation
6. External vault collateral → not seized during liquidation
7. Insufficient insurance fund → bad debt blocks liquidation
8. Fixed bonus exceeds collateral → 110% bonus fails when ratio < 110%
9. Non-18 decimal handling → precision errors cause reverts
10. Multiple nonReentrant → conflicting guards block execution
11. Zero transfer reverts → missing checks with strict tokens
12. Token deny lists → USDC blocklists prevent transfers
13. Single borrower edge case → assumes > 1 borrower

Code examples: See example.md

Severity Criteria

Critical: Liquidation permanently blocked causing protocol insolvency, all positions unliquidatable, MUST be exploitable by non-privileged actors High: Specific positions unliquidatable via griefing, protocol accumulates bad debt from DoS, MUST be exploitable by non-privileged actors Medium: Liquidation delayed or requires special conditions, increases bad debt risk, admin-only liquidation function DoS issues with cascading impact Low: Edge case DoS with limited impact, easily mitigated, admin-only function issues without immediate liquidation impact

IMPORTANT: Admin-only liquidation functions (onlyOwner, onlyAdmin, onlyGovernance) with DoS vectors are MEDIUM or LOW severity unless:

• Admin function failure prevents all liquidations protocol-wide
• DoS in admin function enables bad debt accumulation affecting all users
• Admin liquidation path is the only liquidation mechanism (no trustless alternative)

False Positives - Do NOT Flag

• Bounded loops with documented max limits
• Trusted token integrations (if explicitly documented)
• Admin-controlled liquidation paths with known restrictions
• Intentional liquidation delays with explicit design docs
• Protocols using liquidation queues or alternative mechanisms
• Admin-only liquidation helper functions (onlyOwner, onlyAdmin) where public liquidation path exists
• Governance-controlled collateral seizure functions with documented emergency-only usage
• Admin batch liquidation functions with gas limits where single liquidation still works

Deliverable Format

MANDATORY: Before deliverable, verify each checklist.md item against codebase. Flag violations as findings.

Use template: templates/report-template.md

Each finding includes: severity, pattern #, file/lines, description, vulnerable code, DoS impact analysis, PoC showing griefing attack, remediation, gas impact.

Key Principles

• Bounded iteration - never loop over unbounded user-controlled arrays
• Graceful degradation - liquidation should work even with bad debt/edge cases
• Front-run resistance - liquidation cannot be blocked by borrower actions
• Callback isolation - external calls cannot revert liquidation
• Token compatibility - handle zero transfers, deny lists, non-standard decimals

Output Guidelines

DO:

• Reference specific lines and functions
• Provide executable PoCs showing DoS
• Quantify gas limits and iteration costs
• Show token compatibility issues

DON'T:

• Report intentional design choices with documentation
• Flag bounded loops with max limits
• Use vague terms ("could cause DoS")
• Ignore compensating mechanisms (liquidation queues, etc.)