Part of CertiK’s retainer series
CertiK reviewed WEMIX (Wemix Retainer 129 PlayTokenExchanger) on 9 Sep 2024: 6 findings, 0 critical; 1 marked fixed, 5 open.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 2 | 0 | 0 |
| Medium | 1 | 0 | 0 |
| Low | 2 | 0 | 1 |
In the contract **PlayTokenExchangerByTransfer** the role **owner** has authority over the functions shown in the below. - `function setVault()`: set new vault Any compromise to the **owner** account may allow a hacker to take advantage of this authority. In the contract **PlayTokenExchangerBase**, the role **owner** has authority over the following functions: - `function setRoleManager()`: set new role manager - `function setExecuteManager()`: set new execute manager - `function setRecipientRole()`: set new recipient - `function _authorizeUpgrade()`: upgrade the contract Any compromise to the **owner** account may allow a hacker to take advantage of this authority. In the contract **PeriodCapableUpgradeable**, the role **owner** has authority over the following functions: - `function changePeriodCap()`: change period cap - `function changePeriodUserCap()`: change period user cap Any compromise to the **owner** account may allow a hacker to take advantage of this authority. In the contract **PeriodicUpgradeable**, the role **owner** has authority over the following functions: - `function changeRound()`: change round Any compromise to the **owner** account may allow a hacker to take advantage of this authority.
In the contract `PlayTokenExchangerByMint` and `PlayTokenExchangerByTransfer`, the role `Owner` has the authority to update the implementation contract behind the `PlayTokenExchangerByMint` and `PlayTokenExchangerByTransfer` proxy. Any compromise to the `Owner` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by the proxy and execute potentially malicious functionality.
The current implementation employs `abi.encodePacked()` with multiple dynamic type inputs controlled by users. This encoding method is vulnerable to manipulation, especially with strings, bytes, and other dynamic types. Consequently, it is unsuitable for signature verification as users can alter inputs and potentially achieve identical output bytes from `abi.encodePacked()`. Additionally, it is worth noting that uints and similar variable types do not require conversion to strings prior to encoding.
The project design may not be compatible with non-standard ERC20 tokens, such as deflationary tokens or rebase tokens. The functions use `transferFrom()`/`transfer()` to move funds from the sender to the recipient but fail to verify if the received token amount matches the transferred amount. This could pose an issue with fee-on-transfer tokens, where the post-transfer balance might be less than anticipated, leading to balance inconsistencies. There might be subsequent checks for a second transfer, but an attacker might exploit leftover funds (such as those accidentally sent by another user) to gain unjustified credit.
The contract is serving as the underlying entity to interact with third-party **IRoleManager**, **IExecuteManager**, **IRecipientRole** and **playToken**. The scope of the audit treats third-party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets.
The report names a repository or files. Open the report to see its scope.
Repository and files the report names (8)
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us