RedeemerWithFees.sol#redeem() - we can withdraw disallowed collateral from the vault

`DLoopCoreBase` lacks necessary event emissions

Interest updating loops through the entire tier history, which is unbound.

The redeem limit can be indefinitely filled up with dummy requests

LockingRelock.sol - minimum lock amount can be bypassed via relocking

Incompatibility with Multisig Wallets in `TempleGold::send` Function

Permit calls can be front-ran and user deposits can be DoSed

Tokens with a maximum transfer logic could cause accounting issues on minting portfolio shares

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

Multiple Address ERC20 tokens could be drained from vaults containing them

Block-list ERC20s would lead to unwanted functionality

No access control on IncentivzedMessageEscrow's ``submitMessage`` can lead to a short-term dos of users

Due to missing checks on minimum gas passed through LayerZero, executions can fail on the destination chain

DecentEthRouter.sol#_bridgeWithPayload() - Any refunded ETH (native token) will be refunded to the DecentBridgeAdapter, making them stuck

Unrestricted claiming of fees due to missing balance updates in `FeeSplitter`

Rewards can be drained because of lack of access control

Looping over unbounded `pendingStakes` array can lead to permanent DoS and frozen funds

Reorg attack in SmartVaultManagerV5

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

Bidder can use donations to get VerbsToken from auction that already ended.

removedLiquidity can be underflowed to lock other user's deposits

The price of rsEHT could be manipulated by the first staker

In case of stock split, token holders will either gain or lose value

`rngComplete` function should only be called by `rngAuctionRelayer`

create methods are suspicious of the reorg attack

[H-04] Lender#buyLoan - Malicious user could take over a loan for free without having a pool because of wrong access control

Stealing any loan opening for auction through others' lending pool

Attacker can steal a loan's collateral and break the protocol

Fee on transfer tokens will cause users to lose funds

Rewards can be sabotaged by large deposit and withdraw

Hardcoded Router Address May Cause Token Lockup in Non-Standard Networks

The `borrow` and `refinance` functions can be front-run by the pool lender to set high interest rates

Single-step process for critical ownership transfer is risky

Pragma non-specification can lead to non-functional / corrupted contract when deployed on Arbitrum

Zero address leads to transaction reverts

Lender fails to giveLoan because of inconsistent length between `loadIds` and `poolIds`

Amount != 0 checks are missing

Multiple accesses of a mapping/array should use a local variable cache.

Too many DSC tokens can get minted for fee-on-transfer tokens.

`++i`/`i++` should be `unchecked{++i}`/`unchecked{i++}` when it is not possible for them to overflow, as is the case when used in `for`- and `while`-loops

Fee-on-transfer tokens aren't supported

Fixed `i_arbiterFee` can prevent payment

Contract Can Be Deployed Without Funds.

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

Attacker can frontrun deployVault to deploy at the same address

Long term denial of service due to lack of fees in Well