The Unfettered

One or more `view` functions always return the same constant value. ```solidity=251 function beforeTokenTransfer( ``` - `BotPrevention.beforeTokenTransfer` always returns `true`.

Functions that update state variables should emit relevant events as notifications.

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

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 `getRequiredStableAmountForLiquidity` 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. Although the current usage of the function `getRequiredStableAmountForLiquidity` is not found in the current protocol, we would like to remind the client to be cautious about the usage of this function.

This project has issued the `SOULS` token and distributed it to various vaults through the `MainVault` with vesting plans. The `SOULS` tokens in different vaults serve different purposes, such as airdrop, staking, and PlayToEarn. Most of the privileged functions require the approval of three different `Managers` by invoking the function at least three times for execution. This may result in higher gas costs compared to approving them separately and invoking the function only once. However, these functions are not frequently called, hence the waste would not be significant.

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 `addLiquidty` 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: ````solidity=108 _router.addLiquidity( soulsTokenAddress, stableTokenAddress, _tokenAmountToAdd, _stableAmountToAdd, 0, 0, mainVaultAddress, block.timestamp + 1 hours ); ````

This project assigns the manager role to five addresses and requires at least three out of the five managers to approve a topic for it to take effect. However, the system is still vulnerable if three managers collude, and unfortunately, according to the contract design, the addresses of these `Managers` cannot be modified in this situation.

It is recommended to verify the end time of the previous airdrop period before creating a new one since all other airdrop-related operations depend on the current airdrop. Starting a new airdrop period before the last one ends will invalidate the previous period.

The process for how user deposits to the `PlayToEarnVault` affect the claiming process is currently unclear. While it appears that the project uses a Merkle tree mechanism and generates Merkle proofs for depositors, this process is implemented off-chain, and it is the responsibility of the project owner to ensure the safety and security of this process.

The contract is serving as the underlying entity to interact with third-party **Pancakeswap**. 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.