Using initializer Modifier Prevents Child Contract initialize Function from Being Called

_resetVestingPlans Function’s amount Check Prevents Adjusting Vesting Plans

Reward Vesting Time Can Be Extended Indefinitely by Small Deposits

feeRecipient Address Cannot Be Assigned, Causing 100% Fee Loss

Incorrect tickUpper in collectFees Causes Revert, Disabling Core Protocol Functions

Withdrawal Failure in Leverager.withdraw() Due to Incorrect Repayment Calculation

Users can claim more that their actual allotment

Incorrect listing type validation bypasses enforcement of minimum purchase amount

Incorrect referral fee calculations

Rounding error in stepDuration calculations.

Underflow in `claimable` DOSing `claim` Function

The _getUnlockingPercentage function will always return 2000 due to a precision miscalculation, which will result in the user having to suffer an 80% penalty.

When calculating in the _getUnlockingPercentage function, 540 was mistakenly used instead of 540 days for calculation. As a result, users can unlock all their funds earlier without paying penalties.

Gas griefing/attack via creating the proposals

Malicious actors can manipulate the `cross_chain_callback` callback

There is no refund mechanism in `ChakraSettlement.processCrossChainCallback` or `ChakraSettlementHandler.receive_cross_chain_callback` function

In Starknet already processed messages can be re-submitted and by anyone

The lack of check conditions leads to the loss of contract functions.

Since the status parameter is not used, this will result in the owner being unable to set the permission of any address to false.

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Single plot can be occupied by multiple renters

Failure to Update Dirty Flag in transferToUnoccupiedPlot Prevents Reward Accumulation On Valid Plot

When `LockManager.lockOnBehalf` is called from `MigrationManager`, the user's `reminder` will be set to 0, resulting in fewer received `MunchableNFTs`

Incorrect Comparison Logic in Post-Operation Checks

Vultisig should be burnable

Malicious users can bypass the blacklist.

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Single plot can be occupied by multiple renters

Failure to Update Dirty Flag in transferToUnoccupiedPlot Prevents Reward Accumulation On Valid Plot

When `LockManager.lockOnBehalf` is called from `MigrationManager`, the user's `reminder` will be set to 0, resulting in fewer received `MunchableNFTs`

Funds may not be withdrawn due to a check error

The _stake function in the PufETHAdapter contract will revert

Wrong checking causes the swapETHForYt function to revert with a high probability

In the RsETHAdapter contract, _stake may revert

Incorrect calculations can result in user losses

An attacker can extend the user's reward release time

Division may cause a lot of reward tokens to be locked in the contract

_totalSupply update errors will cause user reward calculation errors.

claimRewards may fail to execute

Adding liquidity may fail

Users can make the protocol issue more rewards through flash loans. And these rewards can be claimed through slippage.

Funds locked due to missing transfer check

Epoch not increasing may cause the protocol to get stuck

Failure of user withdrawal may cause the rebalance function to get stuck.

The deposit may fail due to precision issues.

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

Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUST

Impossible to change managed wallets with `proposeWallets` after first rejection

getBunniTokenPrice function calculation error

Wrong function used to get totalSupply

Borrower has no way to update `maxTotalSupply` of `market` or close market.