Component: Lending (pools providing liquidity via Orderbook → Borrowers)

Description

• Pools supply liquidity and advertise it in the orderbook.

• Orders are sorted by interest rate and LTV.

• Liquidity is tracked so borrowers can match against it.

• Pool totals, shares, and fees update when lenders deposit or withdraw.

What it does:

• batchInsertOrder posts pool supply at chosen rates, replacing older orders.

• When borrowers match, liquidity is used via _processPoolMatches calling depositCollateral + borrow.

• Lenders deposit through ERC4626 (deposit/mint), minting shares and updating totals.

• Withdraws burn shares, lower supply, and update orderbook entries.

How it works:

• Pools must be validated and whitelisted first.

• Orders stored in a red-black tree; each pool tied to its entries.

• accrueInterest grows total supply over time.

• Fees (protocol/manager) minted as new shares.

• Deposits and withdrawals wrap ERC4626 with pool-specific logic.

Invariants

• Deposits always raise both assets and shares proportionally.

• Withdrawals can’t drop supply below outstanding borrows.

• Only whitelisted pools can list orders.

• Orders reset each batchInsertOrder call.

• Fees capped so total can’t exceed MAX_TOTAL_FEE.

Attack surface

• Pool managers: control order posting; must be whitelisted and follow input rules.

• Deposits/withdrawals: checked for >0 amounts, valid receivers, and no overdrawing.

• Order manipulation: spam or bad inputs prevented by ordering checks and pool’s LTV cap.

• Fee changes: guarded by timelock/admin, capped by MAX_TOTAL_FEE.

• Reentrancy: blocked by nonReentrant, safe ERC20, and state-first updates.

• DoS: paused pools skipped, orders cleared each insert.

• Oracle risk: less direct, but still matters for rate models and collateral safety.