WEMIX security record
As of 23 Oct 2026, WEMIX has 75 audit reports by 1 security firm on Trustblock; the latest is by CertiK, dated 13 Feb 2025. Those reports list no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Audits75
Newest first
75 audit reports, 72 in CertiK’s retainer series, 3 in CertiK’s series
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Wemix Retainer 88 NILE MarketPlace (hybrid) | Security firm: CertiK | Date: | Scope: Files named in the report | 2 critical findings, fixed | Open · skynet.certik.com |
| Wemix Retainer 87 NightCrow | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 90 KLEVA | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 84 WMX.Fi (external audit) | Security firm: CertiK | Date: | Scope: Files named in the report | 1 critical finding, fixed | Open · skynet.certik.com |
| Wemix Retainer 83 Governance & Wonder Staking | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 78 NewFanToken | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 77 (EnglishAuctionOrder_auto) | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 69 WEMIX Swap V3 | Security firm: CertiK | Date: | Scope: Files named in the report | 1 critical finding, fixed | Open · skynet.certik.com |
| Wemix Retainer 72 CoveBacking | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 65 DEX V2 | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 60 Reflect project(addendum) | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 68 G-STAR2023 | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 60 Reflect project | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 63 AirDrop | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 53 (Championship TicketNFT) | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 48 PlayNFTMarket | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 26 (NFT Refund) | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix PoET Retainer 52 | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 37 (PPP, PlayBridgeV3 ) | Security firm: CertiK | Date: | Scope: Files named in the report | 1 critical finding, fixed | Open · skynet.certik.com |
| Wemix Retainer 49 - BYLOManager, VaultManager | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 43 (Staking Pool Mainnet) | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 38 (DEX Contract) | Security firm: CertiK | Date: | Scope: Files named in the report | 1 critical finding, fixed | Open · skynet.certik.com |
| Wemix Retainer 46 NileMarketPlace2. | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 44 DEX Bridge | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Wemix Retainer 42 (play, cypress settler v2) | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
Findings646
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 9 |
| High | 89 | 0 | 23 |
| Medium | 25 | 0 | 83 |
| Low | 180 | 0 | 237 |
HighCentralization Related RisksWemix Retainer 150 WEMEME · CertiK · 13 Feb 2025Open
In the contract `WEMEMEBase`, the role `Setter` has authority over the functions shown in the diagram below. Any compromise to the `Setter` account may allow the hacker to take advantage of this authority and set the policy address.  In the contract `WEMEMERole`, the role `Setter` has authority over the functions shown in the diagram below. Any compromise to the `Setter` account may allow the hacker to take advantage of this authority and set the role manager.  In the contract `WEMEMEFactory`, the role `Setter` has authority over the functions shown in the diagram below. Any compromise to the `Setter` account may allow the hacker to take advantage of this authority and set the contract register.  In the contract `WEMEMEPolicy`, the role `Owner` has authority over the function `registToken()`, and the role `Setter` has authority over the functions shown in the diagram below. Any compromise to the `Setter` account may allow the hacker to take advantage of this authority and set the router address, set the listing fee, set the wwemix address, set the creator incentive fee, set the fee basis point, set the holder threshold, set the WemixD address, set the play swap router, set the wemixThreshold value, remove a specified token, set the factory address, set the fee recipient address, set the creation fee, and set the holder condition.  Note that the `Owner` also has the `Setter` role in the contracts above.
Open the reportHighCentralization Risks in GovImp.solWemix Retainer 147 WEMIX Governance · CertiK · 19 Dec 2024Open
In the contract `GovImp`, the role `_govmem` has authority over the functions shown in the diagram below. Any compromise to the `_govmem` account may allow the hacker to take advantage of this authority and add a proposal for member removal, add a proposal to add a new member, add a proposal to change the governance address, propose a change or exit of a governance member, vote on a ballot index with approval choice, finalize the voting process if ended, add a proposal to change an environment variable, and authorize a contract upgrade for a new implementation address.  In the contract `GovImp`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and reinitialize node checks and properties, as well as set the proposal time period. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 147 WEMIX Governance · CertiK · 19 Dec 2024Open
In the contract `GovImp`, the role `GovMem` has the authority to update the implementation contract behind the proxy contract. Any compromise to the `GovMem` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RiskWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
In the contract `PlayMarketOfferBiddingOrder` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and - call `setMinimumPrice()` to set the NFT minimum price. - call `setOrderExpirationPeriod()` to set expiration period of orders. - call `setOfferExpirationPeriod()` to set expiration period of offers.  ----- In the contract `PlayMarketBaseV5` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and - call `addStrategy()` to add or modify strategies to the market. - call `subStrategy()` to inactivate a strategy of the market. - call `setPriceOracle()` to set the `priceOracle` address, which is not used in current protocol. - call `setWhiteList()` to set the whitelist contract. The whitelisted accounts can call paused functions. - call `setTokenManagerAddress()` to change `tokenManagerAddress`, which ensures only whitelisted collections can be traded in the market.  In the contract `PlayMarketBaseV5` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - call `pauseFunction()` to pause a function. - call `resumeFunction()` to resume a function. - call `pauseAllFunction()` to pause all functions. - call `resumeAllFunction()` to disable global function pause. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `PlayMarketBaseV5` contract inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `privileged roles` of the proxy often have the authority to update the implementation contract. Any compromise of the privileged account could allow a hacker to exploit this authority, potentially altering the implementation contract pointed to by the proxy and thus executing malicious functionality within the implementation contract.
Open the reportHighCentralization Ralated RisksWemix Retainer 141 GameServerNFT · CertiK · 15 Nov 2024Open
In the contract `GameServerNftBaseV1`, the role `GAME_SERVER_ADMIN` has authority over the functions shown in the diagram below. Any compromise to the `GAME_SERVER_ADMIN` account may allow the hacker to take advantage of this authority and update token metadata, as well as mint NFT with metadata URI internally.  In the contract `GameServerNftBaseV1`, the role `GAME_SERVER_SUPER_ADMIN` has authority over the functions shown in the diagram below. Any compromise to the `GAME_SERVER_SUPER_ADMIN` account may allow the hacker to take advantage of this authority and mint NFTs, set token URI, and update token metadata URI. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 141 GameServerNFT · CertiK · 15 Nov 2024Open
In the contract `GameServerNFTBaseV1`, the role `admin` has the authority to update the implementation contract behind the proxy contract contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 142 - PNIX DEX V2 · CertiK · 15 Nov 2024Open
In the contract `Factory`, the role `GOVERNOR_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `GOVERNOR_ROLE` account may allow the hacker to take advantage of this authority and set the quote unit for a pair, unpause the specified trading pair, set the base unit, and pause the specified pair.  In the contract `Factory`, the role `MANAGER_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `MANAGER_ROLE` account may allow the hacker to take advantage of this authority and create a new trading pair.  In the contract `Factory`, the role `MASTER_ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `MASTER_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and set or remove router for a component, set a component address, and set the quote token.  In the contract `Factory`, the role `PAIR_CREATOR_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `PAIR_CREATOR_ROLE` account may allow the hacker to take advantage of this authority and create a trading pair with specified parameters.  In the contract `Factory`, the role `_role` has authority over the functions shown in the diagram below. Any compromise to the `_role` account may allow the hacker to take advantage of this authority and set role administrator.  ----- In the contract `Router`, the role `MANAGER_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `MANAGER_ROLE` account may allow the hacker to take advantage of this authority and skim excess tokens from a liquidity pool.  In the contract `Router`, the role `MASTER_ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `MASTER_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and authorize a contract upgrade. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 142 - PNIX DEX V2 · CertiK · 15 Nov 2024Open
In the contract `Router`, the role `MASTER_ADMIN_ROLE` has the authority to update the implementation contract behind these contracts. Any compromise to the `MASTER_ADMIN_ROLE` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization RisksWemix Retainer 137 HSPFE · CertiK · 31 Oct 2024Open
In the contract `SPBase`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set vault addresses, set the base fee percentages, set the end block, and set the compounder address.  In the contract `SPMineSchedule`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set pre-stake period information, set the reward schedule, toggle allow pre-stake status.  In the contract `SPBridgeClaim`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the bridge claim fee percent, set the destination chain, set the token bridge ID, and set the bridge address.  In the contract `SPCoolTime`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the cool time force fee percent, set the unstake cool time, set the claim cooldown time, and set the stake cool time.  In the contract `HSPFactory`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and end all processes at specified block, deploy HSPforGOD contract and handle outcomes, and set the end block for `HSPforGOD`, after which users can no longer stake/unstake/claim tokens.  In the contract `HSPforGOD`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and pause the function with a specified id which prevents staking, unstaking, or claiming reward, shutdown and transfer token balances, or unpause a specified id.  In the contract `HSPforGOD`, the role `_signer` has authority over the functions shown in the diagram below. Any compromise to the `_signer` account may allow the hacker to take advantage of this authority and set the end block.  In the contract `SignerRole`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and add or remove a signer account.  For protocol fees, the fee cap is < 100%, which means that theoretically protocol fees can constitute the vast majority of users' staked tokens or reward tokens.
Open the reportShow 10 more
HighCentralization RisksWemix Retainer 125 WemixPayment Contract · CertiK · 16 Oct 2024Open
In the contract `PaymentCoreV2` the role `paymentSetter` has authority over the functions shown in the diagram below. Any compromise to the `paymentSetter` account may allow the hacker to take advantage of this authority and: - function `setRouter()`, to set swap router. - function `setDeadline()`, to set swap deadline. - function `setSlippage()`, to set swap slippage. - function `setExp()`, to set refundable period. - function `registService()`, to regist service info. - function `removeService()`, to remove registered service. - function `registToken()`, to regist token address. - function `removeToken()`, to remove token address. - function `changeServiceExecutability()`, to change status of service's selector. - function `changeRoleManager()`, to change role manager address. - function `changeExecuteManager()`, to change execute manager address. - function `changeListManager()`, to change blackOrWhiteList address. - function `changeRecipientRole()`, to change recipientRole address. - function `changeWWEMIX()`, to change blackOrWhiteList address.  In the contract `WemixPaymentLogic` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `WemixPaymentLogic` the role `paymentSetter` has authority over the functions shown in the diagram below. Any compromise to the `paymentSetter` account may allow the hacker to take advantage of this authority and: - function `removeService()`, to remove registered service. 
Open the reportHighContract Upgrade Centralization RiskWemix Retainer 125 WemixPayment Contract · CertiK · 16 Oct 2024Open
In the contracts `PaymentCoreV2` and `WemixPaymentLogic`, the role `admin` has the authority to update the implementation contracts behind the proxy contracts. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 129 PlayTokenExchanger · CertiK · 9 Sep 2024Open
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.
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 129 PlayTokenExchanger · CertiK · 9 Sep 2024Open
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.
Open the reportHighCentralization Related RisksWemix Retainer 133 PricePolicy · CertiK · 9 Sep 2024Open
In the contract `PricePolicy`, the role `SETTER` has authority over the following functions: - `setPriceOracle()`: Registers token's price oracle contract. - `setLimitPrice()`: Registers the price to be used as the criterion for determining whether it is a valid price. - `changeRoleManager()`: Change the `RoleManager` contract. Any compromise to the `SETTER` account may allow a hacker to take advantage of this authority and change the price of tokens.
Open the reportHighCentralization Risks in GameTokenTwapRouterV2.solWemix Retainer 131 NightCrowTWAPV3 · CertiK · 22 Aug 2024Open
In the contract `GameTokenTwapRouterV2` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and register/remove game token, token minter and change lock price and freeze period of the minter. 
Open the reportHighCentralization Related RisksWemix Retainer 74 (DIOSV3) · CertiK · 16 Aug 2024Open
In the contract `DollarInAndOutStabilizer3` the role `operator` has authority over the functions shown in the diagram below. Any compromise to the `operator` account may allow the hacker to take advantage of this authority and trigger the `WEMIX$` price stabilizing functions `syncToBaseTick` and `syncToRandomTick`.  In the contract `OperatorManagement` the role `operatorManager` has authority over the functions shown in the diagram below. Any compromise to the `operatorManager` account may allow the hacker to take advantage of this authority and add/remove the operator role.  In the contract `DollarInAndOutStabilizer3` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the rewarder address or the tick threshold value.  In the contract `OperatorManagement` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set an arbitrary account as the `operatorManager` role. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 74 (DIOSV3) · CertiK · 16 Aug 2024Open
`OperatorManagement` and `DollarInAndOutStabilizer3` are upgradeable contracts, the owner can upgrade the contract without the community's commitment. If an attacker compromises the proxy admin account, he can change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 122 TokenPayment · CertiK · 13 Aug 2024Open
In the contract `NightCrowFTExchanger` the role `setterRole` has authority over the functions - setRecipientRole() - registFunctionSelector() Any compromise to the `setterRole` account may allow the hacker to take advantage of this authority and set recipient role and register function selectors. ----- In the contract `TokenPaymentLogic` the role `DEFAULT_ADMIN_ROLE` has authority over the function `_authorizeUpgrade`. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and upgrade the contract. In the contract `TokenPaymentLogic` the role `paymentSetter` has authority over the functions - removeService() - removeVault() Any compromise to the `paymentSetter` account may allow the hacker to take advantage of this authority and remove service and remove vault of the service. ----- In the contract `TokenPaymentCore` the role `paymentSetter` has authority over the functions - setDeadLine() - setRouter() - setSlippage() - registService() - removeService() - registVault() - changeServiceExecutability() - changeRoleManager() - changeExecuteManager() - changeRecipientRole() - changeListManager() - registToken() - registTokens() - removeToken() - removeTokens() Any compromise to the `paymentSetter` account may allow the hacker to take advantage of this authority and - set swap deadline - set router - set slippage - register service - remove service - register vault - change status of service's selector - change role manager address - change execute manager address - change recipient role address - change black or whitelist address - regist token address - remove token address
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 122 TokenPayment · CertiK · 13 Aug 2024Open
In the contract `TokenPaymentLogic`, the role `DEFAULT_ADMIN_ROLE` (owner) has the authority to update the implementation contract behind the proxy contract. Any compromise to the `DEFAULT_ADMIN_ROLE` (owner) account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportShow 10 more
HighCentralization Related RisksWemix Retainer 121 wepublicBank · CertiK · 2 Aug 2024Open
In the contract `FundingProjectTreasury` the role `FUNDING_PROJECT_TREASURY_DEPLOYER_ROLE` has authority over the functions - `addReward()` - `deactivateProject()` - `setMaxRefunderNumber()` - `setTokenAddress()` Any compromise to the `FUNDING_PROJECT_TREASURY_DEPLOYER_ROLE` account may allow the hacker to take advantage of this authority and - add reward items - set the project as `deactivated` for a refund when project is cancelled - set the number of the refunders - set the address of the NFT reward ------------------------------------------------------ In the contract `FundingProjectTreasury` the role `CANCEL_FUNDING_PROJECT_ROLE` has authority over the function `proxyCancelProject()`. Any compromise to the `CANCEL_FUNDING_PROJECT_ROLE` account may allow the hacker to take advantage of this authority and cancel the project. ------------------------------------------------------ In the contract `FundingProjectTreasury` the role `REWARD_DISTRIBUTOR_ROLE` has authority over the function `distributeReward()`. Any compromise to the `REWARD_DISTRIBUTOR_ROLE` account may allow the hacker to take advantage of this authority and distribute the NFT reward. ------------------------------------------------------ In the contract `FundingProjectTreasury` the role `projectOwner` has authority over the functions - `cancelFundByOwner()` - `cancelProject()` - `settleProject()` Any compromise to the `projectOwner` account may allow the hacker to take advantage of this authority and - cancel fund - cancel the project - settle the project ------------------------------------------------------ In the contract `WepublicPointV3Logic` the role `DEFAULT_ADMIN_ROLE` has authority over the function `setFundingProjectTreasuryBeacon()`. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and set funding project treasury beacon ------------------------------------------------------ In the contract `WepublicPointV3Logic` the role `FUNDING_PROJECT_TREASURY_DEPLOYER_ROLE` has authority over the function `deployFundingProjectTreasury()`. Any compromise to the `FUNDING_PROJECT_TREASURY_DEPLOYER_ROLE` account may allow the hacker to take advantage of this authority and deploy funding project treasury contract.
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 121 wepublicBank · CertiK · 2 Aug 2024Open
In the contract `FundingProjectTreasury`, the role `DEFAULT_ADMIN_ROLE` has the authority to update the implementation contract behind the Beacon proxy contract. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 119 DIOSV3 (2) · CertiK · 8 Jul 2024Open
In the contract `UIOS` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and modify the `BaseTick` price which is the target price for sync operations.  In the contract `UIOS` the role `_operator` has authority over the functions shown in the diagram below. Any compromise to the `_operator` account may allow the hacker to take advantage of this authority and trigger the `WEMIX$` price stabilizing functions `syncToBaseTick`.  In the contract `OperatorManagement` the role `operatorManager` has authority over the functions shown in the diagram below. Any compromise to the `operatorManager` account may allow the hacker to take advantage of this authority and add/remove the operator role.  In the contract `UIOSAuthorizedMint` the role `_breaker` has authority over the functions shown in the diagram below. Any compromise to the `_breaker` account may allow the hacker to take advantage of this authority and pause/resume the contract.  In the contract `UIOSAuthorizedMint` the role `_breakersetter` has authority over the functions shown in the diagram below. Any compromise to the `_breakersetter` account may allow the hacker to take advantage of this authority and set breaker role and breakersetter role.  In the contract `UIOSAuthorizedMint` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set whitelisted accounts and modify the USDC treasury address.  In the contract `UIOSDollarTreasury` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and submit/confirm malicious transaction proposals. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 119 DIOSV3 (2) · CertiK · 8 Jul 2024Open
`OperatorManagement` and `UIOS` are upgradeable contracts, the owner can upgrade the contract without the community's commitment. If an attacker compromises the proxy admin account, he can change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Risks in SupportProjectTreasuryV2Wemix Retainer 117 SupportProjectTreasuryV2 · CertiK · 28 May 2024Open
In the contract `SupportProjectTreasuryV2` the role `SUPPORT_PROJECT_ROLE` has authority to sign a signature to call `support()` to support projects. Any compromise to the `SUPPORT_PROJECT_ROLE` account may allow the hacker to take advantage of this authority. In the contract `SupportProjectTreasuryV2` the role `SUPPORT_PROJECT_TREASURY_DEPLOYER_ROLE` has authority to sign a signature to call `setMaxRefunderNumber()`. Any compromise to the `SUPPORT_PROJECT_TREASURY_DEPLOYER_ROLE` account may allow the hacker to take advantage of this authority. In the contract `SupportProjectTreasuryV2` the role `SETTLE_SUPPORT_PROJECT_ROLE` has authority to sign a signature and grant authority to the role `projectOwner` to call `settleProject()`. Any compromise to the `SETTLE_SUPPORT_PROJECT_ROLE` and `projectOwner` accounts may allow the hacker to take advantage of this authority. In the contract `SupportProjectTreasuryV2` the role `CANCEL_SUPPORT_PROJECT_ROLE` has authority to sign a signature and grant authority to the role `projectOwner` to call `cancelProject()`. Any compromise to the `CANCEL_SUPPORT_PROJECT_ROLE` and `projectOwner` accounts may allow the hacker to take advantage of this authority. In the contract `SupportProjectTreasuryV2` the role `CANCEL_SUPPORT_PROJECT_ROLE` has authority to sign a signature to call `deactivateProject()`. Any compromise to the `CANCEL_SUPPORT_PROJECT_ROLE` account may allow the hacker to take advantage of this authority.
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 117 SupportProjectTreasuryV2 · CertiK · 28 May 2024Open
The SupportProjectTreasuryV2 contract inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `privileged roles` of the proxy often have the authority to update the implementation contract. Any compromise to the privileged account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
In the contract `NCPStaking` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - set withdrawalNFT contract address - set `multiplierPointBasis` - set duration of fee ratio change - set platform fee ratio - set registry contract address - add a new LP to the pool - remove the LP from the pool - set the unbound time of the pool  In the contract `NCPStaking` the role `_rewarderowner` has authority over the functions shown in the diagram below. Any compromise to the `_rewarderowner` account may allow the hacker to take advantage of this authority and update the given pool's reward point, update the given pool's reward fee ratio, and update the given pool's reward fee ratio request.  ----- In the contract `Rewarder` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and add/remove the rewarder and set the NCP address.  ----- In the contract `WithdrawalNFT` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and emergency transfer and change claimable time.  In the contract `WithdrawalNFT` the role `minter` has authority over the functions shown in the diagram below. Any compromise to the `minter` account may allow the hacker to take advantage of this authority and mint NFT to any address and burn NFT from any address. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
In the contracts `NCPStaking`,`WithdrawalNFT` and `Rewarder`, the role `admin` has the authority to update the implementation contract behind the proxy contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Risks in StWEMIXV6.solWemix Retainer 113 Liquid Staking · CertiK · 15 Apr 2024Open
In the contract `StWEMIXV6` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - migrate the wonder - update the wonder - migrate the wonder from the exit pid - update fee - transfer Wemix coin to the owner - set treasury address - set breaker address  In the contract `StWEMIXV6` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority and pause/unpause this contract. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 113 Liquid Staking · CertiK · 15 Apr 2024Open
The contract `StWEMIXV6` inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `admin` of the proxy often has the authority to update the implementation contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportShow 10 more
HighCentralization Related RisksWemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
In the contract `KlevaDistributor` the role `_keeper` has authority over the functions shown in the diagram below. Any compromise to the `_keeper` account may allow the hacker to take advantage of this authority and set `beforeKlevaPerSec`, `nextKlevaPerSec`, `nextKlevaPerSecAt`, `feeRate`, create a new pool and update the `allocPoint` for pool.  In the contract `KlevaDistributor` the role `_notifier` has authority over the functions shown in the diagram below. Any compromise to the `_notifier` account may allow the hacker to take advantage of this authority and add user's share and remove user's share.  In the contract `KlevaDistributor` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set `klevaConfig` address and `maxKlevaPerSec`.  In the contract `KlevaDistributor` the role `_userorkeeper` has authority over the functions shown in the diagram below. Any compromise to the `_userorkeeper` account may allow the hacker to take advantage of this authority and claim rewards.  In the contract `KlevaLocker` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set `klevaConfig` address and withdraw the balances of any account.  In the contract `KlevaToken` the role `_minterrole` and `klevaDistributor` has authority over the functions shown in the diagram below. Any compromise to the `_minterrole` account may allow the hacker to take advantage of this authority and mint tokens for any address and burn tokens from any address.  In the contract `KlevaToken` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set `klevaConfig` address, set name and symbol of token and pause/unpause the contract.  In the contract `Dashboard` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set `klevaConfig` address.  In the contract `FeeBox` the role `_keeper` has authority over the functions shown in the diagram below. Any compromise to the `_keeper` account may allow the hacker to take advantage of this authority and distribute fees and set fee receiver list.  In the contract `FeeBox` the role `_notifier` has authority over the functions shown in the diagram below. Any compromise to the `_notifier` account may allow the hacker to take advantage of this authority and transfer fee tokens to this contract.  In the contract `FeeBox` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set `klevaConfig` address.  In the contract `KlevaConfig` the role `_keeper` has authority over the functions shown in the diagram below. Any compromise to the `_keeper` account may allow the hacker to take advantage of this authority and sync all contract's address. ![](https://accelerator-tasks-prod.acc.corp.certik.com/11ee-e4c5-9a54e810-b425-1f403565d
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
In the contracts `KlevaDistributor`, `KlevaLocker`, `KlevaToken`, `Dashboard`, `FeeBox`, `KlevaConfig`, and `EarnRouter`, the role `admin` has the authority to update the implementation contract behind the proxy contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 102 DEX NFT Service · CertiK · 19 Mar 2024Open
A diamond proxy contract, also known as a "diamond," is a design pattern for Ethereum smart contracts that is introduced by [Ethereum Improvement Proposal (EIP) 2535](https://eips.ethereum.org/EIPS/eip-2535). The diamond pattern allows a contract to have an unlimited number of functions by separating the contract's functions into smaller contracts called "facets." The diamond acts as a proxy that routes function calls to the appropriate facets. The `Diamond` contract within the audit scope works as the diamond proxy, the `contractOwner` can add/remove/replace any facets. Any compromise of the privileged account could allow a hacker to exploit this authority and execute malicious functionality within the implementation contract.
Open the reportHighCentralized RiskWemix Retainer 102 DEX NFT Service · CertiK · 19 Mar 2024Open
In the contract `DiamondCutFacet` the role `contractOwner` has authority over the following function: - diamondCut(): add/remove/replace facets of a diamond proxy Any compromise to the `contractOwner` account may allow the hacker to take advantage of this authority. In the contract `OwnershipFacet` the role `contractOwner` has authority over the following function: - transferOwnership(): transfer the ownership Any compromise to the `contractOwner` account may allow the hacker to take advantage of this authority. In the contract `ERC721Facet` the role `contractOwner` has authority over the following function: - function `initialize()`, to set the `_name`, `_symbol`, `_baseURI` of ERC721Storage and the `birthAt` of CharacterStorage. Any compromise to the `contractOwner` account may allow the hacker to take advantage of this authority. In the contract `CharacterFacet` the role `contractOwner` has authority over the following function: - function `registerCharacter()`, to add `characterIDList` to CharacterStorage. Any compromise to the `contractOwner` account may allow the hacker to take advantage of this authority. In the contract `GachaTableInitFacet` the role `contractOwner` has authority over the following function: - function `initialize()`, to set the `dev` of GachaStorage; - function `setBonusStatGacha()`, to set the `bonusStat` of GachaStorage; - function `setCharacterGacha()`, to set the `bonusCharacter` of GachaStorage; - function `newGacha()`, to add `gachaIDList` to GachaStorage and set `collections` and `grades` for Gacha; - function `addGachaCharacter()`, to add `characters` to Gacha; - function `addGachaCollection()`, to add `collections` to Gacha. Any compromise to the `contractOwner` account may allow the hacker to take advantage of this authority.
Open the reportHighCentralization Risks in PlayMarketTokenManagerV3.Wemix 99 PlayNFTMarket · CertiK · 1 Mar 2024Open
In the contract `PlayMarketTokenManagerV3` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and update the sensitive settings of the projects and therefore steal funds and disturb the normal work of the contract. 
Open the reportHighCentralized Control of Contract UpgradeWemix 99 PlayNFTMarket · CertiK · 1 Mar 2024Open
The contract `PlayMarketTokenManagerV3` inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `privileged roles` of the proxy often have the authority to update the implementation contract Any compromise of the privileged account could allow a hacker or malicious insider to exploit this authority, potentially altering the implementation contract pointed to by the proxy and thus executing malicious functionality within the implementation contract, such as withdrawing all the assets from the contract.
Open the reportHighCentralization Related RisksWemix Retainer 100 PlayNFTMarket (hybrid-auction) · CertiK · 1 Mar 2024Open
In the contract `PlayMarketAuctionOrderBase` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority. 
Open the reportHighCentralization Risks in UnaMetaHash.solWemix Retainer 96 UnaMetaHash · CertiK · 22 Feb 2024Open
In the contract `UnaMetaHash` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and : - function `addValidators()`, to call `addValidator()` for several addresses. - function `removeValidators()`, to call `removeValidator()` for several addresses. - function `addValidator()`, to add a non-existing address in the validator. - function `removeValidator()`, to remove an existing address from the validator. 
Open the reportHighCentralization Related RisksWemix Retainer 88 NILE MarketPlace (hybrid) · CertiK · 13 Feb 2024Open
In the contract `HybridAuctionOrder`, `OHybridAuctionOrder` and `CHybridAuctionOrder` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and reset the price of an order.  In the contract `ExecuteManager.sol` the role `ADMIN` has authority over the functions shown below. Any compromise to the `ADMIN` account may allow the hacker to take advantage of this authority and modify the configuration of the ExecuteManager. * setRoleManager * changeExecutability * changeExecutabilityBelongContract In the contract `GrowthRateManager.sol` the role `SETTER` has authority over the functions shown below. Any compromise to the `SETTER` account may allow the hacker to take advantage of this authority and modify the configuration of the GrowthRateManager and affect the auction process. * setCloseDelay * setGrowthRateVersion * setGrowthRate * setCollection * setMarketType In the contract `RoleManager.sol` the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown below. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and modify privileged roles with in the system and damage the operation of the project. * setRoleAdmin * revokeRole
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 88 NILE MarketPlace (hybrid) · CertiK · 13 Feb 2024Open
The `RoleManager.sol`, `ExecuteManager.sol` and `GrowthRateManager.sol` contract inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `privileged roles` of the proxy often have the authority to update the implementation contract. Any compromise of the privileged account could allow a hacker to exploit this authority, potentially altering the implementation contract pointed to by the proxy and thus executing malicious functionality within the implementation contract.
Open the reportShow 10 more
HighCentralization Related RisksWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
In the contract `Oracle` the role `darkOracle` has authority over the functions shown in the diagram below. Any compromise to the `darkOracle` account may allow the hacker to take advantage of this authority and settle orders, liquidating user positions at an undesirable value, causing financial loss to the user.  In the contract `Oracle` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and modify critical parameters of the project, damaging the operation of the project, and causing financial loss to the users.  ----- In the contract `OracleForwarder` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and modify critical configurations of the project, damaging the operation of the project, and causing financial loss to the users.  ----- In the contract `Pool` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and modify critical parameters of the project, damaging the operation of the project, and causing financial loss to the users.  ----- In the contract `Rewards` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and modify the router address and withdraw tokens from the contract  ----- In the contract `Router` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and modify critical parameters of the project, and damaging the operation of the project, causing financial loss to the users.  ----- In the contract `Trading` the role `oracle` has authority over the functions shown in the diagram below. Any compromise to the `oracle` account may allow the hacker to take advantage of this authority and settle orders, liquidating user positions at an undesirable value, causing financial loss to the user.  In the contract `Trading` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and * Modify the router address * Modify the minimal margin * Add a new "product" and modify "product" list * Release margin * Damaging the operation of the project, causing financial loss to the users.  ----- In the contract `Treasury` the role `oracle` has authority over the functions shown in the diagram below. Any compromise to the `oracle` account may allow the hacker to take advantage of this authority and move funds from "Treasury" to the "Oracle".  In the contract `Treasury` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and modify the router address and withdraw funds from the contract. 
Open the reportHighInitial Token DistributionWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
All of the WMX tokens are sent to the contract deployer. This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.
Open the reportHighCentralization Related RisksWemix Retainer 78 NewFanToken · CertiK · 4 Jan 2024Open
In the contract `FanNFTMinter` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and mint NFT.  In the contract `FanNFTMinter` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  ----- In the contract `FanTokenFactory` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority.  ----- In the contract `FanTokenMarket` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and drain funds.  ----- In the contract `FanTokenMinter` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `FanTokenMinter` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority.  In the contract `FanTokenMinter` the role `parameterSetter` has authority over the functions shown in the diagram below. Any compromise to the `parameterSetter` account may allow the hacker to take advantage of this authority.  ----- In the contract `FanTokenRouter` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority.  In the contract `FanTokenRouter` the role `batch` has authority over the functions shown in the diagram below. Any compromise to the `batch` account may allow the hacker to take advantage of this authority.  In the contract `FanTokenRouter` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority.  In the contract `FanTokenRouter` the role `parameterSetter` has authority over the functions shown in the diagram below. Any compromise to the `parameterSetter` account may allow the hacker to take advantage of this authority.  ----- In the contract `FanTokenVault` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and drain funds.  ----- In the contract `GameTokenTwapRouter` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority.  ----- In the contract `NightCrowTWAP` the role `_ow
Open the reportHighCentralization Related RisksWemix Retainer 77 (EnglishAuctionOrder_auto) · CertiK · 5 Dec 2023Open
In the contracts `EnglishAuctionOrderV4_auto` and `OEnglishAuctionOrderV4_auto` the role `_market` has authority over the functions shown in the diagram below. Any compromise to the `_market` account may allow the hacker to take advantage of this authority. 
Open the reportHighCentralization Related RisksWemix Retainer 69 WEMIX Swap V3 · CertiK · 7 Nov 2023Open
In the contract `WeswapV3Factory` the role `breakerSetter` has authority over the functions shown in the diagram below. Any compromise to the `breakerSetter` account may allow the hacker to take advantage of this authority and pause/unpause any pool contracts.  In the contract `WeswapV3Factory` the role `feeControllerSetter` has authority over the functions shown in the diagram below. Any compromise to the `feeControllerSetter` account may allow the hacker to take advantage of this authority and set protocol fees for any pool contracts.  In the contract `WeswapV3Factory` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and - Add/remove arbitrary addresses to/from the whitelist.The whitelisted account can still use the pool contract when it is paused. - Set `tickSpacing` fee through the function `enableFeeAmount()`. - Change `DenylistContract` address through the function `setDenylistContract()`  In the contract `NonfungiblePositionManager` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and initialize the pool. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 69 WEMIX Swap V3 · CertiK · 7 Nov 2023Open
`NonfungiblePositionHelper`/`Quoter`/`QuoterV2`/`WeswapV3Factory`/`NonfungiblePositionManager`/`SwapRouter` are upgradeable contracts, the owner can upgrade the contract without the community's commitment. If an attacker compromises the proxy admin account, he can change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 72 CoveBacking · CertiK · 1 Nov 2023Open
In the contract **CoveBacking.sol**, the role **OWNER** has authority over the following functions: - setClassedCovenant - setVault - setTokenCovenant - withdraw Any compromise to the **OWNER** account may allow a hacker to take advantage of this authority and modify the configuration of the contract, and withdraw assets from the contract. --- In the contract **CoveBacking.sol**, the role **MANAGER** has authority over the following functions: - NEITHifyNext Any compromise to the **MANAGER** account may allow a hacker to take advantage of this authority and withdraw assets from the contract.
Open the reportHighCentralization Risks in GSTAR2023.solWemix Retainer 68 G-STAR2023 · CertiK · 17 Oct 2023Open
In the contract `GSTAR2023` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and - Mint NFTs. - Use (pass) or unuse (unpass) NFTs. - Modify project and NFT configurations. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 68 G-STAR2023 · CertiK · 17 Oct 2023Open
The “GSTAR2023” contract inherits multiple upgradeable contracts, indicating that it’s part of an upgradeable system. Upgradeable contracts often pair with a proxy contract responsible for managing contract upgrades. The `admin` of the proxy has the authority to update the implementation contract (i.e., the GSTAR2023 contract). Any compromise of the admin account could allow a hacker to exploit this authority, potentially altering the implementation contract pointed to by the proxy, and thus executing malicious functionality within the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 60 Reflect project · CertiK · 13 Oct 2023Open
In the contract `REFLECT` the role `_minter` has authority over the functions shown in the diagram below. Any compromise to the `_minter` account may allow the hacker to take advantage of this authority and mint tokens at will.  In the contract `REFLECT` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and make the contract malfunction by changing blacklist.  ----- In the contract `ReflectExchanger` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and make the contract malfunction and steal tokens from the contract.  ----- In the contract `ReflectRouter` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and pause/unpause many functions.  In the contract `ReflectRouter` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change vault contract to potentially steal tokens.  ----- In the contract `ReflectRouterV2`, the role `_owner` has authority over the following functions: - function pause() - function unpause() - function setOperator() - function setExchanger() Any compromise to the `_owner` account may allow a hacker to take advantage of this authority and make the contract malfunction and change important privileged roles operator/exchanger. ----- In the contract ReflectVaultV3, the role `Editor` has authority over the following functions: - setFusedAmount() - setSwapRouter() - setMainnetReflectVault() - setBridge() - addTokens() - subTokens() - activateTokens() - withdrawTokens() - addToken() - subToken() - activateToken() - withdrawToken() Any compromise to the `Editor` account may allow a hacker to take advantage of this authority and make the contract malfunction, steal tokens from the contract. In the contract ReflectVaultV3, the role `Validator` has authority over the following functions: - fusion() - restoreFusion() - fission() Any compromise to the `Validator` account may allow a hacker to take advantage of this authority and make the contract malfunction, steal tokens from the contract. ----- In the contract `ReflectVault`, the role `Editor` has authority over the following functions: - pause() - unpause() - setReflectRouter() - setPlayReflectVault() - setSwapRouter() - setBridge() - setFusedAmount() - addTokens() - subTokens() - activateTokens() - withdrawRemovedAllToken() - addToken() - subToken() - activateToken() - withdrawRemovedToken() Any compromise to the `Editor` account may allow a hacker to take advantage of this authority and make the contract malfunction, steal tokens from the contract. In the contract `ReflectVault`, the role `owner` has authority over the following functions: - withdraw() Any compromise to the `owner` account may allow a hacker to take advantage of this authority and steal tokens from the contract.
Open the reportShow 10 more
HighCentralization Related RisksWemix Retainer 63 AirDrop · CertiK · 21 Sep 2023Open
In the contract `InitializationExecuteManager` the role `_setter` has authority over the functions shown in the diagram below. Any compromise to the `_setter` account may allow the hacker to take advantage of this authority and set the role manager contract address, set the execute manager contract address and set the blacklist contract address.  ----- In the contract `AirDrop` the role `_delegator` has authority over the functions shown in the diagram below. Any compromise to the `_delegator` account may allow the hacker to take advantage of this authority and airdrop the ERC20 token.  In the contract `AirDrop` the role `_setter` has authority over the functions shown in the diagram below. Any compromise to the `_setter` account may allow the hacker to take advantage of this authority and register the delegator for the treasury, deprive the delegator of the treasury, and change the `ReceiveInfo` list max size.  In the contract `AirDrop` the role `treasury` has authority over the functions shown in the diagram below. Any compromise to the `treasury` account may allow the hacker to take advantage of this authority and airdrop the ERC20 token. 
Open the reportHighCentralization Related RisksWemix Retainer 53 (Championship TicketNFT) · CertiK · 11 Sep 2023Open
In the contract `BenefitBase` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and modify the configuration of the contract.  ----- In the contract `BenefitBox` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and modify the important configurations of the contract.  In the contract `BenefitBox` the role `_store` has authority over the functions shown in the diagram below. Any compromise to the `_store` account may allow the hacker to take advantage of this authority and use/unuse and give benefits.  ----- In the contract `FreeDrink` the role `_benefitbox` has authority over the functions shown in the diagram below. Any compromise to the `_benefitbox` account may allow the hacker to take advantage of this authority and use/unuse and give benefits.  ----- In the contract `FreeFood` the role `_benefitbox` has authority over the functions shown in the diagram below. Any compromise to the `_benefitbox` account may allow the hacker to take advantage of this authority and use/unuse and give benefits.  ----- In the contract `Gallery` the role `_benefitbox` has authority over the functions shown in the diagram below. Any compromise to the `_benefitbox` account may allow the hacker to take advantage of this authority and use/unuse and give benefits.  ----- In the contract `Gift` the role `_benefitbox` has authority over the functions shown in the diagram below. Any compromise to the `_benefitbox` account may allow the hacker to take advantage of this authority and use/unuse and give benefits.  ----- In the contract `ParkingArea` the role `_benefitbox` has authority over the functions shown in the diagram below. Any compromise to the `_benefitbox` account may allow the hacker to take advantage of this authority and use/unuse and give benefits.  ----- In the contract `WEMIXChampionship2023` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and mint tokens and modify the token configuration.  ----- In the contract `AccessController` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and modify privileged roles within the contract. 
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 53 (Championship TicketNFT) · CertiK · 11 Sep 2023Open
Multiple contracts inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `privileged roles` of the proxy often have the authority to update the implementation contract. Any compromise of the privileged account could allow a hacker to exploit this authority, potentially altering the implementation contract pointed to by the proxy and thus executing malicious functionality within the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
In the contract `PlayMarketRecipient`, the roles `editor` and `owner` have authority over the following functions: - function setTokenManagerAddress(): set `tokenManagerAddress`. - function setTreasuryAddress(): set the fee address `_treasury`. - function setMaxFee(): set `maxFee`. Any compromise to the `editor` or `owner` account may allow a hacker to take advantage of this authority and change fee settings. In the contract `PlayMarketRecipient`, the role `tokenManagerAddress` has authority over the following functions: - function setRecipient(): set fee recipient addresses. - function distributionEventEmit(): emit `DistributionEvent`. Any compromise to the `tokenManagerAddress` account may allow a hacker to take advantage of this authority. --- In the contract `PlayMarketTokenManager`, the roles `editor` and `owner` have authority over the following functions: - function registerCollection(): register ERC721 or ERC1155 contract that can be traded on market. - function modifyCollection(): modify registered collection. - function modifyCollectionFee(): modify registered collection's fee info. - function blockCollection(): block a collection. - function unblockCollection(): unblock a collection. Any compromise to the `editor` or `owner` account may allow a hacker to take advantage of this authority and manage collections. --- In the contracts `PlayMarketBase`, the roles `editor` and `owner` have authority over the following functions: - function addStrategy(): add or modify strategy to the market. - function subStrategy(): inactivate strategy in the market. - function setPriceOracle(): set price oracle contract. - function setTokenManagerAddress(): set `tokenManager` contract address. - function setPaymentToken(): set payment token. Any compromise to the `editor` or `owner` account may allow a hacker to take advantage of this authority. --- In the contracts `PlayMarketBaseV2`, the roles `editor` and `owner` have authority over the following functions: - function addStrategy(): add or modify strategy to the market. - function subStrategy(): inactivate strategy in the market. - function setPriceOracle(): set price oracle contract. - function setTokenManagerAddress(): set `tokenManager` contract address. - functions addPaymentToken() and removePaymentToken(): manage payment tokens. Any compromise to the `editor` or `owner` account may allow a hacker to take advantage of this authority. --- In the contract `PlayMarketEnglishAuctionOrder`, the roles `editor` and `owner` have authority over the function setMinimumStartPrice() to set the minimum price for the auction price order. Any compromise to the `editor` or `owner` account may allow a hacker to take advantage of this authority. In the contract `PlayMarketEnglishAuctionOrder`, the role `market` has authority over the following functions: - function open(): open an auction. - function offer(): place a bid in an auction. - function cancel(): cancel an auction or bid. - function claim(): the bid winner claims NFT. Any compromise to the `market` account may allow a hacker to take advantage of this authority. --- In the contract `PlayMarketFixedPriceOrder`, the role `market` has authority over the following functions: - function open(): open a sell order. - function offer(): accept a sale order. - function cancel(): cancel an order. - function modify(): update an order. Any compromise to the `market` account may allow a hacker to take advantage of this authority. --- In the contract `PlayMarketOpenPriceOrder`, the role `market` has authority over the following functions: - function open(): open a buy order. - function offer(): accept a buy order. - function cancel(): cancel an order. - function modify(): update an order. Any compromise to the `market` account may allow a hacker to take advantage of this authority. --- In the contracts `LzPlayNFT721` and `PlayNFT721`, the role `owner` has authority over the following functions: - function mint(): mint a non-wrapped NFT. - function mintBatch(): mint multiple non-wrapped NFTs. - function setPlayBridge(): set the `_playBridge` address. - function setTokenIdURI(): set the token's metadata URI. - function setBaseURI(): set the collection's base URI. Any compromise to the `owner` account may allow a hacker to take advantage of this authority. In the contracts `LzPlayNFT721` and `PlayNFT721`, the role `_playBridge` has authority over the following functions: - function mint(): mint wrapped NFT. - function mintBatch(): mint multiple wrapped NFTs. Any compromise to the `_playBridge` account may allow a hacker to take advantage of this authority. --- In the contracts `LzPlayNFT1155` and `PlayNFT1155`, the role `owner` has authority over the following functions: - function mint(): mint non-wrapped ERC1155 token. - function mintBatch(): mint multiple non-wrapped ERC1155 tokens. - function setPlayBridge(): set the `_playBridge` address. - function setTokenIdURI(): set the token's metadata URI. -
Open the reportHighContract Upgrade Centralization RiskWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
In the contracts `PlayMarketTokenManager`, `PlayMarketBase`, `PlayMarketBaseV2`, and `PlayOpenMarket`, the proxy admin has the authority to update the implementation contract behind the proxy contracts. Any compromise to the admin account may allow a hacker to take advantage of this authority and control the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 26 (NFT Refund) · CertiK · 5 Sep 2023Open
In the contract `NFTBurnByValidator` the roles `owner` and `validator` have authority over the functions shown in the diagram below. Any compromise to the `owner` or `validator` account may allow the hacker to take advantage of this authority and sign user signatures to burn NFT and refund tokens.  In the contract `NFTTreasury` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and `changeTreasury()` and `changeRefundAmount()`.  In the contract `NFTLockable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority to update the status of the `paused` and further pause/resume the token transfer status functionality of the `setTransferable()` function, and set the address of the fee token.  In the contract `NFTLockable` the roles `owner` and `validator` have authority over the functions shown in the diagram below. Any compromise to the `owner` or `validator` account may allow the hacker to take advantage of this authority and sign user signatures to mint NFT, and change the transfer status of tokens owned by the user. 
Open the reportHighCentralization Risks in PoET.solWemix PoET Retainer 52 · CertiK · 25 Aug 2023Open
In the contract `PoET` the role `_operator` has authority over the functions shown in the diagram below. Any compromise to the `_operator` account may allow the hacker to take advantage of this authority and setting high rewards for hacker affiliated addresses and subsequently drain WEMIX token from the contract.  In the contract `PoET` the role `_operatormanager` has authority over the functions shown in the diagram below. Any compromise to the `_operatormanager` account may allow the hacker to take advantage of this authority and change operators.  In the contract `PoET` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change `_operatormanager` 
Open the reportHighCentralization Risks in WemixBridgeStorageV2.solWemix Retainer 37 (PPP, PlayBridgeV3 ) · CertiK · 11 Aug 2023Open
In the contract `WemixBridgeStorageV2` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - Set the bridge contract to a malicious implementation through `setBridgeAddress`. - Withdraw tokens and coins locked in the bridge. Since the bridge will transfer locked assets to the `WemixBridgeStorageV2` contract, these privileged functions allow the attacker to rug pull locked asset in the bridge. 
Open the reportHighCentralization Risks in WemixBridgeV3.solWemix Retainer 37 (PPP, PlayBridgeV3 ) · CertiK · 11 Aug 2023Open
In the contract `WemixBridgeV3` the role `_editor` has authority over the functions shown in the diagram below. Any compromise to the `_editor` account may allow the hacker to take advantage of this authority and - lock/unlock token - change the fee rate to Owner percentage - update the address of bridge storage contract. **The current architecture of the system leverages a bridge storage contract where all internal state variables are stored and tracked. It is important to note that any incorrect settings or misconfigurations in this contract could lead to catastrophic system failure.** **Misconfiguration or improper manipulation of storage contract can result in a full shutdown of all bridge services, halting the system's functionality and lock of users' asset.**  In the contract `WemixBridgeV3` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - pause/unpause the contract - add supported tokens to bridge - remove supported tokens from the bridge - withdraw tokens/coins from the bridge - approve `recipient Role` to use the tokens in bridge  In the contract `WemixBridgeV3` the role `_sender` has authority over the functions shown in the diagram below. Any compromise to the `_sender` account may allow the hacker to take advantage of this authority and submit incorrect or forged bridge enter payloads.  **Please note the current bridge implementation relies on the `validator` role to validate parameters of the event(Enter request) from the other side of the bridge. If the validator role get compromised, the attacker can submit arbitrary enter request and drain the asset stored in the bridge.** In the contract `WemixBridgeV3` the role `recipient` has max approval of the bridge contract for all ERC-20 tokens supported. This allows the recipient to not only receive the transferred assets (in `_payCost`) as intended, but also to transfer any leftover ERC-20 token balance to their own address.
Open the reportHighCentralized control of contract address referenceWemix Retainer 37 (PPP, PlayBridgeV3 ) · CertiK · 11 Aug 2023Open
In this project, many contracts, such as `UniversalRouter` and `WemixBridgeV3`, extend `AccessContractRegistry.sol` and rely on `ContractRegistry` to provide the contract address references. In the contract `AccessContractRegistry` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set `contractRegistry` to a malicious implementation.  In the contract `ContractRegistry` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set incorrect `contractsAddress` record. 
Open the reportShow 10 more
HighCentralization RisksWemix Retainer 49 - BYLOManager, VaultManager · CertiK · 7 Aug 2023Open
In the contract `BYLOManager` the role `_setter` has authority over the functions shown in the diagram below. Any compromise to the `_setter` account may allow the hacker to take advantage of this authority and change critical parameters of the project.  In the contract `VaultManagerDeployer` the role `_deployerrole` has authority over the functions shown in the diagram below. Any compromise to the `_deployerrole` account may allow the hacker to take advantage of this authority and deploy potentially defective or malicious vault manager contracts.  In the contract `ScheduleStorage` the role `_setter` and `_vaultmanager` have authority over the functions shown in the diagrams below.   Any compromise to the `_setter` or `_vaultmanager` account may allow the hacker to take advantage of this authority and change critical storage variables. In the contract `VaultManager` the role `_setter` and `navigator` have authority over the functions shown in the diagrams below.   Any compromise to the `_setter` or `navigator` account may allow the hacker to take advantage of this authority and change vault address and other critical parameters of the project.
Open the reportHighCentralization Related RisksWemix Retainer 43 (Staking Pool Mainnet) · CertiK · 3 Aug 2023Open
In the contract `Compounder` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `SPRevenue` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `SPSchedule` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `SPBase` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `SPMineSchedule` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `SPCoolTime` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `SPLimit` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `SPLockUp` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `SPMultiPoint` the role `_owner` has authority over the functions shown in the diagram below.  Any compromise to the `_owner` role would allow the malicious user to drain all `st` and `rt` token from the contract or the respective vault, and change other critical parameters in the project such as changing fee amount.
Open the reportHighCentralization Related RisksWemix Retainer 44 DEX Bridge · CertiK · 20 Jul 2023Open
In the contract `AwayMintBurnableERC20` the role "minter" has authority over the following functions: - mint - burn Any compromise to the "minter" accounts may allow the hacker to take advantage of this authority and mint/burn tokens. ----- In the contract `BridgeV1` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and pause/unpause the bridge, and upgrade the implementation contract.  In the contract `BridgeV1` the role "validator" has authority over the following function: - enter Any compromise to the "validator" accounts may allow the hacker to take advantage of this authority and submit malicious enter messages. In the contract `BridgeV1` the role "validator" has authority to provide signatures for users to bridge tokens in via the following function: - enter Any compromise to the "validator" accounts may allow the hacker to take advantage of this authority and provide malicious signatures. ----- In the contract `BridgeV1Away` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and add malicious tokens at will.  ----- In the contract `BridgeV1AwayFactory` the role "bridge" has authority over the following function: - addMinter Any compromise to the "bridge" accounts may allow the hacker to take advantage of this authority and add malicious token minters. In the contract `BridgeV1AwayFactory` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change token minter to a malicious one, upgrade implementation contract to a malicious one, create a malicious bridge, and change bridge implementation to a malicious one.  ----- In the contract `BridgeV1AwayTokenMinter` the role `__factory` has authority over the following function: - addMinterByFactory Any compromise to the `__factory` account may allow the hacker to take advantage of this authority and add privileged token minters at will. In the contract `BridgeV1AwayTokenMinter` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and add/remove privileged token minters at will.  In the contract `BridgeV1AwayTokenMinter` the role "minter" has authority over the following functions: - mint - burn Any compromise to the "minter" accounts may allow the hacker to take advantage of this authority and mint/burn tokens. ----- In the contract `BridgeV1FeeTable` the role `__bridge` has authority over the following function: - addToken Any compromise to the `__bridge` account may allow the hacker to take advantage of this authority and add token fee information at will. In the contract `BridgeV1FeeTable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update/remove token fee information at will.  ----- In the contract `BridgeV1Home` the role `_owner` has authority over the function shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and add malicious tokens at will.  ----- In the contract `BridgeV1TokenManager` the role `_owner` has authority over the function shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the `__feeTable` at will.  In the contract `BridgeV1TokenManager` the role "validator" has authority over the following functions: - pauseToken - unpauseToken Any compromise to the
Open the reportHighCentralized Control of Contract UpgradeWemix Retainer 44 DEX Bridge · CertiK · 20 Jul 2023Open
In the contracts `BridgeV1Validator`, `BridgeV1AwayFactory`, `BridgeV1TokenManager`, `BridgeV1`, `BridgeV1Away`, and `BridgeV1Home`, the role `_owner` has the authority to update the implementation contracts. 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 proxy and therefore execute potential malicious functionality in the implementation contract.
Open the reportHighCentralization Related RisksWemix Retainer 42 (play, cypress settler v2) · CertiK · 18 Jul 2023Open
In the contract `AccessContractRegistry` the role `_owner` has authority over the function shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the address of `contractRegistry`.  --- In the contract `CypressSettlerV2` the roles `_owner` and `_validator` have authority over the functions shown in the diagram below. Any compromise to the `_owner` or `_validator` account may allow the hacker to take advantage of this authority and settle the WEMIX Classic and transfer the WEMIX Classic to the Wemix vault (main net).  ----- In the contract `PlaySettlerV2` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and `setMinVal`, call `setPeriod()` to set the swap deadline period and call `setCurrencyVault()` to set vaults of currency tokens (p.wemix and p.wemix$).  In the contract `PlaySettlerV2` the roles `owner` and `_validator` have authority over the functions shown in the diagram below. Any compromise to the `owner` or `_validator` account may allow the hacker to take advantage of this authority and settle tokens, `setMinVal()`, transfer `p.wemix` and `p.wemix$` to the Wemix vault (main net), call `changeSwapOption()` to change `swapOption`, call `setSettleDexInfo()` to initialize the balance and settled amount of vault, and call `insertSettleDexInfo()` to manually add swap settlement information.  ----- In the contract `SettlerBaseV2` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority to withdraw tokens, call `setAcquirePercent()` to set close to 100% acquire rate, call `setTokenVault()` to set token vault, and call `setBurner()` to set burner address.  In the contract `SettlerBaseV2` the roles `owner` and `_validator` have authority over the functions shown in the diagram below. Any compromise to the `owner` or `_validator` account may allow the hacker to take advantage of this authority to call `setSettleInfo()` to initialize the balance and settled amount of vault, call `insertSettleInfo()` to manually add settlement information, and call `insertTransferInfo()` to manually add transfer history. 
Open the reportHighCentralization Related RisksOpen
In the contract `RoleManager` the role `role` has authority over the following function: - renounceRole() Any compromise to the `role` account may allow the hacker to take advantage of this authority and renounce corresponding privileges to functions within other contracts. ----------- In the contract `RoleManager` the role `adminRole` has authority over the following functions: - setRoleAdmin() - grantRole() - revokeRole() - renounceRole() Any compromise to the `adminRole` accounts may allow the hacker to take advantage of this authority and grant associated role to any account, revoke the role from any account, and renounce the role. ----------- In the contract `ExecuteManager` the role `setterRole` has authority over the following functions: - changeExecutability() - changeExecutabilityBelongContract() Any compromise to the `setterRole` accounts may allow the hacker to take advantage of this authority and modify important variables. ----------- In the contract `BYLOSports` the role `executeManager` has authority over the following functions: - enter() - reward() Any compromise to the `executeManager` account may allow the hacker to take advantage of this authority and pause or unpause the `enter()` and `reward()` functions. ----------- In the contract `BYLOSports` the role `defaultOwner` has authority over the following functions: - withdrawCharge() - changeValidator() - setVault() - setCoolTime() Any compromise to the `defaultOwner` account may allow the hacker to take advantage of this authority and set important variables, withdraw tokens from the contract, and transfer tokens from `vault`. ----------- In the contract `BYLOSports` the role `validator` has authority to provide signatures, enabling users to interact with the following functions: - enter() - settle() - reward() Any compromise to the `validator` account may allow the hacker to take advantage of this authority and withdraw tokens from this contract and the `vault` address.
HighCentralization Related RisksOpen
In the contract `ERC20WhiteList` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and add/remove whitelisted ERC20 tokens and update `addressManager`.  In the contract `LoanAuctionBase` the role `_admin` has authority over the following functions: - addAllowedAuctionDuration() - removeAllowedAuctionDuration() - pause() - unpause() - setExtendDurationFromLastBidding() - setDefaultLoanDuration() - setTimeToBorrowerFeeDenominator() - setLenderFeeRateMantissa() - setFeeToken() - setFeeWallet() Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and modify important variables, pause/unpause transactions, and set critical variables. In the contract `NFTWhiteList` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and add/remove whitelisted NFTs.  In the contract `NftfiPriceOracle` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and add/remove price oracles.  In the contract `AddressManager` the role `_admin` has authority over the following functions: - setAddressOf() - setAllAddressOf() - removeAddressOf() Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and set critical variables. In the contract `Admin` the role `_admin` has authority over the function shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and transfer the admin role.  In the contract `FixedSwapPath` the role `_owner` has authority over the function shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the role `setterManager`.  In the contract `FixedSwapPath` the role `setterManager` has authority over the function shown in the diagram below. Any compromise to the `setterManager` account may allow the hacker to take advantage of this authority and set the role `swapInfoSetter`.  In the contract `FixedSwapPath` the role `swapInfoSetter` has authority over the functions shown in the diagram below. Any compromise to the `swapInfoSetter` account may allow the hacker to take advantage of this authority and modify the `swapInfos` mapping.  In the contract `OwnableUpgradeable` the role `_owner` has authority over the following functions: - transferOwnership() - renounceOwnership() Any compromise to the `setterManager` account may allow the hacker to take advantage of this authority and transfer or renounce the ownership.
HighCentralization Related RisksOpen
In the contract `AuthorizedMintAccess` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change whitelist status or sensitive state addresses.  In the contract `AuthorizedMintAccess` the role `_whitelistaddresses` has authority over the functions shown in the diagram below. Any compromise to the `_whitelistaddresses` account may allow the hacker to take advantage of this authority and call for the exchange of WEMIX$ and BYLO tokens.  In the contract `AuthorizedMintAccess` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority and stop or resume contract functionality.  In the contract `AuthorizedMintAccess` the role `breakerSetter` has authority over the functions shown in the diagram below. Any compromise to the `breakerSetter` account may allow the hacker to take advantage of this authority and change the respective breaker or breakerSetter addresses.  In the contract `WemixDollarTreasury` the role `_isOwner` has authority over the functions shown in the diagram below. Any compromise to the `_isOwner` account may allow the hacker to take advantage of this authority and create and process transactions through their lifecycle.  In the contract `WemixDollarTreasury` the role `_wallet` has authority over the functions shown in the diagram below. Any compromise to the `_wallet` account may allow the hacker to take advantage of this authority and add/remove/replace owners.  In the contract `DollarInAndOutStabilizerGame` the role `_isOwner` has authority over the functions shown in the diagram below. Any compromise to the `_isOwner` account may allow the hacker to take advantage of this authority and change sensitive contract state data including respective addresses, fees, and `stakingSwitch`.  In the contract `DollarInAndOutStabilizerGame` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority and stop or resume contract functionality.  In the contract `DollarInAndOutStabilizerGame` the role `breakerSetter` has authority over the functions shown in the diagram below. Any compromise to the `breakerSetter` account may allow the hacker to take advantage of this authority and change the respective breaker or breakerSetter addresses.  In the contract `DollarInAndOutStabilizerGame` the role `parameterSetter` has authority over the functions shown in the diagram below. Any compromise to the `parameterSetter` account may allow the hacker to take advantage of this authority and change sensitive contract state data.  In the contract `DollarInAndOutStabilizerGame` the role `swapExecutor` has authority over the functions shown in the diagram below. Any compromise to the `swapExecutor` account may allow the hacker to take advantage of this authority and call for arbitrage swaps to be executed.  In the contract `ContractRegistry` the role `_owner` has authority over the function shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and register the newly deployed contract.  In the contract `CypressSettler` the roles `owner` and `_validator` have authority over the functions shown in the diagram below. Any compromise to the `owner` or `_validator` account may allow the hacker to take advantage of this authority to settle the WEMIX Classic and transfer the WEMIX Classic to the Wemix vault (main net).  In the contract `PlaySettler` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and `setMinVal`, call `setPeriod()` to set the swap deadline period, and `setCurrencyVault`.  In the contract `PlaySettler` the roles `owner` and `_validator` have authority over the functions shown in the diagram below. Any compromise to the `owner` or `_validator` account may allow the hacker to take advantage of this authority and settle tokens, transfer `p.wemix` and `p.wemix$` to the Wemix vault (main net), call `changeSwapOption()` to change `swapOption`, call `setSettleDexInfo()` to initialize the balance of vault, and call `insertSettleDexInfo()` to manually add swap settlement information.  In the contract `SettlerBase` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority to withdraw tokens, call `setAcquirePercent()` to set close to 100% acquire rate, call `setTokenVault()` to set token vault, and call `setBurner()` to set burner address.  In the contract `SettlerBase` the roles `owner` and `_validator` have authority over the functions shown in the diagram below. Any compromise to the `owner` or `_validator` account may allow the hacker to take advantage of this authority to call `setSettleInfo()` to initialize the balance of vault, call `insertSettleInfo()` to manually add settlement information, and call `insertTransferInfo()` to manually add transfer history. 
HighCentralization Related RisksOpen
In the contract **Incinerator**, the role **Editor** has authority over the following functions: - changeDAORouter() - changePurchaseCriteria() - changeAmountPurchase() - changeUnit() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and change the `_daoRouter` address to a hacker affiliated address, such as when `disposeDT()` is called, the new `_daoRouter` receives max `dt` token approval. In the contract **FundManager**, the role **Editor** has authority over the following functions: - changeWeswapRouter() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and change the address of `_weswapRouter`. In the contract **NILEComponent**, the role **Editor** has authority over the following functions: - changeFundRouter() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and change the address of `_fundRouter`. In the contract **ContractFactory**, the role **Editor** has authority over the following functions: - init() - deployDT() - deployGT() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and deploy DAO/Governance token. In the contract **Payment**, the role **Editor** has authority over the following functions: - changeFundRouter() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and init addresses for pointing other contracts. In the contract **Governance**, the role **Editor** has authority over the following functions: - _authorizeUpgrade() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and upgrade the contract. In the contract **MelterRegistry**, the role **Editor** has authority over the following functions: - regist() - deleteMelter() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and register the address of melter and delete the address of melter. In the contract **PteRegistry**, the role **Editor** has authority over the following functions: - regist() - editPte() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and register the address of Pte and change/delete the address of Pte. In the contract **SpellRegistry**, the role **Editor** has authority over the following functions: - addSpell() - removeSpell() - changeSpell() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and add/remove/change the address of Spell. In the contract **EditorRoleUpgradeable**/**EditorRole**, the role **Owner** has authority over the following functions: - addEditor() - removeEditor() Any compromise to the **Owner** account may allow a hacker to take advantage of this authority and add/remove the address of Editor. In the contract **RouterRoleUpgradeable**/**RouterRole**, the role **Editor** has authority over the following functions: - addRouter() - removeRouter() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and add/remove the address of Router. In the contract **MakerRole**, the role **Editor** has authority over the following functions: - addMaker() - removeMaker() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and add/remove the address of Maker. In the contract **DAORouter**, the role **Editor** has authority over the following functions: - init() - changeDenominator() - unpause() - pauseAll() - unpauseAll() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and init addresses for pointing other contracts, change denominator and pause/unpause the DAO. In the contract **FundRouter**, the role **Owner** has authority over the following functions: - init() Any compromise to the **Owner** account may allow a hacker to take advantage of this authority and init addresses for pointing other contract. In the contract **FundRouter**, the role **Melter** has authority over the following functions: - purchaseDT() Any compromise to the **Melter** account may allow a hacker to take advantage of this authority and purchase DAO tokens. In the contract **StakingPool**, the role **Editor** has authority over the following functions: - _authorizeUpgrade() Any compromise to the **Editor** account may allow a hacker to take advantage of this authority and upgrade the contract. In the contract **ReOpen**, the role **Maker** has authority over the following functions: - confirm() Any compromise to the **Maker** account may allow a hacker to take advantage of this authority and check the success or failure of the reopened recruitment. In the contract **ReOpen**, the role **Editor** has authority over the following functions: - changeDenominator() - changeFundRouter() Any compromise to the **
Show 10 more
HighCentralization Related RisksOpen
In the contract `FanTokenMinterV2` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority and pause/unpause the `FanToken` contract.  In the contract `FanTokenMinterV2` the role `parameterSetter` has authority over the functions shown in the diagram below. Any compromise to the `parameterSetter` account may allow the hacker to take advantage of this authority and modify the value of crucial variables such as `additionalMintAmount` and `highestPriceGrade`.  In the contract `FanTokenRouterV2` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and: - Add/remove supported `FanToken` contract - Set donate fee ratio and fee receiver - Set contract addresses of `FanTokenVault`, `PlaySwapRouter`, and `WEMIXPTELTD` 
HighCentralization Related RisksOpen
In the contract `CToken` the role `ServiceAdmin` has authority over the functions - initializeCToken() - setProtocolSeizeShareMantissa() - setReserveFactor() - setInterestRateModel() Any compromise to the `ServiceAdmin` account may allow the hacker to take advantage of this authority and - initialize the money market - set the share of seized collateral that is added to reserves - sets a new reserve factor for the protocol - updates the interest rate model In the contract `CToken` the role `MasterAdmin` has authority over the functions - setController() - setControllerView() - setTransactionHelper() - reduceReservesFresh() Any compromise to the `MasterAdmin` account may allow the hacker to take advantage of this authority and - set the controller contract address - set the controller view contract address - set the transaction helper contract address - reduces reserves by transferring to admin In the contract `Controller` the role `MasterAdmin` has authority over the functions - setControllerView() - setMasterAdmin() - setServiceAdmin() Any compromise to the `MasterAdmin` account may allow the hacker to take advantage of this authority and - set the controller view contract address - set master admin address - set service admin address In the contract `Controller` the role `ServiceAdmin` has authority over the functions - setIncentiveToken() - supportMarket() - setLiquidationIncentive() - setMarketBorrowCaps() - setPriceOracle() - setIsUnsecuredBorrower() - setCloseFactor() - setCollateralFactor() - setMintPaused() - setBorrowPaused() - setSeizePaused() - setTransferPaused() - setOraclePaused() - setIncentiveTokenSpeed() Any compromise to the `ServiceAdmin` account may allow the hacker to take advantage of this authority and - set `INCENTIVE_TOKEN_ADDRESS` - add the market to the markets mapping and set it as listed - set liquidation incentive - set the given borrow caps for the given cToken markets - set the price oracle - add/remove an unsecured borrower to the `isUnsecuredBorrower` map - set the `closeFactor` used to calculate the maximum `repayAmount` when liquidating borrows - set the `collateralFactor` used to calculate the most one can borrow against their collateral in this market - set `isMintPaused` - set `isBorrowPaused` - set `isSeizePaused` - set `isTransferPaused` - set `isOraclePaused` - set incentive token speed of markets and initialize the money market In the contract `InterestRateModel` the role `MasterAdmin` has authority over the functions - updateJumpRateModel() - setMasterAdmin() - setServiceAdmin() Any compromise to the `MasterAdmin` account may allow the hacker to take advantage of this authority and - update the parameters of the interest rate model - set master admin address - set service admin address In the contract `DataCollector` the role `owner` has authority over the functions - setEpochPeriod() - setAggregator() - setQuorum() - addFeeder() Any compromise to the `owner` account may allow the hacker to take advantage of this authority and - set epoch period - set aggregator address - set quorum - add feeder address In the contract `DataCollector` the role `feeder` has authority over the functions - storeData() - setFeederPublicKey() Any compromise to the `feeder` account may allow the hacker to take advantage of this authority and - store data - set the public key for `feeder` own account In the contract `DataCollector` the role `aggregator` has authority over the functions - addData() - setAggregatorPublicKey() Any compromise to the `aggregator` account may allow the hacker to take advantage of this authority and - add the aggregated data of the latest epoch - set the public key of the aggregator In the contract `PriceOracle` the role `admin` has authority over the functions - setGuardians() - setWhiteList() - deleteWhiteList() Any compromise to the `admin` account may allow the hacker to take advantage of this authority and - set guardian addresses - add a new address to the whitelist - remove an address from the whitelist In the contract `PriceOracle` the role `guardian` has authority over the functions - setPrice() Any compromise to the `guardian` account may allow the hacker to take advantage of this authority and - set price for assets In the contract `WemixfiLendingOracle` the role `MasterAdmin` has authority over the functions - setOracle() - setMasterAdmin() - removeOracle() Any compromise to the `MasterAdmin` account may allow the hacker to take advantage of this authority and - set a new price oracle for an asset - transfer the `MasterAdmin` role to a new account - remove the price oracle of an asset
HighCentralization Related RisksOpen
In the contract `FanTokenMinter` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority and pause/unpause the FunToken contract.  In the contract `FanTokenMinter` the role `parameterSetter` has authority over the functions shown in the diagram below. Any compromise to the `parameterSetter` account may allow the hacker to take advantage of this authority and modify the pre-defined state variable `additionalMintAmount`.  In the contract `FanTokenRouter` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - Add/remove supported `FanToken` contract - Set donate fee ratio and fee receiver - Set contract addresses of `FanTokenVault`, `PlaySwapRouter`, and `WEMIXPTELTD`  In the contract `FanTokenRouter` the role `Validator` has authority over the function `mintBatch()`. Any compromise to the `Validator` account may allow the hacker to take advantage of this authority and - Mint `FunToken` to the vault contract In the contract `FanTokenVault`, the role `FunToken` creator and whitelisted accounts have authority over the privileged function `claimFanToken()`. Any compromise to the authorized whitelist accounts may allow the hacker to take advantage of this authority and - Drain the `FanToken` balance from the vault contract
HighCentralization Related RisksOpen
In the contract **PlaySwapZapBase**, **PlaySwapZapIn**, and **PlaySwapZapOut**, the role **owner** has authority over the following functions: - function pause() - function unpause() - function withdrawTokens() Any compromise to the **owner** account may allow a hacker to take advantage of this authority, pause/unpause SwapZap, and withdraw ERC-20 tokens**.
HighCentralization Related RisksOpen
In the contract `DOGMA` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `Drain` the role `onlyBurner` has authority over the functions. Any compromise to the `onlyBurner` account may allow the hacker to take advantage of this authority. - burn anyone's tokens In the contract `Drain` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `Drain` the role `onlyBurner` has authority over the functions. Any compromise to the `onlyBurner` account may allow the hacker to take advantage of this authority. - burn themself's tokens In the contract `DrainAway` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `DrainAway` the role `onlyBurner` has authority over the functions. Any compromise to the `onlyBurner` account may allow the hacker to take advantage of this authority. - burn tokens of the contract In the contract `GameExchanger` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `GovernanceAccrue` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `GovernanceAccrue` the role `validator` has authority over the functions listed below. Any compromise to the `validator` account may allow the hacker to take advantage of this authority. - create agenda and add sectors - drop agenda and kill sectors - execute sectors In the contract `DRONEStakingPool` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `DivineStakingPool` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `HYDRAStakingPool` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `GSPBase` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `GSPCoolTime` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.  In the contract `WemixFeeVaultV4` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the variable `mintFeePercent`.  In the contract `WemixDollarPayment` the role `_owner` has authority over the functions shown in the diag
HighCentralization Related RisksOpen
In the contract `AuthorizedMintAccess` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change whitelist status or sensitive state addresses.  In the contract `AuthorizedMintAccess` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority and stop or resume contract functionality.  In the contract `AuthorizedMintAccess` the role `breakerSetter` has authority over the functions shown in the diagram below. Any compromise to the `breakerSetter` account may allow the hacker to take advantage of this authority and change the respective `breaker` or `breakerSetter` addresses.  In the contract `AuthorizedMintAccess` the role `isWhitelistAddresses` has authority over the functions shown in the diagram below. Any compromise to the `isWhitelistAddresses` account may allow the hacker to take advantage of this authority and call for the exchange of WEMIX$ and BYLO tokens.  In the contract `DollarInAndOutStabilizerGame` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change sensitive contract state data including respective addresses, fees and `stakingSwitch`.  In the contract `DollarInAndOutStabilizerGame` the role `breaker` has authority over the functions shown in the diagram below. Any compromise to the `breaker` account may allow the hacker to take advantage of this authority and stop or resume contract functionality.  In the contract `DollarInAndOutStabilizerGame` the role `breakerSetter` has authority over the functions shown in the diagram below. Any compromise to the `breakerSetter` account may allow the hacker to take advantage of this authority and change the respective `breaker` or `breakerSetter` addresses.  In the contract `DollarInAndOutStabilizerGame` the role `parameterSetter` has authority over the functions shown in the diagram below. Any compromise to the `parameterSetter` account may allow the hacker to take advantage of this authority and change sensitive contract state data.  In the contract `DollarInAndOutStabilizerGame` the role `swapExecutor` has authority over the functions shown in the diagram below. Any compromise to the `swapExecutor` account may allow the hacker to take advantage of this authority and call for arbitrage swaps to be executed.  In the contract `DollarInAndOutStabilizerGame` the role `swapExecutorSetter` has authority over the functions shown in the diagram below. Any compromise to the `swapExecutorSetter` account may allow the hacker to take advantage of this authority and change the respective addresses `swapExecutor` and `swapExecutorSetter`.  In the contract `DollarInAndOutStabilizerGame` the role `_owner` or `bearer` has authority over the following function: - `setMaxArbitrageSwapRatio()` - `setMinArbitrageSwapRatio()` Any compromise to the `parameterSetter` account may allow the hacker to take advantage of this autho
HighCentralization Related RisksOpen
The following contracts contain Privileged functions that can only call by privileged roles. Privileged functions can be used to modify the bridge's configurations and move assets from the bridge. Any compromise to one or more privileged accounts may allow a hacker to take advantage of this authority and alter the bridge configuration, take full control of the bridge, and withdraw assets from the bridge. In the contract `WERC20`, the role `minter` has authority over the following functions: - mint() - burn() Any compromise to the `minter` account may allow the hacker to take advantage of this authority and - mint WERC20 tokens for any address - burn WERC20 tokens from any address In the contract `WemixWERCDeployer`, the role `_owner` has authority over the following functions: - deployWERC20() In the contract `WemixBridgeStorage`, the role `_owner` has authority over the functions. - addBridgeAddress() - removeBridgeAddress() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - add a new bridge address to the `bridge` list - remove the bridge from the `bridge` list In the contract `WemixBridgeStorage`, the role `bridge` has authority over the following functions: - setTokenId() - setToken() - deleteTokenId() - deleteToken() - updateTokenAddr() - updateIncomeFee() - updateFeeAb() - updateMintable() - updateLock() - updateHome() - updateUniDir() Any compromise to the `bridge` account may allow the hacker to take advantage of this authority and - set token id - set token info - delete token id - delete token info - update the configurations of the token In the contract `WemixBridgeV2`, the role `_owner` has authority over the functions. - pause() - unpause() - addToken() - removeToken() - approveTokens() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - pause/unpause the contract - add supported tokens to bridge - remove supported tokens from the bridge - approve tokens when WemixBridgeV2 contract is redistributed **In the contract `WemixBridgeV2`, the role `recipient` gains full control of the token deposited in the contract.** Any compromise to the `recipient` account may allow the hacker to take advantage of this authority and - **steal all tokens in the bridge contract** In the contract `WemixBridgeV2`, the role `editor` has authority over the functions. - lockToken() - unlockToken() - changeFeeRate() - updateRecipientAddr() - updateValidatorAddr() - updateEditorAddr() - updateSenderAddr（） Any compromise to the `editor` account may allow the hacker to take advantage of this authority and - **lock/unlock token** - **change the fee rate of the bridge** - **update the address of the recipient role contract** - **update the address of the validator role contract** - **update the address of the editor role contract** - **update the address of the sender role contract** In the contract `RecipientRoleV3`, the role `_owner` has authority over the following functions: - addService() - removeService() - changeRecipient() - changeServiceRecipient() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - register the recipient of the service - remove registered service - change the token's recipient of a registered service - change the service's recipient of a registered service
HighCentralization Risks in BlackOrWhiteList.solOpen
In the contract `BlackOrWhiteList` the role `_manager` has authority over the functions shown in the diagram below. Any compromise to the `_manager` account may allow the hacker to take advantage of this authority and - add a list of addresses to the entire blacklist, - remove a list of addresses from the entire blacklist, - add a list of addresses to the contract blacklist, - remove a list of addresses from the contract blacklist, - add a list of addresses to the contract whitelist, - remove a list of addresses from the contract whitelist.  In the contract `BlackOrWhiteList` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - deprive manager role from the `addr` address, - grant manager role to the `addr` address. 
HighCentralization Risks in PlaySwapRouter.solOpen
In the contract `PlaySwapRouter` the role `Whitelisted User` has authority over the following functions: - pauseAddLiquidity() - resumeAddLiquidity() - pauseRemoveLiquidity() - resumeRemoveLiquidity() - pauseSwap() - resumeSwap() Any compromise to the `Whitelisted` account may allow the hacker to take advantage of this authority and pause/unpause router functions such as `Add/Remove Liquidity` and `Swap`. Pause of the above functionalities will make the router unusable for normal users.
HighCentralization Risks in PlaySwapZapBase.solOpen
In the contract `PlaySwapZapBase` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and steal tokens from the contract. 
Show 10 more
HighCentralization Risks with MinterOpen
DOGMA is a governance token of the MirM, which is also used as compensation for MirM staking. The DOGMA token is minted in function `mint` and can only be called by `Minter`. The staking reward calculation will use the total amount of minted token Any compromise to the `Minter` account may allow a hacker to take advantage of this authority.
HighCentralized Control of Contract UpgradeOpen
The following contracts are upgradeable contracts, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can modify the implementation in a manner detrimental to the tokenomics. For instance, he could drain tokens from the contracts. - NfiFiHelper - WeswapV2Router - ERC20WhiteList - LoanAuctionFixedInterest - NFTWhiteList - NftfiPriceOracle - AddressManager
HighCentralized Control of Contract UpgradeOpen
`Governance` and `StakingPool` are upgradeable contracts, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.
HighCentralized Control of Contract UpgradeOpen
The owner can upgrade the upgradeable contracts without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.
HighMinting Centralization RiskOpen
In the contract `GameToken`, the role `navigator` has the authority to mint an arbitrary amount of tokens to an arbitrary address. Any compromise to the `navigator` account may allow a hacker to take advantage of this authority and mint a huge amount of tokens to themselves. The hacker could sell those tokens and cause the token price to drop.
HighNo Upper Limits for FeesOpen
There are no upper limits restricting the value of `arbitrageSwapFee`, potentially enabling up to 100% of fees on transactions.
HighNo Upper Limits for FeesOpen
There are no upper limits restricting the value of `arbitrageSwapFee`, potentially enabling up to 100% of fees on transactions.
HighSignature Scheme Should Follow EIP-712 StandardOpen
The current signature validation scheme in contract `WemixBridgeV2` is as follows: ```solidity=292 // multi sig validation for(uint i = 0; i < sigNum; i++){ bytes calldata sig = signatures[i*65:(i+1)*65]; bytes memory message = abi.encodePacked(id_, ca_, tokenAddr_, from_, to_, fromChain_, txHash_, amount_); if(_validatorRole.isValidatorSig(message, sig) == true){ validatedSigNum++; } } // count valid signatures num require(validatedSigNum > SafeMath.div(_validatorRole.numberValidators(),2), "WemixBridge: fail to satisfy sufficient number of valid sig"); ``` This scheme does not follow EIP-712 standard. If the contract is intended to be deployed on multiple blockchains, non-standard signature scheme might cause signature collision and cross-chain replay attacks. See [EIP-712 standard](https://eips.ethereum.org/EIPS/eip-712) for more details.
HighUnsecured Borrowers Can Borrow Assets Without LimOpen
The `borrowAllowed()` function checks if the account should be allowed to borrow the underlying asset of a specified market. However, it does not perform the check for unsecured borrowers in the `isUnsecuredBorrower` map, thus allowing them to borrow an unlimited amount of assets without any collateral. Furthermore, if an unsecured borrower account is compromised, all assets in the market could be drained.
MediumNo cap on feesWemix Retainer 150 WEMEME · CertiK · 13 Feb 2025Open
The `feeBasisPoint` can be set to approach 1 ether, which represents close to 100% fee ratio. When users sell `WEMEME` token via the bonding curve, the fee is deducted from the amount that users receive, which means that users could potentially receive minimal proceeds from the sale of tokens via the bonding curve.
Open the reportShow 10 more
MediumInadequate order id management allows multiple reWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `registerSellOrder()` function prevents the registration of the same NFT multiple times by checking if a valid `OFFER_BIDDING` order already exists. It ensures the order ID of the NFT `tokenId` to be sold is not zero: ```solidity=173 if (_registeredOnOfferBidding[_order.collection][_order.tid] != 0) { ``` However, the initial order ID returned by the `OrderIdManager::getOrderId()` function is zero because the `_ordersID` counter is initially set to zero and not incremented before being returned: ```solidity=27 function getOrderId() external nonReentrant isWhitelist(whitelist, msg.sender) returns(uint){ uint orderID = _ordersID.current(); _ordersID.increment(); return orderID; // <= NOT return the increased ID } ``` If the first order is an `OFFER_BIDDING` order, its order ID will be zero. Since the sellers do not need to escrow the NFT for an `OFFER_BIDDING` order, they can register the order again, leading to multiple registrations of the same NFT. As a result, the 1st and the 2nd orders both are selling the same NFT, leaving one of the orders invalid.
Open the reportMediumPotentially Insufficient `rt` Balance Could BlockWemix Retainer 137 HSPFE · CertiK · 31 Oct 2024Open
In the `unstake()` function, the `_claim()` function is called. In order for the `_claim()` function to execute successfully, there needs to be sufficient `rt` token balance in the `rtVault` contract or `address(this)`, depending on the setup of the contract. There is no guarantee that there is always sufficient `rt` token balance, in which case users would be unable to withdraw their staked token balance. Note that while the `onlyMining` modifier used in the `stake()` function enforces that `totalMinedRT() < amountMax` which mitigates the situation in which users stake into the pool when reward has already run out, there's no enforcement that the `rt` token balance in the `rtVault` contract or `address(this)` is consistent with `amountMax` when the pool is set up initially, and as such insufficient reward token balance could still happen.
Open the reportMediumPotential flashloan attack due to reliance on a sWemix Retainer 125 WemixPayment Contract · CertiK · 16 Oct 2024Open
The contract's dependency on a single DEX pair for price feeds in the `swapPay` and `suggestSwapInAmount` functions makes them susceptible to flashloan attacks. An attacker could use a flashloan to exploit this vulnerability, either by amplifying profits or manipulating the token price on decentralized exchanges.
Open the reportMediumRisks of `abi.encodePacked()` in User-ControlledWemix Retainer 129 PlayTokenExchanger · CertiK · 9 Sep 2024Open
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.
Open the reportMediumPotential MEV Sandwich Attacks due to Missing SliWemix Retainer 74 (DIOSV3) · CertiK · 16 Aug 2024Open
A sandwich attack may happen when an attacker observes a transaction swapping tokens without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (executing before the target) a transaction to purchase one of the assets and make profits by backrunning (executing after the target) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: ```solidity=241 function _executeSwap( address tokenIn, address tokenOut, uint256 amountIn ) internal returns (uint256 amountOut) { bool zeroForOne = tokenIn < tokenOut; (int256 amount0, int256 amount1) = pair.swap( address(this), zeroForOne, amountIn.toInt256(), zeroForOne ? TickMath.MIN_SQRT_RATIO + 1 : TickMath.MAX_SQRT_RATIO - 1, abi.encodePacked(tokenIn) ); return uint256(-(zeroForOne ? amount1 : amount0)); } ```
Open the reportMedium`setMultiplierPointBasis()` Does Not Settle RewarWemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
The function `setMultiplierPointBasis()` in the linked contracts does not settle the current rewards with the old rate. All the staking users will be forced to use the new reward rate. This may be unfair to the user if the new rate is lower.
Open the reportMediumNo Upper Limit for FeeWemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
There are no upper boundaries for the functions `setPlatformFeeRatio()` and `setRewardFeeRatio` which are used to set the platform fee ratio and reward fee ratio. It is possible to set the total fee up to any arbitrary amount.
Open the reportMediumNo Upper Limits for FeesWemix Retainer 113 Liquid Staking · CertiK · 15 Apr 2024Open
The function `feeUpdate()` does not limit the percentage of fees applied. The fee of phase two rates could therefore be 100%. If the `feePhaseTwo` is set to `10000`, the reward will be 0 and all fees will be sent to the treasury address.
Open the reportMediumNo Upper Limit for FeeWemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
There is no upper limit restricting the parameter of `setFeeRate()` which is used to set fee percent. It is possible to set the total fee up to 100%. ```solidity=121 function setFeeRate(uint256 feeRate_) external onlyKeeper { require(feeRate_ <= 1e4, "KlevaDistributor: Invalid feeRate"); harvestAll(); feeRate = feeRate_; emit DevFeeRateSet(feeRate); } ``` ```solidity=196 function setProtocolFeeRate(uint256 pid_, uint256 protocolFeeRate_) external onlyKeeper { require(isValid(pid_), "EarnRouter: Invalid pid"); require(protocolFeeRate_ <= 1e4, "EarnRouter: Invalid protocolFeeRate"); _updateShare(pid_); _poolInfos[pid_].protocolFeeRate = protocolFeeRate_; emit ProtocolFeeRateSet(pid_, protocolFeeRate_); } ```
Open the reportMediumWeak Pseudo Random Number GeneratorWemix Retainer 102 DEX NFT Service · CertiK · 19 Mar 2024Open
The `random` number generation is based on the result of the function `nextSeed()`; And the inputs are the result of `newSeed()`, `keccak256` encryption of `block.number`,`gasleft()` etc... which is easy to control or get. The inputs can be controlled by the caller of the transaction. ```solidity function newSeed(GachaStorage storage _gs, bytes memory _salt) internal returns (uint256) { uint256 _seed = uint256(keccak256(abi.encodePacked(_gs.seed, _salt, msg.sender, block.timestamp, gasleft()))); _gs.seed = _seed; return _seed; } function nextSeed(uint256 _seed, uint256 _maxRatio) internal pure returns (uint256 next, uint256 value) { if (_maxRatio == 0) revert ZeroMaxRatio(); unchecked { value = _seed % _maxRatio; next = _seed / _maxRatio; } } ``` The `nextSeed()` is called multiple times in the function `_executeGacha()`, and the result(value,ratio) of the prior call is used as input to invoke the subsequent call. However, the result is still not randomized, which would result in the result being deterministic. ```solidity function _executeGacha( LibGacha.GachaStorage storage _gs, LibCharacter.CharacterStorage storage _cs, uint256 _gachaID, LibGacha.Gacha storage _gacha, bytes memory _salt ) private { address _owner = msg.sender; // call `nextSeed` 3 times in this internal function (uint256 _seed, uint256 _characterID) = _gachaCharacterID(_gs.newSeed(_salt), _gacha); // call `nextSeed` 2 times in this internal function LibCharacter.Info memory _characterInfo = _gachaCharacterInfo(_cs, _gs, _seed, _characterID); uint256 _tokenID = LibCharacter.mint(_cs, _owner, _characterInfo); emit GachaExecuted(_owner, _gachaID, _tokenID); } ``` Given that the randomize is used on the mint of new Gacha, a user could wait until an "appropriate" block number happens, input prepared gas and other parameters to execute the transaction, and gain an advantage on the random generation of a new Gacha, which would impact its base and bonus stats.
Open the reportShow 10 more
MediumMinimum start price could be too highWemix Retainer 100 PlayNFTMarket (hybrid-auction) · CertiK · 1 Mar 2024Open
The `setMinimumStartPrice()` function specifies the `minimumStartPrice` cannot be smaller than 1e17. This constraint assumes a token with 18 decimals. However, this becomes problematic for tokens with fewer decimals, like [USDC](https://wemixscan.com/token/0xe3f5a90f9cb311505cd691a46596599aa1a0ad7d), which has 6 decimals. With USDC, a `minimumStartPrice` of 1e17 equates to $1e11, preventing sellers from setting lower start prices for their NFTs.
Open the reportMediumOut-of-Scope oracle DependencyWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
The system requires an off-chain oracle (DarkOracle) to settle orders (`settleOrders`) and liquidate positions (`liquidatePositions()`). The audit's scope treats third-party off-chain oracles as black boxes and assumes their functional correctness. However, in the real world, the oracles can be compromised or malfunction, which may result in lost or stolen assets.
Open the reportMediumUsers may lose rewards due to rounding errorsWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
A possible rounding issue was identified in the reward calculation mechanism of the smart contract. The logic in question can lead to precision loss and result in some rewards not being credited to users. Specifically, the problem arises within the `updateRewards` function. When `pendingReward * UNIT` is less than `supply`, the division results in a round-down to zero, causing the value of `cumulativeRewardPerTokenStored` not to increase as intended. There is also a precision loss even in the case where the result is different from zero, this will occur whenever the pendingReward * UNIT is not divisible by the supply. This behavior fails to reflect the true amount of reward that should be accumulated per token, resulting in a discrepancy that leads to reward loss for users. ```sol=60 if (supply > 0) { cumulativeRewardPerTokenStored += pendingReward * UNIT / supply; pendingReward = 0; } ```
Open the reportMediumPotential Unauthorized Re-use of `bridgeTx` and `Wemix Retainer 60 Reflect project(addendum) · CertiK · 19 Oct 2023Open
In the “ReflectVault” contract, the `restoreFission()` and `finalFission()` have two new function arguments `bridgeTx` and `logIdx`. These two new function arguments are user inputs in the same functions of the “ReflectRouter” contract. These two function inputs are independent of the `from` address, `userHash` etc. and the check below only checks that the provided `bridgeTx` and `logIdx` correspond to a finalized bridge transaction. As such, these variables `bridgeTx` and `logIdx` could potentially be re-used by other users if there's insufficient check in the bridge contract and whitelisted address that are out-of-scope of this audit. ```solidity require(WemixBridgeV3(payable(wemixBridge)).checkFinalized(keccak256(abi.encodePacked(bridgeTx, logIdx))), "RV: not bridge finalized"); ```
Open the reportMediumFunction `checkBalance()` cannot verify the receiWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
The `Checker.checkBalance()` function is used to ensure that the token amount received by the strategy contracts is equal to the NFT price. However, if the strategy contracts have any existing token balances before the transaction, the balance check could be incorrect. ```solidity=59 function checkBalance(address token, uint value) internal view returns (bool) { uint balance; if (token == address(0)) { balance = address(this).balance; } else { balance = IERC20(token).balanceOf(address(this)); } return balance >= value; } ```
Open the reportMedium`ReqAddLiquidity` does not revert when Provided wWemix Retainer 37 (PPP, PlayBridgeV3 ) · CertiK · 11 Aug 2023Open
Upon reviewing the existing implementation of `reqAddLiquidity()`, it was observed that the incorporated require checks only confirm the validity of one input token, not both. ```solidity=266 require(addLiqReq.tokens[0] == address(0) || addLiqReq.tokens[1] == address(0) || addLiqReq.tokens[0].isContract() || addLiqReq.tokens[1].isContract(), "PPPRequest: invalid tokens"); ``` To illustrate, if a user inputs a token pair into the `reqAddLiquidity` function, where `tokens[0]` is a valid token and `tokens[1]` is not a valid token contract address (EOA address for example), the function will execute successfully without revert, triggering a ReqAddLiquidity event. As an auditor, we lack insight into the backend server's management of the `ReqAddLiquidity` event and the corresponding PPP request. As a result, we advise seeking confirmation from the development team to ensure that the case highlighted above does not pose potential security risks. Possible vulnerabilities could include bypassing safety checks or initiating incorrect `AddLiquidity` operations on the requested chain.
Open the reportMediumThe `unstakeWithCompound()` Function Might not FuWemix Retainer 43 (Staking Pool Mainnet) · CertiK · 3 Aug 2023Open
In the `unstakeWithCompound()` function, the `_compound()` function could increase the user's staked balance from converting accumulated reward to `st` token, such that there is residual staked balance for the user, even if the input argument `amount` is the user's total staked balance before calling the function.
Open the reportMedium`shutDown()` Function Allows Owner to Transfer AlOpen
The `shutDown()` function in the `SPRevenue` and `SPSchedule` contracts allow the Owner account to transfer all `rt` and `st` tokens from the respective vault to any arbitrary owner designated address (when all IDs are paused). While it could be useful as an emergency rescue method, if the Owner account is ever compromised, the entire token balance at the `rtVault` and `stVault` could be at risk of being drained.
MediumInsufficient `rt` Balance Could Block Users FromOpen
In the external `unstake()` function, the `_claim()` function is called. In order for the `_claim()` function to execute successfully, there needs to be sufficient `rt` token balance in the `rtVault` contract or `address(this)`, depending on the setup of the contract. There is no guarantee that there is always sufficient `rt` token balance, in which case users would be unable to withdraw their staked token balance.
MediumOut of Scope DependenciesOpen
In the contract `WemixFeeVault`: ```solidity=51 function _addIncome(address token, bytes32 column, uint amount, uint percent) internal { _recipientRole._addIncome(token, column, amount, percent); } ``` In the library `RecipientLib`: ```solidity=21 function _addIncome(Recipient storage r, address token, bytes32 column, uint amount, uint percentToOwner) internal { require(r.recipientRoleV2 != address(0), "RecipientLib: RecipientRoleV2 address is not set"); if(IERC20(token).allowance(address(this), r.recipientRoleV2) < amount) { require(IERC20(token).approve(r.recipientRoleV2, uint(-1)),"RecipientLib: approve error"); } require(IRecipientRoleV2(r.recipientRoleV2).addIncome(r.service, token, column, amount, percentToOwner),"RecipientLib: addIncome error"); } ``` When method `_distribution()` is called, the contract `GameExchanger` approves the maximum transfer amount of `recipientRoleV2`， so `recipientRoleV2` can transfer all the tokens from the exchange. The scope of the audit treats contract `_recipientRole` and above-linked parent contracts that are out of scope as black boxes and assumes their functional correctness. However, in the real world, those contracts can be compromised.
Show 10 more
MediumPotential Compounder Migration RiskOpen
The `setCompounder()` function allows the contract owner to change the `compounder` address. In the `_compound()` function, this contract approves the `compounder` address of maximum `rt` amount. If the Owner account is compromised, or if the `compounder` address does not function as intended, users' reward can be lost.
MediumPotential Reentrancy AttackOpen
The following codes in the function `redeemFresh()/borrowFresh()` do not meet the Checks-Effects-Interactions pattern. ```solidity=391 vars.actualBorrowAmount = doTransferOut(borrower, borrowAmount); vars.borrowPrincipalNew; accountBorrows[borrower].principal = vars.accountBorrowsNew; accountBorrows[borrower].interestIndex = borrowIndex; totalBorrows = vars.totalBorrowsNew; vars.borrowPrincipalNew = borrowPrincipal[borrower] + vars.actualBorrowAmount; borrowPrincipal[borrower] = vars.borrowPrincipalNew; ``` It only has a reentrancy lock as there is no lock at the Controller level, only the CToken level. If the `CToken` is an ERC777/ERC677 protocol, the reentrancy can happen in function levels of an ERC777/ERC677-based contract, i.e. multiple function calls that are triggered by the hook mechanism of ERC777/ERC677. This issue is possible to happen with all compound forks, but Compound is not affected as they do not list tokens with callback functionality.
MediumPotential Vault Migration RiskOpen
The constructor of the `SPBase` contract sets the `rtVault` and `stVault` to `address(this)`, but the owner can migrate vaults and transfer all user funds to the new vaults through the `setVault()` function. The new vaults can be compromised / might not have all the users' staking and reward details, and this may lead to lost or stolen assets. Any compromise to the owner's account may allow a hacker to take advantage of this authority.
MediumWhitelisted Users can call paused functionsOpen
The `isFunctionNotBlocked` modifier ensures that a function is not only paused but also checks if the `msg.sender` is whitelisted. However, there are certain cases where even if a function is paused, whitelisted accounts should still have access to specific functions such as `addLiquidity` or `removeLiquidity`.
LowLack of Restriction on virtualWemixReserves CouldWemix Retainer 150 WEMEME · CertiK · 13 Feb 2025Open
When a new MEME token is created, the token creator can designate any `_virtualTokenReserves` and `_virtualWemixReserves` as long as they satisfy the requirements in line 26 and 27 of the `BondingCurve` contract. Given that the `_realTokenReserves` and `_realWemixReserves` are `TOTAL_SUPPLY` and `0` respectively, the token creator can choose a very small `_virtualWemixReserves` such as 1 wei. The advantage of setting a very low `_virtualWemixReserves` is that the first time buyer could use a very small amount of WEMIX to purchase a very large portion of the new MEME token, and subsequent buyers would have to pay a much higher price. Based on the following formula in the `getBuyPrice()` function, assume that `curve.virtualWemixReserves` and `curve.virtualTokenReserves` are `1` and `1e18` initially, and a buyer uses 1 Wemix to purchase the token. ```solidity uint256 n = curve.virtualWemixReserves * curve.virtualTokenReserves; uint256 i = curve.virtualWemixReserves + amount; uint256 r = (n / i) + 1; uint256 tokensToBuy = curve.virtualTokenReserves - r; ``` `n` would be `1e18`, `i` would be `2`, `r` would be `5e17 + 1`, and `tokensToBuy` would be `5e17 - 1`, which is almost half of the total supply of MEME token. If a subsequent buyer uses 1 Wemix to purchase the token, the amount purchased would be meaningfully less than half of the total supply given the shape of the bonding curve. This design could potentially allow token creators and snipers to gobble up a large percentage of new MEME token supply at the expense of future buyers. While the market mechanism would determine if future buyers choose to make subsequent token purchases, participants should be made aware of the implication of such a design.
Open the reportLowOut Of Scope DependenciesWemix Retainer 150 WEMEME · CertiK · 13 Feb 2025Open
The `WEMEMEFactory` contract interacts with out-of-scope dependencies, such as `contractRegistry`, `contractRegister`, and `playSwapRouter` contracts. The scope of the audit treats out-of-scope dependencies as black boxes and assumes their functional correctness, such as ensuring that the same `cName32` cannot be registered more than once.
Open the reportLowStrict Equality Could Make the Last Buy TransactiWemix Retainer 150 WEMEME · CertiK · 13 Feb 2025Open
The `_complete()` function contains a strict equality check that `c.realWemixReserves == wemixThreshold`. When users buy the tokens via the `buy()` function, line 158 `require(toUser >= minTokensOut, "Insufficient tokens out");` effectively put a minimum `amount` that a user can buy, and this value is added to `c.realWemixReserves` in line 170. This could potentially be problematic. For example, if the minimum amount that a user can buy is 10, but `c.realWemixReserves` is currently `wemixThreshold - 5`, then any buy transaction would fail and the `_complete()` function would never execute successfully.
Open the reportLowWEMEME Token DeploymentWemix Retainer 150 WEMEME · CertiK · 13 Feb 2025Open
In order to create a new pump token, the intended workflow is that a user calls the `create()` function of the `WEMEMErouter` contract, which in turn calls the `create()` function of the `WEMEMEFactory` contract to deploy a new `WEMEME` token. However, anyone can also deploy a `WEMEME` token directly without going through `WEMEMERouter` and `WEMEMEFactory` and set its own `_roleManager` and `_policy` addresses that are different from those set by the project team. While these tokens will not be registered in the official `contractRegistry`, it can potentially be confusing to normal users.
Open the reportLowCostly operations inside a loopWemix Retainer 147 WEMIX Governance · CertiK · 19 Dec 2024Open
Costly operations inside a loop might waste gas, so optimizations are justified. ```solidity=1311 memberLength = i; ``` ```solidity=1331 nodeLength = i; ```
Open the reportLowMissing Error MessagesWemix Retainer 147 WEMIX Governance · CertiK · 19 Dec 2024Open
The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.
Open the reportShow 10 more
Low`Order.canceledTime` does not reflect the time anWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `Order.canceledTime` variable is intended to track the cancellation time of orders. However, this variable is not updated to `block.timestamp` when orders are canceled.
Open the reportLow`resumeAllFunction()` does not resume individuallWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `resumeAllFunction()` resumes all paused functions by setting the `allPause` state variable to `true`. However, if a specific function has been paused using the `pauseFunction(FUNCTIONS)` function, calling `resumeAllFunction()` will not resume this individually paused function. This behavior can be misleading, as the name `resumeAllFunction()` suggests that all paused functions will be resumed, but in reality, specific functions paused by `pauseFunction(FUNCTIONS)` remain paused.
Open the reportLowEmit Inaccurate EventsWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `offerBuyOrder()` function allows the caller to specify a different address as the `offerer`. However, when emitting the `OrderAccepted` event, the function incorrectly passes the `offerer` address as the `sender`, instead of `msg.sender`: ```solidity=245 emit OrderAccepted( offerer, // <= should be msg.sender ``` ```solidity=46 event OrderAccepted( address indexed sender, ``` --- The offered price is `_offerPrice[_order.orderID][offerer]` instead of `price`, as users can increase their offer by `price`: ```solidity File: PlayMarketOfferBiddingOrder.sol 71: _offerPrice[_order.orderID][offerer] += price; ... 78: emit OrderOffered(orderID, offerer, price, block.timestamp); ```
Open the reportLowInadequate order type check in `acceptOffer()`Wemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `acceptOffer()` function is used for sellers to accept `OFFER_BIDDING` orders. While the function ensures that the type of orders to be accepted cannot be `BUY`, it does not prevent the acceptance of `SELL` or `AUCTION` orders: ```solidity=318 require(!(_order.orderStrategyType == Type.OrderStrategyType.BUY), "MB: this function is not for buy order"); ```
Open the reportLowIncorrect expire time check in `cancelExpiredOrdeWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `cancelExpiredOrders()` function in the `PlayMarketOpenPriceOrder` contract is designed to cancel orders that have exceeded their duration time. The mapping `durationTime(orderId => durationTime)` stores the duration time for each `orderId`. However, the `cancelExpiredOrders()` function incorrectly accesses this mapping using the loop index `i` instead of the `_order.orderId`: ```solidity File: PlayMarketOpenPriceOrder.sol 14: mapping(uint => uint) public durationTime; // order id => duration time ... 153: function cancelExpiredOrders(uint[] memory orderIDs) external nonReentrant isWhitelist(whitelist, msg.sender) { ... 160: if(durationTime[i] > 0) { // <= array index should be _order.orderId 161: if (_order.startTime + durationTime[i] > block.timestamp) continue; 162: } else{ ``` This error results in the function ignoring `durationTime` configuration and canceling orders based on `stay` duration time.
Open the reportLowIncorrect Handling of WEMIX Payments in `offerSelWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `offerSellOrder()` function in the `PlayMarketBaseV5` contract is marked as `payable`, allowing buyers to pay WEMIX coins to purchase NFTs from the market. However, there are inconsistent with the handling of these payments based on the `order.orderStrategyType`. The function calls `OrderV2::offer()` based on the `order.orderStrategyType`: - If `order.orderStrategyType == Type.OrderStrategyType.SELL`, the `SELL` orders are handled by the `PlayMarketFixedPriceOrder::offer()` function, which supports both WEMIX coins and ERC20 tokens: ```solidity=53 if (_order.payment == address(0)) { require(msg.value == orderPrice, "FP : Invalid value"); } else { IERC20(_order.payment).safeTransferFrom(payer, address(this), orderPrice); } ``` - If `order.orderStrategyType == Type.OrderStrategyType.OFFER_BIDDING`, the `OFFER_BIDDING` orders are handled by the `PlayMarketOfferBiddingOrder::offer()` function, which does not support WEMIX coin payments. Additionally, the `offerSellOrder()` function does not forward the received WEMIX coins to the `OrderV2` strategy contract: ```solidity=283 (success, order) = IOrderV2(strategy.strategyAddress).offer(orderID, msg.sender, offerer, amount, marketType); ``` As a result, while the contract intends to support WEMIX payments, the current implementation fails to do so properly. This leads to WEMIX coins being locked in the contract if buyers pay WEMIX to buy NFT.
Open the reportLowLack of escrow and fee for `OFFER_BIDDING` ordersWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `PlayMarketBaseV5` contract allows NFT owners to register `OFFER_BIDDING` orders without escrowing their NFTs or paying any fees. These orders can be settled only when sellers accept the buyer's offers. This creates an opportunity for malicious users to register `OFFER_BIDDING` orders that will never be settled with prices lower than the market value, thereby causing honest users to pay tokens and submit offers on these fraudulent orders. Since these orders will not be settled by malicious sellers, honest users are forced to cancel their offers after realizing they have been deceived, leading to a poor user experience. The only cost to the malicious users is the low WEMIX chain gas fee.
Open the reportLowLack of Support for WWEMIX Token in `PlayMarketHyWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The strategy `PlayMarketHybridAuctionOrder` is currently not updated to support transactions involving the WWEMIX token, we'd like to confirm if it is intended.
Open the reportLowPossibility to Lock WEMIX in ContractWemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The functions `registerSellOrder()`, `offerBuyOrder()`, and `claimOrder()` in the `PlayMarketBaseV5` contract are marked as `payable`, allowing them to receive WEMIX coins. However, these functions do not include any logic to handle the received WEMIX coins. Additionally, the `PlayMarketBaseV5` contract lacks a function to withdraw the WEMIX coins. As a result, any WEMIX coins sent to these functions will become locked in the contract.
Open the reportLowUnnecessary `payable` Modifier in `offerBuyOrder(Wemix Retainer 123 PlayNftMarket · CertiK · 16 Dec 2024Open
The `offerBuyOrder()` function allows NFT sellers to accept buy orders by transferring their NFTs to the strategy contract. This function is marked as `payable`, which permits the caller to send $WEMIX tokens along with the transaction. However, since this function does not require the payment of any tokens by NFT sellers, the inclusion of the `payable` modifier is unnecessary. NFT sellers inadvertently send $WEMIX tokens when calling `offerBuyOrder()`, leading to an unintended loss of funds.
Open the reportShow 10 more
LowStorage Size ConventionWemix Retainer 141 GameServerNFT · CertiK · 15 Nov 2024Open
While not a requirement, generally each upgradeable contract contains 50 storage slots in total, including already used storage slots. In the `GameServerNftBaseV1` contract, the total number of storage slots used exceeds the common convention for upgradeable contracts. Specifically, the contract uses 2 storage slots for state variables and reserves an additional 50 storage slots using the `__gap` variable, bringing the total to 52 storage slots. This exceeds the typical convention of reserving a total of 50 storage slots, including used and reserved slots, which may lead to issues in future upgrades if not managed carefully.
Open the reportLow`approve` return value not checkedWemix Retainer 137 HSPFE · CertiK · 31 Oct 2024Open
Not all `IERC20` implementations `revert` when there's a failure in `approve`. The function signature has a `boolean` return value and they indicate errors that way instead. By not checking the return value, operations that should have been marked as failed may potentially go through without actually approving anything.
Open the reportLowOut of scope Dependency UsageWemix Retainer 137 HSPFE · CertiK · 31 Oct 2024Open
The in-scope contracts interact with one or more out of scope contracts, such as `recipientRoleV6`, `WemixBridge`, `stVault`, `rtVault`, `rt` and `st` tokens etc. The scope of the audit treats those entities as black boxes and assumes their functional correctness. However, in the real world, those contracts can be compromised and this may lead to lost or stolen assets. In addition, `rt` and `st` tokens cannot be deflationary or fee-on-transfer tokens, and upgrades of any out-of-scope contract can potentially create severe impacts.
Open the reportLowOut-of-Scope DependenciesWemix Retainer 125 WemixPayment Contract · CertiK · 16 Oct 2024Open
The audited code base interacts with several out-of-scope contracts, including `roleManager`, `executeManager`, `recipientRole`, `listManager`, and `IMSWWithdrawImmediately` etc. The scope of the audit treats out-of-scope entities as black boxes and assumes their functional correctness. However, in the real world, those dependencies can be compromised and this may lead to lost or stolen assets.
Open the reportLowPotential Attack for Signatures (Violate EIP-2612Wemix Retainer 125 WemixPayment Contract · CertiK · 16 Oct 2024Open
The current implementation of signed messages in the contract omits the inclusion of the sender's address and a domain separator. Having no domain separator allows the signature to be reused on other contracts or chains. The `_checkAuth` function is intended to ensure that the sender's address is not blacklisted. However, since the sender's address is not included in the signed message, the signature holder can bypass this check by using any other address during verification. Even if the original signer (who might be blacklisted) holds the signature, they can delegate it to a non-blacklisted address, circumventing the intended security measure. This vulnerability can be particularly exploited in the pay and swapPay functions.
Open the reportLowRedundant StatementsWemix Retainer 125 WemixPayment Contract · CertiK · 16 Oct 2024Open
The linked statements do not affect the functionality of the codebase and appear to be either remnants of test code or older functionality.
Open the reportLowShadowing State VariableWemix Retainer 125 WemixPayment Contract · CertiK · 16 Oct 2024Open
A state variable is shadowing another component defined in a parent contract. Variable `deadline` in `PaymentStorageV2` shadows the variable `PayInfo.deadline` in `IPaymentSturct`.
Open the reportLowUser-Defined GettersWemix Retainer 125 WemixPayment Contract · CertiK · 16 Oct 2024Open
The linked functions are equivalent to the compiler-generated getter functions for the respective variables.
Open the reportLowIncompatibility With Deflationary Tokens (Non-staWemix Retainer 129 PlayTokenExchanger · CertiK · 9 Sep 2024Open
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.
Open the reportLowThird-Party DependenciesWemix Retainer 129 PlayTokenExchanger · CertiK · 9 Sep 2024Open
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.
Open the reportShow 10 more
LowConcerns on Price Time CheckWemix Retainer 133 PricePolicy · CertiK · 9 Sep 2024Open
The current implementation of the `isMintableTime()` function checks whether the current time is greater than the timestamp of the TWAP recorded in `priceCache.TimeStamp`: ```solidity=152 function isMintableTime(uint start) public view returns (bool) { return block.timestamp > start; } ``` With the cached price being saved when or before the query occurs, this check will succeed if the price query and TWAP update transactions are not in the same block. The function does not account for the possibility that the cached TWAP price might be stale. A stale TWAP price, which has not been updated for an extended period, could lead to outdated pricing data being used within the protocol.
Open the reportLowLack of Equality Check in `changeGameTokenMinterWemix Retainer 131 NightCrowTWAPV3 · CertiK · 22 Aug 2024Open
The `changeGameTokenMinter()` function does not check whether the `newGameTokenMinter` is the same as the `oldMinter`. If these addresses are the same, the function will mistakenly delete the lock price and freeze period information associated with the `newGameTokenMinter` at the end of the function, leading to unintended consequences. ```solidity=93 function changeGameTokenMinter(address newGameTokenMinter, address gameToken, string memory symbol) external onlyEditor { require(newGameTokenMinter != address(0) && gameToken != address(0), "GTTR : address is zero"); require(tokenToTwap[gameToken] != address(0), "GTTR : not registered game token"); require(tokenToTwap[gameToken] == symbolToTwap[symbol] , "GTTR : wrong input"); address oldMinter = tokenToTwap[gameToken]; //relation info symbolToTwap[symbol] = newGameTokenMinter; tokenToTwap[gameToken] = newGameTokenMinter; //lock price info lockPrice[newGameTokenMinter] = lockPrice[oldMinter]; freezePeriod[newGameTokenMinter] = freezePeriod[oldMinter]; delete lockPrice[oldMinter]; delete freezePeriod[oldMinter]; emit GameTokenChanged(gameToken, oldMinter, newGameTokenMinter); } ```
Open the reportLowOut Of Scope DependenciesWemix Retainer 131 NightCrowTWAPV3 · CertiK · 22 Aug 2024Open
The protocol serves as the underlying entity to interact with out-of-scope dependencies. The out-of-scope dependencies that the contracts interact with are: - `IGameTokenTwapRouter.sol`; - `IGameTokenMinter.sol` - `EditorRole.sol`; The scope of the audit treats out-of-scope dependencies as black boxes and assumes their functional correctness.
Open the reportLowFunction `initialize()` Is UnprotectedWemix Retainer 74 (DIOSV3) · CertiK · 16 Aug 2024Open
One or more logic contracts do not protect their initializers. An attacker can call the initializer and assume ownership of the logic contract, whereby he can perform privileged operations that trick unsuspecting users into believing that he is the owner of the upgradeable contract. ```solidity=20 contract DollarInAndOutStabilizer3 is OperatorManagement, IDollarInAndOutStabilizer3 ``` - `DollarInAndOutStabilizer3` is an upgradeable contract that does not protect its initializer. ```solidity=63 function initialize( IWeswapV3Pool _pair, ISwapRouter _swapRouter, IWeswapRouter _weswapRouter, IAMA _ama, address _rewarder, uint160 _baseSqrtPriceX96 ) external initializer { ``` - `initialize` is an unprotected initializer function.
Open the reportLowModifier `Onlyinitializing` should be used for InWemix Retainer 74 (DIOSV3) · CertiK · 16 Aug 2024Open
For upgradeable contracts, it is recommended to use `onlyInitializing` to protect initialization functions in parent contracts so that they can only be invoked by functions with the `initializer` and `reinitializer` modifiers. Reference: https://docs.openzeppelin.com/contracts/4.x/api/proxy#Initializable-onlyInitializing--
Open the reportLowSafeMath Not UsedWemix Retainer 74 (DIOSV3) · CertiK · 16 Aug 2024Open
`SafeMath` library is not used in the linked contract, making it possible for overflow/underflow to occur and lead to inaccurate calculations. ```solidity=144 data.minSqrtPriceX96 = (data.baseSqrtPriceX96 * 99993) / 100000; data.maxSqrtPriceX96 = (data.baseSqrtPriceX96 * 100007) / 100000; ```
Open the reportLowIncompatibility with Deflationary TokensWemix Retainer 122 TokenPayment · CertiK · 13 Aug 2024Open
When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. If a user uses the `pay()` function to provide a certain `amount` of deflationary tokens for a product, the token payment contract receives fewer tokens than the user-provided `amount`. However, the contract still transfers the full `amount` of tokens to the `recipientRole`, which exceeds the amount received from the user.
Open the reportLowOut-of-Scope DependenciesWemix Retainer 122 TokenPayment · CertiK · 13 Aug 2024Open
The audited code base interacts with several out-of-scope contracts, including `VerifyKeyUpgradeable`, `PaymentStorage`, `roleManager`, `executeManager`, `recipientRole`, `listManager`, `INightCrowFT` etc. The scope of the audit treats out-of-scope entities as black boxes and assumes their functional correctness. However, in the real world, those dependencies can be compromised and this may lead to lost or stolen assets.
Open the reportLowRisks of `abi.encodePacked()` in User-ControlledWemix Retainer 122 TokenPayment · CertiK · 13 Aug 2024Open
Encoding through `abi.encodePacked()` is used with at least two dynamic type inputs controlled by the user. This type of encoding is susceptible to malleability when used with strings, bytes, or other dynamic types. As such, it is not a good choice for signature verification with the input used, since users can change the input and potential get the same bytes output from `abi.encodePacked`. Moreover, note that uints and other variable types do not need to be converted to strings before being encoded.
Open the reportLow`rewardsToCancel`, `bulkCancelInfos` and `funderWemix Retainer 121 wepublicBank · CertiK · 2 Aug 2024Open
The `abi.encodePacked()` function encodes the given arguments into bytes using tightly packed, contiguous encoding. However, the argument `rewardsToCancel`, `bulkCancelInfos` and `funders` are not included as part of the signature message. This omission leads to insufficient checks on these arguments, potentially allowing malicious actors to manipulate these values without proper signature validation. ```solidity=424 bytes memory packedData = abi.encodePacked( "CANCEL_FUND", msg.sender, timestamp, projectTreasury, cancelAmount //@audit: `rewardsToCancel` not encoded in message ); require( RbacSignatureValidator.isValidSignature( wepublicPoint, keccak256(packedData), signature, CANCEL_FUND_ROLE ), "FundingProjectTreasury: invalid signature" ); ``` ```solidity=553 bytes memory packedData = abi.encodePacked( "CANCEL_FUNDING_PROJECT", msg.sender, timestamp, projectTreasury //@audit: `funders` not encoded in message ); require( RbacSignatureValidator.isValidSignature( wepublicPoint, keccak256(packedData), signature, CANCEL_FUNDING_PROJECT_ROLE ), "FundingProjectTreasury: invalid signature" ); ```
Open the reportShow 10 more
LowInadequate Check in the function `fund()/cancelFuWemix Retainer 121 wepublicBank · CertiK · 2 Aug 2024Open
In the function `fund()`, the `timestamp` parameter is intended to refer to the current time but lacks validation to ensure it matches `block.timestamp` and falls within the project's start and end timestamps. Additionally, there are no checks to ensure that the `rewardId` in the `rewards` array for the `fund()` function and the `rewardsToCancel` array for the `cancelFund()` function are within the valid range (Within the range of `rewardInfos.length`). This can lead to issues such as array index out-of-bounds errors.
Open the reportLowRisks Associated with Unknown Implementations inWemix Retainer 119 DIOSV3 (2) · CertiK · 8 Jul 2024Open
When the `executeTransaction()` function is called, it executes code contained within `transaction.data`, which is not known or specified within the audit's scope. ```solidity=108 (bool success, ) = transaction.to.call{value: transaction.value}(transaction.data); ``` While the transaction requires confirmation by multiple signatories, there remains a vulnerability if one or more owners inadvertently approve a malicious transaction. Such transactions could potentially lead to the unauthorized transfer of assets or other harmful actions within the contract. This audit treats external implementations referred to in `transaction.data` as black boxes and assumes their functional correctness. Given the inherent risks of executing unknown code, it is crucial for the development team to monitor these transaction contents continuously.
Open the reportLowCross-chain Reuse of SignatureWemix Retainer 117 SupportProjectTreasuryV2 · CertiK · 28 May 2024Open
The signature computed at the pointed lines does not include any information regarding the chain the contract is deployed to. In the case in which the `SupportProjectTreasuryV2` contract is deployed on multiple blockchains, then the signatures used on one chain for a certain account, can be reused as-is on each chain where the contract is present.
Open the reportLowIneffective `isContract()` CheckWemix Retainer 117 SupportProjectTreasuryV2 · CertiK · 28 May 2024Open
The implementation of the function `isContract()` check can not cover all scenarios. The check can be bypassed if the call is from the constructor of a smart contract or when the contract is destroyed. Because, in that case, the codesize will also be zero. The "isContract" function in the OpenZeppelin "Address" library uses the same implementation, but comments mention that "it's unsafe to rely on the check and it can be bypassed". Reference: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol
Open the reportLowSupporters do not send any `wepublicPoint` to theWemix Retainer 117 SupportProjectTreasuryV2 · CertiK · 28 May 2024Open
Supporters have the option to donate either WEMIX or WepublicPoint to the `SupportProjectTreasuryV2` contract to support projects. However, if supporters choose to support a project with WepublicPoint, the actual transfer of WepublicPoint does not occur.
Open the reportLowThe `supporters` are not being verified by the siWemix Retainer 117 SupportProjectTreasuryV2 · CertiK · 28 May 2024Open
The `cancelProject()` function allows the `projectOwner` to cancel a project and refund assets to supporters after inputs are signed by a signer with the `CANCEL_SUPPORT_PROJECT_ROLE` role. However, the input `supporters` list is not included in the signed data. This omission allows the `projectOwner` to alter the list of supporters using the same signature.
Open the reportLowThe provided `timestamp` is not checkedWemix Retainer 117 SupportProjectTreasuryV2 · CertiK · 28 May 2024Open
In the `deactivateProject()` and `cancelProject()` functions, the `timestamp` is included in the `packedData` that is used to verify the provided `signature`. However, there is no explicit check within the function to validate the `timestamp` against any other time-related constraint. This raises concerns that the `timestamp` may not be serving its intended purpose, as there is no validation to ensure it falls within an acceptable range.
Open the reportLowLacking the condition that the staking amount isWemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
In the function `_deposit()`, if the user is the first to stake, the `totalDepositors` of the pool will be increased by 1. However, the condition that the staking amount is greater than 0 is missing, causing the `totalDepositors` to be greater than the actual count due to no amount being deposited. ```solidity=998 if (user.amount == 0) { pool.totalDepositors++; } ```
Open the reportLowRedundant ComparisonsWemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
Comparisons that are always true or always false may be incorrect or unnecessary. ```solidity=419 require( feeRatioRequests[pid].ratio >= 0 && feeRatioRequests[pid].ratio <= 10000, "fee Ratio is invalid" ); ```
Open the reportLowThird-Party Dependency UsageWemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
The contract is serving as the underlying entity to interact with one or more third party protocols. 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. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=1639 address public registry; ``` - The contract `NCPStaking` interacts with third party contract with `IRegistry` interface via `registry`.
Open the reportShow 10 more
LowUnused modifier `whenNotLock`Wemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
The functions `setFeeCollector()`, `setUnbondTime()`, `ncpDeposit()` and `ncpWithdraw()` do not use the modifier `whenNotLock`, which requires that the pool not to be locked.
Open the reportLowUnused State VariableWemix Retainer 111 Wonder Staking · CertiK · 15 Apr 2024Open
Some state variables are not used in the codebase. This can lead to incomplete functionality or potential vulnerabilities if these variables are expected to be utilized. ```solidity=66 address public governance; ``` --- ```solidity=72 address public governanceStaking; ``` --- ```solidity=18 uint256 public accRewardPerShare; ```
Open the reportLow`nonReentrant` Modifier can be Placed and ExecuteWemix Retainer 113 Liquid Staking · CertiK · 15 Apr 2024Open
As a best practice, the `nonReentrant` modifier could be placed and executed before other modifiers in functions to prevent reentrancy attacks through other modifiers and make the code more efficient.
Open the reportLowThird-Party Dependency UsageWemix Retainer 113 Liquid Staking · CertiK · 15 Apr 2024Open
The contract is serving as the underlying entity to interact with one or more third party protocols. 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. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=27 address public staking; // immutable ``` - The contract `StWEMIXV6` interacts with third party contract with `IStaking` interface via `staking`. --- ```solidity=51 address wonder_, ``` - The function `StWEMIXV6.initialize` interacts with third party contract with `INCPStaking` interface via `wonder_`.
Open the reportLow`approve` return value not checkedWemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
Not all `IERC20` implementations `revert` when there's a failure in `approve`. The function signature has a `boolean` return value and they indicate errors that way instead. By not checking the return value, operations that should have been marked as failed may potentially go through without actually approving anything.
Open the reportLowDifferent pool name can set the same pool idWemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
The function `addPoolName()` only checks whether `poolName` has a pool ID. This means the keeper can set a different pool name for the same pool ID, and the pool ID can be set to any value, including a non-existent ID. ```solidity=173 function addPoolName(string calldata poolName_, uint256 pid_) external onlyKeeper { require(poolNameToId[poolName_] == 0, "EarnRouter: poolName already has pid"); poolNameToId[poolName_] = pid_; emit PoolNameAdded(pid_, poolName_); } ```
Open the reportLowLack of migration logic when setKlevaDistributorWemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
According to the KlevaConfig contract, the owner can set a new `_klevaDistributor`. However, there might be claimable rewards not harvested and shares not migrated from the old `_klevaDistributor`. It's better to have complete migration logic before changing the config of `_klevaDistributor`.
Open the reportLowThe use of the function `depositBehalf()`Wemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
In the contract `KlevaLocker`, users can transfer `klevaToken` tokens to this contract and increase other accounts' balances. If the keeper adds a `KlevaLocker` pool, users deposit 100 `klevaToken` tokens to this pool, and `earnRouter`'s balance is 100. Another user calls the function `depositBehalf()` to increase `earnRouter`'s balance to 150. Therefore, the user can see 150 withdrawable from the function `getEarnPoolUserInfo()`, but they only withdraw 100, leading to confusion.
Open the reportLowThird-Party DependenciesWemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
The contract is serving as the underlying entity to interact with one or more third party protocols including `ICToken`, `IKurrencyEarn`,`IKurrencyPriceCalculator`. 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. In addition, upgrades of third parties can possibly create severe impacts. --- - The contract `WemixfiEarnImpl` interacts with third party contract with `ICToken` interface via `target_`. ```solidity baseToken_ = ICToken(target_).underlying(); ICToken(target_).mint(depositAmount_); ``` --- - The contract `KurrencyEarnImpl` interacts with third party contract with `IKurrencyEarn` interface via `target_`. ```solidity baseToken_ = IKurrencyEarn(target_).WCD(); IKurrencyEarn(target_).stake(depositAmount_); ``` --- - The contract `Dashboard` interacts with third party contract with `IKurrencyPriceCalculator` interface via `kurrencyPriceCalculator`. ```solidity (uint256 lastData, ) = IKurrencyPriceCalculator(kurrencyPriceCalculator).references( klevaToken ); ```
Open the reportLowUsage of `selfdestruct` or `delegatecall` WithinWemix Retainer 103 KLEVA Omni · CertiK · 2 Apr 2024Open
`delegatecall` is an operation that allows a contract to call another contract's function while using the calling contract's storage and context. `selfdestruct` is an operation that destroys the current contract. The usage of these functions in the implementation contract might allow the attacker to either destroy the implementation contract or exploit other vulnerabilities from the misuse of `delegatecall`. However, the external address `implementation_` used in the `_delegate()` function is specified by the `onlyOwner` function `setImplementation()`, hence the possibility of the abovementioned exploit is much lower unless the owner role is compromised.
Open the reportShow 10 more
LowIncompatibility With Deflationary TokensWemix Retainer 102 DEX NFT Service · CertiK · 19 Mar 2024Open
When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee) to the target contract, only 90 tokens arrive at the contract.
Open the reportLowPotential Storage Slot Overwriting Risk in UpgradWemix Retainer 102 DEX NFT Service · CertiK · 19 Mar 2024Open
In the `LibCharacter` library, the `Base` and `Info` structs are put directly in the `CharacterStorage`. It is not able to add new state variables to inner structs in upgrades without overwriting the storage slot of variables declared after the struct. ```solidity=16 struct Base { uint16 collection; uint16 grade; uint32[STAT_SIZE] stat; } // Info 32 bytes struct Info { uint32 id; uint8 level; uint8 powerBonus; // x % POWER_MC uint32[STAT_SIZE] stat; } // @custom:storage-location erc7201:diamond.standard.character.v1.storage struct CharacterStorage { uint256 birthAt; LibERC721.ERC721Storage character; EnumerableSet.UintSet characterIDList; mapping(uint256 => Base) bases; // characterID => CollectionGrade mapping(uint256 => Info) infos; // tokenID => Info; } ```
Open the reportLowRedundant Code ComponentsWemix Retainer 106 DIOS Staking · CertiK · 18 Mar 2024Open
Since the modifier `notInDenylist()` has been removed, the state variable `denylistContract` is redundant as well. The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.
Open the reportLowNFT Tokens May Support Both ERC721 and ERC1155 StWemix 99 PlayNFTMarket · CertiK · 1 Mar 2024Open
Some NFT tokens may support both ERC721 and ERC1155 standards, for example, [Sandbox's ASSETs](https://etherscan.io/address/0x7fbf5c9af42a6d146dcc18762f515692cd5f853b#code#F2#L14). As the 1st “if” statement is always evaluated to true in this scenario, the `collectionType` is set to "ERC721". Consequently, the `collectionType` of `CollectionRegistered` event may be inaccurate. Furthermore, the symbol and name are not saved for the new ERC1155 collection in `registerCollection()`. Calling `modifyCollection()` is required to set them.
Open the reportLowIncompatibility With Fee on Transfer TokensWemix Retainer 100 PlayNFTMarket (hybrid-auction) · CertiK · 1 Mar 2024Open
When transferring transfer-on-fee ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction.
Open the reportLowPotential function selector collisionWemix Retainer 88 NILE MarketPlace (hybrid) · CertiK · 13 Feb 2024Open
The `ExecuteManager` contract is designed to manage un-executable function selectors by maintaining a map that marks certain functions as un-executable. It is worth noting that functions in different contracts could share the same function selector. Since these functions may belong to different contracts, marking a function selector as un-executable could inadvertently affect legitimate and intended functionalities in the protocol.
Open the reportLowUnused owner roleWemix Retainer 88 NILE MarketPlace (hybrid) · CertiK · 13 Feb 2024Open
The `RoleManager` contract is designed as a multiple role management contract. However, it inherits `Ownable2StepUpgradeable`, which is specifically designed to facilitate an owner role that can be granted exclusive access to specific functions within the contract. It was observed that the `RoleManager` contract does not make use of the owner role functionality provided by the `Ownable2StepUpgradeable`. The `ExecuteManager` contract shares the similar issue that the owner role is unused.
Open the reportLowLack of Leverage Check in the `settleOrder` FunctWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
The smart contract contains a pair of functions `submitOrder` and `settleOrder` that enable users to open positions on the trading platform. During the `submitOrder` process, a check for `maxLeverage` is performed. However, it has been identified that `settleOrder`, which is executed by an external oracle, is missing this check. Due to the potential time gap between `submitOrder` and `settleOrder`, the currency price may fluctuate, resulting in a possibility where the user’s position might exceed the `maxLeverage` at the time of settlement.
Open the reportLowMissing Zero Address ValidationWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=32 owner = newOwner; ``` - `newOwner` is not zero-checked before being used. --- ```solidity=36 router = _router; ``` - `_router` is not zero-checked before being used. --- ```solidity=44 currency = _currency; ``` - `_currency` is not zero-checked before being used. --- ```solidity=48 owner = newOwner; ``` - `newOwner` is not zero-checked before being used. --- ```solidity=52 router = _router; ``` - `_router` is not zero-checked before being used. --- ```solidity=37 pool = _pool; ``` - `_pool` is not zero-checked before being used. --- ```solidity=38 currency = _currency; ``` - `_currency` is not zero-checked before being used. --- ```solidity=42 owner = newOwner; ``` - `newOwner` is not zero-checked before being used. --- ```solidity=46 router = _router; ``` - `_router` is not zero-checked before being used. --- ```solidity=81 treasury = _treasury; ``` - `_treasury` is not zero-checked before being used. --- ```solidity=82 trading = _trading; ``` - `_trading` is not zero-checked before being used. --- ```solidity=83 wmxPool = _wmxPool; ``` - `_wmxPool` is not zero-checked before being used. --- ```solidity=84 oracle = _oracle; ``` - `_oracle` is not zero-checked before being used. --- ```solidity=85 darkOracle = _darkOracle; ``` - `_darkOracle` is not zero-checked before being used. --- ```solidity=108 owner = newOwner; ``` - `newOwner` is not zero-checked before being used. --- ```solidity=94 owner = newOwner; ``` - `newOwner` is not zero-checked before being used. --- ```solidity=98 router = _router; ``` - `_router` is not zero-checked before being used. --- ```solidity=25 owner = newOwner; ``` - `newOwner` is not zero-checked before being used. --- ```solidity=29 router = _router; ``` - `_router` is not zero-checked before being used.
Open the reportLowPool liquidity providers can front-run liquidatioWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
The perpetual contract project allows users to deposit funds into a pool, which serves as liquidity for other users engaging in perpetual trading against the pool providers. An issue is discovered in the contract's handling of deposits and withdrawals amount calculation; it fails to account for unrealized profits and losses. This vulnerability exposes the pool to front-running tactics. Specifically, if someone detects a significant position that is about to be liquidated, they can front-run the transaction by depositing it first. Similarly, if a large profitable position is about to be settled, a liquidity provider can front-run the transaction to minimize the loss.
Open the reportShow 10 more
LowPotential Cross-Chain Replay AttackWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
Signed messages are not properly verified with the current chain ID, thus allowing attackers to perform replay attacks across chains. Hardcoded or cached chain ID values are also vulnerable since a hard fork may occur and change the chain ID in the future. ```solidity=51 require(_verify(users, productIds, currencies, directions, prices, signer, nonce, signature), "Invalid signature"); ``` - Calling `_verify`, which eventually calls `ecrecover`. ```solidity=142 address signer = ecrecover(hash, v, r, s); ``` - Calling `ecrecover` with a hash that does not properly include the chain ID.
Open the reportLowReminder to Provide Initial Deposit to the Pool tWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
The method used by the pool to calculate user shares is possibly vulnerable to "Inflation Attacks". In essence, an attacker can deposit one share into the pool when the vault is empty and front-run another user's deposit. This action causes the subsequent user's deposit to receive zero shares, effectively stealing the other user's deposit. For more information regarding "Inflation Attacks," please see: https://blog.openzeppelin.com/a-novel-defense-against-erc4626-inflation-attacks
Open the reportLowThe Purpose of the "ReleaseMargin" FunctionWemix Retainer 84 WMX.Fi (external audit) · CertiK · 24 Jan 2024Open
The "ReleaseMargin" function enables the owner to close a position and refund all the principal, possibly including the fee, to the user. The auditor would like to know why such a function, which can create an unfair situation for most of the protocol users, is added to the contract.
Open the reportLowLack of validation on token URIWemix Retainer 78 NewFanToken · CertiK · 4 Jan 2024Open
The NFT token URI is specified by the editor role but lacks duplication validation to prevent NFT tokens from sharing the same URI. NFT tokens are inherently unique, and their URIs should not be identical.
Open the reportLowMint less fan tokens if `twapMint()` is not calleWemix Retainer 78 NewFanToken · CertiK · 4 Jan 2024Open
The minter of the fan token (`fanTokenToMinter[fanToken]`) can be modified using the `factory::registerFanToken()` or `factory::createFanTokenMinter()` functions. However, the `minter::twapMint()` function is not invoked for the new minter to initiate the "first twap record." If price of fan token increases from \$1 to \$1.1, and `twapMint()` is called for the first time, with `twapGrade = highestPriceGrade` (FanTokenMinter, L353), the `mintingAmount` calculated by `_computeMintable()` is zero. Therefore, no fan token will be minted, even though token price has increased.
Open the reportLowMissing Update `initialized` State VariableWemix Retainer 78 NewFanToken · CertiK · 4 Jan 2024Open
Based on the implementation of the `myrtleMigration()` and `initAddLiquidity()` functions, it is evident that the state variable `initialized` is employed to track the initialization status of the FanToken by invoking the `initialize()` function within the `FanTokenMinter.sol` file. Nevertheless, in the `upgradeMinter()` function, there is an absence of code logic to update the state variable `initialized`, despite the invocation of the `initialize()` function at line 86. ```solidity=33 mapping(address => bool) public initialized; ``` ```solidity=78 //only for upgrading FanTokenMinter function upgradeMinter(uint highestPrice, address fanToken) external onlyEditor NotZeroAddress(fanToken) { address fanTokenMinter = IFanTokenFactory(fanTokenFactory).fanTokenToMinter(fanToken); require(fanTokenMinter != address(0), "FTR : MYRTLE is not registered in factory"); address swapPair = IPlaySwapRouter(playSwapRouter).getPair(fanToken, WEMIXDollar); require(swapPair != address(0), "FTR : swap pool is not created"); IFanTokenMinter(fanTokenMinter).initialize(parameterSetter, breaker, fanTokenVault, WEMIXDollar,fanTokenMarket, fanToken, swapPair); ISpecialTokenMinter(fanTokenMinter).specialMigration(highestPrice); IFanTokenMinter(fanTokenMinter).twapMint(); } ```
Open the reportLow`collectBlockNumber` not returned in function `poWemix Retainer 69 WEMIX Swap V3 · CertiK · 7 Nov 2023Open
The `positions()` function is intended to expose details about a specific position. While the function successfully returns most of the details, it omits the `collectBlockNumber` field that is available in the Position struct. ```solidity=185 function positions( uint256 tokenId ) external view override returns ( uint96 nonce, address operator, address token0, address token1, uint24 fee, int24 tickLower, int24 tickUpper, uint128 liquidity, uint256 feeGrowthInside0LastX128, uint256 feeGrowthInside1LastX128, uint128 tokensOwed0, uint128 tokensOwed1 ) ```
Open the reportLowOut of Scope DependenciesWemix Retainer 72 CoveBacking · CertiK · 1 Nov 2023Open
The `CoveBacking.sol` contracts serve as the underlying entity to interact with the external dependency `ClassedCovenant` and `roleManager`, `ClassedToken` contracts. However, the scope of the audit assumes this contract is functionally correct and is treated as a black box.
Open the reportLowLack of Safety Check in `setFusedAmount()` FunctiWemix Retainer 60 Reflect project · CertiK · 13 Oct 2023Open
The `setFusedAmount()` function allows the Editor to set `fusedAmount` to any positive number. The `fusedAmount` variable is supposed to track the users' total fusion minus total fission amount, as the `finalFusion()` function increments this variable and the `finalFission()` function decrements this variable. If the `fusedAmount` is set to be too low, then any legitimate fission transaction would revert, as line 486 would revert if/when there's underflow.
Open the reportLowMissing `getUseDate` in `FreeDrink.sol`Wemix Retainer 53 (Championship TicketNFT) · CertiK · 11 Sep 2023Open
The `FreeFood.sol` contract contains the `getUseDate` function, which is used for querying the "_useDateOf" data. However, it is missing in the `FreeDrink.sol` file.
Open the reportShow 10 more
LowOut of Scope DependenciesWemix Retainer 53 (Championship TicketNFT) · CertiK · 11 Sep 2023Open
Most of the non-view functions in the project can only be called by privileged roles, such as the Owner, "onlyStore," and "onlyAdmin." The security and operational correctness will heavily rely on the contracts outside the current audit scope or off-chain components. If the out-of-scope component performs incorrect operations, it can cause the contracts in scope to exhibit erroneous behavior.
Open the reportLowNFT price can be manipulatedWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
The NFT market stores order information, including the NFT price, in the `PlayNFTMarketOracle` contract. However, users can list their NFTs on the market for trading and can specify any price for their NFTs. This situation opens the possibility for malicious users to engage in price manipulation by paying fees and trading with different wallets. As a consequence, any protocols relying on the NFT price provided by the `PlayNFTMarketOracle` are potentially not safe.
Open the reportLowNo Upper Limits for FeesWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
There is no upper limit restricting parameter of `modifyCollectionFee()` and the maximum fee in the `PlayMarketRecipient` contract is 100%, potentially enabling up to 100% of fees on transactions.
Open the reportLowNot all orders support the native tokenWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
In the `PlayMarketBase` contract, payable functions `registerBuyOrder()`, `offerBuyOrder()` and `claimAuction()` are able to receive native tokens, but their functionality does not depend on native tokens, and the contract does not have a withdrawal function, which could result in tokens being locked.
Open the reportLowOrder price is not check when registering a saleWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
The `registerSellOrder()` function lacks of a sanity check to ensure the order price is not zero.
Open the reportLowOrders in `_orderIDsBySeller[]` are never removedWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
Opened orders are saved in the `_orderIDsBySeller[]` but they are never removed, for example, the order is completed or canceled.
Open the reportLowOut of Scope DependenciesWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
The contract serves as the underlying entity to interact with `PriceOracle` contract. The scope of the audit treats contract that is out of scope as black boxes and assumes their functional correctness. However, in the real world, those contracts can be compromised.
Open the reportLowThe `cancelSellOfferBuy()` is not restricted by `Wemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
The modifier `nonReentrant` is not applied to the function `PlayOpenMarket.cancelSellOfferBuy()` to prevent reentrance attacks.
Open the reportLowThe default auction close delay is zeroWemix Retainer 48 PlayNFTMarket · CertiK · 7 Sep 2023Open
An auction will end if there is no new bid after the designated close delay of the auction order. If the seller hasn't called `setCloseDelay()` to change the close delay, the default close delay for an auction order is zero. Consequently, the auction will conclude after the first bid.
Open the reportLowCannot refund tokens if NFT is unlockedWemix Retainer 26 (NFT Refund) · CertiK · 5 Sep 2023Open
The `refundByValidator()` function unlocks the NFT before refunding tokens. Once the NFT has been unlocked, it cannot be burned to refund tokens.
Open the reportShow 10 more
LowMalleability of `abi.encodePacked`Wemix Retainer 26 (NFT Refund) · CertiK · 5 Sep 2023Open
Encoding through `abi.encodePacked()` is used with dynamically-sized inputs controlled by the user. This type of encoding is susceptible to malleability when used with strings, bytes, or other dynamically-sized types. As such, it is not a good choice for signature verification with the input used, since users can change the input and potentially get the same bytes output from `abi.encodePacked`. ```solidity=93 onlyValidatorSig(abi.encodePacked(tokenURI, userSig), validatorSig) ``` - `abi.encodePacked` is called with dynamically-sized arguments: `tokenURI`, `userSig` ```solidity=88 string calldata tokenURI, ``` - `tokenURI` is a dynamically-sized external parameter. ```solidity=89 bytes calldata userSig, ``` - `userSig` is a dynamically-sized external parameter.
Open the reportLowPotential Cross-Chain Replay AttackWemix Retainer 26 (NFT Refund) · CertiK · 5 Sep 2023Open
Signed messages are not properly verified with the current chain ID, thus allowing attackers to perform replay attacks across chains. Hardcoded or cached chain ID values are also vulnerable since a hard fork may occur and change the chain ID in the future.
Open the reportLowThe event triggered when burning and returning toWemix Retainer 26 (NFT Refund) · CertiK · 5 Sep 2023Open
Both `burnByValidator()` and `refundByValidator()` functions emit the same `NFTBurned` event, while the `refundByValidator()` function refunds tokens after the NFT has been burned.
Open the reportLowTransfer all tokens to new treasury when changingWemix Retainer 26 (NFT Refund) · CertiK · 5 Sep 2023Open
The `changeTreasury()` function allows the owner to change the `treasury` address. If the new `treasury` address is that of the `NFTTreasury` contract, all tokens in the old `treasury` address will be migrated to the `newTreasury` address. However, if the old `treasury` address is an EOA address, no tokens will be transferred, and the `treasury` will need to migrate the tokens separately.
Open the reportLowUsers can choose refund or not by themselfWemix Retainer 26 (NFT Refund) · CertiK · 5 Sep 2023Open
If the data signed by users is approved and signed by a validator, the signed data `userSig` and `validatorSig` can be used as input to call `burnByValidator()` or `refundByValidator()`. The `burnByValidator()` function will unlock and burn the NFT, while the `refundByValidator()` function will additionally refund the `account` wallet. The caller can choose whether to refund tokens or not by choosing which function to call. ```solidity=42 require(account == ECDSA.recover(keccak256(abi.encodePacked(address(this), tokenID, account, column)), userSig), "NFT: user recover error"); ```
Open the reportLowPotential Outdated Library UsageWemix PoET Retainer 52 · CertiK · 25 Aug 2023Open
The `initialize()` function of the `PoET` contract contains `__Ownable_init()` with no function argument. In the latest OpenZepplin library, the `__Ownable_init()` function contains an `initialOwner` function argument, as seen here: https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/access/OwnableUpgradeable.sol This indicates that the OpenZeppelin library being used might not be the latest one. In certain situations, this might create real problems. For example, if the deployer of the `PoET` logic contract is the same as the Admin or Owner of the proxy contract, and if the proxy contract uses the Transparent Proxy pattern that only delegate calls to the `PoET` contract from non admin / non owner addresses, then the `onlyOwner` function in `PoET` contract might be unreachable, as the proxy contract would not reach the `fallback()` function if the caller is the admin / owner address.
Open the reportLowThird-Party DependenciesWemix PoET Retainer 52 · CertiK · 25 Aug 2023Open
The `PoET` contract is a logic contract that should be used in connection with a proxy contract. The scope of the audit does not include the proxy contract itself, and this audit treats it as a black box and assumes its functional correctness. However, if the proxy contract contains errors or vulnerabilities, it may lead to loss or stolen assets, such as via upgrading the contract to allow the hacker to withdraw all Wemix tokens.
Open the reportLowDangerous Usage of `tx.origin` in PPP contractsWemix Retainer 37 (PPP, PlayBridgeV3 ) · CertiK · 11 Aug 2023Open
In PPP contracts, `tx.origin` is used to check if the `***Info.User` is the transaction sender. As mentioned in finding `PPP-01`, the external function `addLiquidity` and `removeLiquidity` do not allow direct calls and can only be called by the `UniversalRouter` or the `Sender` role. Therefore, we recommend the team move the `user` check to the `UniversalRouter` and use the `msg.sender` to verify the user. ```solidity=124 require(addLiqInfo.user == tx.origin || ISenderRoleV2(CA(PPPConfigs.senderRole)).isSender(tx.origin, pppService), "PPPLiquidity: not valid sender"); ``` `tx.origin` check has been deprecated after EIP-3074. EIP3074 introduces two EVM instructions AUTH and AUTHCALL. The first sets a context variable authorized based on an ECDSA signature. The second sends a call as the authorized. This essentially delegates control of the EOA to [a] smart contract. This means there will be a way for smart contracts to send transactions in the context of an Externally Owned Account, thus bypassing this check. **Also tx.origin is widely discourage as there are possible phishing attempts.** For a contract, the `tx.origin` is not transparent. In a simple call chain A->B->C->D, inside D msg.sender will be C, and tx.origin will be A. If the origin is really desired in D, then each of the functions in the contracts B, C, D could take an extra parameter to propagate the origin: A would pass its address (this) to B, B would pass the value to C, and C would pass it to D. `tx.origin` based protection can be abused by a malicious contract if a legitimate user interacts with the malicious contract. Hence it's not recommended to use `tx.origin` for authorization in solidity documentation. Refer to: https://docs.soliditylang.org/en/v0.6.12/security-considerations.html#tx-origin
Open the reportLowDirect call to the function `addLiquidity` will fWemix Retainer 37 (PPP, PlayBridgeV3 ) · CertiK · 11 Aug 2023Open
The require check in L125 and L126 requires fund to be transferred from the `UniversalRouter` to the PPP contract, which means only the call from the `UniversalRouter` will be processed. Any direct call of `addLiqudity` will revert. ```solidity=125 require(IERC20(addLiqInfo.swapTokens[0]).transferFrom(CA(PPPConfigs.universalRouter), address(this), addLiqInfo.amounts[0]), "PPPLiquidity: fail to transfer token to router"); require(IERC20(addLiqInfo.swapTokens[1]).transferFrom(CA(PPPConfigs.universalRouter), address(this), addLiqInfo.amounts[1]), "PPPLiquidity: fail to transfer token to router"); ``` Same cases also apply to `removeLiquidity`, `reqSwapIn`, `reqSwapOut`, `reqAddLiquidity`, `reqZapIn`, `swapIn` , `swapOut`, `zapIn` and `zapOut`
Open the reportLowRedundant use of SafeMathWemix Retainer 37 (PPP, PlayBridgeV3 ) · CertiK · 11 Aug 2023Open
Solidity version >=0.8.0 includes checked arithmetic operations and underflow/overflow by default, making SafeMath redundant.
Open the reportShow 10 more
LowUser-Defined GettersWemix Retainer 37 (PPP, PlayBridgeV3 ) · CertiK · 11 Aug 2023Open
The linked functions are equivalent to the compiler-generated getter functions for the respective variables.
Open the reportLowThird-Party DependenciesWemix Retainer 49 - BYLOManager, VaultManager · CertiK · 7 Aug 2023Open
The audited code base interacts with several contracts outside of the scope of this particular audit, as well as database off-chain related to game items, and relies on the `validator` signature for important verifications. Access control of some of these external parties are also critical for the security for the system overall. For example, in the `VaultManager` contract, we assume that the `Navigator` provides correct inputs to the `exchangeToToken()` and `exchangeToItem()` functions, and that the `sender` correctly corresponds to the user intending to perform the transaction. Otherwise, user funds could be misappropriated without the user's consent. The scope of the audit treats these entities as black boxes and assumes their functional correctness. However, in the real world, these external parties can be compromised and this may lead to lost or stolen assets.
Open the reportLowNo Cap on FeesWemix Retainer 43 (Staking Pool Mainnet) · CertiK · 3 Aug 2023Open
The `setBaseFeePercent()` and `_setFeePercent()` functions only require each fee to be no greater than 100%. In the extreme case, the fee could be as high as 100%, in which case all user funds would go to the fee address.
Open the reportLowPotential Sandwich AttacksWemix Retainer 43 (Staking Pool Mainnet) · CertiK · 3 Aug 2023Open
A sandwich attack may happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (executing before the target) a transaction to purchase one of the assets and make profits by backrunning (executing after the target) a transaction to sell the asset. The following function is called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: - `PlaySwapRouter(psr).swapExactTokensForTokens(amountRT, 0, path, address(this), _deadline());`
Open the reportLowThird Party DependencyWemix Retainer 43 (Staking Pool Mainnet) · CertiK · 3 Aug 2023Open
The contract is serving as the underlying entity to interact with one or more third party protocols / addresses, such as `psr`, `ExecuteManager`, `rt`, `st`, `rtVault`, `stVault`, etc.. The scope of the audit treats third party entities as black boxes and assume their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties etc.
Open the reportLowUsers' Staked Tokens Might Be Paid Out to Other UWemix Retainer 43 (Staking Pool Mainnet) · CertiK · 3 Aug 2023Open
The `SPBase` contract contains no restriction on the `rt` and `st` token addresses. If they are the same address, and the `rtVault` and `stVault` are also the same address as is the default in the constructor, then user A's staked token might be paid out as reward to user B when user B claims reward. This is possible because the contract does not guarantee that there's always sufficient `rt` token balance for reward payout, and there's no clear separation of funds.
Open the reportLowMissing Error MessagesWemix Retainer 42 (play, cypress settler v2) · CertiK · 18 Jul 2023Open
The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.
Open the reportLowNo Upper Limits for Acquire RateWemix Retainer 42 (play, cypress settler v2) · CertiK · 18 Jul 2023Open
There is no upper limit restricting the parameter of `setAcquirePercent()`, potentially enabling close to 100% of the acquire rate on transactions. If the `acquirePercent` is too high, swap settlement will remove a significant amount of liquidity, which could seriously affect the token price.
Open the reportLowPotential Divide by ZeroWemix Retainer 42 (play, cypress settler v2) · CertiK · 18 Jul 2023Open
Performing division by zero would raise an error and revert the transaction. ```solidity=352 uint balanceA = (amount.mul(reserveA)).div(lpSupply); uint balanceB = (amount.mul(reserveB)).div(lpSupply); ``` The expression `(amount.mul(reserveA)).div(lpSupply)` may be divided by zero. Its divisor has an estimated interval [0, 115792089237316195423570985008687907853269984665640564039457584007913129639935].
Open the reportLowState Variable Should Be Declared ConstantWemix Retainer 42 (play, cypress settler v2) · CertiK · 18 Jul 2023Open
State variables that never change should be declared as `constant` to save gas. ```solidity=42 uint public denominator = 1 ether; // denominator for calculate settle amount ``` - `denominator` should be declared `constant`.
Open the reportShow 10 more
LowThird-Party Dependency UsageWemix Retainer 42 (play, cypress settler v2) · CertiK · 18 Jul 2023Open
The contract is serving as the underlying entity to interact with one or more third party protocols. 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. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. - The contract `PlaySettler` interacts with third party contract with `IPlaySwapRouter` interface via `psr`.
Open the reportLow`quorum` should not be updatedOpen
In the function `removeOwner`, it update the `quorum` to `owners.length` if the `quorum` is greater than the owner numbers, this may cause the `notExecuted` transaction to be executed.
LowBypass Via Custom Token LogicOpen
The modifier `onlyValidator` can be bypassed if the caller provides their own deployed `token` address with a custom `isValidator`. This will enable users to record malicious state data through the `TokenFurnaceAway.exit()` and `TokenFurnaceBase.burn()` function. `TokenFurnaceBase.burn()` will also execute the tokens custom `burn()` logic.
LowDifferent input params between `cast` and `isValiOpen
In the function `cast()`, the input params are `daoId` and `hashed`. However, in the function `isValidParams()`, the input param is struct `PInfo`. Missing check if the business information is valid.
LowDivide Before MultiplyOpen
Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=325 _payment = _amount.div(1 ether).mul(_price); ```
LowDivision Before MultiplicationOpen
Precision is lost when division is performed before multiplication, which may result in incorrect result. For example: 99/100 * 1000 = 0; 99*1000 / 100 = 990
Lowfunction `getAvailableNum()` cannot reflect the nOpen
The sender only transfers `Governance` tokens when creating an agenda or vote, and does not transfer voting power to the `Governance` contract. Therefore, the function `getAvailableNum()` does not really reflect the number of votes available to the sender, because the number of votes cannot be transferred and the number of votes already cast is not deducted.
LowFunction `setMasterAdmin` not remove old master aOpen
The `setMasterAdmin()` function transfers the master admin role to a new account and grants it the service admin role. The previous master admin, on the other hand, is not removed from the `isServiceAdmin` map and still retains the service admin role.
LowIncompatibility with Deflationary TokensOpen
When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction.
LowIncompatibility with Deflationary TokensOpen
When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f ```solidity=76 require(IERC20(_token).transferFrom(_from, address(this), _valueOrTid), "B:E20 transfer"); //deposit to this contract ``` - Transferring tokens by `_valueOrTid`. ```solidity=78 require(IBridgeERC20(_token).burnFrom(_from, _valueOrTid), "B:E20 burn"); //burn ``` - The `_valueOrTid` appears to be used for bookkeeping purposes without compensating the potential transfer fees. - Note: `burnFrom` is an external function and its behavior wasn't evaluated. --- ```solidity=66 require(IERC20(_token).transferFrom(_from, address(this), _cost), "TransferCost: transferFrom is failed"); ``` - Transferring tokens by `_cost`. ```solidity=67 addIncome(_token, _column, _cost); ``` - This function call executes the following operation. - In `RecipientRole.addIncome`, - `sumIncomes[_token] = sumIncomes[_token].add(_amount);` - In `SafeMath.add`, - `uint256 c = a + b;` - The `_cost` appears to be used for bookkeeping purposes without compensating the potential transfer fees. --- ```solidity=22 _payCost(CA(WEMIX), _from, _cost, _column); ``` - Transferring tokens by `_cost`. - This function call executes the following operation. - In `TransferCost._payCost`, - `require(IERC20(_token).transferFrom(_from, address(this), _cost), "TransferCost: transferFrom is failed");` ```solidity=22 _payCost(CA(WEMIX), _from, _cost, _column); ``` - This function call executes the following operation. - In `TransferCost._payCost`, - `addIncome(_token, _column, _cost);` - In `RecipientRole.addIncome`, - `sumIncomes[_token] = sumIncomes[_token].add(_amount);` - In `SafeMath.add`, - `uint256 c = a + b;` - The `_cost` appears to be used for bookkeeping purposes without compensating the potential transfer fees. --- ```solidity=55 _exit(_token, msg.sender, msg.sender, _valueOrTid, _extraData); ``` - Transferring tokens by `_valueOrTid`. - This function call executes the following operation. - In `BridgeBase._exit`, - `require(IERC20(_token).transferFrom(_from, address(this), _valueOrTid), "B:E20 transfer"); //deposit to this contract` ```solidity=55 _exit(_token, msg.sender, msg.sender, _valueOrTid, _extraData); ``` - This function call executes the following operation. - In `BridgeBase._exit`, - `require(IBridgeERC20(_token).burnFrom(_from, _valueOrTid), "B:E20 burn"); //burn` - Note: `burnFrom` is an external function and its behavior wasn't evaluated. - The `_valueOrTid` appears to be used for bookkeeping purposes without compensating the potential transfer fees. --- ```solidity=95 _exit(_token, _msgSender(), _msgSender(), _valueOrTid, _extraData); ``` - Transferring tokens by `_valueOrTid`. - This function call executes the following operation. - In `BridgeBase._exit`, - `require(IERC20(_token).transferFrom(_from, address(this), _valueOrTid), "B:E20 transfer"); //deposit to this contract` ```solidity=95 _exit(_token, _msgSender(), _msgSender(), _valueOrTid, _extraData); ``` - This function call executes the following operation. - In `BridgeBase._exit`, - `require(IBridgeERC20(_token).burnFrom(_from, _valueOrTid), "B:E20 burn"); //burn` - Note: `burnFrom` is an external function and its behavior wasn't evaluated. - The `_valueOrTid` appears to be used for bookkeeping purposes without compensating the potential transfer fees.
Show 10 more
LowIncompatibility With Deflationary TokensOpen
When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee.
LowIncompatibility With Deflationary TokensOpen
When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the transaction may fail due to the validation checks. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee) to the target contract, only 90 tokens actually arrive to the contract.
LowInconsistency Between Comments and CodeOpen
In the function `LoanAuctionBase._checkListTerms()`, the provided comments suggest that the annual percentage rate (APR) should be set at no less than 20% of the borrowed amount. This implies that `listTerms.maxRepayAmount >= 1.2 * listTerms.principalAmount`. However, this is not the condition currently checked in the code. Instead, it only requires `listTerms.maxRepayAmount >= listTerms.principalAmount`, potentially allowing APR to be set lower than 20%. Additionally, comments in the `ListTerms` struct indicate that setting `loanDuration` as 0 should utilize the default loan duration stored in the contract. However, this condition is not implemented in the `LoanAuctionBase.listLoan()` function, as `ListTerms.loanDuration` attribute is not used. Lastly, the comments in the function `LoanAuctionBase.repayLoan()` suggest that only the borrower should be able to repay the loan. However, the code itself does not enforce this restriction, potentially allowing anyone to repay the loan.
LowInconsistency in the `withdrawCharge()` functionOpen
The comments for the `withdrawCharge()` function indicate its purpose is for the owner to "get remain reward" from winning events. However, in practice, this function withdraws the betting amount, not the reward. Additionally, it can be utilized to withdraw tokens from losing events as well. ```solidity=189 /** * @dev External function to withdraw * Withdraws the amount of the event ID from which the reward was not received by user to another address * @param to address of get remain reward * @param eventID ID of user don't received event */ function withdrawCharge( address to, bytes32 eventID ) external onlyOwner { require(betInfo[eventID].isSettled, "BYLOSports: event is not settled yet"); require(!betInfo[eventID].taken, "BYLOSports: user already received"); require(betInfo[eventID].amount > 0, "BYLOSports: event non-existence"); betInfo[eventID].taken = true; require(_token.transfer(to, betInfo[eventID].amount), "BYLOSports: withdraw error"); } ```
LowInconsistent Comment and CodeOpen
The comment above function `ResumeSwap` mismatch the purpose of the function, as suggested by its name. Also, the condition `RANDOM NUMBER(0 =< random number < maxRandomNumber)` defined in the comment it is not implemented in the code and could be false. See the scenario section for more information.
LowInconsistent Comment and CodeOpen
The linked comment states that 'when index is out of the range of chartList, data is retrieved from currentChar.'. However, the `if` statement doesn't handle the case when the `_index` is larger than `chartList[_token][_interval].length`.
LowIneffective `isContract()` CheckOpen
The implementation of the `isContract` check can not cover all scenarios. The check can be bypassed if the call is from the constructor of a smart contract or when the contract is destroyed. In that case, the codesize will also be zero. The "isContract" function in the OpenZeppelin "Address" library uses the same implementation, but comments mention that "it's unsafe to rely on the check and it can be bypassed". Reference: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol
LowInefficient Memory ParameterOpen
One or more parameters with `memory` data location are never modified in their functions and those functions are never called internally within the contract. Thus, their data location can be changed to `calldata` to avoid the gas consumption copying from calldata to memory. ```solidity=59 function enter(address _token, address _to, uint256 _valueOrTid, bytes32 _txHash, uint256 _extraData, bytes memory _signature, string memory) public onlyValidatorSig(abi.encodePacked(address(this), _token, _to, _valueOrTid, _txHash, _extraData), _signature){ ``` `enter` has memory location parameters: `_signature`. --- ```solidity=152 function tradeSeed(uint256 _serialSeed, uint256 _serialCurrency, uint256 _amount, bytes memory _signature) public onlyValidatorSig(abi.encodePacked(address(this), _serialSeed, _serialCurrency, _amount), _signature){ ``` `tradeSeed` has memory location parameters: `_signature`. --- ```solidity=157 function closeOrder(uint256 _serial, bytes memory _signature) public onlyValidatorSig(abi.encodePacked(address(this), _serial), _signature){ ``` `closeOrder` has memory location parameters: `_signature`. --- ```solidity=54 function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) public virtual; ``` `safeTransferFrom` has memory location parameters: `data`.
LowInsufficient removalOpen
```solidity=33 if (_tokenCollection[id].length > 0) { for(uint i = 0; i < _tokenCollection[id].length; i++) { address token = _tokenCollection[id][i]; uint balance = _balance[id].token[token]; if(balance == 0) { _tokenCollection[id][i] = _tokenCollection[id][_tokenCollection[id].length - 1]; _tokenCollection[id].pop(); } } } ``` The code is intended to remove the token from the array `_tokenCollection` if its balance is 0. However, it doesn't, some tokens are skipped. For example, there are two tokens in the _tokenCollection, both of which have a balance of 0. After the first execution completes, the length of `_tokenCollection` and `i` become 1, so `i` does not satisfy `i < _tokenCollection[id].length`, and the loop ends. The 2nd data is not removed successfully. The new issue with the commit `2c55201c5fb7f8805ace0947e32eed9cae0f9ebf` is that if the first token in the token collection has a zero balance, the code `i -= 1;` will underflow and cause 'liquidate()' to revert unintendedly.
LowLack of Input ValidationOpen
The `ParameterSetter` can call `setMaxRandomNumber` to update `maxRandomNumber` with any nonzero value, like 1. I think the minimal value is not valid.
Show 10 more
LowLocked Tokens Can Still Be TradedOpen
The `buySeed()`, `buyItem()` and `tradeSeed()` functions do not check if tokens are locked, which means that locked tokens can still be traded.
LowMissing Emit EventsOpen
There should always be events emitted in the sensitive functions that are controlled by centralization roles.
LowMissing Emit EventsOpen
There should always be events emitted in the sensitive functions that are controlled by centralization roles.
LowMissing Emit EventsOpen
Functions that update state variables should emit relevant events as notifications.
LowMissing Emit EventsOpen
There should always be events emitted in the sensitive functions that are controlled by centralization roles.
LowMissing Emit EventsOpen
There should always be events emitted in the sensitive functions that are controlled by centralization roles.
LowMissing Emit EventsOpen
There should always be events emitted in the sensitive functions that are controlled by centralization roles.
LowMissing ERC20 FieldOpen
The `PlaySwapERC20` fields `name` and `symbol` are unassigned and have no related setter method. Users looking for this metadata would be unable to find descriptive information for the related token.
LowMissing Error MessagesOpen
The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.
LowMissing Removal of Index from `_registIndex` MappOpen
The `_removeListElement()` function within the contract is designed to remove an account from a specific role's list. However, the function is not correctly removing the index from the `_registIndex` mapping.
Show 10 more
LowMissing Zero Address ValidationOpen
Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. If critical roles are assigned to a zero address, it could result in permanent loss of those roles. ```solidity=80 _validator = validator; ``` - `validator` is not zero-checked before being used. --- ```solidity=18 navigator = navigator_; ``` - `navigator_` is not zero-checked before being used.
LowNo Cap on FeesOpen
The `setBaseFeePercent()` and `_setFeePercent()` functions only require each fee to be no greater than 100%. In the extreme case, the unstake fee could be as high as 100%, in which case users wouldn't be able to receive any tokens back when they unstake.
LowNo Upper Limits for Acquire RateOpen
There is no upper limit restricting the parameter of `setAcquirePercent()`, potentially enabling close to 100% of the acquire rate on transactions. If the `acquirePercent` is too high, swap settlement will remove a significant amount of liquidity, which could seriously affect the token price.
LowOut of Scope DependencyOpen
The contract is serving as the underlying entity to interact with one or more out of scope. The scope of the audit treats out of scope entities as black boxes and assume their functional correctness. However, in the real world, out of scope contracts can be compromised and this may lead to lost or stolen assets. In addition, upgrades of out of scope contracts can possibly create severe impacts, such as increasing fees of out of scope contracts, migrating to new LP pools, etc. ```solidity=25 address private _psr; // PlaySwapRouter ``` - The contract `TokenFurnaceAway` interacts with out of scope contract with `IPlaySwapRouter` interface via `_psr`. --- ```solidity=26 address private _pWemixD; // p.wemix$ ``` - The contract `TokenFurnaceAway` interacts with out of scope contract with `IERC20` interface via `_pWemixD`. --- ```solidity=27 address private _exchanger; // AwayExchanger ``` - The contract `TokenFurnaceAway` interacts with out of scope contract with `IExchanger` interface via `_exchanger`.
LowOut of Scope Dependency - ValidatorOpen
The system has privileged roles called 'validator' who have the power to manage orders in smart contracts. The scope of the audit treats the 'validator' as black boxes and assumes their functional correctness. However, if a 'validator' is compromised, the attacker can take advantage of that and damage the project.
LowOut-of-Scope ImplementationsOpen
The contract is serving as the underlying entity to interact with one or more protocols via interfaces. The scope of the audit treats third party entities as black boxes and assume their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=47 IPlaySwapRouter _router; ``` - The contract `WemixDollarPaymentV2` interacts with third party contract with `IPlaySwapRouter` interface via `_router`. --- ```solidity=53 address private _dollar; ``` - The contract `WemixDollarPaymentV2` interacts with third party contract with `IERC20` interface via `_dollar`. --- ```solidity=54 address private _recipient; ``` - The contract `WemixDollarPaymentV2` interacts with third party contract with `IRecipientRoleV6` interface via `_recipient`.
LowOutdated Solidity VersionOpen
All the contracts in the project use Solidity version 0.6.x, which is a version introduced more than two years ago. Outdated versions might contain security issues and miss the new features and security enhancements included in the recent solidity version.
LowOutdated Solidity VersionOpen
All the contracts in the project use Solidity version 0.6.x, which is a version introduced more than two years ago. Outdated versions might contain security issues and miss the new features and security enhancements included in the recent solidity version.
LowPossible Out-of-scope DependenciesOpen
The following contracts are not in the audit scope: - pair - factory The audit treats them as black boxes and assumes their functional correctness. However, in the real world, they can be compromised and this may lead to lost or stolen assets. Addtionally, in the current code, the init code of the pair contract does not match it in the latest [WeswapLibrary.sol](https://github.com/wemixarchive/weswap-periphery/blob/13b27ea93db764952934e1270c0fc1482ff01d02/contracts/libraries/WeswapLibrary.sol) file or the audited version. As such, we would like the client to confirm whether the current state of the code is indeed correct.
LowPotential Cross-chain Replay AttackOpen
The signature does not include the identification of the blockchain. So if the signer signed a message on one blockchain and accidentally leaked the signature, the signature would be valid for a similar transaction on another blockchain with the same encryption method. For example, if the signer signed a message using `address(this), nonce` on Ethereum and the same `address(this)` and `nonce` exist on BSC, the attacker can reuse this signature to set the winners via `BYLOSports.settle()` on BSC.
Show 10 more
LowPotential Cross-Chain Replay AttackOpen
Signed messages are not properly verified with the current chain ID, thus allowing attackers to perform replay attacks across chains. Hardcoded or cached chain ID values are also vulnerable since a hard fork may occur and change the chain ID in the future.
LowPotential Inconsistencies Amongst the Various LimOpen
The `SPLimit` contract allows the owner to set various interconnected limits independently. The setter functions do not check whether the limit being set is consistent with the other existing limits. For example, nothing enforces that the `stakeMaxLimit` is greater than the `stakeMinLimit`, and nothing enforces that the `stakeUnit` modulo `unStakeUnit` equals 0 (if not, users won't be able to completely unstake their entire balance). The `SPCoolTime` contract allows the owner to set `stakeCoolTime`, `unstakeCoolTime`, and `claimCoolTime` independently. However, the `_claim()` function is always triggered in the external `stake()` and `unstake()` functions, and thus if `claimCoolTime` is greater than either `stakeCoolTime` or `unstakeCoolTime`, the latter would have no effect. Similarly, the `SPLockUp` contract contains no enforcement that `globalLu` is no smaller than the `userLu`.
LowPotential Inconsistency in `settle()` FunctionOpen
The `settle()` function is utilized for settling events, determining the winners and losers. However, that there might be an inconsistency in this function, specifically with the `totalReward` parameter. This parameter represents the total reward amount to be distributed among winners, yet the individual reward for each event is not considered within the function. This could lead to a discrepancy where the `totalReward` does not accurately represent the actual reward amount.
LowPotential Lack Of Access ControlOpen
The functions `withdrawExchangeIncome` and `withdrawOrder` can be called by anyone as they have no access restrictions. This enables anyone to call them and withdraw assets for other parties.
LowPotential misuse of the `isValidator()` check.Open
The function `isValidator(address account)` is used to check if parameter `account` is validator while function `isOwner()` checks if msg.sender is the deployer/owner of the contract. They are totally different functionalities. It may have serious consequence if the deployer/owner of the contract is not validator and calls `isValidator(address account)` with an arbitrary account successfully.
LowPotential Risks Related to Contract BalanceOpen
In the existing design, users place bets by transferring tokens into this contract and also claim their rewards from the contract. However, there might be two potential risks. Specifically, if the contract's balance is insufficient, users may not be able to claim their rewards. Furthermore, if the amount of the bet is larger than the rewards, the excess tokens could potentially be locked within the contract.
LowPotential Sandwich AttacksOpen
A sandwich attack may happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (executing before the target) a transaction to purchase one of the assets and make profits by backrunning (executing after the target) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: - `_swap()`
LowRedundant Code ComponentsOpen
The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.
LowRisk of Function Reversion Due to Insufficient VaOpen
The `settle()` function in the current implementation may require a transfer of tokens from the vault to this contract. If the balance in the vault is not sufficient to cover this transfer, the `settle()` function could potentially revert, which would prevent the correct settlement of events.
LowRole Indexing Issue in Role ManagementOpen
The `_registIndex` mapping records the index of an element in the `_roleList[_role]` array. However, if the index is 0, it does not distinguish whether the element exists in the `_roleList[_role]` array. This is due to the default behavior of Solidity mappings, where querying a non-existent key returns a zero value. As a result, for accounts that do not exist in `_roleList[_role]`, the value of `_registIndex[_role][_account]` is also 0.
Show 10 more
LowSolidity Version Not RecommendedOpen
All three contracts use "pragma solidity ^0.6.12;". Solidity frequently releases new compiler versions. Using an old version prevents access to new Solidity security features.
LowSolidity Version Not RecommendedOpen
Solidity frequently releases new compiler versions. Using an old version prevents access to new Solidity security features. We also recommend avoiding complex `pragma` statements. ```x Pragma version^0.6.0 (contracts/Common/UserNonce.sol#3) allows old versions ``` ```solidity=3 pragma solidity ^0.6.0; ``` --- ```x Pragma version^0.6.0 (contracts/Role/IRecipientRoleV6.sol#3) allows old versions ``` ```solidity=3 pragma solidity ^0.6.0; ``` --- ```x Pragma version<=0.7.0 (contracts/openzeppelin-solidity/contracts/GSN/Context.sol#3) uses lesser than ``` ```solidity=3 pragma solidity <=0.7.0; ``` --- ```x Pragma version<=0.7.0 (contracts/openzeppelin-solidity/contracts/cryptography/ECDSA.sol#3) uses lesser than ``` ```solidity=3 pragma solidity <=0.7.0; ``` --- ```x Pragma version^0.6.3 (contracts/openzeppelin-solidity/contracts/drafts/Counters.sol#3) allows old versions ``` ```solidity=3 pragma solidity ^0.6.3; ``` --- ```x Pragma version<=0.7.0 (contracts/openzeppelin-solidity/contracts/ownership/Ownable.sol#3) uses lesser than ``` ```solidity=3 pragma solidity <=0.7.0; ``` --- ```x Pragma version^0.6.3 (contracts/openzeppelin-solidity/contracts/ownership/Secondary.sol#3) allows old versions ``` ```solidity=3 pragma solidity ^0.6.3; ``` --- ```x Pragma version^0.6.3 (contracts/openzeppelin-solidity/contracts/utils/Address.sol#3) allows old versions ``` ```solidity=3 pragma solidity ^0.6.3; ```
LowState Variable Should Be Declared ConstantOpen
State variables that never change should be declared as `constant` to save gas. ```solidity=57 uint public denominator = 1 ether; // denominator for calculate settle amount ``` - `denominator` should be declared `constant`.
LowThe currency vault `tokenBridge` is not used forOpen
The comment for the `tokenBridge` vault indicates that it is the vault of a bridge. ```solidity=24 struct CurrencyVault { address tokenBridge; // TokenBridgeTrade or TokenBridgeTradeV2 ``` In the `settle()` function, the `_settle()` function is called to handle `TRANSFER` and `BRIDGE` type settlements for currency tokens. If the settlement type is `BRIDGE`, the vault used for the settlement is `_tv[settleType].account` but not `_cv[token].tokenBridge`.
LowThird Party and Out of Scope DependenciesOpen
The in-scope contracts interact with several third-party or out-of-scope contracts, including PlaySwapRouter, PlaySwapFactory, RecipientRoleV6, etc. The audit treats third-party entities and out-of-scope dependencies as black boxes and assumes their functional correctness. However, in the real world, they can be compromised, which may lead to lost or stolen assets.
LowThird Party DependencyOpen
The contract is serving as the underlying entity to interact with one or more third party protocols / addresses, such as `rt`, `st`, `rtVault`, `stVault`. The scope of the audit treats third party entities as black boxes and assume their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties etc. ```solidity=36 address public override rt; // reward token ``` - The contract `SPBase` interacts with third party contract with `IERC20` interface via `rt`. --- ```solidity=37 address public override st; // staking token ``` - The contract `SPBase` interacts with third party contract with `IERC20` interface via `st`. --- ```solidity=20 function _addIncome(Recipient storage r, bytes32 service, address token, bytes32 column, uint amount) internal { ``` - The function `RecipientLibV6._addIncome` interacts with third party contract with `IRecipientRoleV6` interface via `r`. --- ```solidity=28 function _addMintIncome(Recipient storage r, address token, uint amount) internal { ``` - The function `RecipientLibV6._addMintIncome` interacts with third party contract with `IRecipientRoleV6` interface via `r`.
LowThird Party DependencyOpen
The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assume their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=18 address internal _weswapRouter; // address of WeswapRouter ``` - The contract FundManager interacts with third-party contract with IWeswapRouter interface via _weswapRouter.
LowThird-Party DependenciesOpen
The contract is serving as the underlying entity to interact with third party protocols. 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. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. The third parties include: - price oracles - ERC20 tokens - ERC721 tokens - ERC1155 tokens
LowThird-Party DependenciesOpen
The audited code base contains external dependencies that are not in scope for this particular audit engagement, including but is not limited to: `GTNavigator`, `whitelistContract`, `WeswapBreaker`, `WeswapPair`, `BYLO` token, etc. The scope of the audit treats these entities as black boxes and assumes their functional correctness. However, in the real world, they can be compromised and this may lead to lost or stolen assets.
LowThird-Party DependenciesOpen
The contract is serving as the underlying entity to interact with third-party `feeders` and `aggregator`. 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 manipulated prices and lost assets.
Show 10 more
LowThird-Party Dependency UsageOpen
The contract is serving as the underlying entity to interact with one or more third party protocols. 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. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. - The contract `PlaySettler` interacts with third party contract with `IPlaySwapRouter` interface via `psr`.
LowUnknown Implementation of Interface and 3rd PartyOpen
The `FundRouter` contract uses a `vrfVerify` address for verifying random number generation. The implementation of the IVRF interface is unknown, and so are the behavior of `IVRF(_vrfVerify).fastVerify()` and `(IVRF(_vrfVerify).verifyByProof()`. It is also unclear if there's mechanism to prevent reusing the same `vrf` and pass the checks. If not, there could be potential replay attack. There are also numerous dependencies on other parts of the code base that are out of the scope of this particular audit. The audit treats these unknown implementation of interface and other dependencies as a black box and assume their functional correctness, but in reality it can potentially be compromised.
LowUnknown Implementation of InterfacesOpen
The code base contains external function calls with unknown implementation, such as the below. The scope of the audit treats contracts that are out of scope, unknown implementation of interfaces, and other dependencies as black boxes and assumes their functional correctness. However, in the real world, these out of scope contracts can be compromised, potentially causing major vulnerability for the project. ```solidity=298 require(IVRF(_vrfVerify).fastVerify(_publicKey, _proof, _seed, _uPoint, _vComponents), "FR0-PD0-090"); require(IVRF(_vrfVerify).verifyByProof(gamma, _message), "FR0-PD0-091"); ```
LowUnknown InterfacesOpen
The linked interfaces used in the protocol are unknown. We understand that this protocol depends on the service of other contracts, however, the unknown imported source file may incur unexpected behaviors. This audit will treat the unknown imported source files as a black box.
LowUnreasonable or Missing Upper Limit in `setTimeToOpen
There is no upper boundary for `setLenderFeeRateMantissa()` which is used to set fee rates. It is possible to set the lender fee rate up to any arbitrary amount. The `setTimeToBorrowerFeeDenominator()` function may not have a reasonable upper limit and can be used to set the borrower fee up to 100%.
LowUnused ContractOpen
```solidity=8 library Math { ``` - The library `Math` is declared but never used. --- ```solidity=4 library UQ112x112 { ``` - The library `UQ112x112` is declared but never used. --- ```solidity=4 library TransferHelper { ``` - The library `TransferHelper` is declared but never used.
LowUsage of `_transfer` instead of `transferFrom`Open
In function `exchangeToItem`, users will transfer tokens to the contract in the following line: `super._transfer(user, address(this), amount);`. This does not requires users to call approve(address(this), amount) prior to calling `exchangeToItem`, which increased the risk of users being phished.
LowUsage of Magic NumbersOpen
In the functions `computeProfitMaximizingTradeRenewal` and `computeProfitMaximizingStablecoinPoolTrade` used for swap amountIn calculation, the magic number used in the calculation of `leftSide` and `rightSide`. We need confirm the mathematics of the formulas. Why the number `53200`, `53067`, and `636804` are used for the left side and `799`, `798`( `636804`'s square root ) for the right side.
LowUsers' Staked Tokens Might Be Paid Out to Other UOpen
The `SPBase` contract contains no restriction on the `rt` and `st` token addresses. If they are the same address, and the `rtVault` and `stVault` are also the same address as is the default in the constructor, then user A's staked token might be paid out as reward to user B when user B claims reward. This is possible because the contract does not guarantee that there's always sufficient `rt` token balance for reward payout, and there's no clear separation of funds.
LowVariables That Could Be Declared as ImmutableOpen
The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.
Show 4 more
LowVariables That Could Be Declared as ImmutableOpen
The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.
LowVariables That Could Be Declared as ImmutableOpen
The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.
LowWeak PRNGOpen
The functions `DollarInAndOutStabilizerGame.quadraticRandomPrice()` and `DollarInAndOutStabilizerGame._linearRandomPrice()` utilize modulus operation on the parameter `_randomNumber` to calculate `randomNumber`, a pseudo-random number. This value is then used for price calculation and may be influenced by a user who can change the `_randomNumber` parameter by sending and canceling transactions to calculate a more desirable price.
LowWeak PRNGOpen
The functions `DollarInAndOutStabilizerGame.quadraticRandomPrice()` and `DollarInAndOutStabilizerGame._linearRandomPrice()` utilize modulus operation on the parameter `_randomNumber` to calculate `randomNumber`, a pseudo-random number. This value is then used for price calculation and may be influenced by a user who can change the `_randomNumber` parameter by sending and canceling transactions to calculate a more desirable price.
Contracts
No deployed address is recorded for these audits.
The reports name a repository or files. Open a report to see its scope.
Show this on your site
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Content
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
Style
Format
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="wemix"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something 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