Audit name:
[SCA] Kabila / Vesting + Staking / Dec2024
Date:
Jan 7, 2025
Table of Content
Introduction
We express our gratitude to the Kabila team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Kabila is a complete NFT platform that seeks to empower Hedera creators and communities with robust and easy-to-use NFT tools.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Kabila |
| Audited By | Seher Saylik |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://www.kabila.app→ |
| Changelog | 03/01/2025 - Preliminary Report |
| 07/01/2025 - Final Report | |
| Platform | Hedera Network |
| Language | Solidity |
| Tags | Vesting, Staking, ERC20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Kabila
- Audited By
- Seher Saylik
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://www.kabila.app→
- Changelog
- 03/01/2025 - Preliminary Report
- 07/01/2025 - Final Report
- Platform
- Hedera Network
- Language
- Solidity
- Tags
- Vesting, Staking, ERC20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Kabila-Tech/lazy-token-vesting→ |
| Commit | f3104024de458868d49a39345c2f4f3b84d76520 - For LazyVestingContract, HederaResponseCodes and LazyVestingMultiSpeedContract |
| Commit | d09dbfe1bad18a3b678adb1cf886f5341b7a0085 - For Mothership contract |
Review Scope
- Commit
- f3104024de458868d49a39345c2f4f3b84d76520 - For LazyVestingContract, HederaResponseCodes and LazyVestingMultiSpeedContract
- Commit
- d09dbfe1bad18a3b678adb1cf886f5341b7a0085 - For Mothership contract
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are partially missed.
Technical description is provided.
Code quality
Some Gas inefficient usages were found.
The development environment is configured.
Test coverage
The code coverage of the MotherShip contract is 0% (branch coverage) as no tests have been provided. For the Vesting contract, tests are available, but coverage could not be measured.
System Overview
Kabila is a staking and vesting protocol with the following contracts:
HederaResponseCodes — a contract that defines a comprehensive set of error and response codes as constants to standardize the handling of various outcomes and issues in transactions and operations within a Hedera-based system.
LazyVestingContract — a contract that manages the vesting of Hedera HBAR and Hedera Token Service (HTS) tokens for a specified beneficiary, supporting linear vesting schedules. All funds can be released immediately if the vesting is accelerated, while cancellation halts the vesting process and allows the owner to reclaim the remaining tokens
LazyVestingMultiSpeedContract — a contract that extends the LazyVestingContract to introduce a customizable multi-speed vesting schedule, allowing the release of tokens according to specified epochs and percentages. Each epoch defines a time period, and the corresponding percentage determines the amount of tokens vested during that period. The contract ensures that the sum of the epochs equals the vesting duration and the percentages add up to 100, while supporting features like acceleration for immediate full release or cancellation to reclaim tokens by the owner.
MotherShip — a contract thatfacilitates the swapping of KBL tokens to and from xKBL tokens on the Hedera network. It manages the creation and association of the fungible xKBL token and provides mechanisms for users to deposit KBL tokens to mint xKBL, which represents a share in the contract's KBL balance
Privileged roles
The owner of the LazyVestingContract can;
add additional HTS tokens
cancel vesting
accelerate vesting
transfer Hbars when vesting is canceled
transfer fungible tokens when vesting is canceled
Potential Risks
The cancelVesting feature allows the owner to terminate vesting at any time and withdraw all funds to any address if the vesting type is cancelable. While this ensures flexibility and immediate fund access post-cancellation, it bypasses the planned vesting schedule, potentially impacting beneficiaries' expectations and trust.
The owner can directly withdraw funds (
transferHbarortransferFungible) post-cancellation, leaving the beneficiary reliant on the owner's actions.
If the contract is configured for fungible tokens only, any native HBARs transferred to it may become permanently inaccessible as vestedAmount(uint256 timestamp) function returns 0 when ONLY_FUNGIBLES is set to true.
The accelerateVesting function allows the owner to release all funds immediately, overriding the vesting schedule.
The audited contracts rely on the HederaTokenService for token association, token creation and proper token transfers. The safety or reliability of these interactions is not validated, as the HederaTokenService contract lies outside the scope of this review.
If deployed on a blockchain with a mempool and frontrunning capabilities, malicious users can exploit the system by monitoring the mempool for reward transactions intended for the MotherShip contract. By submitting a frontrunning transaction to stake a significant amount of KBL just before the reward transfer is processed, they can artificially inflate their share of the total rewards. This allows them to claim a disproportionate amount of rewards without remaining in a staked position for a meaningful duration.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-8022 | Lack of Validation for Zero Epoch Durations | accepted | Low | |
| F-2025-8063 | Potential Zero Value for what in enter and leave Functions | fixed | Low | |
| F-2024-8024 | Unnecessary Initialization to 0 | accepted | Observation | |
| F-2024-8023 | Public Functions Not Marked as External | accepted | Observation | |
| F-2024-8021 | Event Missing for Critical Functions in LazyVestingContract Contract | accepted | Observation | |
| F-2025-8062 | Missing Detailed Error Messages in Constructor Reverts | accepted | Observation | |
| F-2025-8061 | Event Missing for Critical Functions in Mothership Contract | accepted | Observation | |
| F-2025-8065 | kbl and xKbl Could Be Declared as immutable | fixed | Observation |
Identify vulnerabilities in your smart contracts.
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/Kabila-Tech___lazy-token-vesting→ |
| Commit | f3104024de458868d49a39345c2f4f3b84d76520 - For LazyVestingContract, HederaResponseCodes and LazyVestingMultiSpeedContract, d09dbfe1bad18a3b678adb1cf886f5341b7a0085 - For Mothership contract |
| Retest commit | 0515d461948898bcb2b01224ab2819275bea303a - For Mothership contract |
| Whitepaper | N/A |
| Requirements | https://academy.kabila.app/token/distribution→ |
| Technical Requirements | N/A |
Scope Details
- Commit
- f3104024de458868d49a39345c2f4f3b84d76520 - For LazyVestingContract, HederaResponseCodes and LazyVestingMultiSpeedContract, d09dbfe1bad18a3b678adb1cf886f5341b7a0085 - For Mothership contract
- Retest commit
- 0515d461948898bcb2b01224ab2819275bea303a - For Mothership contract
- Whitepaper
- N/A
- Requirements
- https://academy.kabila.app/token/distribution→
- Technical Requirements
- N/A
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Kabila, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry →, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 5 invariants were tested over 10,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
LazyVestingMultiSpeedContract::_vestingSchedule() Correctly calculates releasable amounts for a given time point across multiple epochs | Passed | 10k |
LazyVestingMultiSpeedContract::_vestingSchedule() Accurately computes releasable amounts based on dynamic percentage allocations for different epochs at various time points | Passed | 10k |
LazyVestingContract::release() Correctly calculates and releases fungible tokens based on partial vesting across different vesting periods. | Passed | 10k |
LazyVestingContract::release() Double-release attempts are prevented after tokens have already been released. | Passed | 10k |
LazyVestingContract::releasable() All tokens must be fully releasable once the vesting period has ended. | Passed | 10k |
Mothership::enter Any amount should be staked, reducing the user's KBL balance and increasing the contract's KBL balance. | Passed | 10k |
Mothership::leave Any staked amount can be withdrawn. | Passed | 10k |
Mothership::leave Rewards distributed to the contract are allocated correctly based on users' stakes.. | Passed | 10k |
Invariant
LazyVestingMultiSpeedContract::_vestingSchedule()Correctly calculates releasable amounts for a given time point across multiple epochsTest Result
- Passed
Run Count
- 10k
Invariant
LazyVestingMultiSpeedContract::_vestingSchedule()Accurately computes releasable amounts based on dynamic percentage allocations for different epochs at various time pointsTest Result
- Passed
Run Count
- 10k
Invariant
LazyVestingContract::release()Correctly calculates and releases fungible tokens based on partial vesting across different vesting periods.Test Result
- Passed
Run Count
- 10k
Invariant
LazyVestingContract::release()Double-release attempts are prevented after tokens have already been released.Test Result
- Passed
Run Count
- 10k
Invariant
LazyVestingContract::releasable()All tokens must be fully releasable once the vesting period has ended.Test Result
- Passed
Run Count
- 10k
Invariant
Mothership::enterAny amount should be staked, reducing the user's KBL balance and increasing the contract's KBL balance.Test Result
- Passed
Run Count
- 10k
Invariant
Mothership::leaveAny staked amount can be withdrawn.Test Result
- Passed
Run Count
- 10k
Invariant
Mothership::leaveRewards distributed to the contract are allocated correctly based on users' stakes..Test Result
- Passed
Run Count
- 10k
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.