Lombard is on a mission to unlock Bitcoin's potential as a dynamic financial tool by connecting it to DeFi with LBTC. LBTC is a secure Bitcoin LST, developed by Lombard on top of Babylon. It's a yield-bearing, natively cross-chain, liquid Bitcoin backed 1:1 by BTC. With LBTC, Bitcoin can be held as a store of value and simultaneously used to lend, borrow, stake, trade, and transfer in DeFi across multiple blockchain ecosystems
Live
Triaged by Immunefi
PoC required
KYC required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Proof of Concept (PoC) Requirements
A PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.
Whitehat Educational Resources & Technical Info
What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?
ERC-20, ERC-20 Permit
What emergency actions may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?
If the Ethereum mainnet contract is Paused or upgraded from the audit competition version.
What monitoring systems may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?
We use https://www.hexagate.com/ for contracts monitoring.
What addresses are considered out of scope for bug reports requiring their involvement, regardless of whether they operate within or exceed their attributed privileges?
All admin and operational roles are out of scope
Which chains and/or networks will the code in scope be deployed to?
Ethereum, Base, BSC
Is this an upgrade of an existing system? If so, which? And what are the main differences?
It's an upgrade and extension of the contracts deployed here: https://etherscan.io/address/0x4cbd8802465f690e7637454783955fa8e6d0c4bc#code https://etherscan.io/address/0x67927d7ea19f9a1053f4f5bbdf827ed9870f1a1b#code The main difference is upgraded and extended logic(for example TSS was replaced with multisig), and also new contracts which provide new functionality to the Lombard stack(like integration with Chaiblink bridge and Layerzero, previous contract also had bridge functions but it never was used and was moved to separate contract). Also, there is new logic and a new contract for improved user experience (mintWithFee)
Where do you suspect there may be bugs? We are most concerned about stealing or loss of funds. We would most like security researchers to break our 1:1 peg with bitcoin by contract exploits, and to focus on how to steal funds from another user through the contracts provided. We are most concerned about re-entrancy attacks and malicious payload injections as attack vectors. Different ways that allow double claiming of deposits.
What external dependencies are there? We rely on OpenZeppelin contracts for a lot of boilerplate Solidity code (https://github.com/OpenZeppelin/openzeppelin-contracts and https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable). On top of this, we depend on Chainlink and LayerZero code for bridging (https://github.com/Cyfrin/ccip-contracts and https://github.com/LayerZero-Labs/LayerZero-v2/tree/main/packages/layerzero-v2/evm).
Where might Security Researchers confuse out-of-scope code to be in-scope? All admin/operator functions are out of scope, and all notarization systems(lombard/chainlink/LayerZero) are out of scope. For upgradable contracts, all bugs that can be fixed by upgrade and do not bring financial damage are counted as low severity.
Are there any unusual points about your protocol that may confuse Security Researchers? We use complex bridging code and extend base functionality for given contracts in this regard, which takes a bit of back and forth reading to understand. In this case, specifically, there will be some logic that will be activated given a setting about enabling attestations; in a mainnet scenario, we should always assume that attestations are enabled. We have a complex notarization system with different validators, so there is no centralization.
Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Permanent freezing of funds
Protocol insolvency
Temporary freezing of funds for at least 30 days
Smart contract unable to operate due to lack of token funds
Block stuffing
Theft of gas
Unbounded gas consumption
Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol (not lower than $1K))
Contract fails to deliver promised returns, but doesn't lose value
Out of scope
- Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (governance, strategist) except in such cases where the contracts are intended to have no privileged access to functions that make the attack possible
- Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
- Best practice recommendations
- Feature requests
- Impacts on test files and configuration files unless stated otherwise in the bug bounty program