GradientBasedRules will not work for >=4 assets with vector lambdas

Users can claim more that their actual allotment

maxSellPercent can be buypassed by selling previously bought vestings at a later time

Attacker can steal the deposits , when user tries to deposit using permit2.

Collision attack may lead to the loss of funds for the user.

Precision loss in while calculating the fee in `DebitaV3Aggregator::matchOffersV3`.

Vulnerability in `DLOFactory::deleteOrder()` allows owner of `DLOImplementation` to decrease `activeOrdersCount` as much they want.

Overflow in `DebitaV3Loan::extendLoan()`.

Overflow while calculating fee in `DebitaV3Loan::extendLoan`.

MembershipERC1155 proxy cannot be upgraded

Wrong handling of `reservedDs` leading wrong accounting and loss of funds

User can redeem extra `ra` in exchange of `ct` token.

Incorrect set up and logic of `referralInfoMap` in `SystemConfig::updateReferrerInfo` function

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`.

`listOffer` Unsafely References Fungible Identifiers

PreMarkets - Unable to withdraw platform rewards

Number of entities in generation can surpass the 10k number

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

TraitForgeNft: Generations without a golden god are possible

A malicious User can DOS all offchain orders making them unexecutable and leaving the protocol in an insolvent state. Also all offchain Trades can also be DOSed for honest parties that do not meet the fillorder requirements (no try and catch)

Voting Malfunction Leading to Core Protocol Vulnerability

Access Control Vulnerability in `MlumStaking.sol:addToPosition`

Depositors will loose extra balance while withdrawing there balance from the protocol.

Critical Vulnerability Allowing Users to Exceed `collateralUserCap` in `AssetsProcess.sol:deposit` function.

The `lossFee` is simply added to the `commonData` and not reimbursed to the keeper, leading to potential losses for the keeper.

Miscalculation results in the protocol not accounting for and managing actual losses incurred by the keeper.

The implementation of `payExecutionFee()` didn't take `EIP-150` into consideration. Keepers can steal additional execution fee from users.