Malda Protocol launched on Linea with a challenge: how do you secure a cross-chain lending protocol spanning multiple networks without introducing centralized monitoring systems or slowing down operations? Their answer: the Credible Layer.
As one of the first protocols to integrate the Credible Layer on Linea, Malda now prevents entire categories of attacks.
Here's exactly how six assertions protect $2.25M in user funds across Malda's cross-chain architecture. But first, a bit about Malda and the Credible Layer.
The Credible Layer
The Credible Layer introduces a new security primitive: assertions. Instead of trying to predict every possible attack, assertions define what states should never occur in a protocol and enable the network to prevent them before they ever are included in a block.
Core concept: Assertion: State → {true, false}
Assertions execute off-chain in a modified EVM (PhEVM) that is now part of Linea’s sequencer and prevent transactions from being included in blocks if they would invalidate an assertion that a protocol defines.
Malda Protocol
Malda enables users to lend and borrow across multiple chains with Linea as the security and liquidity hub in what they call Unified Lending.
mErc20Host (Linea mainnet): Primary lending markets where all actual capital resides. Handles deposits, borrows, liquidations, and ZK proof verification from extension chains.
mTokenGateway (Extension chains): Lightweight gateways on chains like Base and Arbitrum. Users supply tokens here, with operations settled on Linea via ZK proofs.
Rebalancer: Manages liquidity distribution from Linea to extension chains using whitelisted bridges.
To secure this complex cross-chain architecture, we analyzed Malda's security invariants with their team and helped them implement five assertions. Each assertion addresses a specific hacked state that could compromise user funds or general protocol stability.
Six Assertion Collections Deployed
1. Oracle Price Sanity, Freshness, and Cross-Feed Delta
Focus: MixedPriceOracleV4 contract on Linea that feeds price data to all lending operations across the protocol.
What the assertion protects: Consistent price feeds across chains are crucial for a healthy cross-chain lending protocol. Inconsistent price oracles across chains can lead to price variation or manipulation exploits, which allow attackers to take advantage of price inconsistencies.
How the assertion protects: Validates three critical conditions before any price-dependent transaction executes: all price feeds must be fresh within acceptable time windows, no price can be zero, and different price feeds must remain consistent within configured tolerance bounds. This prevents any operation from proceeding with compromised or manipulated price data.
Explore the full assertion here.
2. Account Liquidity Soundness Across Transactions
Focus: Operator contract's liquidity calculations and the beforeMTokenBorrow, beforeMTokenRedeem hooks that validate user positions before operations.
Possible attacks: Malda's existing checks validate liquidity per operation, but complex cross-chain transactions involving ZK proof verification can reference previous state transitions. Attackers could exploit mid-transaction price changes to borrow while underwater or force liquidations on positions that should remain solvent. Flash loan attacks could manipulate collateral values temporarily to bypass single-point checks.
How the assertion protects: Continuously validates borrower collateralization at every step of the transaction call stack, not just at operation boundaries. Ensures borrowers maintain sufficient collateral throughout multi-step cross-chain operations and that liquidations only occur when accounts are genuinely underwater. This catches state changes that occur during execution that single-point validation would miss.
Explore the full assertion here.
3. Interest Accrual Monotonicity and Rate-Cap Adherence
Focus: Interest rate model contracts that calculate borrowing costs and the accrual mechanisms that update user balances over time.
What the assertion protects: Bugs or manipulation in interest rate calculations could create negative interest rates, allowing borrowers to profit from holding debt positions. Rate calculations that exceed maximum bounds could impose unfair borrowing costs or break protocol economics.
How the assertion protects: Enforces that the borrow index only increases when time advances, and individual borrow balances can only increase through interest accrual or decrease through repayment—never the reverse. Caps interest rates at configured maximums (0.03% per block) to prevent excessive accumulation. This prevents rate manipulation attacks and ensures protocol-wide borrows remain consistent with individual positions.
Explore the full assertion here.
4. Rebalancer Allowlists and Rate Limits
Focus: Rebalancer contract's sendMsg function and bridge integrations that move assets between Linea and extension chains.
What the assertion protects: A compromised Rebalancer could route assets to unauthorized bridges or malicious contracts, effectively draining protocol liquidity to attacker-controlled addresses. Even with proper authorization, excessive single-transfer sizes could destabilize liquidity distribution across chains. Unauthorized addresses gaining Rebalancer access could initiate transfers that bypass all other controls.
How the assertion protects: Validates that all rebalancing operations only use explicitly whitelisted bridges and destination chains. Enforces minimum and maximum transfer size bounds to prevent both dust attacks and excessive single-transfer risk. Implements cumulative transfer volume caps per destination/token pair within time windows for rate limiting. Verifies that only addresses with the REBALANCER_EOA role can initiate operations, preventing unauthorized access.
Explore the full assertion here.
5. Oracle Configuration and Price Safety Bounds
Focus: Oracle configuration functions that set feed addresses, staleness periods, price deviation tolerances, and token decimals.
What the assertion protects: Malicious or compromised admin addresses could set dangerous oracle configurations: zero addresses for price feeds that would break all pricing, excessive staleness periods allowing outdated prices, unreasonably high deviation tolerances between feeds enabling manipulation, or invalid token decimals breaking all value calculations.
How the assertion protects: Validates all Oracle configuration changes before they take effect. Ensures API3 and eOracle feed addresses are non-zero, staleness periods stay capped at 7 days maximum, price deviation tolerances between feeds never exceed 10%, and token decimals remain between 1 and 18. Applies the same validation rigor to both global settings and per-symbol overrides, preventing dangerous parameter changes from compromising the oracle system.
Explore the full assertion here.
The Integration
Malda deployed six assertion collections that now prevent entire categories of attacks from ever occurring. This is the power of preventing the hack directly instead of trying to find every hack vector before a hacker does.
The integration happened with zero downtime, no contract changes, and no redeployments of contracts; assertions simply are deployed as smart contracts on Linea and referenced directly by the sidecar in Linea's sequencer, meaning their code continues running exactly as before while gaining new protection layers.
Being able to deploy assertions quickly and at no cost meant they could launch with institutional-grade security from day one, rather than spending months on traditional security approaches during their initial growth phase.
All of Malda's active assertions are publicly verifiable and transparent.
Users can inspect the exact rules protecting their funds, and other developers can audit the security logic without trusting black-box systems. This transparency builds user confidence and makes it easier for risk-averse capital to assess risk before allocation. Check Malda's live assertion dashboard to see their active protection rules yourself.