The user can send tokens to any address by using two bridge transfers, even when transfers are restricted.

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

not adding `claimable` balance to the total assets in `_harvestAndReport` can cause losses.

Old router retains token allowance after update

Missing KYC and NFT Ownership Verification for Ecosystem Access

Reorg Vulnerability in DAO Membership Creation Allows Users to Join Incorrect DAOs

Users Can Join DAOs Using Removed Currencies Due To Missing Validation

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

SettlementSignatureVerifier is missing check for duplicate validator signatures

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

SettlementSignatureVerifier's required_validators is not updated, resulting in a low or high number of signatures being required

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

TokenManager - Unlimited withdraw

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

Token withdrawal fails until someone manually approves spending

Unnecessary balance checks and precision issues in TokenManager::_transfer

`WrappedNativeToken` Can Only Work in `NativeToken` Mode

[Low-01] Missing Access Control in `CapitalPool::approve()` Function Allows any User to call it to set Allowance Amount `TokenContract` to `type(uint256).max`.

`Tokens` Are Automatically Whitelisted Upon Creation And Binding Even When `_whiteListEnabled == false`

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

Number of entities in generation can surpass the 10k number

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

Invalid validation in _farmPlots function allowing a malicious user repeated farming without locked funds

Future stakers are paid with rewards that have been accrued from the past due to miscalculation in userRewardPerTokenPaid and _perTokenReward.

Malicious user can prevent `rewardData.perodfinish` from ending by calling `TempleGoldStaking::distributeRewards()` before the end of the reward duration when no starter is set.

Incorrect Comparison Logic in Post-Operation Checks

`claim` function lacks slippage controls for `amount0` and `amount1` returned by `pool.burn` function call

Transfer of ILOPool NFT token to different account allows for users to bypass the pool's `maxCapPerUser` invariant

Value of kerosene can be manipulated to force liquidate users

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

`PanopticFactory` uses spot price when deploying new pools, resulting in liquidity manipulation when minting

`LiquidInfrastructureERC20.sol` disapproved holders keep part of the supply, diluting approved holders revenue.

Distribution can be bricked, and double claims by a few holders are possible when owner calls `LiquidInfrastructureERC20::setDistributableERC20s`

A locked fighter can be transferred; leads to game server unable to commit transactions, and unstoppable fighters

Since you can reroll with a different fighterType than the NFT you own, you can reroll bypassing maxRerollsAllowed and reroll attributes based on a different fighterType

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

Fighters cannot be minted after the initial generation due to uninitialized `numElements` mapping

Non-transferable `GameItems` can be transferred with `GameItems::safeBatchTransferFrom(...)`

NFTs can be transferred even if StakeAtRisk remains, so the user's win cannot be recorded on the chain due to underflow, and can recover past losses that can't be recovered(steal protocol's token)

Minter / Staker / Spender roles can never be revoked`..,

DoS in `MergingPool::claimRewards` function and potential DoS in `RankedBattle::claimNRN` function if called after a significant amount of rounds passed.

The use of spot price by CoreSaltyFeed can lead to price manipulation and undesired liquidations

Unwhitelisting does not clear _arbitrageProfits, so re-whitelisting may result in an unfair distribution of liquidity rewards.

Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUST

Impossible to change managed wallets with `proposeWallets` after first rejection

Creation of token whitelisting proposals can be DOS'd

Unauthorized Access to setCurves Function

Single token purchase restriction on curve creation enables sniping

If a user sets their curve token symbol as the default one plus the next token counter instance it will render the whole default naming functionality obsolete