audit 1 #66
audit 1 #66
Conversation
|
|
||
| **Description** | ||
|
|
||
| In the `_validatePreConditions` function, the contract checks if `payment.deadline < block.timestamp * 1000`. Since `block.timestamp` returns the current block timestamp in seconds, multiplying it by 1000 converts it to milliseconds. This means `payment.deadline` is expected to be in milliseconds, which may cause confusion and inconsistencies, as most Solidity time-related functions and variables use seconds. |
There was a problem hiding this comment.
This is intentional. Millisecond-based deadlines are necessary to differentiate between duplicate payments during the validation process.
There was a problem hiding this comment.
Will document it clearly.
|
|
||
| **Description** | ||
|
|
||
| In the `_payReceiver` function, when `payment.receiverType == 0` and `payment.tokenOutAddress` is an ERC20 token, the contract transfers `payment.paymentAmount` to `payment.paymentReceiverAddress` without checking if the address is `address(0)`. If `payment.paymentReceiverAddress` is `address(0)`, the tokens will be sent to the zero address, effectively burning them, which may not be the intended behavior. |
There was a problem hiding this comment.
Using DePay to burn tokens might be intentional. We can address this in the SDKs by giving users control over the process, rather than completely preventing it.
|
|
||
| **Description** | ||
|
|
||
| If users accidentally send Ether to the contract without proper interaction (e.g., directly sending Ether to the contract's address), or if there are rounding errors and leftover Ether after operations, these funds may remain stuck in the contract. While the owner can withdraw tokens via the `withdraw` function, regular users cannot retrieve their mistakenly sent funds. |
There was a problem hiding this comment.
Calculating excess funds would result in an unnecessary increase in gas usage due to the conditional checks required. In worst-case scenarios, the owner can withdraw and return the excess Ether. However, this situation should not occur, as the SDKs can prevent it, and input amounts are confirmed and signed by the users.
No description provided.