Wrong amount is minted to user when they deposit into the lending pool

Faulty Gauge Weight Update Formula: Voting Power Delta Not Considered Leading to Arithmetic Underflow and Vote Weight Inconsistency

Incorrect decimal handling in `Auction::buy()` leads to massive overpayment for ZENO tokens

Users Can Overwrite Existing Locks in veRAACToken Resulting in Permanent Loss of Funds

Ownership Parameter Mismatch in LendingPool’s Vault Withdrawal Logic

Gauge Voting Misallocation Vulnerability

`MAX_TOTAL_SUPPLY` Bypass in `veRAACToken` via `increase()` Function

Gauge reward period can be extended indefinitely

LendingPool deposits do not work with CurveVault due to lack of funds

Multiple Critical Calculation And Logic Errors in `RToken::mint/burn` Function

`mint` function in RToken contract doesn't return the correct expected values, leading to emission of ReserveLibrary `Deposit` event and LendingPool `Deposit` event with incorrect values.

Limited veRaac Token Supply Triggers DoS, Hampering Proper Governance Participation.

`FeeCollector::updateFeeType` wrong fee share validation leads to impossible update for some fee types

Missing whenNotPaused modifier on withdraw function allows token withdrawals during emergency

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.