Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

Claiming rewards while the deduction rate is != 0, allows for repeated withdrawal of redistributed rewards

Incentive accumulation can be sandwiched with additional shares to gain advantage over long-term depositors

Malicious user can stake an amount which causes zero curStakeAtRisk on a loss but equal rewardPoints to a fair user on a win

Player can mint more fighter NFTs during claim of rewards by leveraging reentrancy on the `claimRewards() function `

Non-transferable `GameItems` can be transferred with `GameItems::safeBatchTransferFrom(...)`

NFTs can be transferred even if StakeAtRisk remains, so the user's win cannot be recorded on the chain due to underflow, and can recover past losses that can't be recovered(steal protocol's token)

Constraints of dailyAllowanceReplenishTime and allowanceRemaining during mint() can be bypassed by using alias accounts & safeTransferFrom()

DoS in `MergingPool::claimRewards` function and potential DoS in `RankedBattle::claimNRN` function if called after a significant amount of rounds passed.

When borrowers repay USDS, it is sent to the wrong address, allowing anyone to burn Protocol Owned Liquidity and build bad debt for USDS

User can evade `liquidation` by depositing the minimum of tokens and gain time to not be liquidated

formPOL lacks slippage and deadline protection

If there is only one USDS borrower, he can never be liquidated

Unauthorized Access to setCurves Function

Missing deadline check allow pending transactions to be maliciously executed

`costInEuros` calculation will incur precision loss due to division before multiplication

Lack of Minimum Amount Check in `SmartVaultV3::mint`, `SmartVaultV3::burn`, and `SmartVaultV3::swap` Can Result in Loss of Fees

`pause/unpause` functionnalities not implemented in many pausable contracts

Return value of `transfer` function is not checked which leads to false claim and lost prize

Bio Protocol - `tokenURI` JSON injection

Solmate's ERC20 does not check for token contract's existence, which opens up possibility for a honeypot attack

`repay` function can be DOSed

Chainlink oracle data feed is not sufficiently validated and can return stale `price`

Very critical `Owner` privileges can cause complete destruction of the project in a possible privateKey exploit

Variable balance token causing fund lock and loss

Solmate safetransfer and safetransferfrom doesnot check the codesize of the token address, which may lead to fund loss