Threshold in `Consensus::checkSignatures()` can be bypassed via duplicate signatures

Incorrect Permission Check in `ShareManager::updateChecks()`

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

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

Multiple issues from unnecessary balance increase calculation in DebtToken.mint

Reward manipulation vulnerability in StabilityPool

Incorrect Reward Claim Logic in FeeCollector::claimRewards Causes Denial of Service

RToken's transfer function lead to loss of funds due to incorrect math

Attackers can get most of RAACToken rewards by withdrawing dust amount from StabilityPool multiple times

Boost Miscalculation Leads to Excess Distribution

Attackers can double voting power and veToken amount by locking and increasing

Ineffective Time-Weighted Average Implementation in Fee Distribution

Gauge stakers won't get any reward due to round-down in user weight calculation

Multiple calls to `BaseGauge::notifyRewardAmount()` override existing reward rate, causing loss of rewards for stakers

Incorrect accounting in `veRAACToken::emergencyWithdraw` and `veRAACToken::withdraw` due to missing `totalLocked` update

Incorrect DebtToken totalSupply Scaling Breaks Interest Rate Calculations

There is no logic checking for RAACNFT price staleness before minting it

`RToken::calculateDustAmount` are incorrectly calculated, leading to not be able to transfer the accrued dust amount

Treasury Contract Deposit Function Can Be Frontrun To Deny Protocol Operations

Owner Can Change Vote Results After Voting Ends by Updating Quorum Numbers for New proposals

Emergency revoke in RAACReleaseOrchestrator will freeze revoked RAAC tokens in orchestrator

Inconsistent Scaling in RToken Transfer Functions

`RAACReleaseOrchestrator::emergencyRevoke()` fails to update `categoryUsed`, leading to token lockup and incorrect accounting

The `TimelockController::executeEmergencyAction()` function does not update the `_operations` mapping, which can lead to an operation being executed twice.

Emergency withdraw functionality in veRAACToken takes longer than expected

Improper Lock State Updates: Misreported Locked Token Data infects Governance Participation, rewards distribution and Harms Protocol Trust.

Incorrect Initialization of minBoost in BaseGauge Constructor Breaks Core Contract Functionality

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

`DebtToken::burn`'s Return Values are wrong

`DebtToken::burn()` event parameters and return values ​​are incorrect

`collateralLiquidated` value is always 0 when emitted in the `LiquidationFinalized` event

Precision Loss Issue in FeeCollector Contract

Lack of Validation for `tierConfigs[i].minted` Value in New Tiers During DAO Membership Update

No LSTs transfer on node operator withdrawals resulting in stuck funds and loss for node operators

Remove splitter will always revert if there are some rewards left on splitter contract

Low Findings : L01 - L04

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

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

TokenManager - Unlimited withdraw

Native token withdrawal fails until manually approved

`DeliveryPlace::settleAskTaker` Has Incorrect Access Control

Formulaic Error Rounds Down Causing Total Loss Of Funds For Bid Takers During Abort

The `DeliveryPlace::settleAskTaker()` function mistakenly uses `makerInfo.tokenAddress` to update the `TokenBalanceType.PointToken` in the `userTokenBalanceMap` mapping, leading to a critical error.

Fund Withdrawal Flaw in preMarket Allows Users to Avoid Settlement Obligations

[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

When the `DeliveryPlace::settleAskMaker()` function calls `tokenManager.addTokenBalance()` to update the user balance, the `TokenBalanceType` parameter uses an operation, resulting in a balance update error

Starknet tokens deposited with use_withdraw_auto can never be withdrawn

There is No `msg.value` check in `depositTokens`, causing potential token stuck

Inadequate Checking of `isIncreasing` when trader adjusts position size

Incorrect logic for checking isFillPriceValid

Market Disruption and Financial Loss Post-Liquidation

`LiquidationBranch::checkLiquidatableAccounts()` executes `for` loop with wrong values, causing array out of bounds to be recovered, the program will not work as expected

Wrong parameter passed in `TradingAccount::deductAccountMargin` function that results in excess margin withdrawal

An Uninitialized Variable In The `MarketConfiguration::update` Function Causes The `PrepMarket::getIndexPrice` Function To Revert

Incorrect liquidatable checking for market order creation

`LibChainlinkOracle::getTokenPrice` will always return instantaneuous prices

LibUsdOracle will compromise Beanstalk peg due to wrong price and DoS

The declaration and use of `LibTractor::BLUEPRINT_TYPE_HASH` are inconsistent with the structure `struct Blueprint`, and the standard is confusing. It is recommended to unify the standard

`BeanL1RecieverFacet#recieveL1Beans()` would never work

`Lock::_notifyreward()` Malicious users use Lightning Loans to quickly accumulate rewarding tokens `reward.cumulatedreward` . In the end, the reward of the user cannot withdraw the reward

`PositionMarginProcess::updateAllPositionFromBalanceMargin()` error, users can update `position.initialMarginInUsdFromBalance` in all positions by depositing a small amount of funds

`AccountFacet::batchUpdateAccountToken()` lacks calling permission. Anyone can call this method to add any number of tokens to the account.

`Edition::mintBatch()-0x904868b2`, the attacker can mint token for free

`Edition::mint()` does not check and process user input, `_refundExcess()` is invalid, and an attacker can tail the transaction and consume the ETH in the contract to mint tokens for free

`Edition::mintBatch()-0x1f7fdffa` design error, batch minting tokens does not work as expected

liquidity providers can maliciously burn tokens, causing the final result of `ZivoeITO::claimAirdrop()` to deviate significantly from expectations.

Every time you call `ZivoeRewards::depositReward()` to deposit a reward, after the reward is vested, there will almost always be some dust left behind, and the amount will expand infinitely.

Anyone can call `ZivoeRewardsVesting::depositReward()` to deposit the corresponding token, lower the `rewardRate` and postpone `periodFinish` indefinitely

`Auctioneer::auction()` using wrong lotId value to get `Routing storage routing` failed to save data as expected.

Calling `AuctionHouse::claimProceeds()` will modify `Auction.Status`, causing `AuctionHouse::claimBids()` to revert and the buyer cannot withdraw the token.

Repeated calculation of `routing.funding` resulted in `AuctionHouse::claimProceeds()::prefundingRefund` error, and the seller could not normally get the proceeds (quote tokens) and refund (base tokens)

Attackers can lock market funds, prevent normal execution of transactions, and steal funds in the maker

Infinite Minting `PointsModule::FMP`

`JUSDBankStorage::getTRate()`,`JUSDBankStorage::accrueRate()` are calculated differently, and the data calculation is biased, Causes the `JUSDBank` contract funciton result to be incorrect