Lending: Aave, Compound, Morpho, and Isolated Markets

Lending protocols accept deposits, lend them to borrowers against collateral, and liquidate undercollateralized positions to keep the protocol solvent. They are the second-largest category of DeFi TVL after DEXs, and they have a long history of expensive bugs.

Canonical Architectures

Compound V2

The historical reference design. Each market is a CToken (ERC-20 representing the supply position in one underlying asset). Markets share a Comptroller that enforces global rules (which assets are collateral, what their factors are, when accounts are liquidatable).

Key concepts:

  • cToken.exchangeRate grows over time as interest accrues; it's the conversion between cToken shares and underlying.
  • Collateral factor caps how much of an asset's value counts as borrowing power (e.g., 75% for ETH means $100 of ETH supports $75 of borrowing).
  • Liquidation incentive is a discount given to liquidators on the seized collateral (e.g., 8%); the liquidator pays the borrower's debt and seizes collateral worth debt * (1 + incentive).
  • Interest-rate model is per-market and a function of utilization.

Compound V3

A re-architecture: one market per base asset (USDC, ETH), each with multiple supportable collateral assets but a single borrow asset. Simpler than V2 in some ways, more isolated in others.

Aave V2/V3

Similar high-level shape to Compound but more featureful: variable and stable interest rates, isolated mode, efficiency mode (eMode), credit delegation, flash loans built into the protocol. V3 adds isolation (limits borrowing against certain collateral) and eMode (looser parameters for correlated assets).

Morpho

Originally a "peer-to-peer optimizer" on top of Compound/Aave; now Morpho Blue, an isolated-market primitive. Each market is a single supply/borrow pair with fixed parameters (oracle, IRM, LLTV); markets are permissionless to create. Drastically reduces the protocol's surface area and shifts complexity to the integrators who choose which markets to use.

Isolated / Custom Markets

Many newer protocols (Euler V2, Silo, Fraxlend, custom designs) borrow from these architectures while introducing their own twists — risk-adjusted oracles, segregated debt pools, custom liquidation mechanics. Their audit footprints are bespoke; the same checks apply but the specific bugs vary.

Recurring Lending Findings

1. Oracle Manipulation Liquidation

The most expensive lending bug class. The protocol observes a price; an attacker manipulates it (spot AMM, low-liquidity pool, stale oracle); the protocol misvalues collateral or debt; the attacker withdraws excess value or liquidates a position they shouldn't.

Examples in production:

  • Spot-AMM oracle reads (bZx, multiple 2020 incidents).
  • Low-liquidity Uniswap V3 pool used as oracle (multiple 2022-2023 incidents).
  • Chainlink price deviating from market price during volatility, with no deviation check (multiple incidents).
  • Pyth confidence-interval not checked (multiple 2023-2024 incidents).

Mitigations: pull oracles with attestation, multi-source aggregation, deviation checks, TWAP smoothing with appropriately-sized windows.

2. Re-entrancy in Liquidation or Withdrawal Paths

Classic re-entrancy in modern lending tends to involve:

  • Receiving native ETH (or a token with hooks) before updating internal accounting.
  • Calling out to the seized-collateral token's transfer function before reducing the borrower's debt.
  • Cross-function re-entrancy where withdrawal calls a hook that re-enters borrow.

Aave V3 and Compound V2 are battle-tested in this regard; forks of them frequently re-introduce reentrancy when they add features (new asset types, new hook points).

3. Liquidation Bonus / Bad Debt

If the liquidation incentive is set too high relative to the collateral factor, "bad" liquidations become possible — the liquidator takes more than the debt is worth, leaving the protocol with bad debt.

Conversely, if the bonus is too low or the protocol takes too long to liquidate (high gas, congested chain, oracle lag), positions can fall below water before being liquidated, again leaving bad debt.

Audit: the relationship between collateralFactor, liquidationThreshold, and liquidationIncentive must keep all positions liquidatable while solvent.

