A user can steal an already transfered and bridged reSDL lock because of approval

A user can lose funds in `sdlPoolSecondary` if tries to add more sdl tokens to a lock that has been queued to be completely withdrawn

Audit Report for SDLPool.sol - Scalability Concern

Updates from the `secondary pool` to the `primary pool` may not be sent because there are `no rewards` for the secondary pool

The `Token::updateFounders()` func does not remove the previous founders, which leads to them being able to claim tokens from the DAO

The `QVSimpleStrategy.maxVoiceCreditsPerAllocator` can be evaded by the allocator causing that he can allocate infinite credits to the same recipient

Malicious registrant can front-run `RFPSimpleStrategy._allocate()` in order to change the `proposalBid` and get a bigger payout in the distribution

The `RFPSimpleStrategy._registerRecipient()` does not work when the strategy was created using the `useRegistryAnchor=true` causing that nobody can register to the pool

Error in counting the `allocator.voiceCreditsCastToRecipient` causing the `recipient` to have more votes and get the majority of the pool

Pool's strategies does not support `fee on transfer` tokens causing an error in the counting system

User can create small position after exit with bid

Primary short liquidation can not be completed in the last hour of the liquidation timeline

Malicious trader can intentionally obtain `dittoMatchedShares` in some edges cases

Lender can block loan repayments using malicious `Callback` contract causing the collateral lost

The `rollLoan()` function must be called only by the borrower

Malicious lender can make the borrower to pay non-agreed interests via frontrunning attack

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

Signature missing nonce & expiration deadline

Centralization Risk for trusted organizers

Organizers are not incentivized to deploy and distribute to winners causing that winners may not to be rewarded for a long time and force the protocol owner to manage the distribution

Sandwich attack to steal all ERC-20 tokens in the Fees contract

Borrower can use Refinance to cancel auctions so they can extend their loan indefinitely

During refinance() new Pool balance debt is subtracted twice

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

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

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

Fee on transfer tokens will cause users to lose funds

The `borrow` and `refinance` functions can be front-run by the pool lender leading to collateral being seized in the next block

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

Malicious lender can increment the loan interest using the auction process

An attacker can steal `native` token from the `LMPVaultRouterBase` contract due `LMPVaultRouterBase::deposit()` malfunction

`Destination` vault rewards will be lost if the `swap` action in the `LMPVault::withdraw()` get more assets than the anticipated

The `AbstractRewarder::queueNewRewards()` will transfer from the caller the incorrect rewards amount causing the liquidation process may be stuck and the vaults' rewarder not to receive rewards

Rewards will not be distributed to the vault's rewarder due a malfunction in `LiquidationRow::_performLiquidation()`

The `Vault.reduce_position()` function does not increment the account's margin `Vault.margin[account][debt_token]`

The `Vault._update_debt()` function should be executed before admin sets new interest rate via `Vault.set_variable_interest_parameters()`

The `Vault._to_usd_oracle_price()` function uses the same `ORACLE_FRESHNESS_THRESHOLD` for all token prices feeds which is incorrect

A malicious `vUSD` withdrawal receiver can cause a DOS in the `vUSD.processWithdrawals()` function

`Chainlink.latestRoundData()` may return stale results

Malicious actor can flood the `vUSD` withdrawals causing a single user to spend a lot of gas when processing their withdrawal via `MarginAccountHelper.withdrawFromInsuranceFund()` or `MarginAccountHelper.removeMarginInUSD()`

When the `JUSDBank.withdraw()` is to another internal account the `ReserveInfo.isDepositAllowed` is not validated

Malicious lender can block borrower repayment causing the borrower default

Malicious lender can assign his own commitment to another victim lender

Malicious borrower can block liquidations causing the lender to receive neither the settlement amount nor the collateral

If the loan is into default, an attacker can force to the lender to receive the collateral instead the settlement amount

The ```DepositManagerV1.sol::fundBountyToken()``` must accept only whitelisted tokens.

User claim is compromised if the deposited NFT is refunded by the funder.

The first assigned winner can close the competition via ```ClaimManagerV1.sol::permissionedClaimTieredBounty()``` even when the other winners are not assigned yet.

```tokenAddresses``` count is not decreased on refunds causing a limitation in deposits.