Incorrect position leverage calculation

Secondary position is not compatible with position width <= 4 * tickSpacing

The calculation of `totalAssets()` could be wrong if `operatorFeeAmount` > 0, this can cause potential loss for the new depositors

Incorrect Logic in onlyOperator Modifier Leading to Denial-of-Service for Authorized Operators Across Critical Functions

Some pod token transfers can be reverted unexpectedly

Utilization rate change can be sandwiched in lending vault for profit

Incorrect calculation of vault utilization value may cause loss of funds for the lending vault users in bad debt scenario

Incorrect `minAnswer` check doesn't protect the protocol from massive price drops

Malicious liquidator can intentionally leave dust amount of collateral and won't trigger bad debt handling

Transaction may revert unexpectedly due to missing allowance for the lending pair asset

Last position's liquidation price is incorrectly calculated

All the burn and mint functions are impacted from incorrect _update handling if there is a fee

aspToken price is incorrectly calculated when `hasSelfLendingPod` = true

Project tokens can be stolen by the attacker with frontrunning

Compromised addresses can take action in the profile

Wrong handling of call data check indices, forcing it sometimes to revert

Gas griefing/attack via creating the proposals

`clawback()` function can't be called by the owner of the boost due to wrong owner checking

Fee on transfer tokens are not supported in boost protocol

Wrong conversion from liquidity shares to assets causing loss of funds

Interest rate is not updated correct after debt repayment, it can cause higher borrowing rate

Incorrect Variable Usage in Liquidation Logic Can Prevent Positions from Being Fully Liquidated

Borrowing rate is dropping significantly due to wrong interest rate update

Vault's `totalAssets()` implementation causing wrong amount of share minting

Liquidated positions which is borrowed from NFT position manager can still earn rewards

Inflation/donation attack is possible in current Vault implementation

[H-01] Auction tokens will be lost forever when auction ends without bids

All the raffle events can be cancelled by the attacker

Admin can't withdraw available balance due to wrong locked ETH amount

In certain situations, winner can't claim his prize due to unbounded ticket count

TokenManager - Unlimited withdraw

Native token withdrawal fails until manually approved

Malicious user can drain protocol by bypassing `ASK` offer abortion validation in `Turbo` mode

Unnecessary balance checks and precision issues in TokenManager::_transfer

[Low-01] Missing Access Control in `CapitalPool::approve()` Function Allows any User to call it to set Allowance Amount `TokenContract` to `type(uint256).max`.

3 `OfferStatus` are never used, and code seems to have contradicting intentions

The maximum number of generations is infinite

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

NFTs mature too slowly under default settings.

Incorrect check against golden entropy value in the first two batches

Invalid validation in _farmPlots function allowing a malicious user repeated farming without locked funds

Users can farm on zero-tax land if the landlord locked tokens before the LandManager deployment

Fallback Handlers Can Be Installed with Invalid Calltype

Anyone can add funds to any position

No revert on failure tokens can be deposited without adding funds and can be stolen by the user

Staking ETH incorrectly assumes revert bubbling

`AccountingManager::resetMiddle` will not behave as expected

Attacker can increase the length of `withdrawQueue` by withdrawing 0 amount of tokens frequently