Attacker can steal any funds in the contract by state confusion (no preconditions)

Attacker may DOS auctions using invalid bid parameters

Owner can transfer all ERC20 reward token out using function recoverERC20

Pledge may be out of reward due to the decay in veCRV balance. targetVotes is never reached.

Calling `repay` function sends less DOLA to `Market` contract when `forceReplenish` function is not called while it could be called

If user sets a low `gasPrice` the operator would have to choose between being locked out of the pod or executing the job anyway

`voucherIndexes` is incorrectly updated

`ERC721Votes`: Token owners can double voting power through self delegation

Use can get unlimited votes

`Governor` - Quorum could be less than intended

Interface definition error

Putty position tokens may be minted to non ERC721 receivers

`fee` can change without the consent of users

Total supply can be incorrect in `ERC20`

Stableswap - Deadline do not work

A cap is needed on the amount of Note than can be borrowed

Basket NFT have no name and symbol

Yield of `LiquidityReserve` can be stolen

Incorrect implementation of APWine and Tempus `redeem`

Funds may be stuck when `redeeming` for Illuminate

`_harvest` has no slippage protection when swapping `auraBAL` for `AURA`

In `ERC20`, `TotalSupply` is broken

Anyone can set the `baseRatePerYear` after the `updateFrequency` has passed

Note: When _initialSupply ! = 0, the _mint_to_Accountant function will fail

Total Supply is not guaranteed and is not deterministic.

Amount distributed can be inaccurate when updating weights

Contracts should be robust to upgrades of underlying gauges and eventually changes of the underlying tokens

`VoterProxy` incorrectly assumes a 1-1 mapping between the gauge and the LP tokens.

Incorrect deployment parameters

temporary DOS by calling notifyRewardAmount() in Bribe/Gauge with malicious tokens

hard-coded slippage may freeze user funds during market turbulence

`UNISWAP_FEE` is hardcoded which will lead to significant losses compared to optimal routing

Verification should be leafed based and not address based

Fund loss or theft by attacker with creating a flash loan and setting SuperVault as receiver so executeOperation() will be get called by lendingPool but with attackers specified params

System could be wrapped and made useless without contract whitelisting

Should prevent users from sending more native tokens in the `startBridgeTokensViaCBridge` function

ERC4626 mint uses wrong `amount`

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