Lombard Finance — Smart Contract Security Audit Report

Executive Summary

This report presents the findings of a comprehensive smart contract security audit of the Lombard Finance protocol, a Bitcoin liquid staking system with cross-chain bridging capabilities. The audit covered 59 custom Solidity contracts (~13,933 LOC) across three deployment modules: LombardConsortium_6792, LombardTimeLock_055e, and StakedLBTC_21f3.

The audit identified 19 confirmed findings after rigorous Devil's Advocate falsification:

Key risk areas include: fee approval signature reuse across deposits, missing maximum validator set size caps, BasculeV3 proof context binding, PMM accounting gaps, and oracle configuration guardrails.

Scope

Files Audited

Exclusions

Findings

Critical & High Findings

H-1: FeeApproval Signature Not Bound to Specific mintPayload — Reuse Across Multiple Deposits

The getFeeDigest() function in BaseLBTC.sol:33-48 computes the EIP-712 digest for fee approvals as:

keccak256(abi.encode(
    Actions.FEE_APPROVAL_EIP712_ACTION,
    block.chainid,
    fee,
    expiry
))

The type hash FEE_APPROVAL_EIP712_ACTION is defined in Actions.sol:106 as keccak256("feeApproval(uint256 chainId,uint256 fee,uint256 expiry)"). Critically, the digest does not include the mintPayload hash (the specific Bitcoin deposit being claimed). This means a single fee approval signature is valid for all deposits from the same user on the same chain with matching fee and expiry parameters.

The _mintWithFee() flow in both NativeLBTC.sol:435-476 and AssetRouter.sol:705-751 verifies the fee signature via Assert.feeApproval(digest, recipient, userSignature) but does not bind it to the specific deposit payload being processed.

keccak256("feeApproval(uint256 chainId,bytes32 payloadHash,uint256 fee,uint256 expiry)")

This binds each fee approval to exactly one deposit payload.

H-2: BasculeV3 Trusted Signer Proof Lacks Chain and Contract Binding — Cross-Chain Replay

If multiple BasculeV3 instances exist across chains sharing the same trustedSigner, a proof signed for a deposit on Chain A is valid on Chain B. The contract provides no structural guarantee against cross-deployment replay.

bytes32 signedData = keccak256(abi.encode(address(this), block.chainid, depositID));
(address signer, , ) = ECDSA.tryRecover(signedData, sig);

H-3: Consortium Validator Set Has No Maximum Size — Gas-Based Protocol DoS

With a sufficiently large validator set, checkProof gas cost exceeds the block gas limit, permanently preventing:

uint256 constant MAX_VALIDATORS = 100;
require(_validators.length <= MAX_VALIDATORS, "TooManyValidators");

Also consider early-exit in _checkProof once weightSum >= weightThreshold.

H-4: PMM totalStake Never Decrements — Permanent Swap Function DoS

In both PMM contracts, swapBTCBToLBTC / swapCBBTCToLBTC increment $.totalStake += amountLBTC on every swap (BTCB.sol:87, CBBTC.sol:116). However, no function in either contract ever decrements totalStake:

Once totalStake >= stakeLimit, all future swaps revert with StakeLimitExceeded. The PMM is permanently bricked until admin raises stakeLimit.

H-5: CEI Violation in AssetRouter._redeem/_deposit — Cross-Chain Message Before Token Burn

In AssetRouter._redeem() (lines 553–618), the execution order is:

Line 608: $.mailbox.send(...)        // Dispatches cross-chain message
Line 614: tokenContract.mint(treasury, fee)  // Mints fee to treasury
Line 617: tokenContract.burn(fromAddress, amount + fee)  // Burns user tokens

In AssetRouter._deposit() (lines 396–430):

Line 423: $.mailbox.send(...)        // Dispatches cross-chain message
Line 429: IBaseLBTC($.nativeToken).burn(fromAddress, amount)  // Burns user tokens

