GameBuild security record

In the contract `GameBuild` the role `_owner` has authority over the functions listed below. - lockAddress(): blacklist an account. - unLockAddress(): remove an account from blacklist. - pause(): pause the token transfer. - unpause(): unpause the token transfer. - transferOwnership(): transfer ownership to a new account. - renounceOwnership(): renounce the ownership. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the configuration of the contract. In the contract `GameBuildSwap` the role `_owner` has authority over the functions listed below. - withdrawToken(): transfer the ERC20 token in the contract to `to` address. - setTokenCRE(): manage `tokenCRE`. - setTokenSLG(): manage `tokenSLG`. - setTokenGameBuild(): manage `tokenGameBuild`. - setRatioCRE(): manage swap ratio of `tokenCRE`. - setRatioSLG(): manage swap ratio of `tokenSLG`. - setRatioGameBuild(): manage `ratioGameBuild`. - setMaxSwappableCRE(): manage `maxSwappableCRE`. - setMaxSwappableSLG(): manage `maxSwappableSLG`. - pause(): pause the swap. - unpause(): unpause the swap. - transferOwnership(): transfer ownership to a new account. - renounceOwnership(): renounce the ownership. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority, change the configuration of the contract, and transfer assets. For example, if the owner changes the ratio of the swap without notifying the community, users may swap more/fewer tokens than expected. --- In the updated version d9140c34cb7eaff1f488e38e7dc2e2093613449d, the privileged functions are changed as below: #### GameBuildSwap - setTokenCRE(): removed. - setTokenSLG(): removed. - setTokenGameBuild(): removed. - setDeadline(): newly added, manage `deadline`.

All of the `GameBuild` 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.

In the GameBuild smart contract, there is a specific design choice in the implementation of the contract's blacklist mechanism. The mechanism is currently designed to only restrict transactions originating from blacklisted addresses, as evidenced in the _update function. This function is overridden to include a validation check against the blacklist mapping before proceeding with transaction execution. However, it only evaluates the `from` address involved in the transaction, leaving the `to` address unchecked. ```solidity function _update(address from, address to, uint256 value) internal virtual override whenNotPaused { super._update(from, to, value); require(!blacklist[from], "address is locked"); } ```

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the transaction fee charged. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrive at 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. ```solidity=51 tokenCRE.transferFrom(msg.sender, address(this), amountCRE); ``` - Transferring tokens by `amountCRE`. ```solidity=47 swappedCRE = swappedCRE + amountCRE; ``` - The `amountCRE` appears to be used for bookkeeping purposes without compensating the potential transfer fees. --- ```solidity=68 tokenSLG.transferFrom(msg.sender, address(this), amountSLG); ``` - Transferring tokens by `amountSLG`. ```solidity=64 swappedSLG = swappedSLG + amountSLG; ``` - The `amountSLG` appears to be used for bookkeeping purposes without compensating the potential transfer fees.

It is important to emit events for sensitive actions, particularly those that can be executed by centralized roles or administrators. This ensures transparency and enables tracking of critical changes, which is essential for security and trust in the system. Missing event logs can indeed result in a lack of visibility and potential information loss.

The `GameBuildSwap` contract lacks zero address checks for the `tokenCRE`, `tokenSLG`, and `tokenGameBuild`. Moreover, the contract fails to ensure that `tokenCRE`, `tokenSLG`, and `tokenGameBuild` represent three distinct ERC20 tokens. Improper configuration may result in the swap functionality malfunctioning.