← Back to Audits

Demos Contracts V1 - LucidLabs

Prepared by:

Halborn Logo

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

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.
The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.
The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.
The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.
The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

5.1 EXPLOITABILITY

Attack Origin (AO):
Captures whether the attack requires compromising a specific account.
Attack Cost (AC):
Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.
Attack Complexity (AX):
Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.
Metrics:
EXPLOITABILITY METRIC (mem_e)METRIC VALUENUMERICAL 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
Exploitability EE is calculated using the following formula:

E=∏meE = \prod m_e

5.2 IMPACT

Confidentiality (C):
Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.
Integrity (I):
Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.
Availability (A):
Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.
Deposit (D):
Measures the impact to the deposits made to the contract by either users or owners.
Yield (Y):
Measures the impact to the yield generated by the contract for either users or owners.
Metrics:
IMPACT METRIC (mIm_I)METRIC VALUENUMERICAL 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
Impact II is calculated using the following formula:

I=max(mI)+∑mI−max(mI)4I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}

5.3 SEVERITY COEFFICIENT

Reversibility (R):
Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.
Scope (S):
Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.
Metrics:
SEVERITY COEFFICIENT (CC)COEFFICIENT VALUENUMERICAL VALUE
Reversibility (rr)None (R:N)
Partial (R:P)
Full (R:F)		1
0.5
0.25
Scope (ss)Changed (S:C)
Unchanged (S:U)		1.25
1
Severity Coefficient CC is obtained by the following product:

C=rsC = rs

The Vulnerability Severity Score SS is obtained by:

S=min(10,EIC∗10)S = min(10, EIC * 10)

The score is rounded up to 1 decimal places.
SeverityScore Value Range
Critical9 - 10
High7 - 8.9
Medium4.5 - 6.9
Low2 - 4.4
Informational0 - 1.9

6. SCOPE

Files and Repository
(a) Repository: lucid-contracts
(b) Assessed Commit ID: 377fd95
(c) Items in scope:
  • Original scope: `https://github.com/LucidLabsFi/demos-contracts-v1/pull/11`
  • Original commit hash: `dcc9f83551331a0961fb808dcfff8b90c3d156f8`
Out-of-Scope:
Remediation Commit ID:
Out-of-Scope: New features/implementations after the remediation commit IDs.

7. Assessment Summary & Findings Overview

Critical

0

High

0

Medium

0

Low

0

Informational

4

Security analysisRisk levelRemediation Date
Vesting schedule duration not validatedInformationalSolved - 05/08/2025
Inaccurate vesting schedule total amount trackingInformationalNot Applicable
Assumed fixed-point precision in price oracleInformationalSolved
Redundant logic in tier amount calculationInformationalNot Applicable - 05/05/2025

8. Findings & Tech Details

8.1 Vesting schedule duration not validated

//

Informational

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
https://github.com/LucidLabsFi/demos-contracts-v1/commit/b86e2a62cf9d5d8f35f9a5b6f3a97050575ab8f4

8.2 Inaccurate vesting schedule total amount tracking

//

Informational

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

//

Informational

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
https://github.com/LucidLabsFi/demos-contracts-v1/commit/9e40a19b94b825b8c2cbcffc66fcba7a1e9990de

8.4 Redundant logic in tier amount calculation

//

Informational

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.

// Download the full report

Demos Contracts V1

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed

© Halborn 2025. All rights reserved.