Users can double claim in claimTokens()

No access control on ERC1155Voucher::onERC1155BatchReceived()

User might execute PositionToken of token set by previous token owner.

Holders array can be manipulated by transferring or burning with amount 0, stealing rewards or bricking certain functions

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

Call to declareInsolvent() would revert when contract status reaches liquidation point after repayment of credit position 1

Unchecked transfers

Anyone can spend on behalf of roller periphery

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

Anybody can withdraw underlying asset without ERC5095 token burn before maturity without burning leading to theft of funds

User can double mint illuminate PTs through cross-function re-entrancy.

setFee() in Redeemer contract would always revert.

Vault can be drained of funds using arbitrary commitment input when Private vault delegate is 0.

Vault can be drained of funds via Signature replay.

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

Different Oracle issues can return outdated prices

Delegation should not be allowed to address(0)

Anyone can pass any proposal alone before first `VOTES` are minted

OlympusGovernance#executeProposal: reentrancy attack vulnerable function

Inconsistent logic of increase unlock time to the expired locks

FraxlendPair.sol is not fully EIP-4626 compliant

Project funds can be drained by reusing signatures, in some cases

Signature Checks could be passed when SignatureDecoder.recoverKey() returns 0

Incorrect initialization of smart contracts with Access Control issue

removeWrapping can be called when there are still wrapped tokens

It is possible to create fake ERC1155 NameWrapper token for subdomain, which is not owned by NameWrapper

transfer() depends on gas consts

Cash-out from a successful buyout allows an attacker to drain Ether from the `Buyout` contract

Use of `payable.transfer()` may lock user funds

Use a safe transfer helper library for ERC20 transfers

Allowance check always true in ERC5095 redeem

Unable to redeem from Notional

Funds may be stuck when `redeeming` for Illuminate

Lend method signature for illuminate does not track the accumulated fee

accountant address can be set to zero by anyone leading to loss of funds/tokens

Missing zero address check can set treasury to zero address

No check for existing extraRewards during push

USDT is not supported because of approval mechanism

Possible token reentrancy in release() of BathBuddy.sol

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

safeTransferFrom is recommended instead of transfer (1)