The most common advice for launching a lending protocol in 2023 was: fork Compound v2, change the token, launch on a new chain. It worked for a lot of teams. It also produced a graveyard of abandoned forks with identical vulnerabilities and no maintenance.
We looked at that and decided to build from scratch.
Not because forking is wrong — forking is a legitimate strategy when the original codebase is the right fit. But Compound v2's architecture couples pool logic, interest accrual, and governance in ways that make each piece harder to reason about in isolation. When something breaks, you are debugging three systems at once.
The coupling shows up in concrete ways. The interest rate calculation lives inside the same contract that holds deposit state. The oracle integration is baked into the pool contract rather than routed through an abstraction layer. Governance is entangled with the protocol's admin functions in a way that makes the governance surface area larger than it needs to be. None of these are bugs — they are reasonable design choices for 2019. They become liabilities when you're trying to audit the system in 2024, upgrade components independently, or deploy on chains where the original oracle providers don't exist.
CoreLend separates these concerns deliberately.
PoolCore handles deposits and borrows. It knows nothing about how interest is calculated or where prices come from. It calls registered contracts for both. RateModel is a pure function: given utilization, return a rate. It holds no state. OracleRouter normalizes prices from multiple sources without the pool needing to know which oracle is active. When Chainlink releases a new feed address, you update the router, not the pool. Liquidator handles undercollateralized position resolution by calling back into PoolCore — it does not hold position state itself.
The result is four contracts, each under 300 lines, each with a single responsibility, each independently testable, each independently auditable.
The audit surface is smaller per contract. An auditor reviewing RateModel does not need to understand PoolCore. An auditor reviewing OracleRouter does not need to understand liquidation logic. The scope of each engagement is bounded by the interface, not by the entire system.
Upgradability works without migration. If we need to update the interest rate model — say, to add a dual-slope kinked model where the original was linear — we deploy a new RateModel contract and register it with the pool. No position state moves. No user action is required. The pool continues operating through the upgrade. The equivalent operation in a Compound v2 fork typically requires a full protocol migration.
We are not claiming this is better than Compound. Compound v2 has years of mainnet history, a significant security track record, and a community that has stress-tested its edge cases in production over a long period. CoreLend has none of that yet. What we are claiming is that it is easier to audit, easier to modify, and easier to understand — which matters if you are deploying on a chain where Compound does not exist and you need to evaluate the security of the code you are about to deploy.
The audit is in progress. We will publish the full report before any mainnet deployment. Until then, CoreLend is testnet only, and that constraint is not negotiable.