Lending Protocol Security

Injectable Skill: Lending Protocol Security

Protocol Type Trigger: lending (detected when recon finds: liquidate|borrow|repay|collateral|lend|loan|LTV|healthFactor|interestRate|debtToken) Inject Into: Breadth agents, depth-token-flow, depth-edge-case, depth-state-trace Language: Language-agnostic methodology Finding prefix: [LEND-N]

Orchestrator Decomposition Guide

When decomposing this skill into depth agent investigation questions, map sections to domains:

• Sections 1, 4: depth-edge-case (health factor boundaries, first borrower)
• Sections 2, 5: depth-state-trace (interest accrual, collateral state, pause mechanics)
• Sections 3, 3b, 3c: depth-token-flow (liquidation flows, bad debt socialization)
• Section 6: depth-external (oracle dependency for pricing)

When This Skill Activates

Recon classifies protocol as lending type based on indicators: liquidate, borrow, repay, collateral, lend, loan, LTV, healthFactor, interestRate, debtToken, reserve, utilizationRate, debtShare. This skill adds lending-specific checks that the general ECONOMIC_DESIGN_AUDIT does not cover.

1. Health Factor Boundary Analysis

1a. Health Factor Computation

Identify the health factor (HF) formula and trace each input:

• What is the formula? (typically: HF = (collateralValue * liquidationThreshold) / debtValue)
• How is collateralValue derived? (oracle price * collateral amount * collateral factor)
• How is debtValue derived? (oracle price * borrow amount including accrued interest)
• Is interest included in the HF check at the moment of the check, or from a stale snapshot?

Substitute boundary values into the formula:

1b. Check-to-Execution Consistency

• Between HF check and liquidation execution: can any state change (oracle update, interest accrual, collateral deposit) alter the HF?
• If a user's borrow increases their debt: is HF re-checked atomically or can they borrow below HF=1.0?
• Grep every exit-path (withdraw, transfer, finalize_transfer) for the SAME health predicate used at borrow entry. If a DIFFERENT or WEAKER predicate is used on any exit-path, document both predicate names and flag the asymmetry.

1c. Dust Position Economics

• Grep deposit/borrow entry points for minimum amount/value checks (min_borrow, min_deposit, require amount >= X). If NONE found → document "NO_MINIMUM_POSITION" as a finding: attackers can Sybil-create dust positions that cost more to liquidate than they're worth, accumulating bad debt.
• If a minimum exists at creation: grep partial-repay path for the same check. If missing → dust positions can be created by repaying down to near-zero.

Tag: [BOUNDARY:HF={value} → liquidatable={YES/NO} → operator={>=/>}]

1d. Guard Selector → Post-Transaction Enforcement Completeness

For protocols that use transaction guards or post-transaction hooks with conditional enforcement checks (e.g., post-transaction guard/hook triggered by selector or return value):

1. Enumerate ALL function selectors the guard/hook handles
2. For each selector: does the operation affect HF? (changes collateral amount, debt amount, collateral factor, efficiency/isolation mode, reserve configuration)
3. For each HF-affecting selector: does the guard/hook trigger the post-transaction HF enforcement check?
4. Flag any HF-affecting selector where post-tx enforcement is skipped

Tag: [TRACE:guard_hook_selector={fn} → HF_affecting={YES/NO} → post_tx_check={YES/NO}]

2. Interest Accrual Correctness

2a. Accrual Timing

Identify the interest accrual mechanism and trace when it updates:

• Is interest accrued per-block, per-second, or on-demand (lazy accrual on interaction)?
• For lazy accrual: which functions trigger accrual? (borrow, repay, deposit, withdraw, liquidate)
• Can a user interact without triggering accrual? (view functions used for state-changing decisions)
• Is there a maximum time gap the accrual formula handles correctly? (overflow risk for long-dormant positions)

2b. Index Update Ordering

For index-based interest (where debt = principal * currentIndex / borrowIndex):

• Is the global interest index updated BEFORE or AFTER the user's balance change?
• If AFTER: the user's new balance accrues interest from the wrong base
• Trace the exact ordering: accrueInterest() → updateIndex → updateUserBalance → updateUserIndex
• If any step is out of order or conditional: flag for depth review

2c. Precision Loss

