Audit name:
[SCA] Cueva | Escrow | Jul2025
Date:
Aug 13, 2025
Table of Content
Introduction
We express our gratitude to the Cueva team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
PaydeceEscrow is a non-custodial smart contract that facilitates peer-to-peer crypto-fiat transactions using ERC20 stablecoins.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Cueva |
| Audited By | Ivan Bondar; Olesia Bilenka |
| Approved By | Ataberk Yavuzer |
| Website | https://www.cueva.xyz/→ |
| Changelog | 22/07/2025 - Preliminary Report |
| 13/08/2025 - Final Report | |
| Platform | BNB Chain, Polygon, Base |
| Language | Solidity |
| Tags | Escrow |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Cueva
- Audited By
- Ivan Bondar; Olesia Bilenka
- Approved By
- Ataberk Yavuzer
- Website
- https://www.cueva.xyz/→
- Changelog
- 22/07/2025 - Preliminary Report
- 13/08/2025 - Final Report
- Platform
- BNB Chain, Polygon, Base
- Language
- Solidity
- Tags
- Escrow
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/PayDece/paydece-contracts/→ |
| Commit | 9fcb207 |
| Retest commit | 9525771 |
Review Scope
- Commit
- 9fcb207
- Retest commit
- 9525771
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
{FindingsVulnSeverityStatusTable}
Documentation quality
Functional requirements are detailed.
Project overview is detailed.
All roles in the system are described.
Use cases are described and detailed.
For each contract, all futures are described.
All interactions are described.
Technical description is detailed.
Run instructions are provided.
Technical specification is provided.
The NatSpec documentation is sufficient.
Code quality
The code duplicates commonly known contracts instead of reusing them.
The development environment is configured.
Test coverage
Code coverage of the project is 97.55% (branch coverage).
Deployment and basic user interactions are covered with tests.
Interactions by several users are tested.
Not all branches are covered with tests.
System Overview
PaydeceEscrow provides a decentralized escrow system for stablecoin-backed trades between buyers and sellers, supporting transaction mediation and dispute handling directly on-chain. All transactions involve a sender (buyer) and receiver (seller), with tokens held during the fiat operations of the trade. The system integrates multi-tiered fee mechanics, appeal processes, and time-based cancelation rights.
The escrow lifecycle is managed through multiple statuses, from deposit (CRYPTOS_IN_CUSTODY) to release (COMPLETED or RELEASEOWNER) or cancellation (CANCEL_SENDER, CANCEL_RECEIVER). The contract supports dispute initiation by either party, triggering a resolution path that only the owner can finalize.
Core Components
Escrow: Struct storing trade data: participants, token, amount, time, merchant flags, and fees.
Appeal: Struct tracking whether sender/receiver raised a dispute and associated reason.
Fee System: Tiered fee logic:
Merchants pay a flat 0.25%.
Non-merchants are charged a fixed or percentage fee based on trade size (6 scale brackets).
Whitelisting: Only pre-approved stablecoins can be used as escrow currency.
Timelocks: Escrow cancelation is time-gated (default 45 minutes) for protection.
Privileged roles
owner (inherited from
Ownable):Sets all fee parameters and escrow durations
Whitelists/delists stablecoins
Resolves disputes (
releaseEscrowOwner,refundOwner)Overrides trade progression (
setMarkAsPaidOwner)Withdraws protocol fees
Potential Risks
Owner’s Unrestricted Escrow Control: The contract grants the owner unconditional authority to release or refund funds during disputes, posing centralization risks. Users are entirely reliant on the owner's impartiality and availability, which may compromise trust in high-value or adversarial trades.
Whitelisted Token Dependency: Only stablecoins whitelisted by the owner can be used. This reliance on centralized token approval introduces operational friction and can disrupt markets if tokens are arbitrarily removed or delayed in approval.
Single-Point Admin Dependency for Dispute Resolution: Appeals are resolved solely by the owner, with no multi-sig, DAO, or arbitration process. Inactivity, compromise, or malicious behavior from the owner can permanently stall or misresolve user disputes.
Hardcoded Time Constraints: The timeProcess value, governing how long users must wait before canceling, is arbitrarily set and mutable by the owner. Without user opt-in or notice, abrupt reductions could hinder user recovery actions, while excessive increases may stall trades unnecessarily.
No On-Chain Fiat Verification: The system assumes off-chain fiat transfers are completed honestly. There is no integration with proof-of-fiat oracles or reputation systems, creating inherent risks around false payment claims.
Dual-Sided Fee Deduction Per Trade: The protocol charges a fee to both the sender (at deposit) and the receiver (at withdrawal), even though only the sender supplies the total funds upfront. This means users are effectively charged two separate fees per transaction, potentially making trades economically unviable—especially for low-margin or high-frequency operations. The fee burden may be unintuitive for users expecting single-sided costs and could result in effective overpayment, especially when one party is unaware of the deduction mechanics.
Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1225 | Missing Status Check Allows Repeated Payouts in releaseEscrow | fixed | Critical | |
| F-2025-1226 | Misuse of Merchant Flags Enables Arbitrary Fee Reduction | fixed | High | |
| F-2025-1225 | setScale1FixedFee Assumes 18 Decimals, Breaking Compatibility with Tokens of Varying Precision | fixed | High | |
| F-2025-1227 | Inconsistent Appeal Logic Prevents Sender From Finalizing Resolved Disputes | fixed | Medium | |
| F-2025-1225 | Hardcoded Fee Overrides Configurable merchantVerifiedPercent in PaydeceEscrow Contract | fixed | Medium | |
| F-2025-1227 | Lack of Time Window Bounds Allows Abusive or Inconsistent Escrow Durations | fixed | Low | |
| F-2025-1227 | Absence of Ownership Transfer Functionality Prevents Recovery and Governance Flexibility | fixed | Low | |
| F-2025-1227 | Lack of Hierarchical Validation in Fee Tiers Enables Misconfigured Escalating Fees | fixed | Low | |
| F-2025-1227 | Race Condition from Dynamic Fee Parameters May Lead to Unexpected Overpayment | accepted | Low | |
| F-2025-1226 | Front-running of orderId Enables Denial-of-Service Against Escrow Creation | accepted | Low |
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/PayDece/paydece-contracts/→ |
| Commit | 9fcb207be74714c8b9e3d4469acee9efde53c5ab |
| Retest Commit | 9525771699e4a27be8f931ffc5f97326483aa018 |
| Whitepaper | N/A |
| Requirements | https://github.com/PayDece/paydece-contracts/blob/v5/docs/PaydeceEscrowV5.md→ |
| Technical Requirements | https://github.com/PayDece/paydece-contracts/blob/v5/docs/PaydeceEscrowV5.md→ |
Scope Details
- Commit
- 9fcb207be74714c8b9e3d4469acee9efde53c5ab
- Retest Commit
- 9525771699e4a27be8f931ffc5f97326483aa018
- Whitepaper
- N/A
- Technical Requirements
- https://github.com/PayDece/paydece-contracts/blob/v5/docs/PaydeceEscrowV5.md→
Appendix 3. Additional Valuables
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.