Oracle assumes token and feed decimals will be limited to 18 decimals

Permanent freeze of vested tokens due to overflow in _baseVestedAmount

not able to create claim

Variable balance token causing fund lock and loss

Two address tokens can be withdrawn by the admin even if they are vested

Wrong balanceOf user after minting legendary gobbler

Possible that unanimous votes is unachievable

Calling `transferEth` function can revert if `receiver` input corresponds to a contract that is unable to receive ETH through its `receive` or `fallback` function

Calculated `token0TVL` may be zero under certain scenarios

Creating a new governance proposal can be prevented by anyone

`Governor` - Quorum could be less than intended

Founders can receive less tokens that expected

Truncation in casting can lead to a founder receiving all the base tokens

Moving average precision is lost

Unsafe usage of ERC20 transfer and transferFrom

ERROR IN UPDATING **_checkpoint** IN THE **increaseUnlockTime** FUNCTION

Unsafe casting from int128 can cause wrong accounting of locked amounts

The current implementation of the VotingEscrow contract doesn't support fee on transfer tokens

Attackers can abuse the quitLock function to get a very large amount of votes

`increaseUnlockTime` missing `_checkpoint` for delegated values

Decimals limitation limits the tokens that can be used

First depositor can break minting of shares

previewWithdraw calculates shares wrongly

Use `safeTransfer()`/`safeTransferFrom()` instead of `transfer()`/`transferFrom()`

Wrong DOMAIN_SEPARATOR

The check for value transfer success is made after the return statement in _withdrawFromYieldPool of LidoVault

DoS in wrap and unwrap

safeTransferFrom is recommended instead of transfer (1)

amount requires to be updated to contract balance increase (1)

Missing check in the updateValset function

Non-Cudos Erc20 funds sent through sendToCosmos() will be lost.

[WP-H1] A malicious early user/attacker can manipulate the vault's pricePerShare to take an unfair share of future users' deposits

_depositAmount requires to be updated to contract balance increase

StakedCitadel: wrong setupVesting function name

Low level call returns true if the address doesn't exist

User's funds can get lost when transferring to other chain

`requiredImprovementRate` can not work as expected when `previousInterestRate` less than 10 due to precision loss

Failed transfer with low level call won't revert

First depositor can break minting of shares

Can deposit native token for free and steal funds

call to non-existing contracts returns success

wrong condition checking in price calculation

`sharesToTokenAmount`: Division by zero

TurboRouter: deposit(), mint(), createSafeAndDeposit() and createSafeAndDepositAndBoost() functions do not work

ERC4626 mint uses wrong `amount`

`ERC4626RouterBase.withdraw` should use a **max** shares out check

[WP-H14] `ConvexStakingWrapper`, `StakingRewards` Wrong implementation will send `concur` rewards to the wrong receiver

`MasterChef.updatePool()` Fails To Update Reward Variables If `block.number >= endBlock`

During stake or deposit, users would not be rewared the correct Concur token, when MasterChef has under-supply of it.

[ConcurRewardPool] Possible reentrancy when claiming rewards

user won't be able to get his rewards in case of staking with amount = 0

The system can get to a "stuck" state if a bad proposal (proposal that can't be executed) is accepted

flan can't be transferred unless the flan contract has flan balance greater than the amount we want to transfer