Audit name:
[SCA] Zharta | DEX | Dec2022
Date:
Jan 20, 2023
Table of Content
Introduction
We express our gratitude to the Zharta team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Zharta stands for individual empowerment via financial sovereignty, made possible through a foundation of responsible decentralization.
| title | content |
|---|---|
| Platform | EVM |
| Language | Vyper |
| Timeline | 09/12/2022 - 23/01/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/Zharta/protocol-v1→ |
| Commit | 8e1875d7bcc14f8d56c20ac100517def469dd63b |
Review Scope
- Repository
- https://github.com/Zharta/protocol-v1→
- Commit
- 8e1875d7bcc14f8d56c20ac100517def469dd63b
Audit Summary
10/10
70%
9/10
7/10
The system users should acknowledge all the risks summed up in the risks section of the report
Document Information
This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.
The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Zharta |
| Audited By | Hacken |
| Website | https://www.zharta.io→ |
| Changelog | 09/12/2022 - Initial Review |
| 06/01/2023 - Second Review | |
| 20/01/2023 - Third Review | |
| 23/01/2023 - Fourth Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Zharta
- Audited By
- Hacken
- Website
- https://www.zharta.io→
- Changelog
- 09/12/2022 - Initial Review
- 06/01/2023 - Second Review
- 20/01/2023 - Third Review
- 23/01/2023 - Fourth Review
System Overview
The Zharta protocol includes smart contracts governing lending pools, loans, and liquidations. Lenders deposit funds, with a lock period, withdrawable after. The amount withdrawable is always greater than the total deposited, but may be tied up in loans. Upper bound on borrowed to deposited ratio. Interest from loans is distributed to lenders, with the system receiving a fraction. Lenders can buy collateral after loan default. Core contracts define data structures, Periphery contracts manage protocol logic and interaction.
The system consists of the following contracts:
CollateralVaultCore — a simple contract for storing and transferring ERC721 collaterals.
CollateralVaultPeripheral - a simple contract that handles business logic for CollateralVaultCore contract.
LendingPoolPeripheral - contract that allows to deposit and withdraw funds for users and invest these funds for loans contract.
LiquiditationCore - the contract that stores liquidation data and provides an API for LiquiditationPeripheral to add/remove liquidations.
LiquiditationPeripheral \- business logic contract, that interacts with multiple contracts to add liquidations, pay loans, buy NFT grace/lender period and liquidate NFTX.
LiquidityControls - helper contract that helps to validate if landing out of lock period, calculate pool, loan and collection share limits.
Loans - business logic contract to create and pay loan.
LoansCore - helper contracts to store loans and update their values.
Privileged roles
The CollateralVaultCore contract has the next privileged roles:
owner can:
transfer ownership.
set new collateral vault peripheral address.
collateral vault peripheral can:
approve ERC-721 token.
transfer from sender to contract ERC-721 token.
transfer from the contract ERC-721 token.
The CollateralVaultPeripheral contract has the next privileged roles:
owner can:
transfer ownership.
add/remove loan peripheral address.
set liquidation peripheral address.
loan peripheral can:
store collateral.
transfer collateral from loan.
liquidation peripheral can:
transfer collateral from liquidation.
approve backstop buyer.
The LendingPoolPeripheral contract has the next privileged roles:
owner can:
transfer ownership.
change max capital efficiency.
change protocol wallet.
change protocol fee share.
set loan peripheral address.
set liquidation peripheral address.
set liquidation control address.
change whitelist status.
add/remove addresses from whitelist.
change pool active status.
deprecate pool.
loans contract can:
invest funds from the contract.
send back funds after loans contract investment.
liquidation peripheral can:
sends funds from liquidation to the contract.
The LiquidationsCore contract has the next privileged roles:
owner can:
transfer ownership.
set liquidation peripheral address.
add/remove loan core address.
liquidation peripheral can:
add/remove liquidation.
The LiquidationsPeripheral contract has the next privileged roles:
owner can:
transfer ownership.
set grace period duration.
set lenders period duration.
set auction period duration.
set liquidation core address.
add/remove loans core addresses.
add/remove lending peripheral addresses.
set collateral peripheral address.
set NFTX vault factory address.
set NFTX marketplace zap address.
set sushi router address.
transfer collateral after auction period.
The LiquidityControls contract has the next privileged roles:
owner can:
set max pool share conditions.
set max loans share conditions.
set max collections share conditions.
change lock period duration.
The Loans contract has the next privileged roles:
owner can:
transfer ownership.
set max allowed loans.
set max allowed loans duration.
set max loan amount.
change interest actual period.
add/remove collateral from whitelist.
set lending pool peripheral address.
set collateral vault peripheral address.
set liquidation peripheral address.
set liquidity controls address.
change wallet whitelist status.
add/remove wallet from whitelist.
change contract accepting loans status.
deprecate contract.
The LoansCore contract has the next privileged roles:
owner can:
transfer ownership.
set loans peripheral address.
loans peripheral can:
add/remove collateral from loan.
update collaterals.
add loan.
update loan started.
update loan invalidated.
update loan paid amount.
update paid loan.
update default loan.
update canceled loan.
update highest single collateral loan.
update highest bundle collateral loan.
update highest repayment.
update highest defaulted loan.
Executive Summary
Documentation quality
The total Documentation quality score is 7 out of 10.
The documentation gives a good overview of the system, and it is illustrated.
Technical description is not provided. There is little information about actual formulas for fees, interests, earnings, collateral pricing. Ideally, the documentation should be detailed enough to be used as requirements for developers of this very system.
Highly permissive owner’s role is not described in the documentation.
It is claimed that Zharta indexer calls LoansPeripheral validate/invalidate methods. The contract name is actually different, and there are no such methods.
Code quality
The total Code quality score is 9 out of 10.
Code is well-written and formatted, architecture is well-designed.
Presence of duplicate code.
Code is documented with comments.
Test coverage
Code coverage of the project is 70%.
Deployment and basic user interactions are covered with tests.
Negative cases coverage is missed.
Some tests are failing.
Weak coverage for the LiquidationsPeripheral, LiquidityControls, and LoansCore contracts.
Security score
Upon auditing, the code was found to contain 2 critical, 17 high, 5 medium, and 5 low severity issues. Out of these, 14 issues have been addressed and resolved, leading to a Security score of 10 out of 10.
All identified issues are detailed in the “Findings” section of this report.
Summary
The comprehensive audit of the customer's smart contract yields an overall score of 8.4. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
Highly permissive role access allows the owner to update implementations in contracts.
NFTX integration is out of the audit scope, but the existing system interacts with them.
The system relies on some contract methods being called at right timings (e.g. by off-chain software) - that may not happen for various reasons, and lead to unpleasant consequences. For example, if a loan maturity has passed, the loan is stuck until the default is initiated, which defers the ability of the borrower to buy the collateral back during the grace period.
LiquidityControls does not have a key-rotation scheme like the other contracts. If the single private key for the “owner” address is lost, there is no way to regain control.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2022-1808 | Requirements Violation | fixed | Critical | |
| F-2022-1807 | Access Control Violation | fixed | Critical | |
| F-2022-1824 | Highly Permissive Role Access | mitigated | High | |
| F-2022-1825 | Funds Lock | fixed | High | |
| F-2022-1823 | Highly Permissive Role Access | mitigated | High | |
| F-2022-1822 | Highly Permissive Role Access | mitigated | High | |
| F-2022-1821 | Highly Permissive Role Access | mitigated | High | |
| F-2022-1820 | Highly Permissive Role Access | fixed | High | |
| F-2022-1819 | Highly Permissive Role Access | fixed | High | |
| F-2022-1818 | Highly Permissive Role Access | mitigated | High |
Appendix 1. Severity Definitions
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, do not affect security score but can affect code quality score. |
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, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/Zharta/protocol-v1→ |
| Commit | 5dcd9f978960f4d336c026041af44e8d95324549 |
| Whitepaper | Not provided |
| Requirements | Provided→ |
| Technical Requirements | Provided→ |
Scope Details
- Repository
- https://github.com/Zharta/protocol-v1→
- Commit
- 5dcd9f978960f4d336c026041af44e8d95324549
- Whitepaper
- Not provided
- Requirements
- Provided→
- Technical Requirements
- Provided→