Audit name:
[SCA] Credbull | Credbull-DeFi | Oct2024
Date:
Dec 17, 2024
Table of Content
Introduction
We express our gratitude to the Credbull team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Credbull manages the first licensed on-chain private credit fund that emphasizes governance and transparency in strategy, risk management, and off-chain asset allocation. This is done through Vaults that will provide ERC1155 tokens (shares) to users in exchange for their ERC20 USDC (assets) deposits. Users will later be able to redeem their shares for to recover their deposits and some extra yield, generated from an off-chain strategy.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Credbull |
| Audited By | David Camps Novi, Paul Clemson |
| Approved By | Ataberk Yavuzer |
| Website | https://credbull.io/→ |
| Changelog | 23/10/2024 - Preliminary Report |
| 17/12/2024 - Final Report | |
| Platform | Plume Network→ |
| Language | Solidity |
| Tags | Vault, Proxy, ERC1155 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Credbull
- Audited By
- David Camps Novi, Paul Clemson
- Approved By
- Ataberk Yavuzer
- Website
- https://credbull.io/→
- Changelog
- 23/10/2024 - Preliminary Report
- 17/12/2024 - Final Report
- Platform
- Plume Network→
- Language
- Solidity
- Tags
- Vault, Proxy, ERC1155
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/credbull/credbull-defi→ |
| Commit | Initial commit - a3316f3; final commit - e38e285. |
Review Scope
- Commit
- Initial commit - a3316f3; final commit - e38e285.
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided.
Technical description are provided.
Code quality
NatSpec is included.
The development environment is configured.
Test coverage
Code coverage of the project is 95% (branch coverage).
Deployment and basic user interactions are covered with tests.
System Overview
Credbull manages the first licensed on-chain private credit fund that emphasizes governance and transparency in strategy, risk management, and off-chain asset allocation. This is done through Vaults that will provide ERC-1155 tokens (shares) to users in exchange for their ERC20 USDC (assets) deposits. Users will later be able to redeem their shares for to recover their deposits and some extra yield, generated from an off-chain strategy.
The project consists of the following contracts:
AbstractYieldStrategy.sol - calculates the number of periods based on the input time bonds.
CalcDiscounted.sol - helper library to calculate principals and yields.
CalcInterestMetadata.sol - defines context variables.
CalcSimpleInterest.sol - helper library to calculate yield.
RedeemOptimizerFIFO.sol - provides the optimal withdrawal requests based on the desired shares or assets to be obtained.
Timer.sol - helper library to calculate periods and timestamps.
TripleRateContext.sol - defines context variables.
LiquidContinuousMultiTokenVault.sol - main entry-point of the protocol for the users to deposit and withdraw assets in exchange for some shares/yield.
MultiTokenVault.sol - baseline vault contract inherited by the LiquidContinuousMultiTokenVault.
TimelockAsyncUnlock.sol - manages the requests to unlock assets from the vault.
SimpleInterestYieldStrategy.sol - defines a yield strategy based on the number of periods.
TripleRateYieldStrategy.sol - defines a yield strategy based on a combination of full maturity periods and the other periods.
Privileged roles
Operator can
Change the addresses of
_redeemOptimizer,_yieldStrategy.Set a new interest rate and the vault start timestamp.
Pause and unpause the contract.
Lock the tokens of a user (requires ERC20 allowance).
Upgrader can
Upgrade the vault contracts.
Asset Manager can
Withdraw assets from the vault.
Potential Risks
The project utilizes Solidity version 0.8.20 or higher, which includes the introduction of the PUSH0 (0x5f) opcode. This opcode is currently supported on the Ethereum mainnet but may not be universally supported across other blockchain networks. Consequently, deploying the contract on chains other than the Ethereum mainnet, such as certain Layer 2 (L2) chains or alternative networks, might lead to compatibility issues or execution errors due to the lack of support for the PUSH0 opcode. In scenarios where deployment on various chains is anticipated, selecting an appropriate Ethereum Virtual Machine (EVM) version that is widely supported across these networks is crucial to avoid potential operational disruptions or deployment failures.
The funds held by the contract depend on their correct management by the system admins: they must ensure the contract will always have the required funds to fulfil each redeem request with the corresponding interest.
The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.
The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.
The yield strategy used in the protocol is defined by the system role OPERATOR_ROLE, relying on their correct setup to have a proper functioning of the yield calculations.
In the TripleRateYieldStrategy contract, if a deposit was made prior to the latest interest valid timestamp, the system will take into account the previous period's interest in order to compute the yield obtained by the user. However, this check assumes there is only a single previous interest period (i.e. current interest plus a previous period only); if there was an even earlier interest period (i.e. current interest plus two previous periods), or more, the earliest periods would not be taken into account. Although it is technically possible to have more than two interest periods, the development team communicated that each vault will never have more than two.
The system includes a pausable feature, which allows the OPERATOR_ROLE to halt any transfer of shares at will: deposits, withdraws and token transfers cannot execute.
Protocol users should note that yield will be calculated for deposits up to the period in which they perform a request for redeeming their funds. If, per example, the notice period to withdraw funds is 5 days, none of these 5 days will be accounted for yield calculations.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-6592 | Incorrect validation of spender approval in _withdraw allows theft of user funds | fixed | Critical | |
| F-2024-6665 | Public method allows malicious users to cause DoS on other users withdrawals | fixed | High | |
| F-2024-6713 | Users can earn yield while depositing funds for only a few seconds | fixed | High | |
| F-2024-6708 | Optimize function receives incorrect owner in requestRedeem leading to incorrect request data being stored | fixed | Low | |
| F-2024-6700 | Redeem Requests Cannot be Cancelled or Modified Until Redeem Period | fixed | Low | |
| F-2024-6693 | The optimize function fails for deposit/redeem amounts less than $1 | fixed | Low | |
| F-2024-6721 | Missing Storage Gaps | fixed | Observation | |
| F-2024-6699 | Incorrect Order of Parameters Result in Wrong Calculations | fixed | Observation | |
| F-2024-6678 | Floating Pragma | accepted | Observation |
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/credbull/credbull-defi/→ |
| Commit | a3316f3 |
| Whitepaper | https://docs.credbull.io/docs/litepaper→ |
| Requirements | https://github.com/credbull/credbull-defi/blob/docs/liquid-audit/packages/contracts/docs/src/SUMMARY.md→ |
| Technical Requirements | https://github.com/credbull/credbull-defi/tree/docs/liquid-audit/packages/contracts#readme→ |
Scope Details
- Commit
- a3316f3
- Whitepaper
- https://docs.credbull.io/docs/litepaper→
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Credbull, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Forge foundry fuzz tests were used to test how the protocol handles a wide variety of 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 Foundry fuzzing suite was prepared for this task, and throughout the assessment, 4 invariants were tested over 40,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Earned yield should match expected earned yield (SimpleInterestYieldStrategy) | Passed* | 10,000 |
| Earned yield should match expected earned yield (TripleRateYieldStrategy) | Passed* | 10,000 |
| Withdrawing any amount less than deposit amount should cause no issues | Passed* | 10,000 |
| Users should be able to withdraw full amount after a partial withdraw | Passed* | 10,000 |
Invariant
- Earned yield should match expected earned yield (SimpleInterestYieldStrategy)
Test Result
- Passed*
Run Count
- 10,000
Invariant
- Earned yield should match expected earned yield (TripleRateYieldStrategy)
Test Result
- Passed*
Run Count
- 10,000
Invariant
- Withdrawing any amount less than deposit amount should cause no issues
Test Result
- Passed*
Run Count
- 10,000
Invariant
- Users should be able to withdraw full amount after a partial withdraw
Test Result
- Passed*
Run Count
- 10,000
*Tests passed after ensuring the minimum amount deposited/withdrawn was greater than 1e6 (this issue was raised as part of the audit's findings)
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.