Introduction
We express our gratitude to the Mystic Finance team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Mystic Finance is a fork of Aave v3.1 that adds KYC integration, semi-permissioned pools, vault management, and custody control features to the core Aave protocol.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Mystic Finance |
| Audited By | Niccolò Pozzolini |
| Approved By | Grzegorz Trawinski |
| Website | https://mysticfinance.xyz→ |
| Changelog | 20/01/2025 - Preliminary Report |
| 12/02/2025 - Final Report | |
| Platform | Plume Network |
| Language | Solidity |
| Tags | Lending, CDP |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Mystic Finance
- Audited By
- Niccolò Pozzolini
- Approved By
- Grzegorz Trawinski
- Website
- https://mysticfinance.xyz→
- Changelog
- 20/01/2025 - Preliminary Report
- 12/02/2025 - Final Report
- Platform
- Plume Network
- Language
- Solidity
- Tags
- Lending, CDP
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/mystic-finance/lending-v3-origin→ |
| Commit | 0cae4c5 |
| Retest | a740d23 |
Review Scope
- Commit
- 0cae4c5
- Retest
- a740d23
Audit Summary
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 provided.
Technical description is not provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is N/A.
Deployment and basic user interactions are covered with tests.
Negative cases are covered.
Interactions by several users are tested.
System Overview
Mystic Finance is a fork of Aave v3.1 that adds KYC integration, semi-permissioned pools, vault management, and custody control features to the core Aave protocol. The main contracts of the audit scope are:
Vault: an ERC4626-compliant vault contract that allows users to deposit a base asset which is then allocated across multiple Aave-like lending pools ("Mystic pools") according to curator-defined allocation percentages.
VaultFactory: a factory that allows authorized curators to create and manage MysticVault instances while maintaining a registry of deployed vaults.
SemiPermissionedPool: a specialized version of the Aave Pool contract that implements permission controls for liquidators and pool users while providing calldata-optimized functions.
KYCPortal: this contract manages KYC (Know Your Customer) permissions and access control for partners, users, and liquidators in a DeFi protocol through a role-based system.
CustodyController: a custody management contract that handles asset deposits and withdrawals with multi-role authorization, allowing designated operators to request withdrawals that must be approved by custodians before execution.
Privileged roles
Vault
OWNER: Can set fees, fee recipient, and has all curator capabilities.
CURATOR: Can add/remove other curators, add/update pools and asset allocations, set withdrawal timelock, set max deposit/withdrawal limits.
FEE_RECIPIENT: Can withdraw accrued fees.
VaultFactory
DEFAULTADMINROLE: Can add/remove curators.
CURATOR_ROLE: Can create new vaults.
owner: Set at deployment, stored but not used in this contract (though passed to created vaults).
SemiPermissionedPool
POOL_USER: Can perform borrowing, repaying, rate swapping, collateral management, and rebalancing operations.
LIQUIDATOR: Can perform liquidation calls on positions.
ACL_MANAGER: Controls the access list that determines who is a pool user or liquidator.
KYCPortal
OWNER: Can add relayers.
RELAYER: Can add/remove pool users and partners.
LIQUIDATOR_ADMIN: Can add/remove liquidators (this role is granted to partners).
PARTNER: A special status that grants all pool user permissions plus liquidator admin capabilities.
LIQUIDATOR: Can perform liquidations (with different types: regular, investor, regulated).
CustodyController
DEFAULTADMINROLE: Can grant/revoke all other roles.
TREASURYMANAGERROLE: Can pause/unpause, add assets/targets, update custody wallet/locker, set withdrawal limits, manage withdrawal operators.
WITHDRAWALOPERATORROLE: Can deposit assets and request withdrawals.
CUSTODIANOPERATORROLE: Can update withdrawal request status and trigger callbacks.
Potential Risks
The Vault contract exhibits inconsistent implementation patterns, containing remnants of multi-asset functionality alongside single-asset code. This architectural inconsistency creates confusion about the intended behavior, complicates code maintenance, and increases the risk of introducing bugs during future modifications, potentially masking security vulnerabilities.
The absence of key contracts like the VaultController from the audit scope poses a significant security risk to the protocol. These central components likely interact with and control critical functionality of the audited contracts, making it impossible to fully assess the security implications and potential vulnerabilities of the system as a whole.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8242 | APR Calculation Returns Inflated Values When Assets Are Not Fully Allocated | fixed | High | |
| F-2025-8233 | Rebalancing Function Can Lead to Funds Lock Due to Incorrect Operation Order | fixed | High | |
| F-2025-8227 | Withdrawal Limit Bypass Through Share Distribution | accepted | High | |
| F-2025-8219 | ERC4626 Vault Vulnerable to Inflation Attack Due to Zero Initial Supply | fixed | High | |
| F-2025-8150 | Incorrect Array Index Handling in Liquidator Removal Process | fixed | High | |
| F-2025-8149 | Partner Removal Function Fails to Properly Remove Partner Status | fixed | High | |
| F-2025-8241 | Oracle Price Bounds Not Validated in Price Conversion Functions | accepted | Medium | |
| F-2025-8240 | Missing Oracle Staleness Check in Price Conversion Functions | fixed | Medium | |
| F-2025-8229 | Missing Rebalancing After Withdrawal Operations | fixed | Medium | |
| F-2025-8226 | Missing SafeERC20 Usage for Token Operations can Lead to Funds Lock | fixed | Medium |
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/mystic-finance/lending-v3-origin→ |
| Commit | 0cae4c5 |
| Retest commit | a740d235 |
| Requirements | https://github.com/mystic-finance/lending-v3-origin/blob/mfi-v1/README.md→ |
Scope Details
- Commit
- 0cae4c5
- Retest commit
- a740d235
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Mystyc Finance, 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, 9 invariants were tested over 100,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| testFuzzDeposit: Ensures that deposits with randomly generated amounts respect system invariants, such as maintaining proper balances, honoring limits, and correctly updating contract states. | Passed | 100k |
| testFuzzWithdrawalRequest: Verifies that withdrawal requests uphold invariants across a range of deposit and withdrawal combinations, ensuring no balance mismatches or state inconsistencies. | Passed | 100k |
| testFuzzBorrow: Tests borrowing functionality by applying random collateral and borrow amounts to ensure the system adheres to invariants like collateralization ratios and borrow limits. | Passed | 100k |
| testFuzzAssetAllocation: Evaluates asset allocation by testing varying allocation percentages to confirm that the system respects invariants such as total allocation limits and proper value mapping. | Passed | 100k |
| testFuzzDepositAndWithdraw: Simulates the full deposit-withdraw cycle with random amounts and timelocks to confirm that all related invariants, including state transitions and balance integrity, are upheld. | Passed | 100k |
| testFuzzRepayment: Ensures loan repayment invariants by testing with random borrow and repayment amounts, verifying proper balance adjustments and interest accrual handling. | Passed | 100k |
| testFuzzMultipleDeposits: Evaluates system behavior with multiple deposits of varying amounts, ensuring that invariants such as balance accuracy and aggregate limits remain intact. | Passed | 100k |
| testFuzzUpdateAssetAllocation: Verifies the integrity of asset allocation updates, ensuring that changes comply with allocation constraints and do not violate system invariants. | Passed | 100k |
| testFuzzFeesAccrual: Tests fee accrual and withdrawal processes with random transaction amounts to validate that fee-related invariants, including accurate accounting and withdrawal mechanics, are consistently upheld. | Passed | 100k |
Invariant
- testFuzzDeposit: Ensures that deposits with randomly generated amounts respect system invariants, such as maintaining proper balances, honoring limits, and correctly updating contract states.
Test Result
- Passed
Run Count
- 100k
Invariant
- testFuzzWithdrawalRequest: Verifies that withdrawal requests uphold invariants across a range of deposit and withdrawal combinations, ensuring no balance mismatches or state inconsistencies.
Test Result
- Passed
Run Count
- 100k
Invariant
- testFuzzBorrow: Tests borrowing functionality by applying random collateral and borrow amounts to ensure the system adheres to invariants like collateralization ratios and borrow limits.
Test Result
- Passed
Run Count
- 100k
Invariant
- testFuzzAssetAllocation: Evaluates asset allocation by testing varying allocation percentages to confirm that the system respects invariants such as total allocation limits and proper value mapping.
Test Result
- Passed
Run Count
- 100k
Invariant
- testFuzzDepositAndWithdraw: Simulates the full deposit-withdraw cycle with random amounts and timelocks to confirm that all related invariants, including state transitions and balance integrity, are upheld.
Test Result
- Passed
Run Count
- 100k
Invariant
- testFuzzRepayment: Ensures loan repayment invariants by testing with random borrow and repayment amounts, verifying proper balance adjustments and interest accrual handling.
Test Result
- Passed
Run Count
- 100k
Invariant
- testFuzzMultipleDeposits: Evaluates system behavior with multiple deposits of varying amounts, ensuring that invariants such as balance accuracy and aggregate limits remain intact.
Test Result
- Passed
Run Count
- 100k
Invariant
- testFuzzUpdateAssetAllocation: Verifies the integrity of asset allocation updates, ensuring that changes comply with allocation constraints and do not violate system invariants.
Test Result
- Passed
Run Count
- 100k
Invariant
- testFuzzFeesAccrual: Tests fee accrual and withdrawal processes with random transaction amounts to validate that fee-related invariants, including accurate accounting and withdrawal mechanics, are consistently upheld.
Test Result
- Passed
Run Count
- 100k
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.