The current implementation is incompatible with `WBTC` as collateral token

Readding the reward token causes userRewardPerTokenPaid to be incorrect for some users, resulting in them receiving too many rewards.

A validator can reuse their signature multiple times to post a batch with low voting power on Secp256k1ProverV1

batchSender can be a smart contract without the ability to receive native tokens, which would DOS postResult because the fee transfer would fail

The attacker can steal rewards from AutoCompoundingPodLP because in _processRewardsToPodLp, the rewards from TokenRewards are not distributed

Attacker can steal rewards in AutoCompoundingPodLp because he can revert the compounding with slippage

The attacker can steal rewards from spTKNs because they can influence the fee processing by making a direct token transfer to the pod when the fees are below the minimum

Pods with `hasTransferTax` set to `true` have an incorrect `totalSupply` because the burn fee is applied recursively to itself

Swapping in _acquireBorrowTokenForRepayment is not working when the sell fee is enabled because the swap does not support fee-on-transfer tokens

Transferring of _userProvidedDebtAmtMax does not work in _acquireBorrowTokenForRepayment because _props.sender is never set, which leads to a transferFrom call from address(0), causing the transaction to revert

`transferReserveToAuction` uses the wrong period, which is why `endAuction` will always fail, and the bidders' bids will be locked

An attacker can get many shares with a flashloan within one transaction and thus receive a lot of rewards and cause auctions to fail without having to permanently deposit reserve tokens.

There are shares in a period with failed auctions, which leads to some users receiving rewards from other users from successful periods

In `transferVesting`, the `grantorVesting.releaseRate` is calculated incorrectly, which leads to the sender being able to unlock more tokens than were initially locked.

Users can claim more that their actual allotment

Design flaw and mismanagement in vault licensing leads to double counting in collateral ratios and positions collateralized entirely with kerosine

Users can get their Kerosene stuck until TVL becomes greater than Dyad's supply

User can get their Kerosene stuck because of an invalid check on withdraw

Unable to withdraw Kerosene from `vaultmanagerv2::withdraw` as it expects a `vault.oracle()` method which is missing in Kerosene vaults

Attacker Can Frontruns User's Withdrawals To Make Them Reverts Without Costs

Incorrect deployment / missing contract will break functionality

Unbond_instant removes incorrect amount of shares

Re-adding assets to the omnipool can cause a problem with the oracle

The userGaugeProfitIndex is not set correctly, allowing an attacker to receive rewards without waiting

Users staking via the `SurplusGuildMinter` can be immediately slashed when staking into a gauge that had previously incurred a loss

Wrong ProfitManager in GuildToken, will always revert for other types of gauges leading to bad debt

`totalBorrowedCredit` can revert, breaking gauges.

Incorrect calculations in debtCeiling

LendingTerm::debtCeiling() can return wrong debt as the min() is evaluated incorrectly

The price of rsEHT could be manipulated by the first staker

try-catch does not store the state when it is reverted

`GMXVault` can be blocked by a malicious actor

User can revert processWithdraw

Incorrect state transition may cause vault in stuck

Token injection leads to unintended behavior of vault

Users can avoid liquidation while being under the primary liquidation ratio if on the last short record

User's can loose collateral when exiting a short

Event in secondaryLiquidation could be misused to show false liquidations

Malicious/Compromised organiser can reclaw all funds, stealing work from supporters

Lack of checking the existence of the Proxy contract

Centralization Risk for trusted organizers

Insufficient validation leads to locking up prize tokens forever

Anyone can burn **DecentralizedStableCoin** tokens with `burnFrom` function

Lack of events for critical actions

`++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

Spelling errors

Prefer array assignment over pushing elements in for-loops