Security at Lotus

Overview

Users and allocators should be able to understand the principles behind Lotus security and verify them for themselves. Each principle below is paired with what enforces it and where to check it: in the code, in third-party review, and, from launch, in the live state of the contracts.

This page is the canonical reference, and it will be updated as each effort completes, starting with the audit now underway.

Security for an onchain lending protocol rests on three pillars: design (how the system is architected, how its markets are parameterized, and where risk and authority live), code (the smart contracts themselves and the testing, verification, and review they pass through), and operations (how the protocol is run onchain: keys, signers, monitoring, and incident response). No one of them is sufficient on its own.

Design

The ledger's code never changes

The core Lotus protocol contract holds all accounting: supply, borrow, collateral, tranche balances, and loss allocation. It has no proxy and no upgrade path; the code deployed at launch is the code that runs. The logic that must adapt over time, interest rates and liquidations, lives in dedicated modules: risk engines and liquidation modules, which upgrade only through the 72-hour timelock described below. The parts that adapt do so slowly and in public view, while the ledger they operate on cannot be changed underneath anyone.

What a lender underwrites is explicit and fixed

A Lotus market is defined by its economic parameters: 

• Loan token

• Risk engine

• Liquidation module

• Each tranche's collateral token, oracle, and liquidation LTV (LLTV), the threshold at which a position becomes eligible for liquidation

These parameters are hashed into the market's identity, so they cannot change for the life of the market. Exactly three things about a live market can change, all through the governance tiers described below: 

• Tranche fees (capped onchain at 25%; raises wait 24 hours, cuts are instant)

• Market hook (an optional extension contract that can add market-level safeguards such as flow caps; changes wait 24 hours)

• Module logic behind those fixed addresses (proxied implementations; upgrades wait 72 hours)

Losses are bounded by tranche

Every Lotus lender chooses a tranche and that choice sets their risk ceiling. Unutilized capital only cascades in one direction, from junior to senior. This means a lender may end up underwriting positions less risky than their selected tranche, but never riskier ones. 

If a position incurs bad debt, losses remain with the lenders who funded it and are not socialized across the market. In Lotus, seniority describes the risk you underwrite, not payment priority. You are never underwriting tranches you did not choose.

Economic parameters are security parameters

The rates a risk engine sets, the LLTVs a market enables, and the tranches it offers determine how the protocol behaves under stress, so they receive third-party scrutiny of their own: Block Analitica published an economic assessment of Lotus's markets and risk parameters, and Credora published preliminary per-tranche risk ratings for the launch markets.

Those preliminary ratings are a snapshot of an ongoing engagement with Credora. From launch, each tranche in a market carries a dynamic risk rating shown in the app. A vault's risk rating reflects its underlying positions, measured against the vault’s stated risk mandate. If a vault drifts above or below its mandate, the drift surfaces in an independent third-party rating.

Permissionless by architecture but curated in practice

Anyone can deploy a market, but its risk engine, liquidation module, and tranche LLTVs must come from explicitly enabled sets. The loan token, collateral tokens, and oracles are the creator's choice, and a new market starts empty: it holds only the capital of lenders who choose to underwrite it. An enabled entry cannot be removed, so no existing market can have its dependencies pulled out from under it. New LLTVs enter only through the 24-hour timelock; risk engines and liquidation modules enter through that same timelock or via an approved module manager, typically a module factory that registers the modules it deploys.

In practice, the launch markets are created and parameterized by Lotus, and their risk engines are actively managed after deployment. 

Module managers are the deliberate exception to the one-way rule: their approval waits out the 24-hour timelock, and they are the one approval that can be revoked instantly, which is what keeps the fast path accountable.

De-risk instantly, re-risk slowly

At launch, ownership of the core contract will sit with the LotusGovernor, an onchain timelock contract whose code enforces this asymmetry:

• Instant: risk-reducing and incident-response actions, such as lowering fees, pausing or unpausing markets, and disabling a module manager.

• 24-hour timelock: risk-increasing changes, such as raising fees or directly enabling a new risk engine, liquidation module, LLTV, or market hook.

• 72-hour timelock: the highest-impact actions: module upgrades, ownership transfers, and guardian changes.

The pause power acts as an emergency circuit breaker. A pause can apply globally or to a single market, and halts every user-facing operation in its scope, including withdrawals. It is intended for situations where continuing normal operation could worsen an active incident, and provides time to investigate and contain the issue. No interest accrues while paused.

Because pausing is a containment measure, both pausing and unpausing take effect immediately. Once an incident is resolved, funds do not have to wait through a timelock before normal operations resume.

Other sensitive actions remain subject to enforced delay. The two timelock tiers are hard-coded in the Governor, with durations set at deployment to 24 hours and 72 hours and immutable afterward. Module parameter changes pass through a companion OperatorTimelock: 24 hours for parameter changes, 72 hours for operator transfers, under the same guardian model described next.

Timelocks create oversight windows

Lotus has no token governance. In its place, sensitive actions are subject to enforced delays and an independent veto. A separate guardian role monitors every pending action during its timelock and can revoke it before execution.

These controls are enforced onchain rather than left to policy. From launch, anyone can inspect the enable lists, the timelock durations, the owner and guardian addresses, and every pending timelocked action directly from the contracts. Pending and executed actions are also shown in the app on every market page.

Code

The contracts have been through layered review since the start of development:

Audit scope

The audit covers the full protocol surface. Cyfrin's engagement runs five weeks from mid-July 2026 and spans the core lending contract, all risk engines and liquidation modules, governance (LotusGovernor and OperatorTimelock), vault integrations including the real-world-asset adapters (Coinbase Prime, WisdomTree WTGXX), the bundler, market hooks, the lens, the module and vault factories, pre-liquidation, and oracle staleness bounds. When the audit completes, the findings and our remediations will be linked at the top of this page.

Formal verification proves specific properties under stated assumptions. Cyfrin is developing the proof suite as part of the audit engagement, using the Certora prover, with machine-checked proofs targeting core accounting invariants.

Operations

Security does not end at the contracts

Across the industry, operational compromise accounted for roughly 76% of value stolen in the first half of 2026 despite representing about 15% of incidents. Lotus is adopting the SEAL Frameworks for operational security and will pursue SEAL certification and accreditation once multisig and treasury operations are live onchain.

Operating Lotus means operating in public

The owner and guardian are separate roles with separate holders. The guardian role is intended for an external security council, seated with parties independent of Lotus such as auditors, monitoring services, and risk managers.

Every owner action enters the public timelock queue defined above, and routine module tuning flows through the OperatorTimelock. Day-to-day operation of the protocol is visible onchain in the same place its constraints are.

Monitoring, guardian oversight, and instant pause authority together form a circuit breaker: anomalies can be detected, pending actions revoked, and markets paused without waiting on any timelock, while risk-increasing changes wait out their delays in public view. A dedicated post on operational security will follow.

Verify

• The protocol documentation

• The full architecture breakdown 

• Interactive mechanism explainers for cascading supply, loss allocation, and liquidations

• Block Analitica's economic assessment of Lotus's markets and risk parameters.

• Credora’s preliminary risk assessment for the cbBTC/USDC and wstETH/USDC markets

• All research: lotuslabs.net/research

Lotus is built on the belief that onchain lending should be underwritable. That standard applies to the protocol itself. Everything provided here is to enable you to reach your own view of Lotus's security.

If any claim on this page doesn't hold up under your review, or you've found something we haven't, we want to hear it: email security@lotuslabs.net