PortfolioToken::deposit is vulnerable to reverse LP sandwich attacks

First depositor can inflate the real amounts

Users can steal funds meant for refunds through `_doMixSwap`

Users can steal funds meant for refunds using a `decoded.targetZRC20`

Anyone can steal a refund from Solana

Zeta Chain contracts doesn't check source sender, which results in compromised instructions

`GatewayTransferNative::onCall` don't decrease `amount` when platform fee is deducted

Revert transaction from BTC will refund funds to a random address

`AccountEncoder::decompressAccounts` does not decode `isWritable` correctly

GatewayTransferNative::withdraw - The function is public and can be called by anyone

`_existsPairPool` has flawed design, which allows for an attacker to control

`_swapAndSendERC20Tokens` has no slippage protection

borrowing::liquidate - `lastEventTime` isn't updated after `calculateCumulativeRate` is called

`GlobalVariables` may be compromised, if there are concurrent in-flight messages

borrowing::depositTokens - `calculateCumulativeRate` is called after borrower has been added

borrowing::_withdraw - `lastEventTime` is updated before calling `calculateCumulativeRate`

Attackers can force the rewards to be stuck in the contract with malicious `x/tokenfactory` denoms

Logical error in `validate_fees_are_paid` can cause a DoS or allow users to bypass fees if `denom_creation_fee` includes multiple coins including `pool_creation_fee` and the user attempts to pay all fees using only `pool_creation_fee`

When a user single-side deposit into a pool, slippage protection is invalid

`withdraw_liquidity` lacks slippage protection

Single sided liquidity can't be used to lock LP tokens in the farm manager

Penalty fees can be shared among future farms or expired farms, risks of exploits

Unspent gas fees are always refunded to the `FeePayer()` which leads to incorrect refunds if the `FeeGranter()` paid for the fees

Potentially sensitive issue - disclosed privately

`xfeemarket` module is not wired up, resulting in non-working CLI commands, message server, genesis export

Positions, which are using assets with large heartbeat may accrue bad debt

Exploiter can always bypass `LIQUIDATION_DISCOUNT` and always seize all collateral

Exploiter can force user into unhealthy condition and liquidate him

SuperPoolFactory

Under certain circumstances bad debt will cause first depositor to lose funds

Pool::liquidate()

`SuperPool` has a `togglePause` function, but lack `whenNotPaused` modifier

Liquidators won't have incentive to repay positions under some conditions

`SuperPool#convertToShares` violates ERC4626

Use can grief `SuperPool#reallocate` for USDT because it doesn't use `forceApprove`

`WellUpgradeable` can be upgraded by anyone

Stable2LUT1::getRatiosFromPriceLiquidity - In extreme cases, `updateReserve` will start breaking

For extreme ratios getRatiosFromPriceSwap will return data for which is impossible to converge into a reserve

Malicious users can front-run host users safe management actions and add those safes as root for wrong org

Safe owner/s can prevent being removed from organization by indefinitely increasing their child array

Many cases `stEth::transferFrom` will transfer 1-2 less way, which would result in revert in consequent functions, because of not enough balance

Loss of funds when deposit flow uses `_ethTOeEth`, because deposit amount is not handled correctly

SophonFarming.sol

Malicious actor can use block stuffing to force staker into another cycle

Insufficient input validation on `SablierV2NFTDescriptor::safeAssetSymbol` allows an attacker to obtain stored XSS

The overflow in the `_calculateStreamedAmount` function can lead to unexpected results.

`SablierV2Lockup.sol` - The caller of withdraw and renounce can skip callbacks, by sending less gas

Use of CREATE method is suspicious of reorg attack

User looses StakeDao rewards, if he misses to call `claimCvgCvxRewards` for cycle

`CvxConvergenceLocker::sentTokens` doesn't protect from newly added reward tokens

`LenderCommitmentGroup_Smart.sol::burnSharesToWithdrawEarnings` steal previous depositors funds

TellerV2.sol

LenderCommitmentGroup_Smart.sol#liquidateDefaultedLoanWithIncentive()

LenderCommitmentGroup_Smart.sol

LenderCommitmentGroup_Smart.sol

LenderCommitmentGroup_Smart.sol#getCollateralRequiredForPrincipalAmount()

If `repayLoanCallback` address doesn't implement `repayLoanCallback` try/catch won't go into the catch and will revert the tx

Unchecked `transferFrom` value may lead to borrower falsy repaying loan

