Liquidations will be significantly delayed due to incorrect maths

Wrong variable usage upon withdrawing, resulting in unexpected results

Multi-hop swaps are not properly supported, the code will run OOG

Tick spacing of 1 does not work properly

Setting the secondary position will cause unexpected results

Funds to be withdrawn can be stolen due to incorrect variable usage

Posting results can be blocked in `SedaCoreV1` due to using the push pattern

Creating a vesting account can be perpetually disallowed

Wrong amount of gas will be used in a certain case

User will have tokens stuck closing a leverage position due to an unconsidered case

Vault inflation attack in `AutoCompoundingPodLp` is possible due to incorrectly minting dead shares

Handling tokens in the contract upon adding liquidity results in breaking the optimal one-sided supply amounts

`PodUnwrapLocker` can be drained due to an arbitrary input

Users can prevent reward accrual in order to capture rewards distributed before they have joined

`_calculateBasePerPTkn` includes debond fee twice, lowering the price too much

Removing leverage will often revert due to calling an incorrect function

Adding leverage using a podded token will lead to a revert

Leverage position can be impossible to close due to a non-initialized struct field

`_tokenToPodLp` will lower the yield of `AutoCompoundingPodLp` during volatile markets

Bad data would DOS the whole `AutoCompoundingPodLp`

`addInterest` will not update the interest acurately which would enable users to claim rewards for time that they weren't staked inside `LendingAssetVault`

Incomplete logic will allow malicious users to perpetually override the amount to swap to the minimum

`LendingAssetVault::_updateAssetMetadataFromVault()` results in incorrect calculations

Protocol assumes the same deployment on all chains on multiple occasions

MEV bots will steal from users due to an incorrectly manipulated value

Incorrect `min/maxPrice` checks

Incorrect total assets available calculation leads to incorrect utilisation

Removing leverage will often fail when the received pair LP token is insufficient

Pausing rewards will lead to tokens being bricked and users not being able to claim them

A vault can be considered not over-utilized when it is and vice versa upon depositing

Liquidations will revert incorrectly due to an out-of-sync leftover collateral value

Tokens will be stuck in `AutoCompoundingPodLp` if the intermediary swap token is not a reward token

Debasing/rebasing periods can be decreased by 50% by a malicious actor

Lenders blacklisted for USDC can disallow borrowers from repaying

`acceptLoanOfferAndFillOrder()` will result in a lower fee for the protocol

Shares of a user will be wrong after a liquidation

Wrong interest rate after a liquidation

`getSupplyBalance()` and `getDebtBalance()` return wrong values

Interest rate will be wrong after a repay

Liquidations will be executed with wrong values

Withdrawals might be DoS in certain cases and funds can get stuck

Repayments using the NFT position manager will revert in a lot of cases

Using a hardcoded value for the Chainlink stale price check is dangerous

Not including Chainlink decimals upon calculations will lead to accounting issues

Users can increase their rewards and dilute rewards for other users

Funds will always be stuck in a pool and unexpected reverts will occur upon reallocations

The `Pool` contract can be DoSed

`Superpool` contract doesn't strictly follow EIP4626

Superpool can not be paused despite the implemented functionality

Not removing a token from the position assets upon an owner removing a token from the known assets will cause huge issues

Liquidations will revert if a position has been blacklisted for USDC

Reallocations will often fail upon using USDT

The Redstone oracle can report stale prices

Partial liquidations are next to impossible to happen despite the code being supposed to allow them

`mintToken()`, `mintWithBudget()`, and `forge()` in the `TraitForgeNft` Contract Will Fail Due to a Wrong Modifier Used in `EntropyGenerator.initializeAlphaIndices()`

The maximum number of generations is infinite

Number of entities in generation can surpass the 10k number

Incorrect Percentage Calculation in NukeFund and EntityForging when `taxCut` is Changed from Default Value

Wrong minting logic based on total token count across generations

There is no slippage check in the `nuke()` function.

Forger Entities can forge more times than intended

Pause and unpause functions are inaccessible

NFTs mature too slowly under default settings.

Imprecise token age calculation results in an incorrect nuke factor, causing users to claim the wrong amount

`Golden God` Tokens can be minted twice per generation

Each generation should have 1 "Golden God" NFT, but there could be 0

Excess ETH from `forgingFee` can get stuck in `EntityForging` under certain situations

Discrepancy between nfts minted, price of nft when a generation changes & position of `_incrementGeneration()` inside `_mintInternal()` & `_mintNewEntity()`

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.

The collateral remainder cap is incorrectly calculated during liquidation

Fragmentation fee is not taken if user compensates with newly created position

`executeBuyCreditMarket` returns the wrong amount of cash and overestimates the amount that needs to be checked in the variable pool

Sandwich attack on loan fulfillment will temporarily prevent users from accessing their borrowed funds

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

A malicious user can steal money out of the vault and other users

Due to the use of `msg.value` in for loop, anyone can drain all the funds from the `THORChain_Router` contract

[M-02] Incorrect call argument in `THORChain_Router::_transferOutAndCallV5`, leading to grief/steal of `THORChain_Aggregator`'s funds or DoS

Users are unable to claim their tokens

Users are unable to claim tokens now and might be able to drain the whole contract

User might unexpectedly lose his funds upon exiting

Availability of deposit invariant can be bypassed

`totalPrincipalTokensRepaid` and `totalInterestCollected` can be manipulated

Lenders might not be able to close their loans and get their collateral back in the case of default

Liquidating a loan will leave the liquidator at a loss

A market owner can put borrowers in a very unfavorable position and steal money out of lenders

Incorrect logic causes inaccurate values for a weight/votes checkpoint

User funds scheduled for vesting can get locked due to incorrectly decrementing the total supply in `ZivoeRewardsVesting`

Forwarding yield in `OCL_ZVE` is possible a lot more often than the enforced 30 days

Flawed if check causes inaccurate tracking of the protocol's ercDebt and collateral