# DeFi Lending Protocol Pre-Launch Checklist: 24 Items Before You Go Live

> A pre-launch checklist for DeFi lending protocol teams covering smart contract security, oracle setup, liquidation logic, risk parameters, and operational readiness.

- **Published:** 2026-05-09
- **Author:** Clixo
- **Reading time:** 5 min read
- **Tags:** lending, defi, checklist, smart-contract-security, protocol-launch
- **Canonical URL:** https://clixo.sh/blog/defi-lending-protocol-prelaunch-checklist

DeFi lending protocols hold user funds under algorithmic control with no way to reverse a bad transaction. A missed item in your pre-launch process does not become a support ticket — it becomes an exploit or a bad debt event that strains the protocol permanently. This checklist covers what production-grade lending protocol teams verify before going live.

```mermaid
flowchart TD
  U["User"] --> SC["Lending Smart Contracts"]
  SC --> IR["Interest Rate Model"]
  SC --> HF["Health Factor Engine"]
  SC --> LQ["Liquidation Engine"]
  SC --> AC["Access Control and Pause"]
  OR["Price Oracle"] --> HF
  OR --> LQ
  LQ --> BOT["Liquidator Bots"]
  AC --> TL["Timelock and Multisig"]
```

## Smart Contract Architecture

- **Interest rate model is parameterized correctly.** Verify that utilization ratios, kink points, and slope values produce reasonable APY across the full utilization range (0% to 100%). Test that APY does not go negative or produce overflow at boundary conditions.
- **Health factor calculation is correct and tested.** The health factor formula — weighted collateral value divided by borrowed value — must produce exactly 1.0 as the liquidation threshold. Verify it handles multiple collateral types with different factors correctly.
- **Reentrancy is blocked on all state-modifying paths.** Add reentrancy guards to `deposit`, `withdraw`, `borrow`, `repay`, and `liquidate` functions. Cross-function reentrancy — using function A to re-enter function B — is a distinct risk from single-function reentrancy.
- **Storage layout is locked before proxy deployment.** If using a proxy pattern, document the storage layout and include tests that verify adding state variables does not collide with existing slots.
- **Token transfer accounting handles fee-on-transfer tokens.** Some ERC20 tokens deduct a fee on transfer, so the contract receives less than the amount specified. Either explicitly exclude these tokens or use balance-diff accounting rather than trusting the `amount` parameter.

## Oracle Configuration

- **All supported collateral assets have active, monitored price feeds.** Verify feed addresses point to the correct aggregators on the target chain, not a testnet feed.
- **Staleness checks are enforced on every price read.** Define maximum acceptable age per asset and revert if `updatedAt` is older than the threshold.
- **Deviation thresholds are set appropriately per asset class.** Volatile assets may warrant tighter maximum deviation between oracle sources than stablecoins.
- **A circuit breaker pauses new borrows if all oracles fail.** Oracle failure should not allow borrows at stale or zero prices.

## Liquidation Engine

- **Liquidation incentive is correctly calibrated.** A liquidation bonus that is too low means liquidators will not participate. Too high means borrowers are over-penalized and good debt gets liquidated unnecessarily.
- **Close factor limits liquidation size appropriately.** Allowing a single liquidation to close 100% of a position can cause unnecessary loss for borrowers who are slightly underwater. A 50% close factor is standard for healthy positions.
- **Liquidations are profitable at realistic gas prices.** Run simulations at mainnet gas prices to ensure the liquidation bonus covers gas cost for typical position sizes. If small positions cannot be liquidated profitably, they become bad debt.
- **Liquidation path handles insolvent positions.** If a position's collateral value drops below the outstanding debt (the protocol is underwater), the system needs a mechanism to absorb bad debt — either an insurance fund, protocol reserves, or token dilution.

## Risk Parameters

- **Loan-to-value (LTV) and liquidation threshold are conservative for launch.** It is easier to raise limits after launch than to absorb losses from initial miscalibration.
- **Supply and borrow caps are set per asset.** Caps limit the protocol's exposure to any single asset during the first weeks of operation when behavior is hardest to predict.
- **Concentration limits prevent a single whale from controlling rates.** Extremely large deposits can manipulate utilization-based interest rates. Consider rate model design or deposit limits that prevent this.

## Access Control and Admin

- **All privileged functions have been mapped and role-assigned.** Functions that change risk parameters, oracle addresses, or admin roles should require a multisig — not a single EOA.
- **Timelock is active on all risk parameter changes.** A 24–48 hour timelock gives users time to exit before changes take effect.
- **Pause functionality is tested and works.** Verify you can pause the protocol end-to-end and that a pause does not prevent users from repaying debt or withdrawing collateral above their borrow.

## Testing and Audit

- **Fuzz tests cover deposit-borrow-liquidation cycles.** Automated fuzz testing with property assertions (health factor never goes negative, protocol never holds less than total deposits) should run for millions of iterations.
- **Invariant tests are defined and passing.** Total debt should always equal the sum of user borrows. Total supplied minus total borrowed should equal reserves. These invariants should hold after every action.
- **At least one full-scope audit is complete.** Lending protocols hold concentrated financial risk and are frequent exploit targets. One audit from a credible firm is a minimum; two independent audits is better practice for protocols targeting significant TVL.
- **Bug bounty is live before mainnet launch.** Immunefi or a self-managed program should be in place with a bounty commensurate with expected TVL.

## Operational Readiness

- **Monitoring is set up for all critical protocol metrics.** Track health factor distribution across positions, utilization rate per asset, oracle price deviation, and liquidation queue depth. Set alerts for anything outside expected ranges.
- **An incident response runbook exists.** Document who gets paged, what the pause procedure is, how to communicate with users, and what the decision tree looks like for a potential exploit.

---

A well-prepared launch is not just about the code — it is about the systems around the code that catch problems before they become irreversible. If you are building a DeFi lending protocol and need engineering support from architecture through audit coordination, [reach out to Clixo](https://clixo.sh/#contact).

---

Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh)
[Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)