Improper Transfer Restrictions on Non-Bridged Tokens Due to Boolean Bridged Token Tracking, Allowing a DoS Attack Vector

Users can claim more that their actual allotment

Incorrect listing type validation bypasses enforcement of minimum purchase amount

Stable swap pools don't properly handle assets with different decimals, forcing LPs to receive wrong shares

Stableswap does disjoint swaps, breaking the underlying invariant

Stableswap pool can be skewed free of fees

Protocol allows creating broken tricrypto CPMM pools

Multi-token stableswap pools allow 0 liquidity for tokens, creating bricked pools

Farms can be created to start in past epochs

`withdraw_liquidity` lacks slippage protection

Protocol fees are mistakenly configured by protocol pools rather than being imposed

Single sided liquidity can't be used to lock LP tokens in the farm manager

In edge cases, create_pool can either be reverted or allow user underpay fees.

Spread calculation does not account for swap fees

`profileIdByAddress` not cleared in `deleteAddressAtIndex`

Raffle winner unable to claim prize in `RAFFLE` incentive strategy

Unnecessary check on `ManagedBudget::allocate` prevents allocation of Fee-On-Transfer tokens to the contract

Malicious actors can manipulate the `cross_chain_callback` callback

There is no refund mechanism in `ChakraSettlement.processCrossChainCallback` or `ChakraSettlementHandler.receive_cross_chain_callback` function

Inconsistent Handler Validation Behavior in Cairo ERC20Handler's Cross-Chain Callback

Anyone can manipulate user nonce (nonce_manager) in settlement contract

Forcing Starknet handlers to be whitlisted on the same chain allows exploit of `BurnUnlock` mode to drain handler funds

The LockMint and BurnUnlock modes cannot be used

SettlementSignatureVerifier is missing check for duplicate validator signatures

In Starknet already processed messages can be re-submitted and by anyone

Invalid token address used in `ChakraSettlementHandler::cross_chain_erc20_settlement(...)` leading to invalid transaction creation and event emission

handler's `receive_cross_chain_callback()` will always set the tx_status to `SETTLED` on source chain & burn the tokens (MintBurn Mode) even when the msg fails on destination

Permanent loss of user tokens on both chains if `BurnUnlock` mode fails because of flawed burning pattern

A cross-chain message can be initiated with invalid parameters

Settlement contract is mistakenly used for the handler contract when assigning ReceivedCrossChainTx struct

Incorrect decimals Setting for ckrBTC Token May Lead to User Confusion and Inaccurate Transaction Amounts

Does not check if to_chain and to_handler is whitelisted in cross_chain_erc20_settlement

Excessive Authority Granted to Managers in the `ckr_btc.cairo` Contract Presents Significant Management Risks

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

Owner of a cancelled Sablier stream will be elegible for a full amount reward claim, due to a revert in `FjordStaking::onStreamCanceled(...)`

Malicious users can exploit raffle cancellation to disrupt protocol functionality

Failure to update `_lockedETH` during refunds causes inaccurate revenue withdrawals

Lack of parameter validation in `propagateRaffleWinner` Leads to failed prize claims on mainnet

Roles can not be revoked

Admins can influence the odds of raffles

TokenManager - Unlimited withdraw

Taker of bid offer will loss assets without any benefit if he calls the DeliveryPlace::settleAskMaker() for partial settlement.

`DeliveryPlace::settleAskTaker` Has Incorrect Access Control

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

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

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

listOffer maker can settle offer via settleAskMaker() in Turbo settle type.

Incorrect Check in closeBidOffer function

`PreMarket::createTaker` Should Update the `offerInfo.offerStatus` According to `amount usedPoints`

High risk of griefing attack during settlement period in Protected mode

`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

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

Incorrect check against golden entropy value in the first two batches

Failure to Update Dirty Flag in transferToUnoccupiedPlot Prevents Reward Accumulation On Valid Plot

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

Not upadting `_totalAuctionTokenAllocation` when removing last auction config at cooldown leads to wrong accounting of `_totalAuctionTokenAllocation` and permanent lock of auction tokens

Auction tokens cannot be recovered for the first ever spice auction

TempleGold tokens cannot be recovered when a `DaiGoldAuction` ends with 0 bids

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

Design flaw and mismanagement in vault licensing leads to double counting in collateral ratios and positions collateralized entirely with kerosine

Kerosene collateral is not being moved on liquidation, exposing liquidators to loss

Users can get their Kerosene stuck until TVL becomes greater than Dyad's supply

User can get their Kerosene stuck because of an invalid check on withdraw

Incorrect deployment / missing contract will break functionality

No incentive to liquidate when CR <= 1 as asset received < dyad burned

The highest bidder can cancel his bid, leading to funds loss of other bidders when closing the auction

Any fee claim lesser than the total `yieldFeeBalance` as unit of shares is lost and locked in the `PrizeVault` contract

Lack of Slippage Protection in `withdraw`/`redeem` Functions of the Vault

Malicious user can stake an amount which causes zero curStakeAtRisk on a loss but equal rewardPoints to a fair user on a win

Players have complete freedom to customize the fighter NFT when calling `redeemMintPass` and can redeem fighters of types Dendroid and with rare attributes

A user can lose funds in `sdlPoolSecondary` if tries to add more sdl tokens to a lock that has been queued to be completely withdrawn

Incorrect amounts of ETH are transferred to the DAO treasury in `ERC20TokenEmitter::buyToken()`, causing a value leak in every transaction