background
logo

Security Audit Report for DCS Protocol's Commerce Payments

專案簡介

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.

關鍵發現

我們在該智能合約中共發現 2 個潛在問題,另有 6 條建議與 9 條說明,明細如下:

高風險:0
中風險:0
低風險:2
建議:6
說明:9
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 -

更多細節見審計報告

邁出走向安全的第一步

立即聯絡我們,獲取 BlockSec 的專業程式碼審計服務,在協議上線之前把安全性提上來!