• Compound interest over many small intervals vs one large interval: is the result equivalent?
• For utilization-rate-based interest: does the utilization rate use pre- or post-operation values?
• Over 365 days of per-second compounding: does accumulated precision error become material? (compute concrete drift using the protocol's actual rate model constants)

2d. Pause-Interest Interaction

• During pause: does interest continue to accrue?
• If interest accrues during pause BUT repayment is blocked: borrowers accumulate debt they cannot repay, potentially becoming liquidatable upon unpause
• If interest does NOT accrue during pause: lenders lose yield for the paused period

Tag: [TRACE:accrueInterest() → index_update_order={before/after} → user_balance_change → {correct/misordered}]

3. Liquidation Mechanism Safety

3a. Liquidation Profitability

For the liquidation incentive structure:

• What is the liquidation bonus/discount? Is it configurable per asset?
• At what position size does liquidation become unprofitable after gas? (concrete calculation: bonus * seized_value - gas_cost)
• Is the liquidation bonus taken from the borrower's collateral or from a protocol reserve?
• Can the liquidation bonus exceed the remaining collateral? (over-incentivized liquidation = protocol loss)

3b. Partial vs Full Liquidation

• Is partial liquidation supported? What is the close factor (max % of debt repayable per liquidation)?
• Can the close factor be bypassed? (rounding, minimum amounts, or repeated calls in same tx)
• After partial liquidation: is the remaining position still healthy? (HF should improve, not worsen)
• Can an attacker force full liquidation by manipulating the position to make partial liquidation insufficient?

3c. Collateral Selection

• If a borrower has multiple collateral types: can the liquidator choose which to seize?
• Can cherry-picking the most valuable collateral leave the position with only low-quality collateral?
• Is there a priority ordering for collateral seizure? If so, who defines it?

3d. Front-Running Protection

• Can a borrower front-run liquidation by removing collateral or adding debt?
• Can a borrower front-run liquidation by repaying just enough to raise HF above threshold?
• Are there any callbacks during liquidation that the borrower's contract can intercept?

Tag: [TRACE:liquidate(amount={X}) → bonus={Y} → seized_collateral={Z} → remaining_HF={value}]

3b. Liquidation DoS Vectors

Callback Reverts

• Does the liquidation path call any function on the borrower's address? (token transfer hooks, onReceive callbacks)
• If the borrower is a contract: can it revert in a callback to block liquidation?
• Does the liquidation path use try/catch or pull-pattern to isolate borrower behavior?

Token Blocklist Interaction

• If collateral or debt tokens have blocklist functionality (USDC, USDT): can a blocklisted borrower prevent liquidation?
• Pattern: borrower gets blocklisted → liquidator cannot receive seized collateral → liquidation reverts
• Is there a fallback path (escrow, protocol seizure) for blocklisted positions?

Gas Bounds

• Count max storage reads per liquidation call: (reserves_in_position × oracle_reads_per_reserve × token_ops_per_reserve). Compare against chain's per-transaction resource limit (EVM: block gas; Stellar: ~40 read ledger entries; Solana: CU budget). If a user controlling N reserves can exceed the limit → document "LIQUIDATION_RESOURCE_DOS".
• Grep for maximum asset/reserve count limits enforced at deposit/borrow entry. If none → users can grow positions until liquidation is physically impossible.

Reentrancy Guard Conflicts

• If liquidation acquires a reentrancy lock: do any internal calls (token transfers, oracle reads) also require the same lock?
• Pattern: liquidate() → nonReentrant → internal transfer → callback → another protocol function → same nonReentrant → revert

Tag: [TRACE:liquidate() → callback_to_borrower={YES/NO} → revert_possible={YES/NO} → fallback={exists/missing}]

3c. Bad Debt Socialization

Bad Debt Detection

• What happens when a position's debt exceeds its collateral value? (underwater position)
• Is bad debt detected automatically or does it require manual trigger?
• Can bad debt exist silently (no revert, no event) while corrupting the pool's accounting?

Socialization Mechanism

Trace the bad debt absorption path in order:

1. Is there an insurance fund or reserve? What fills it? (liquidation fees, protocol revenue)
2. If insurance is exhausted: is bad debt spread across all lenders? (share price reduction, or explicit socialization call)
3. Is there a protocol backstop? (treasury injection, governance action)
4. What is the ordering? (insurance → socialization → backstop)

Bad Debt Amplification

• Can bad debt be created faster than the socialization mechanism can process it?
• During a cascade (multiple positions liquidated simultaneously): does each liquidation's bad debt compound?
• If the debt token accrues interest: does bad debt also accrue interest? (phantom interest on unrecoverable debt)

Tag: [TRACE:position_underwater → insurance_fund={sufficient/exhausted} → socialization={mechanism} → lender_loss={amount}]

4. Collateral Factor Manipulation

4a. Retroactive Factor Changes

• When admin changes collateral factor (LTV ratio): does it affect existing positions immediately?
• If immediate: can existing healthy positions become instantly liquidatable?
• Is there a buffer period or grace period for borrowers to adjust after factor changes?
• Is there a maximum single-step change (e.g., can factor go from 80% to 0% in one tx)?

4b. Boundary Positions

• For positions at exactly the collateral factor boundary: does a factor reduction by 1 bps make them liquidatable?
• Substitute concrete values: position with 80% LTV at 80% collateral factor → factor reduced to 79% → position immediately unhealthy
• Is there a notification mechanism or delay that protects these boundary positions?

Tag: [VARIATION:collateralFactor 80%→79% → positions_at_80%_LTV → instantly_liquidatable={YES/NO}]

5. Asymmetric Pause Analysis

5a. Pause Granularity

Enumerate all pausable functions and their pause groupings:

5b. Dangerous Asymmetries

Check for these specific asymmetric pause states:

• Repay paused, liquidation active: Borrowers cannot repay but can be liquidated (interest accrues, HF drops, user has no recourse)
• Borrow paused, repay active: Safe asymmetry (users can reduce risk but not increase it)
• Withdraw paused, deposit active: Users can add funds but cannot exit (potential trap)
• Liquidation paused, interest active: Underwater positions grow worse with no resolution

5c. Post-Unpause Grace Period

• Grep for grace_period/cooldown/delay/repay_window near unpause/set_pause logic. If NONE found → document "NO_UNPAUSE_GRACE": positions that became liquidatable during pause are seized immediately upon unpause with no user recourse.

Tag: [TRACE:pause(repay) → interest_accrues={YES/NO} → liquidation_active={YES/NO} → borrower_recourse={YES/NO}]

6. Oracle Dependency for Pricing

Cross-reference with ORACLE_ANALYSIS skill for general oracle checks. This section covers lending-specific oracle concerns only.

6a. Price-Token Matching

• Does the oracle price correspond to the EXACT token used as collateral/debt? (not a wrapper, not an underlying)
• For rebasing tokens or interest-bearing tokens: is the oracle price adjusted for the rebase/interest?
• For LP tokens used as collateral: how is the LP token priced? (underlying reserves * oracle prices, or direct LP oracle?)

6b. Stale Oracle Impact on Liquidation

• If the oracle returns a stale price: can liquidation proceed with outdated prices?
• If a staleness check reverts: does liquidation revert too? (stale oracle = liquidation DoS)
• Grep for fallback/backup/secondary/chainlink_fallback near oracle/price logic. If NONE found → document "NO_FALLBACK_ORACLE": single oracle failure = liquidation DoS for all positions using that price feed.

6c. Self-Liquidation via Oracle Manipulation

• Can a borrower manipulate the oracle to inflate their collateral value, borrow maximum, then let the oracle correct?
• Can a liquidator manipulate the oracle to make a healthy position appear liquidatable?
• For oracle-based liquidation bonus: can the bonus be manipulated via price feeds?

Tag: [TRACE:oracle_price={source} → token_match={exact/wrapper/underlying} → stale_revert_blocks_liquidation={YES/NO}]

Common False Positives

• Admin-controlled collateral factor changes with timelock: Retroactive effect is by design when timelock gives users notice period to adjust positions
• Interest accrual paused during emergency pause IF repayment is also paused: Symmetric pause - neither debt nor repayment ability changes
• Dust positions below minimum borrow size: If minimum borrow is enforced at creation AND after partial repayment, dust positions cannot be created by users
• Liquidation bonus exceeding collateral for tiny positions: If minimum borrow size prevents tiny positions, the economics are safe for all valid positions
• Oracle staleness check reverting liquidation: If a fallback oracle exists and is used when primary is stale, liquidation is not blocked

Step Execution Checklist (MANDATORY)