Audit name:
[SCA] Zharta / P2PLending / Sept2024
Date:
Oct 16, 2024
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 is a peer-to-pool lending platform that allows users to lend and loan out NFTs.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Zharta |
| Audited By | Seher Saylik, Giovanni Franchi |
| Approved By | Ataberk Yavuzer |
| Website | https://www.zharta.io/→ |
| Changelog | 24/09/2024 - Preliminary Report |
| 16/10/2024 - Final Report | |
| Platform | Ethereum |
| Language | Vyper |
| Tags | P2P Lending, NFT Lending, ERC721 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Zharta
- Audited By
- Seher Saylik, Giovanni Franchi
- Approved By
- Ataberk Yavuzer
- Website
- https://www.zharta.io/→
- Changelog
- 24/09/2024 - Preliminary Report
- 16/10/2024 - Final Report
- Platform
- Ethereum
- Language
- Vyper
- Tags
- P2P Lending, NFT Lending, ERC721
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Zharta/lending-protocol-v2→ |
| Commit | 1e32d64 |
Review Scope
- Commit
- 1e32d64
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 is provided.
NatSpecs are detailed.
Code quality
The code is well written and is clear in its intentions.
The code follows best practises in terms of readability and input validation.
The development environment is configured.
Test coverage
Code coverage of the project is 98.00% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage are mostly covered.
Some fuzz testing is present.
System Overview
Zharta is a Peer-to-peer ERC-721 backed lending protocol with the following contract:
P2PLendingNfts — It is the core contract. It enables users to provide and take loan offers backed by ERC-721. This contract facilitates the creation and acceptance of loan offers, where lenders provide loans and borrowers use NFTs as collateral. The contract supports both ERC-721 and CryptoPunks NFTs, offering flexibility in collateral types. Additionally, it integrates with DelegateRegistry v2 for delegation functionality, allowing borrowers to delegate their collateral.
Two Interest Models: Lenders can choose between two types of interest structures—fixed or pro-rata. Fixed interest applies uniformly across the loan duration, while pro-rata interest is calculated based on the time the loan is held.
P2PLendingControl — It is an auxiliary module that manages state variables related to supported collateral and trait types. It allows the owner to update and modify these parameters as needed.
Privileged roles
The owner of the contract can set protocol fees.
The owner of the contract can change the protocol wallet.
The owner of the contract can enable or disable an authorised proxy.
The owner of the contract can propose a new owner.
The owner of the contract can enable or disable supported ERC-721 collections.
The owner of the contract can set the
type_rootfor a specific collateral.
Potential Risks
A potential risk arises from using tx.origin to identify the borrower's address when a loan is initiated through an authorised proxy. If this feature remains part of the protocol, as highlighted in issue F-2024-6068, it could be vulnerable to phishing attacks, particularly if the authorized proxy fails to implement robust access control measures. Since the current audit does not cover the code of authorised proxies, this security risk cannot be fully addressed or verified within the scope of this assessment. It is therefore recommended to only enable authorised proxies whose code has been audited.
Delegation of collateral is handled through an external registry. If the delegation registry fails or is compromised, it could lead to improper management of collateral or delegation rights.
Compilers used for converting smart contract code (e.g., Solidity or Vyper) into executable bytecode can contain hidden bugs, posing a risk to the integrity of the final deployed contract. Even after a thorough audit of the source code, undetected compiler bugs may introduce unintended behaviour or vulnerabilities that cannot be identified during typical code reviews.
The loan duration in the signed offer can potentially be set to zero or very low durations. If this occurs, borrowers could immediately be at risk of default upon loan creation, as the loan would mature instantly. This could result in borrowers losing their collateralized assets without an opportunity to fulfill repayment obligations. It is the responsibility of the users to carefully review all signed offer data to ensure fairness and accuracy.
The protocol utilises Merkle trees to allow lenders to specify particular traits of collateral they are willing to lend against. For computational efficiency, the trait_root of a specific collateral address is calculated off-chain, making it impossible to verify its correctness within the current audit. If a trait type is incorrectly mapped to a token ID during the construction of the trait_root, there is a potential scenario where a borrower could secure a loan intended for a specific trait type that the collateral does not actually possess.
When pro-rata is set to True at loan creation, and if the loan is replaced with a higher interest rate by lenders, borrowers may lose their broker fees for the remainder of the loan duration.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-6069 | Lender Paying Borrower Broker Fee in settle_loan Enables Loan Theft | fixed | Critical | |
| F-2024-6139 | Delegation Not Revoked After Loan Closure | fixed | High | |
| F-2024-6063 | Potential Exploit via Lender Blacklisting in the USDC Contract Leading to Collateral Seizure | fixed | Medium | |
| F-2024-6156 | No Cap on Settlement Fees | fixed | Low | |
| F-2024-6068 | Use of tx.origin Leads to Phishing Attack Risks When setApprovalForAll is Granted | mitigated | Low | |
| F-2024-6065 | Owner Can Frontrun Borrowers by Setting High Protocol Fees | accepted | Low | |
| F-2024-6213 | Immutable Variables Can Be Constants | fixed | Observation | |
| F-2024-6163 | Missing Zero Address Validation | 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/Zharta/lending-protocol-v2→ |
| Commit | 1e32d64ad042701e8157c7f93a6a0da7e3779c7c |
| Remediation Commit | 1e7048e248349fab4d720cba43b47f64e0735dbc |
| Whitepaper | N/A |
| Requirements | https://github.com/Zharta/lending-protocol-v2/blob/feat/initial-impl/README.md→ |
| Technical Requirements | https://github.com/Zharta/lending-protocol-v2/blob/feat/initial-impl/README.md→ |
Scope Details
- Commit
- 1e32d64ad042701e8157c7f93a6a0da7e3779c7c
- Remediation Commit
- 1e7048e248349fab4d720cba43b47f64e0735dbc
- Whitepaper
- N/A
- Technical Requirements
- https://github.com/Zharta/lending-protocol-v2/blob/feat/initial-impl/README.md→
Assets in Scope
P2PLendingControl.vyP2PLendingNfts.vyAppendix 3. Additional Valuables
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.