__Asset Accuracy Assurance__

Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.

__Public Disclosure of Known Issues__

Bug reports covering previously-discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk. 

__Previous Audits__

Lombard’s completed audit reports can be found [here](https://github.com/lombard-finance/evm-smart-contracts/tree/main/docs/audit). Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.

__Eligibility Criteria__

Security researchers who wish to participate must adhere to the rules of engagement set forth in this program and cannot be:
- On OFACs SDN list 
- Official contributor, both past or present
- Employees and/or individuals closely associated with the project 
- Security auditors that directly or indirectly participated in the audit review

__Private Known Issues Reward Policy__

Private known issues, meaning known issues that were not publicly disclosed, are valid for a reward equal to that of a bug one severity lower.

__Primacy of Impact vs Primacy of Rules__

Lombard adheres to the Primacy of Rules, which means that the whole bug bounty program is run strictly under the terms and conditions stated within this page.

__Responsible Publication__

Whitehats may publish their bug reports after they have been fixed & paid, or closed as invalid, with the following exceptions:
- Bug reports in mediation may not be published until mediation has concluded and the bug report is resolved.

Immunefi may publish bug reports submitted to this audit competition and a leaderboard of the participants and their earnings.

__Immunefi Standard Badge__

By adhering to Immunefi’s best practice recommendations, Lombard has satisfied the requirements for the [Immunefi Standard Badge](https://immunefisupport.zendesk.com/hc/en-us/articles/15006865432209-The-Immunefi-Standard-Badge).

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


Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

Permanent freezing of funds

Protocol insolvency

Smart contract unable to operate due to lack of token funds

Block stuffing

Theft of gas

Unbounded gas consumption

Contract fails to deliver promised returns, but doesn't lose value

Temporary freezing of funds for at least 30 days

Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol (not lower than $1K))

__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](https://immunefisupport.zendesk.com/hc/en-us/articles/9946217628561-Proof-of-Concept-PoC-Guidelines-and-Rules).



__Whitehat Educational Resources & Technical Info__

https://docs.lombard.finance/

__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.

Lombard

Lombard provides rewards in USDC on Ethereum, denominated in USD. The following reward terms are a summary. For the full details read our [Lombard Audit Competition Reward Terms](https://immunefisupport.zendesk.com/hc/en-us/articles/31051806316433-Lombard-Audit-Competition-Reward-Terms)

Rewards are distributed all at once after the competition has ended. No rewards are distributed during the competition.

The reward pool size is determined by the greatest condition met. If multiple conditions are met only the largest reward pool applies. 

If one or more Critical severity bugs are found, the reward pool will be - **$100,000 USD**
If one or more High severity bugs are found, the reward pool will be - **$75,000 USD**
If one or more Medium severity bugs are found, the reward pool will be - **$35,000 USD**
If one or more Low severity bugs or only Insights [no valid bugs] are found, the reward pool will be - **$20,000 USD**

Duplicates and private known issues are valid for a reward.

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System V2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/).

__Insight Rewards Payment Terms__

*Insight Rewards*: Portion of the Rewards Pool

*The "Insight" severity was introduced on Boost (Audit Competitions) & Attackathon programs to recognize contributions that extend beyond identifying immediate vulnerabilities. Currently, it's not an option to select the Insight severity when submitting a report. However, our team or program will designate it accordingly if applicable. "Insights" underscores our commitment to valuing all types of contributions that contribute to a more secure environment and will always be rewarded. [View more information about Insights](https://immunefisupport.zendesk.com/hc/en-us/articles/13333032674961-Severity-Classification-System?utm_source=immunefi)

Duplicates of Insight reports are not eligible for a reward.

Audit Comp | Lombard

Live

Live

Documentation