Both violate Checks-Effects-Interactions: the cross-chain message is dispatched before the on-chain token burn. While Mailbox.send() only emits an event (no immediate cross-chain execution), the MessageSent event persists in logs even if the subsequent burn() reverts (events from reverted internal calls are still included in the outer transaction's receipt only if the outer transaction succeeds — but the event emission before state settlement creates misleading off-chain signals).

The nonReentrant guard on the outer redeem() / deposit() functions prevents reentrancy exploitation in the current implementation, but the structural violation creates fragility for future modifications.

// _redeem:
tokenContract.burn(fromAddress, amount + fee);  // Effects first
if (fee > 0) tokenContract.mint(treasury, fee);
$.mailbox.send(...);                              // Interactions last

// _deposit:
IBaseLBTC($.nativeToken).burn(fromAddress, amount);  // Effects first
$.mailbox.send(...);                                   // Interactions last

Medium Findings

M-1: Oracle maxAheadInterval Has No Upper Bound — Oracle Freeze Vector

M-2: No Oracle Freshness/Staleness Check in AssetRouter

M-3: BridgeTokenAdapter.spendDeposit() Has No Access Control — Deposit Proof Griefing

The comment on line 298 says /// TODO: remove after used, confirming this is a temporary migration function that should have been removed or access-controlled.

M-4: PMM Zero-Output Swap Due to Fee Ceiling Rounding on Dust Amounts

The ZeroAmount check (BTCB.sol:79) only guards amountLBTC == 0, not amountLBTC - fee == 0.

Additionally, FeeUtils.validateCommission() allows fees up to 9999 (99.99%), meaning an admin can set near-100% fee that silently extracts almost all value from users.

M-5: Oracle prevRatio Active During Full switchTime Interval — Front-Running Window for External Consumers

After publishNewRatio() is called, _ratio() (lines 221–227) returns prevRatio until block.timestamp >= switchTime. The upcoming currRatio is publicly readable via nextRatio(). This creates a deterministic, publicly visible arbitrage window for external DeFi integrations that consume the oracle's getRate().

M-6: StakedLBTC Pauser Not Set at Initialization — Emergency Pause Unavailable Post-Deploy

In contrast, NativeLBTC uses AccessControl with PAUSER_ROLE set during initialization.

M-7: AssetRouter.deposit() Allows Token Contract to Specify Arbitrary fromAddress for Burning

if (sender != fromAddress && sender != toToken) {
    revert AssetRouter_Unauthorized();
}

The sender == toToken branch allows a token contract (which has CALLER_ROLE via setRoute()) to call deposit() with an arbitrary fromAddress. The subsequent _deposit() (line 429) calls IBaseLBTC($.nativeToken).burn(fromAddress, amount), burning tokens from the specified address if AssetRouter holds MINTER_ROLE.

The same pattern exists in _redeem() (line 565) where sender == fromToken passes the check.

Low Findings

L-1: IBCVoucher.leftoverAmount() Division-by-Zero When window == 0

L-2: PoR.initialize() Missing _disableInitializers() Constructor

L-3: StakedLBTC EIP-712 Domain Name Is a TODO Placeholder

L-4: getRate() Uses Ceiling Rounding — Systematic Rate Overpricing

L-5: CLAdapter Deprecated Contract Uses Shared Mutable State — Race Condition

L-6: Unsafe approve() Pattern in Bridge._deposit() and CLAdapter

This is subject to the classic ERC20 approve race condition if previous approvals are not fully consumed.

L-7: IBCVoucher Rate Limit Uses uint64 for Credit Accounting — Truncation at Scale

Invariants Verified

The following invariants were tested and confirmed to hold:

False Positives Eliminated

The following suspected issues were investigated and determined to be false positives:

Tools Used

Disclaimer

This audit was performed using the sc-mega-auditor methodology combining systematic vulnerability hunting with adversarial reasoning. While every effort has been made to identify all vulnerabilities, no audit can guarantee the absence of bugs. This report should not be considered an endorsement of the protocol's security. The findings are based on the code as reviewed and may not reflect subsequent modifications.