clinq.

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=46 stakingToken.transferFrom(sender, address(this), amount); ``` - Transferring tokens by `amount`. ```solidity=47 _mint(sender, amount); ``` - This function call executes the following operation. - In `ERC20Upgradeable._mint`, - `_balances[account] += amount;` - The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees. --- ```solidity=82 stakingToken.transferFrom(sender, address(this), amount); ``` - Transferring tokens by `amount`. ```solidity=83 _mint(sender, amount); ``` - This function call executes the following operation. - In `ERC20Upgradeable._mint`, - `_balances[account] += amount;` - The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.

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.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted 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. *This finding is considered minor because the state variable is only incremented or decremented. So, the effect of out-of-order increments may be unobservable after transaction. However, the reentrancy vulnerability may still cause other issues in the middle of transaction.* ### External call(s) ```solidity=45 collect(); ``` * This function call executes the following external call(s). * In `CGTStaking.collect`, * `rewardsToken.transfer(sender,rewards)` ```solidity=46 stakingToken.transferFrom(sender, address(this), amount); ``` ### State variables written after the call(s) ```solidity=47 _mint(sender, amount); ``` * This function call executes the following assignment(s). * In `ERC20Upgradeable._mint`, * `_balances[account] += amount` ```solidity=47 _mint(sender, amount); ``` * This function call executes the following assignment(s). * In `ERC20Upgradeable._mint`, * `_totalSupply += amount` --- ### External call(s) ```solidity=58 collect(); ``` * This function call executes the following external call(s). * In `CGTStaking.collect`, * `rewardsToken.transfer(sender,rewards)` ### State variables written after the call(s) ```solidity=59 _burn(sender, amount); ``` * This function call executes the following assignment(s). * In `ERC20Upgradeable._burn`, * `_totalSupply -= amount` --- ### External call(s) ```solidity=82 stakingToken.transferFrom(sender, address(this), amount); ``` ### State variables written after the call(s) ```solidity=83 _mint(sender, amount); ``` * This function call executes the following assignment(s). * In `ERC20Upgradeable._mint`, * `_balances[account] += amount` ```solidity=83 _mint(sender, amount); ``` * This function call executes the following assignment(s). * In `ERC20Upgradeable._mint`, * `_totalSupply += amount` --- ### External call(s) ```solidity=82 stakingToken.transferFrom(sender, address(this), amount); ``` ### State variables written after the call(s) ```solidity=90 forfeitedRevenue += pending; ``` ```solidity=84 uint256 pending = collect(); ``` * This function call executes the following assignment(s). * In `CNQStaking._setStaker`, * `stakers[addr] = payload` ```solidity=85 _changeValue(sender, balanceOf(sender)); ``` * This function call executes the following assignment(s). * In `CNQStaking._setStaker`, * `stakers[addr] = payload` --- ### External call(s) ```solidity=105 stakingToken.transfer(sender, amount); ``` ### State variables written after the call(s) ```solidity=109 forfeitedRevenue += pending; ```

We have two questions related to CGTMinting design: 1. The `orders` mapping is basically for bookkeeper use only. 2. Users can use any account to call the `burn()` function in order to fulfill a unique burn order.

The return value of the transfer()/transferFrom() call is not checked. ```solidity=46 stakingToken.transferFrom(sender, address(this), amount); ``` --- ```solidity=61 stakingToken.transfer(sender, amount); ``` --- ```solidity=71 rewardsToken.transfer(sender, rewards); ``` --- ```solidity=82 stakingToken.transferFrom(sender, address(this), amount); ``` --- ```solidity=105 stakingToken.transfer(sender, amount); ```

```solidity=248 event Forfeit(address indexed addr, uint256 indexed amount); ``` - `Forfeit` is declared in `CNQStaking` but never emitted.

It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring Ether, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation.