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

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.

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.