Fees are incorrectly subtracted breaking the invariant

Anybody can perforrm an unstake/withdrawal tx as the sender is not properly checked

requestId has no unique parameters leading to different collisions

Refund currency amount is incorrectly used when checking for minTokenAmountForUser

Pool fraction is not truncated when allocating the tokens allowing to receive more rewards than owed

Refund mechanism doesn't make sure that there is a fee granter

Message is indexed as refundable even if the signature was over a fork

Missing slippage protection in `AerodromeDexter.sol` `swapExactTokensForTokens()`

In `transferVesting`, the `grantorVesting.releaseRate` is calculated incorrectly, which leads to the sender being able to unlock more tokens than were initially locked.

Possible DoS scenario when transferring vests to another address

Creator of one vesting plan can affect vesting plans created by other users.

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

Incorrect listing type validation bypasses enforcement of minimum purchase amount

Fetching principal amount in active loans can revert if there were partial repayments previously

Orders will be overwritten in a multicall

Users can DoS the system by creating unlimited pending orders in the OracleLess contract

Unspent gas fees are always refunded to the `FeePayer()` which leads to incorrect refunds if the `FeeGranter()` paid for the fees

Multiplier is calculated using denom and not coin.Denom

Resolver is not initialized in the protocol's keeper

Gas refunds use block gas instead of transaction gas, leading to incorrect refund amounts

Wooracle authority is incorrectly set

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

`ChakraSettlement.receive_cross_chain_msg` and `ChakraSettlement.receive_cross_chain_callback` functions do not ensure that receiving `ChakraSettlement` contract's `contract_chain_name` must match `to_chain` corresponding to respective `txid` input though

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

settlement.cairo doesn't process callback correctly leading to CrossChainMsgStatus marked as SUCCESS even if it failed on destination chain

In settlement.cairo::receive_cross_chain_msg - the message will always be marked with Status::SUCCESS

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

A cross-chain message can be initiated with invalid parameters

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

Wrong usage of transaction originator address instead of caller address

Does not check if to_chain and to_handler is whitelisted in cross_chain_erc20_settlement

Missing `lower<upper` check in `mint_position`

update_emergency_council_7_D_0_C_1_C_58() updates nft manager instead of emergency council

_onTransferReceived() does not work as intended

`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

Pause and unpause functions are inaccessible

NFTs mature too slowly under default settings.

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

TraitForgeNft: Generations without a golden god are possible

Claiming rewards while the deduction rate is != 0, allows for repeated withdrawal of redistributed rewards

committee_sizes is not properly updated

CultureIndex.sol#dropTopVotedPiece() - Malicious user can manipulate topVotedPiece to DoS the whole CultureIndex and AuctionHouse

The peg stability module can be compromised by forcing lowerDepeg to revert.

`sync` function in `RdpxV2Core.sol` should be called in multiple scenarios to account for the balance changes that occurs

Users can front-run the owner and update the rewards if the rewardsMinOracles hasn't been set yet

`fastTrackProposalExecution` should only be callable when `TemporalGovernor` is paused

`TemporalGovernor` can be bricked by `guardian`

`Vault.mintYieldFee` FUNCTION CAN BE CALLED BY ANYONE TO MINT `Vault Shares` TO ANY RECIPIENT ADDRESS

`VaultFactory` allows deployment of vaults with non-authentic `TwabController` and `PrizePool`

mintRebelancer() can be called outside of rebalance() function

100% slippage tolerance can lead to sandwich attacks

Incorrect address of BTC/USD price feed in StableOracleWBTC.sol

Improper decimals handling in StableOracleDAI.sol

The protocol doesn't check for the price staleness when requesting price from Chailink

Improper state update when deleting items from a list in removeCollateral()

missing isEpochClaimed validation

Claiming accumulated rewards while the contract is underfunded can lead to a loss of rewards

No check if transfer() operation was successful in FootiumEscrow.sol

safeMint() function in FootiumClub.sol doesn't check if there is onERC721Received callback in recipient contract