Attacker can freeze users first rewards

Un-bonding will lead to staked tokens getting stuck

Rewards will get stuck if `withdrawaddrenabled` is set to false on the target chain

Changes of the `UnbondingTime` are not accounted for

Slashing allows users to bypass the lockup period of vestings

Slashing of Unbondings is not accounted for and can lead to DOS of withdrawals

Staked tokens will get stuck after claim

Batch creation will break if vestings are opened to recipients

Malicious liquidity provider can put pool into highly manipulatable state

Users can MAKE EMA-Oracle price outdated with direct transfers to StableSwap

a huge loss of funds for all the users who try to remove liquidity after swapping got disabled at manipulated price .

Missing hook call will lead to incorrect oracle results

Storage can be bloated with low value liquidity positions

[M02] Complete liquidity removals fail from stableswap pools

[M09] No slippage check in `remove_liquidity` function in omnipool can lead to slippage losses during liquidity withdrawal.

User can evade `liquidation` by depositing the minimum of tokens and gain time to not be liquidated

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

First Liquidity provider can claim all initial pool rewards

THE USER WHO WITHDRAWS LIQUIDITY FROM A PARTICULAR POOL IS ABLE TO CLAIM MORE REWARDS THAN HE DULY DESERVES BY CAREFULLY SELECTING A `decreaseShareAmount` VALUE SUCH THAT THE `virtualRewardsToRemove` IS ROUNDED DOWN TO ZERO

Chainlink price feed uses BTC, not WBTC. In case of depegging, oracles will become easier to manipulate.

DOS of proposals by abusing ballot names without important parameters

SALT staker can get extra voting power by simply unstaking their xSALT

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

Reusing a SALT that has already been used for voting can allow a malicious proposal to pass and compromise the protocol.

If there is only one USDS borrower, he can never be liquidated

Creation of token whitelisting proposals can be DOS'd

ETHCrowdfundBase.sol#processContribution - Impossible to finalize crowdfund because of minContribution check

``FULL_RESTRICTED`` Stakers can bypass restriction through approvals

Protocol markets are incompatible with rebasing tokens

Some tokens enable the direct draining of all approved `ERC20Votes` tokens

Investors claiming their maxDeposit by using the LiquidityPool.deposit() will cause that other users won't be able to claim their maxDeposit/maxMint

The Restriction Manager does not completely implement ERC1404 which leads to account that are supposed to be restricted actually have access to do with their tokens as they see fit