Prepared by:
HALBORN
Last Updated 05/15/2025
Date of Engagement: April 22nd, 2025 - May 1st, 2025
Summary
100% of all REPORTED Findings have been addressed
All findings
4
Critical
0
High
0
Medium
0
Low
0
Informational
4
Table of Contents
1. Summary
2. Introduction
LucidLabs engaged our security analysis team to conduct a comprehensive security assessment of their smart contract ecosystem. The primary aim was to meticulously assess the security architecture of the smart contracts to pinpoint vulnerabilities, evaluate existing security protocols, and offer actionable insights to bolster security and operational efficacy of their smart contract framework. Our assessment was strictly confined to the smart contracts provided, ensuring a focused and exhaustive analysis of their security features.
3. Assessment Summary
Our engagement with LucidLabs spanned a 1-week period, during which we dedicated one full-time security engineer equipped with extensive experience in blockchain security, advanced penetration testing capabilities, and profound knowledge of various blockchain protocols. The objectives of this assessment were to:
- Verify the correct functionality of smart contract operations.
- Identify potential security vulnerabilities within the smart contracts.
- Provide recommendations to enhance the security and efficiency of the smart contracts.
4. Test Approach and Methodology
Our testing strategy employed a blend of manual and automated techniques to ensure a thorough evaluation. While manual testing was pivotal for uncovering logical and implementation flaws, automated testing offered broad code coverage and rapid identification of common vulnerabilities. The testing process included:
- A detailed examination of the smart contracts' architecture and intended functionality.
- Comprehensive manual code reviews and walkthroughs.
- Functional and connectivity analysis utilizing tools like Solgraph.
- Customized script-based manual testing and testnet deployment using Foundry.
This executive summary encapsulates the pivotal findings and recommendations from our security assessment of LucidLabs smart contract ecosystem. By addressing the identified issues and implementing the recommended fixes, LucidLabs can significantly boost the security, reliability, and trustworthiness of its smart contract platform.
5. RISK METHODOLOGY
5.1 EXPLOITABILITY
Attack Origin (AO):
Attack Cost (AC):
Attack Complexity (AX):
Metrics:
| 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 |
5.2 IMPACT
Confidentiality (C):
Integrity (I):
Availability (A):
Deposit (D):
Yield (Y):
Metrics:
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I: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 |
5.3 SEVERITY COEFFICIENT
Reversibility (R):
Scope (S):
Metrics:
| 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 |
6. SCOPE
- Original scope: `https://github.com/LucidLabsFi/demos-contracts-v1/pull/11`
- Original commit hash: `dcc9f83551331a0961fb808dcfff8b90c3d156f8`
7. Assessment Summary & Findings Overview
Critical
0
High
0
Medium
0
Low
0
Informational
4
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Vesting schedule duration not validated | Informational | Solved - 05/08/2025 |
| Inaccurate vesting schedule total amount tracking | Informational | Not Applicable |
| Assumed fixed-point precision in price oracle | Informational | Solved |
| Redundant logic in tier amount calculation | Informational | Not Applicable - 05/05/2025 |
8. Findings & Tech Details
8.1 Vesting schedule duration not validated
//
Description
In the contract, there is a lack of validation for the vesting schedule duration, similar to the minMarketDuration validation found in other contracts. Without a minLinearDuration check, the vesting schedule can be created with a duration of zero, leading to a revert with the error message "duration must be > 0". This oversight can disrupt the contract's functionality and lead to unexpected reverts during execution.
BVSS
Recommendation
Introduce a minLinearDuration variable to enforce a minimum duration for vesting schedules. This variable should be initialized to a sensible default value, such as 1 day, and used in conditional checks to validate the duration parameter when creating vesting schedules. This will prevent the creation of vesting schedules with invalid durations and ensure consistent contract behavior.
Remediation Hash
8.2 Inaccurate vesting schedule total amount tracking
//
Description
In the BondVesting contract, the vestingSchedulesTotalAmountByToken mapping is used to track the total amount of vesting schedules for each token. However, this value is not decremented when tokens are released, leading to a potential overestimation of the total vesting amount. This discrepancy can result in misleading data regarding the actual amount of tokens still under vesting, which may affect decision-making processes based on this information.
BVSS
Recommendation
Evaluate the necessity of maintaining the vestingSchedulesTotalAmountByToken mapping. If accurate tracking of the total vesting amount is required, implement a decrement operation within the release function to adjust the total amount when tokens are released. This will ensure that the mapping accurately reflects the current state of vesting schedules and provides reliable data for stakeholders.
Remediation Comment
The functionality is intended.
8.3 Assumed fixed-point precision in price oracle
//
Description
In the BondSteerOracle contract, the twapOracle.getPrice() function is used to retrieve token prices, with the assumption that these prices are in 18-decimal fixed-point format. This assumption, if incorrect, can lead to miscalculations in financial operations that depend on these prices. Without explicit confirmation or re-scaling, the contract may operate on inaccurate data, potentially affecting the accuracy of price-dependent logic.
BVSS
Recommendation
To ensure the correctness of price calculations, explicitly verify that the twapOracle provides prices in 18-decimal fixed-point format or document that fact. This can be achieved by either asserting the decimal precision within the contract or re-scaling the prices to the expected format. Implementing this verification step will safeguard against potential errors arising from incorrect decimal assumptions.
Remediation Hash
8.4 Redundant logic in tier amount calculation
//
Description
In both XERC20Votes and XERC20VotesUpgradeable, the calculateBridgeTax function contains redundant conditional logic when determining the tierAmount for each bridge tax tier. Specifically, the if block handling the final tier replicates the same assignment as the else block in the case where remainingAmount is less than or equal to the difference between the current threshold and the previous one. This redundancy increases the cognitive load and could lead to confusion or potential inconsistency during future modifications, without adding functional value.
BVSS
Recommendation
Simplify the tierAmount assignment logic by removing the special case for the final tier. The same result is achieved by relying on the else condition, which already correctly handles the case where all the remaining amount fits within the current tier. This makes the function more concise and easier to audit and maintain.
Remediation Comment
As per business decision, the client wants to be able to charge the last tier at the remaining amount, so that we still collect the tax if the amount goes above the latest threshold
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.
Table of Contents
// Download the full report
Demos Contracts V1
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed