Audit name:
[SCA] Paydece | Escrow | Nov2023
Date:
Nov 3, 2023
Table of Content
Introduction
We express our gratitude to the Paydece team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Paydece is a P2P crypto to FIAT decentralized trading marketplace that works on-chain with a smart contract escrow. Users have total control over the funds during the transaction. Funds are released only if both sides validate.
| title | content |
|---|---|
| Platform | Ethereum, BNB Chain, Polygon, RSK |
| Language | Solidity |
| Tags | Escrow |
| Timeline | 01/10/2023 - 02/11/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/PayDece/paydece-contracts/commits/v4.2→ |
| Commit | 182aff27450ad5fc6d9f11e0bb931fec66143ac8 |
Review Scope
- Commit
- 182aff27450ad5fc6d9f11e0bb931fec66143ac8
Audit Summary
10/10
90.71%
7/10
9/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 Paydece |
| Audited By | Hacken |
| Website | https://www.paydece.io/→ |
| Changelog | 05/10/2023 – Initial Review |
| 02/11/2023 - Second Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Paydece
- Audited By
- Hacken
- Website
- https://www.paydece.io/→
- Changelog
- 05/10/2023 – Initial Review
- 02/11/2023 - Second Review
System Overview
PAYDECE - is an escrow protocol with the following contracts:
PaydeceEscrow.sol — A smart contract decentralized escrow, that allows users to exchange goods or services using the ERC20 and native tokens they hold in a self-custodial wallet. Users connect to the Dapp with their wallet where they own their private keys (they have total control over their funds) and will block their funds in a smart contract that will hold the value until the transaction of the goods or service is completely done and validated by them.
Privileged roles
PaydeceEscrow is using the Ownable library from OpenZeppelin to restrict access for administrative functions. Contract owner have access for following functions:
setFeeTaker()- configures the fee charged to the buyer (taker).setFeeMaker()- configure the fee charged to the seller (maker).setTimeProcess()- configure the time after which the cryptocurrency seller (maker) could cancel the transaction and be refunded the funds.releaseEscrowOwner()- release ERC20 tokens to the cryptocurrency buyer (taker) when a dispute arises.releaseEscrowOwnerNativeCoin()- release native tokens to the cryptocurrency buyer (taker) when a dispute arises.refundMaker()- refunding ERC20 tokens to the cryptocurrency seller (maker) when a dispute arises.refundMakerNativeCoin()- refunding native tokens to the cryptocurrency seller (maker) when a dispute arises.withdrawFees()- withdraw collected fees from different ERC20 tokens.withdrawFeesNativeCoin()- withdraw collected native token fees.addStablesAddresses()- add new tokens that are accepted by the contract.delStablesAddresses()- remove tokens accepted by the contract.CancelMakerOwner()- cancel the fund custody and refund it to the seller after available time passes.CancelTakerOwner()- cancel the fund custody and refund it to the seller before available time passes.setMarkAsPaidOwner()- confirm the fiat money transfer when issues arise and the buyer cannot perform it.
Executive Summary
Documentation quality
The total Documentation quality score is 9 out of 10.
Technical descriptions have some gaps.
No run instructions.
Code quality
The total Code quality score is 7 out of 10.
Best practice violations (I-2023-0316; I-2023-0320).
Unused statuses (I-2023-0310).
Test coverage
Code coverage of the project is 90.71% (branch coverage).
Contracts are not tested thoroughly.
Negative cases coverage missing.
Security score
Upon auditing, the code was found to contain 1 critical, 3 high, 1 medium, and 7 low severity issues. Out of these, 10 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.9. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
The contract owner possesses significant control over the contract, which includes the ability to establish fees, disburse funds, issue refunds to buyers, and cancel escrow arrangements. This level of centralization could pose a risk in the event of the owner's account being compromised.
The contract solely relies on the owner to define time locks for the escrow process. This arrangement could potentially result in funds becoming indefinitely locked within the contract if the owner neglects to define a time limit or if the owner's account is compromised. In the documentation, it is stated that the "timeProcess" variable should have a preset value of 45 minutes. However, it is important to note that, in reality, the owner has the flexibility to set any processing time they choose.
The contract owner has the ability to whitelist any currency that may be employed in the escrow process. Users, particularly takers, must exercise caution and diligently confirm whether the correct currency has been specified in the escrow, including verifying the address associated with the escrow currency. This is crucial because if a malicious ERC20 token is whitelisted, takers could potentially suffer a loss of value.
Escrowed funds can be released either by the maker or by the contract owner. Takers must place their trust in these entities, as in the current contract version, a process for raising disputes has not been implemented.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-1188 | The maker fee is locked inside the contract when escrow is canceled or refunded | fixed | Critical | |
| F-2023-1191 | Owner can drain users’ funds from contract with refund mechanism | fixed | High | |
| F-2023-1190 | Users funds could be locked due to incorrect escrow status check | fixed | High | |
| F-2023-1189 | Missing functionality for cancellation of escrow holding native tokens | fixed | High | |
| F-2023-1192 | Lack of strict validation of msg.value can lead to funds lock | fixed | Medium | |
| F-2023-1199 | Usage of built-in transfer | fixed | Low | |
| F-2023-1198 | Makers can omit fee payment | accepted | Low | |
| F-2023-1197 | Fee on transfer tokens can break contract logic | accepted | Low | |
| F-2023-1196 | Missing event for critical value updation | fixed | Low | |
| F-2023-1195 | Optimizing variable assignment in the constructor | fixed | Low |
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/PayDece/paydece-contracts/commits/v4.2→ |
| Commit | 182aff27450ad5fc6d9f11e0bb931fec66143ac8 |
| Whitepaper | Provided→ |
| Requirements | Provided→ |
| Technical Requirements | Provided→ |