Malicious recipient can unfairly get more funding in RFP strategies

Invalid poolAmount check will result in a failed distribution

Invalid qv_allocate allows allocators to give unlimited votes to a recipient

reviewRecipients allows for contradictory outcomes which might make recipient non-eligible for funding

Overlapping registration and fund allocation times might result in an unfair competition

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

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

If a winner is blacklisted on any of the tokens they can't receive their funds

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

Centralization Risk for trusted organizers

Using basis points for percentage is not precise enough for realistic use-cases

Tokens with less than 18 decimals allow for draining of funds

Lender contract can be drained by re-entrancy in `setPool`

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

Token spending by Uniswap router doesn't get approved

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

Fixed fee level is used when swap tokens on Uniswap

Unbounded loop in Lender.sol functions may revert.

Theft of collateral tokens with fewer than 18 decimals

staleCheckLatestRoundData() does not check the status of the Arbitrum sequencer in Chainlink feeds.

[H-01] Lack of emergency withdraw function when no arbiter is set

Use Openzeppelin Minimal Clones to Save a Lot of Gas

Use predefined address instead of `address(this)`