PAW Chain security record

Flash loans are a way to borrow large amounts of money for a certain fee. The requirement is that the loans need to be returned within the same transaction in a block. If not, the transaction will be reverted. An attacker can use the borrowed money as the initial funds for an exploit to enlarge the profit or manipulate the token price in decentralized exchanges. The function `CalculatePAWequivalent()` relies on price calculations that are based on-chain, meaning they are susceptible to flash-loan attacks by manipulating the price of given pairs to the attacker's benefit. The balance of the `PAW` in the pair contract can be manipulated as described in the scenario. ```solidity function CalculatePAWequivalent(uint256 amount) public view returns(uint256){ return (((ERC20(PAW).balanceOf(PairContract)*((((1000000000000000000 * amount) / (ERC20(PairContract).totalSupply())))) / 1000000000000000000))*2); } ```

The function `ChangeMultiplier()` 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.

The conditions to trigger the function `Claim()` are different in the functions `Deposit()` and `Withdraw()`. The `if` condition in the function `Deposit()` lacks the check of `ERC20(wPAW).balanceOf(address(this)) >= (GetUnclaimed(msg.sender))`. As a result, if the balance of the token `wPAW` is not sufficient, the users may not be able to call the function `Deposit()`. ```solidity //Deposit if(Deposits[msg.sender] > 0 && RewardsPaused == false){ Claim(); } //Withdraw if((ERC20(wPAW).balanceOf(address(this)) >= (GetUnclaimed(msg.sender))) && RewardsPaused == false){ Claim(); } ```

In the linked contracts in the new commit [cd93a72a77aed596685d4f948976196318a9cdbb](https://github.com/Pawkishi/PAWSWAPtoken/tree/cd93a72a77aed596685d4f948976196318a9cdbb), the value of `stakedTokenSupply` will be the current contract's balance of the staking token(`PAWToken` or `lpToken`). However, this does not consider direct token transfers. If someone mistakenly transfers the staking token directly to the current contract, the result of the variable `stakedTokenSupply` will be incorrect and include the direct transfer amount. This will cause all the stakers to lose some of their rewards.

In functions `Deposit()` and `Withdraw()` of the linked contracts `PAWFlexibleStaking` and `PawLPStaking`, the Checks Effects Interaction Pattern is not strictly followed.

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 For example: ```solidity=50 ERC20(PairContract).transferFrom(msg.sender, address(this), amount); ``` - Transferring tokens by `amount`. ```solidity=52 Deposits[msg.sender] = (Deposits[msg.sender] + amount); ``` - The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.

In the contract `PAWLockedStaking`, the user needs to stake for at least a `lockDuration` before withdraw. 1. The variable `holderUnlockTime[msg.sender]` is used to record the unlock time of each user instead of a single deposit. The below code snippet in the `deposit()` function will not update the `holderUnlockTime[msg.sender]` if there are already locked deposit from the given user. Therefore, the user can shorten the lock time of multiple deposit. ```solidity if(holderUnlockTime[msg.sender] == 0){ holderUnlockTime[msg.sender] = block.timestamp + lockDuration; } ``` 2. The conditions of withdrawal restriction and emergency penalty are slightly different. If the block.timestamp equals holderUnlockTime[msg.sender], the user can successfully withdraw the tokens with rewards but still need to pay the exit penalty using `emergencyWithdraw()`. ```solidity require(holderUnlockTime[msg.sender] <= block.timestamp, "May not do normal withdraw early"); if(holderUnlockTime[msg.sender] >= block.timestamp) ```

The function `rewardsRemaining()` calculate the remaining rewards as `rewardToken.balanceOf(address(this)) - totalStaked`. Based on our understanding, the remaining rewards is the current reward balance - current rewards to be distributed, which should be `rewardToken.balanceOf(address(this)) - calculateNewRewards`.

Performing integer division before multiplication truncates the low bits, losing the precision of the calculation. Although the `1000000000000000000` seems to be a multiplying to mitigate the issue, the `*2` operation is placed at the end. Also, the statement contains many redundant parentheses making the code hard to read. ```solidity=155 return (((ERC20(PAW).balanceOf(PairContract)*((((1000000000000000000 * amount) / (ERC20(PairContract).totalSupply())))) / 1000000000000000000))*2); ```

There should always be events emitted in the sensitive functions that are controlled by centralization roles.