`LendderCommitmentGroup::_calculateCollateralTokensAmountEq` may be manipulated

LenderCommitmentGroup_Smart.sol#liquidateDefaultedLoanWithIncentive()

User can easily DoS `FlashRolloverLoan_G5` for USDT loans

__Ownable_init is missing in LenderCommitmentGroup_Smart and TellerV2

TellerV2.sol#lenderAcceptBid()

`FlashRolloverLoan_G5::_acceptCommitment` with `smartCommitmentAddress` uses wrong signature

LenderCommitmentGroup_Smart.sol#_generateTokenNameAndSymbol()

LenderCommitmentGroup_Smart.sol#__valueOfUnderlying()

Inability to perform partial liquidations allows huge positions to accrue bad debt in the system

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

`VaultManagerV2.sol::burnDyad` function is missing an `isDNftOwner` modifier, allowing a user to burn another user's minted DYAD

Attacker can frontrun to prevent vaults from being removed from the dNFT owner's position

No incentive to liquidate small positions could result in protocol going underwater

Value of kerosene can be manipulated to force liquidate users

Incorrect deployment / missing contract will break functionality

Owner of a position can prevent liquidation due to the 'onERC721Received' callback

Repayments and liquidations can be forced to revert by an attacker that repays miniscule amount of shares

PrincipalToken is not ERC-5095 compliant

All claimed rewards will be lost for the users using the account abstraction wallet

When `DecentBridgeExecutor.execute` fails, funds will be sent to a random address

Anyone can update the address of the Router in the DcntEth contract to any address they would like to set.

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

Users can use the protocol freely without paying any fees by calling the `DecentEthRouter::bridgeWithPayload()` function directly.

Attack to make ````CurveSubject```` to be a ````HoneyPot````

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

Unauthorized Access to setCurves Function

A subject creator within a single block can claim holder fees without holding due to unprotected reentrancy path

onBalanceChange causes previously unclaimed rewards to be cleared

If a user sets their curve token symbol as the default one plus the next token counter instance it will render the whole default naming functionality obsolete

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

Wrong Implementation of `LiquidationPool::empty` excludes holder with pending stakes when decreasing a position, resulting in exclusion from asset distribution

Removal of approved token from token manager can lead to unintended liquidation of vaults

Once EntropyRateBps is set too high, can lead to denial-of-service (DoS) due to an invalid ETH amount

Since art pieces' size is not limited, attacker may block AuctionHouse from creating and settling auctions

MaxHeap.sol: Already extracted tokenId may be extracted again.

It may be possible to DoS AuctionHouse by specifying malicious creators

No slippage protection for Market functions

Update in strategy will cause wrong issuance of shares

Adversary can block `claimAuction()` due to push-strategy to transfer assets to multiple bidders

`emergencyPause` does not check the state before running && can cause loss of funds for users

Invariant violation (funds could remain in the vault and a depositor could benefit from it)

Emergency Closed Vault Can Be Paused Then Resume

Consider erasing cache after completing deposit/withdraw/rebalance/compound operations

Collateral could be transferred to an address, which is not `SAFEHandler` managed by the `SAFEManager`

Updating `SafeManager` address in the `Vault721` will disable NFV minting

`ODSafeManager#allowSAFE()` cannot be executed either by the proxy contract or any other address.

Cached `DOMAIN_SEPARATOR` is incorrect for tranche tokens potentially breaking permit integrations

Malicious lender could DoS repay functionallity and always default loans.

Borrower has no choice whether to roll a loan. Lender could propose extreamly large interest rate, which will benefit the lender.

The same signature can be used in different `distribution` implementation causing that the caller who owns the signature, can distribute on unauthorized implementations

The `digest` calculation in `deployProxyAndDistributeBySignature` does not follow EIP-712 specification

Potential DOS due to Gas Exhaustion Due to Large Array Iteration in `_distribute` Function

Insufficient validation leads to locking up prize tokens forever

Tokens with less than 18 decimals allow for draining of funds

Using forged/fake lending pools to steal any loan opening for auction

Missing Events Emitting

Uncheck Arithmetic where overflow/underflow impossible

Chainlink oracle will return the wrong price if the aggregator hits `minAnswer`

All of the USD pair price feeds doesn't have 8 decimals

Improving the burnDsc() to allow users to mitigate their liquidation's impact

Zero address check for 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

No amountCollateral > balance check