Prepared by:
HALBORN
Last Updated 07/28/2025
Date of Engagement: June 10th, 2025 - June 19th, 2025
100% of all REPORTED Findings have been addressed
All findings
20
Critical
2
High
7
Medium
3
Low
1
Informational
7
Lair Finance engaged Halborn to conduct a security assessment of their smart contracts from June 10th to June 19th, 2025, with a follow-up review from July 19th to July 23rd, 2025. The scope of this assessment was limited to the smart contracts provided to the Halborn team. Commit hashes and additional details are documented in the Scope section of this report.
The Halborn team dedicated a total of twelve days to this engagement, deploying one full-time security engineer to evaluate the smart contracts’ security posture.
The assigned security engineer is an expert in blockchain and smart contract security, with advanced skills in penetration testing, smart contract exploitation, and a comprehensive understanding of multiple blockchain protocols.
The objectives of this assessment were to:
Verify that the smart contract functions operate as intended.
Identify potential security vulnerabilities within the smart contracts.
In summary, Halborn identified several areas for improvement to reduce both the likelihood and impact of potential risks. The Lair Finance team has partially addressed some of these recommendations. The primary suggestions include:
Restrict receivedToken() to internal calls to prevent unauthorized token transfers by approved users.
Use correct decimals for price calculations in reward swaps.
Verify proper Kodiak interface usage.
Correct arithmetic underflow in the getTokenAmountByToken1 function to prevent staking denial-of-service (DoS) via token1.
Fix incorrect refund logic in _stake to prevent staking reverts caused by ERC20InsufficientBalance errors.
Address unit mismatch between BGT and WBERA tokens during token0 swap to prevent DoS in token0 staking.
Mitigate front-running attacks on reward harvesting by integrating reward execution within stake and unstake flows.
Implement a safe token approval mechanism compatible with tokens like USDT to prevent reverts.
Incorporate slippage protection in reward token swaps to defend against MEV extraction.
Follow established smart contract best practices.
Halborn employed a combination of manual, semi-automated, and automated security testing methods to ensure effectiveness, efficiency, and accuracy within the scope of this assessment. Manual testing was vital for uncovering issues related to logic, processes, and implementation details, while automated techniques enhanced code coverage and helped identify deviations from security best practices. The assessment involved the following phases and tools:
Research into the architecture and purpose of the smart contracts.
Manual review and walkthrough of the smart contract code.
Manual evaluation of critical Solidity variables and functions to identify potential vulnerability classes.
Manual testing using custom scripts.
Static security analysis of the scoped contracts and imported functions utilizing Slither.
Local deployment and testing with Foundry.
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
2
High
7
Medium
3
Low
1
Informational
7
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Token1 Single-Stake Function Permanent DoS Due to Arithmetic Underflow | Critical | Solved - 06/26/2025 |
| Incorrect Refund Calculation causes Permanent Staking DoS | Critical | Solved - 07/26/2025 |
| Token Decimal Mismatch in Reward Swaps | High | Solved - 07/25/2025 |
| Incorrect Minimum Swap Amount for Non-18 Decimal Tokens | High | Solved - 07/26/2025 |
| Oracle Interface Mismatch DoS | High | Solved - 07/24/2025 |
| Unauthorized Fund Transfer Vulnerability Enables Token Theft from Approved Users | High | Solved - 07/25/2025 |
| Unit Mismatch Causes Permanent Staking Failures for Token0 | High | Solved - 06/26/2025 |
| Step-Wise Jumps In the Reward System Allows Attacker To Steal Rewards | High | Solved - 06/26/2025 |
| MEV Extraction via Zero-Slippage Reward Swaps | High | Solved - 06/26/2025 |
| Unsafe Token Approval Pattern | Medium | Solved - 06/26/2025 |
| Potential Flash Loan Oracle Manipulation | Medium | Risk Accepted - 07/26/2025 |
| Stale Ratio Parameters Could Affect Legitimate Function Calls | Medium | Risk Accepted - 07/25/2025 |
| Division by Zero in Ratio Calculations | Low | Acknowledged - 07/26/2025 |
| Hard-coded Slippage in LP Reward Staking Could Cause Reverts | Informational | Solved - 06/26/2025 |
| Misleading Function Names | Informational | Acknowledged - 07/26/2025 |
| Duplicate Code in Swap Functions | Informational | Acknowledged - 07/26/2025 |
| Inconsistent Error Messages | Informational | Acknowledged - 07/26/2025 |
| Magic Numbers Without Named Constants | Informational | Acknowledged - 07/26/2025 |
| Missing NatSpec Documentation | Informational | Acknowledged - 07/26/2025 |
| Missing Event Emission for Critical Configuration Changes | Informational | Solved - 06/26/2025 |
//Critical
//Critical
//High
//High
//High
//High
//High
//High
//High
//Medium
//Medium
//Medium
//Low
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
Bera LRT Contracts
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
