`VaultManager::updateBuyFeePID()` assumes different `ETH` bought than the actual, leading to incorrect `buyFeePID` adjustments.

`UsualSP::removeOriginalAllocation()` does not call `updateReward()` leading to the insider losing his earned and generated rewards.

Incorrect calculation of fee in `UsualX::withdraw()` leading to protocol taking less fee amount and other consequences.

Anyone can redeem the ```canWithdrawAsset``` token by burning ```1``` ```CollectionToken``` while it is non-floor item leading to stealing it from lister of ```ProtectedListings```.

The health of a ```ProtectedListing``` is incorrectly calculated if the ```tokenTaken``` has be changed through ```ProtectedListings::adjustPosition()```.

Lister is overpaying during the cancel of his listing on ```Listings::cancelListings()```.

```setFee``` function is writing on memory leading to protocol not able to apply ```Pool```-specified ```fees``` as intended.

```CollectionShutdown::execute()``` calculates the ```newQuorum``` before burning ```Locker```'s collection tokens leading to unfair ETH distribution and lost funds forever.

Unused ```nativeToken```s are not transferred back to the Pool initializer after the ```Locker::initializeCollection()``` and they stay on ```UniswapV4Implementation```.

```Listings::modifyListings()``` doesn't update the ```listing.created``` (when only the ```floorMultiple``` is modified) leading to double paying and wrong accountings.

```UniswapV4Implementation::beforeSwap()``` incorrectly the ```beforeSwapDelta_``` comparing ```tokenOut``` with ```amountSpecified``` while the ```amountSpecified``` is in ```WETH``` terms.

```_calculateDebt``` function of ```LiquidationLogic``` does not convert ```debtShares``` to ```debtAmount``` and returns always ```debtShares``` breaking the functionality of every liquidation.

```liquidationProtocolFeeAmount``` are not subtracted from the collaterals of borrower during the liquidation process.

Liquidations will fail if there is not enough liquidity of the collateral that is supposed to be seized because it has been borrowed from other users.

Incorrect ```totalDebt``` calculation during the liquidation process since ```repayDebt``` function returns the ```burnt``` shares, not the total debt shares after the burn.

Outdated ```supplyIndex``` usage during ```getBalanceByPosition()``` call on ```CuratedVault::totalAssets``` leads to wrong ```lastTotalAssets```.

```reallocate``` function of ```CuratedVault``` can not withdraw fully from a ```Pool``` due to wrong handle of ```allocation.assets == 0```.

Repayments will revert on ```NFTPositionManager``` due to outdated debt measurement on ```_repay()```.

Before changing the ```reserveFactor``` on ```PoolFactory```, all existing Pools must update their reserves to avoid using an incorrect ```reserveFactor``` for interest accrued prior to the change.

```Pool``` expects all chainlink price feeds to have the same staleness thershold (1800 seconds) while this is not the case.

RedStone oracle is vulnerable because ```updatePrice``` is not called during the ```getEthValue``` function.

Pause and unpause functions are inaccessible

```vote``` function does not correctly checks if the remaining duration of a ```LockingPosition``` is greater than 14 days.

Rewards in ```MlumStaking``` are distributed unfairly not taking into consideration the time someone has been locked.

```_requireOnlyOperatorOrOwnerOf``` does not correctly check the owner or the operator of the position leading to anyone can adjust the duration of a ```LockingPosition``` by adding to it.

A malicious user can execute a Denial of Service (DoS) attack on the registration of legitimate ```BribeRewarder``` contracts in the ```Voter``` contract by registering 5 worthless ```BribeRewarder``` contracts in each ```VotingPeriod```.

```BribeRewarder``` contract funtionality is broken with low-decimals tokens.

Users won't liquidate positions because the logic used to calculate the liquidator's profit is incorrect

When `sellCreditMarket()` is called to sell credit for a specific cash amount, the protocol might receive a lower swapping fee than expected.

Size uses wrong source to query available liquidity on Aave, resulting in borrow and lend operations being bricked upon mainnet deployment

Users can not to buy/sell minimum credit allowed due to exactAmountIn condition

Multicall does not work as intended

withdraw() users may can't withdraw underlyingBorrowToken properly

Use of CREATE method is suspicious of reorg attack

Incorrect Calculation of `_totalSupply` of `vestZVE`

Airdrop amounts diminish over time due to continuous increase in `zSTT` and `zJTT` tokens total supply