DESCRIPTION
The target of this audit is the private code repository of Commerce Payments of DCS Protocol. The Commerce Payments Protocol is a permissionless protocol for on-chain payments that mimics traditional authorize-and-capture payment flows. It facilitates secure escrow-based payments through modular token collectors and operator-driven execution, while separating authorization, settlement, capture, reclaim, and refund flows. The core payment state machine is implemented in AuthCaptureEscrow, while custody and settlement are handled through a dedicated TokenStore for each operator to avoid commingling funds across operators. The protocol supports multiple collection mechanisms, including direct transfers, signature-based transfers, and swap-assisted settlement, while providing relatively clear fund and state boundaries among the payer, receiver, and fee recipient.
Please refer to the report for the detailed audit scope.
Our audit methodology employs automated vulnerability scans, manual verification, and business logic analysis to uncover potential security issues coupled with gas and code quality optimization recommendations.
In summary, we did not find any critical issues within the audited codebase. However, we have identified some non-critical issues that should be addressed. Additionally, we have put forth recommendations and notes that should be taken into consideration. It is important to note that the scope of our audit was strictly limited to the specific code versions mentioned in the report. Any updates made subsequent to our review would require a re-evaluation.
KEY FINDINGS
In total, we find 2 potential issues in the smart contract. We also have 6 recommendations and 9 notes, as follows:
| ID | Severity | Description | Status |
|---|---|---|---|
| 1 | Low | Incorrect refund amount in contract BitgetSwapPaymentCollector |
Fixed |
| 2 | Low | Lack of binding between paymentInfo and Permit2 authorization |
Fixed |
| 3 | - | Add checks in function _collectTokens() |
Fixed |
| 4 | - | Atomize proxy deployment and initialization | Confirmed |
| 5 | - | Fix fee rounding direction | Confirmed |
| 6 | - | Align comments with implementation | Fixed |
| 7 | - | Add a token rescue mechanism | Confirmed |
| 8 | - | Add swapRouter whitelist restriction |
Fixed |
| 9 | - | Weird ERC20 tokens | - |
| 10 | - | Integration assumptions | - |
| 11 | - | Operator fee estimation assumption | - |
| 12 | - | Consistency of tokenStoreImplementation across upgrades |
- |
| 13 | - | Security assumption on the variable PaymentInfo.salt |
- |
| 14 | - | Potential centralization risks | - |
| 15 | - | EIP-1153 compatibility on supported chains | - |
| 16 | - | The fee and refund designIntroduced by Version 1 | - |
| 17 | - | The operator trust assumption | - |
More details are provided in the audit report.