qiibee foundation $QBX security record

When transferring deflationary ERC20 tokens, the input amount may not equal 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 arrive in the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens causing the contract to lose 10 tokens in such a transaction. ```solidity=51 stakingToken.safeTransferFrom(beneficiary, address(this), amount); ``` - Transferring tokens by `amount`. ```solidity=55 userStake.amount += amount; ``` - The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.

The contract serves as the underlying entity to interact with a third-party protocol 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=18 IERC20 public immutable stakingToken; ``` - The contract `Staking` interacts with third-party contract with `IERC20` interface via `stakingToken`.

Check-effect-interaction pattern violation occurs when a function makes an external call to another contract before resolving any effects. If an attacker can control the contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. In the `stake()` function, the state variables update and the event emission takes place after the call. \ In the `withdraw()` function the event is emitted after the external call.

In the `setEndTime()` function, `endTime` can only be updated when `uint64(block.timestamp) > endTime`, indicating the token sale has ended. However, changing the `endTime` value to a smaller value `_endTime` after the token sale has concluded does not affect the status of the sale, as it remains ended.

The constructor in the `Raffle` contract fails to ensure that the `startTime` is set in the future relative to the current `block.timestamp` and that `endTime` is greater than `startTime`. This oversight can lead to scenarios where the raffle is incorrectly initialized, potentially allowing immediate closure or incorrect operation of the raffle. ```solidity constructor( uint64 _startTime, uint64 _endTime, uint64 _ownerWithdrawAfter ) Ownable(msg.sender) { startTime = _startTime; endTime = _endTime; ownerWithdrawAfter = endTime + (_ownerWithdrawAfter * 1 days); allowWithdrawals = false; } ```

The smart contract does not check or store the return value of an external call in a local or state variable, which may introduce vulnerabilities due to the unhandled outcome. ```solidity=160 targetContract.setWinnersAndWithdrawFunds(transaction.winners, transaction.amountList); ```