Audit name:
[SCA] Clearpool / Prime-Protocol / Jan2025
Date:
Feb 25, 2025
Table of Content
Introduction
We express our gratitude to the Clearpool.finance team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Clearpool is the DeFi credit marketplace pioneering Real-World Asset lending. Clearpool’s permissionless protocol enables institutions to raise unsecured liquidity directly from DeFi markets, while a separate fully permissioned platform, Clearpool Prime, further meets the compliance needs for wholesale borrowing and lending of digital assets by institutional market participants.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Clearpool.finance |
| Audited By | Kornel Światłowski |
| Approved By | Grzegorz Trawinski, Ataberk Yavuzer |
| Website | https://clearpool.finance/→ |
| Changelog | 21/01/2025 - Preliminary Report |
| 17/02/2025 - Secondary Report | |
| 25/02/2025 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Lending Platform, Factory, Lending/Borrowing, Upgradable |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Clearpool.finance
- Audited By
- Kornel Światłowski
- Approved By
- Grzegorz Trawinski, Ataberk Yavuzer
- Website
- https://clearpool.finance/→
- Changelog
- 21/01/2025 - Preliminary Report
- 17/02/2025 - Secondary Report
- 25/02/2025 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Lending Platform, Factory, Lending/Borrowing, Upgradable
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/clearpool-finance/prime-protocol→ |
| Commit | a9d9e8529755e95e46c01afd6cf623aa28286d0f |
| Retest Commit | baf06f31d6e28b2b6035b687558268ace15e0d7c |
Review Scope
- Commit
- a9d9e8529755e95e46c01afd6cf623aa28286d0f
- Retest Commit
- baf06f31d6e28b2b6035b687558268ace15e0d7c
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are detailed.
Technical description is detailed.
Code quality
Insufficient Gas modeling.
Development environment is configured.
Unused variables.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is present.
Chain compatibility
The smart contracts, along with their respective test cases, were thoroughly executed and validated across multiple blockchain networks, including Optimism, Ethereum, Avalanche, Base, Mantle, and Arbitrum. The testing process ensured proper functionality, expected behavior, and compatibility within each ecosystem, confirming the contracts’ resilience and reliability under various conditions.
System Overview
The Asset library manages a collection of addresses representing assets, providing functions to insert new addresses, check for their existence, and retrieve the entire list. It uses internal mappings to track the presence and index of each address, ensuring efficient lookups and preventing duplicate entries.
The Prime contract acts as a membership database for Clearpool Prime, enabling the registration, whitelisting, and blacklisting of members with associated risk scores. It incorporates functionality to stores and manages supported stablecoin assets, penalties, origination fee rate and spread rate, with a treasury address designated to receive collected fees. These values are used in the Pool contract. Contract is a upgradable contract with the transparent pattern.
The AddressCoder library provides functions for encoding and decoding arrays of Ethereum addresses into and from byte format.
The NZAGuard contract defines a set of modifiers used to enforce input validation in smart contracts. These modifiers ensure that provided addresses are non-zero, values are non-zero, and prevent the use of identical addresses or values where distinct inputs are required.
The PoolFactory contract facilitates the creation and management of decentralized lending pools using a beacon proxy pattern. It integrates with the Prime contract to ensure that only authorized prime members can create pools and enforces input validation through inherited modifiers from NZAGuard. The contract manages various parameters, such as deposit windows and maturities. Contract is a upgradable contract with the beacon pattern.
The Pool contract is designed to manage lending pools, allowing borrowers to create pools with specific terms and lenders to participate by depositing assets. It supports different loan types, including bullet loans and monthly repayment plans, and incorporates various configurable parameters such as interest rates, deposit windows, and pool sizes. It incorporates penalties for delays, ensuring compliance with agreed terms. Contract is a upgradable contract with the beacon pattern.
Privileged roles
The Prime contract uses the OwnableUpgradeable library to restrict access to important functions. The contract owner can:
Alter or creates membership record by setting given address status and risk score.
Blacklists given member address.
Changes risk score of given member address.
Changes the spread rate.
Changes the origination fee rate.
Changes the rolling increment fee rate.
Sets a new treasury address for the contract.
Updates penalty rate per year value.
The PoolFactory contract uses the OwnableUpgradeable library to restrict access to important functions. The contract owner can:
Marks the pools as defaulted.
Changes the prime contract address.
Changes the pool beacon address.
The Pool contract uses the custom role based mechanism to restrict access to important functions.
The borrower role can:
Whitelists and blacklists lenders.
Converts the pool to public.
Fully repays the lender with the principal and interest.
Repays all lenders with the principal and interest.
Repays interest to the lender.
Requests the roll.
Closes the pool.
The prime role can:
Lends funds to the pool.
Creates the callback.
Cancels the callback.
Accepts the roll.
Potential Risks
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.
Flexibility and Risk in Contract Upgrades: 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 Pool smart contract lacks a built-in mechanism to ensure borrowers can reclaim their tokens. However, token security is upheld through off-chain legal protections and agreements between lenders and borrowers, which govern such situations.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8278 | Increased Interest Amount Due to Incorrect Time Calculation in _repayInterestTo | mitigated | Medium | |
| F-2025-8329 | Incorrect Interest Calculation in balanceOf() Function After Maturity Date | fixed | Low | |
| F-2025-8327 | Missing Check for Active Callbacks in requestRoll() Function | fixed | Low | |
| F-2025-8324 | Potential Front-Running in PoolFactory::createPool() Function | accepted | Low | |
| F-2025-8309 | Inconsistent Management of _activeCallbacksCount in Pool Contract | fixed | Low | |
| F-2025-8281 | Missing Input Validation in _Poolinit_unchained Allows Out-of-Range mantissaRate Values | fixed | Low | |
| F-2025-8320 | Missing Two-step Ownership Transfer Process | mitigated | Observation | |
| F-2025-8310 | Potential Gas Optimization by Declaring Variables as Constant | accepted | Observation | |
| F-2025-8308 | Code Contains hardhat Import | 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/clearpool-finance/prime-protocol→ |
| Commit | a9d9e8529755e95e46c01afd6cf623aa28286d0f |
| Whitepaper | N/A |
| Requirements | https://docs.clearpool.finance/clearpool/how-it-works/prime→ |
| Technical Requirements | https://docs.clearpool.finance/clearpool/how-it-works/prime→ |
Scope Details
- Commit
- a9d9e8529755e95e46c01afd6cf623aa28286d0f
- Whitepaper
- N/A
- Technical Requirements
- https://docs.clearpool.finance/clearpool/how-it-works/prime→
Assets in Scope
Pool/IPool.solPool/IPoolFactory.solPool/Pool.solPool/PoolFactory.solPrimeMembership/Asset.solPrimeMembership/IPrime.solPrimeMembership/Prime.solutils/AddressCoder.solutils/NZAGuard.solAppendix 3. Additional Valuables
Verification of System Invariants
During the audit of Clearpool / Prime-Protocol, 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, 6 invariants were tested over 100000 runs each. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Monthly loan - lend random amount | Passed | 100.000 |
| Monthly loan - check penalties after random amount of time | Passed | 100000 |
| Bullet loan - lend random amount | Passed | 100000 |
| Bullet loan - same user lends two time with random amounts | Passed | 100000 |
| Bullet loan - no fee after random time (before maturity date) | Passed | 100000 |
| Bullet loan - fee applied after random time (after maturity date) | Passed | 100000 |
Invariant
- Monthly loan - lend random amount
Test Result
- Passed
Run Count
- 100.000
Invariant
- Monthly loan - check penalties after random amount of time
Test Result
- Passed
Run Count
- 100000
Invariant
- Bullet loan - lend random amount
Test Result
- Passed
Run Count
- 100000
Invariant
- Bullet loan - same user lends two time with random amounts
Test Result
- Passed
Run Count
- 100000
Invariant
- Bullet loan - no fee after random time (before maturity date)
Test Result
- Passed
Run Count
- 100000
Invariant
- Bullet loan - fee applied after random time (after maturity date)
Test Result
- Passed
Run Count
- 100000
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.