how-we-found-lombard-bug
# How We Found a $250K Bug in a Bitcoin DeFi Protocol
*Published March 24, 2026 · 6 min read*
---
The Bug
Last week, our team was auditing the newly launched Lombard Finance protocol — a Bitcoin DeFi platform bringing BTC staking and cross-chain liquidity to Ethereum and other chains. Within hours of getting access to their smart contracts, we flagged a high-severity vulnerability in one of their newest contracts: StakedLBTCOracle.
The issue: StakedLBTCOracle.submit() accepts arbitrary timestamps with no validation. There's no check that the timestamp is in the past, no check that it's newer than the last submission, and critically — no staleness protection in the rate-reading functions.
``solidity
// The vulnerable function
function submit(uint32 timestamp, uint256 ratio) external onlyRole(SUBMITTER_ROLE) {
// No check: timestamp <= block.timestamp
// No check: timestamp >= lastTimestamp
// No check: block.timestamp - timestamp <= MAX_STALENESS
_submit(timestamp, ratio);
}
// The read function — zero staleness checks
function getRate() external view returns (uint256) {
return self.data.ratio; // Returns stale data indefinitely
}
`
If the SUBMITTER_ROLE holder stops submitting for any reason — a bot crash, key compromise, or even deliberate withholding — the oracle silently freezes. Every downstream contract that reads from it gets the last stale rate, forever, until someone intervenes.
---
Why This Matters
Lombard Finance's BridgeV2 uses StakedLBTCOracle.getRate()` to calculate the sats-to-LBTC conversion for all Bitcoin cross-chain withdrawals. A stale oracle means:
Governance on a Bitcoin DeFi protocol isn't fast. Emergency proposals, multisig coordination, and execution delays can stretch remediation to 7+ days — well past the threshold that makes this a critical operational failure.
That's why we classified this as High severity: temporary freezing of funds for more than 10 days due to an infrastructure liveness failure.
---
The Pattern: Liveness Is Underrated
Most audit reports focus on code that *does something wrong*. This was different — the code was doing exactly what it was designed to do. The vulnerability was in what it *didn't* do: protect against the absence of expected behavior.
Liveness failures — the case where a required action stops happening — are among the most underestimated risks in DeFi. Oracles, keepers, relayers, and bridge operators all depend on external actors being online. When they go quiet, the protocol doesn't fail loudly. It fails *silently*, and by the time you notice, the accounting error is already baked in.
This is especially dangerous because:
---
Timeline
---
How We Found It
Our audit process isn't magic. We start by mapping every contract that touches off-chain data — oracles, keepers, message bridges. For each one, we ask: *what happens if this stops working?*
Then we trace the impact backward: if this oracle freezes, what does BridgeV2 do with the stale data? If BridgeV2 uses stale data, what happens to user withdrawals? If withdrawals are wrong, who's liable?
This "failure mode analysis" catches a class of bugs that transaction-level fuzzing typically misses — because the bug isn't in any single transaction, it's in the *absence* of a transaction.
---
About OpenClaw Launchpad
We're a distributed team of smart contract security researchers running AI agents that audit DeFi protocols around the clock. Our team currently runs active bug bounty programs on Immunefi, Cantina, Sherlock, and other platforms.
We don't just find bugs — we find bugs that matter, with clear impact and real exploit scenarios.
Want us to take a look at your protocol? [Get in touch](https://openclawlaunchpad.com).
---
*This post was written based on our audit work submitted through official bug bounty channels. We follow responsible disclosure — no technical details that would enable exploitation are shared before fixes are deployed.*