4. Donation / First-Deposit Inflation on Lending Vaults

ERC-4626-style lending vaults are subject to the inflation attack described in §4.15.0. Aave's aTokens and Compound's cTokens have specific defenses; freshly forked lending markets often don't.

5. Interest-Accrual Manipulation

If interest is accrued lazily (on-demand when a user interacts), an attacker can craft a sequence of transactions that triggers accrual at a profitable moment — e.g., depositing immediately before a large borrower's interest tick, then withdrawing immediately after.

This is usually not a critical bug (the values involved are small), but it's a real category. Properly designed accrual systems update on every state change to the market.

6. Isolation / eMode Bugs

Aave V3's eMode lets correlated assets (e.g., stablecoins) share more aggressive collateral parameters. Bugs in eMode have included:

  • Allowing an asset in eMode to be borrowed against an asset outside eMode at eMode parameters.
  • Letting an account enter eMode while holding incompatible collateral.

Custom isolation mechanisms in lending forks often replicate this bug class.

7. Liquidation Front-Running / Cooperative Liquidation

Some custom lending protocols implement "liquidation auctions" or "co-liquidation" — schemes where multiple liquidators participate in seizing one position. These often have new bug surfaces: liquidator collusion, partial-liquidation gaming, etc.

Audit: any departure from the standard "first valid liquidator takes the whole position at fixed bonus" model expands the audit scope significantly.

8. Borrow Cap / Supply Cap Bypass

V3-style supply and borrow caps are intended to limit the protocol's exposure to any single asset. Bugs include:

  • Caps that aren't enforced for certain borrow types (variable vs. stable).
  • Caps that can be bypassed via flash loans + repay.
  • Caps that have rounding errors letting users slightly exceed them.

Each finding is bounded — caps are usually conservative — but they recur.

9. Bad Debt Socialization

When liquidations don't cover a borrower's debt, the protocol has bad debt. Designs differ on who eats it: protocol reserve, all suppliers, specific risk tranches. Bugs:

  • Bad-debt socialization happening at the wrong time (before all liquidations have run).
  • Socialization producing rounding errors that compound.
  • The reserve being depletable by repeated bad debt without protocol intervention.

10. Pause / Freeze Misuse

Modern lending protocols have pause/freeze switches. Bugs:

  • Pause that doesn't prevent liquidation, letting bad actors liquidate the paused protocol.
  • Pause that does prevent liquidation, letting positions accumulate bad debt while paused.
  • Asset-level freeze that creates inconsistent state (deposits paused but borrows allowed, etc.).

Audit: every admin/pause path should be exercised against every market state.

Audit Checklist for a Lending Protocol

  • Oracle architecture: source, freshness, deviation tolerance, fallback, manipulation resistance.
  • Collateral/liquidation parameters: relationship between factors keeps all positions liquidatable while solvent.
  • Liquidation incentive sized to motivate fast liquidation under realistic gas/MEV conditions.
  • Interest accrual: updated on every state change; lazy accrual paths reviewed.
  • Re-entrancy: every external call (token transfers, oracle pulls, hooks) reviewed for cross-function and read-only reentrancy.
  • Donation / inflation attack on freshly-created markets.
  • Supply and borrow caps actually enforced on all paths.
  • Bad-debt handling specified and tested.
  • Pause/freeze paths consistent (paused markets are fully paused, including liquidation if intended).
  • Isolation/eMode logic (if applicable) tested for cross-category contamination.
  • Token compatibility: which token behaviors are supported? Rebasing? Fee-on-transfer? Pause-able tokens? Tokens with blocklists?
  • Permissionless market creation (Morpho Blue, Euler V2): each new market's parameters are sanity-checked by the protocol, even if not gated.

A lending audit that touches every item here covers most of the recurring bug catalogue. The protocol-specific quirks remain — and are usually where the most interesting findings live.