Gondi

`Solmate/Owned` allows the owner of the inheriting contracts to call `transferOwnership()` to transfer the ownership to a new address. If an uncontrollable address is accidentally provided as the new owner address then the contract will no longer have an active owner, and functions with the `onlyOwner` modifier can no longer be executed.

In general, the protocol has minor limits on what the token can be supported to interact: * The protocol does not support token charging fees on transfers: Such tokens could cause all protocol interactions to revert, as the accounting relies on the complete flow of funds specified in transfers. * The protocol does not support rebaseable tokens: the `UserVault`and the `AuctionLoanLiquidator` contract maintain the accounting of token balances in state variables. Tokens with elastic supply (also known as rebasing tokens) and tokens with dishonest implementation would not be compatible with the logic intended by this contract. * Even though reentrancy guards are used within the protocol, we would strongly discourage the usage of any ERC777 token or any other ERC20 with hooks on transfers.

Loans can be refinanced at any moment by any lender. If a borrower defaults on the loan, the NFT would get automatically transferred to the lender (if there is a single lender). Since there is also no constraint to refinancing besides making the loan better for the borrower, lenders might front-run each other for full refinance requests at the end of the loan duration to get the NFT. As it is fairly unlikely that a loan will be paid back in one of the last blocks, there is no downside for lenders to engage in such behaviour, if the NFT is worth more than the principal. Given that the loan would have a very small duration left, a refinance with e.g. the minimum possible APR of 0.01% of would not leave the new lender's funds ineffectively idle for long, yet make follow-up refinances impossible, locking the NFT claim to the lender in case of loan default.

Certain contracts have state variables, e.g. `owner`, which provide certain addresses with privileged roles. Such roles may pose a risk to end-users. For a detailed list of roles per contract see the following list: The owner of the `MultiSourceLoan` contract has access to: 1. `setDelegateRegistry()` to update the delegate registry 2. `setMaxSources()` to update the total number of sources a loan's principal can be partitioned in. 3. `updateRefinanceInterestFraction()` to update the percentual share of how much of the delta of a refinanced source the original lender is entitled to in case of loan repayment and renegotiations. 4. `setFlashActionContract()` to update the address that a borrower can execute flash loans with when their asset is locked as collateral. 5. Via inheritance of the abstract `WithCallbacks` contract, the `MultiSourceLoan` contract furthermore has access to:<br/> a) `addWhitelistedCallbackContract()` and `removeWhitelistedCallbackContract()` to maintain the list of whitelisted callback contract instances that can reenter after the execution of callback hooks. 7. Via inheritance of the abstract `BaseLoan` contract, the `MultiSourceLoan` contract furthermore has access to:<br/> b) `updateProtocolFee()` and `setProtocolFee()`, offering a two-step update mechanism to overwrite the protocol fee deducted at various places in the protocol.<br/> c) `updateLiquidationContract()` to update the contract to use for liquidations. Overwriting this contract with incorrect values could cause the loss of all collateral of defaulted loans.<br/> d) `updateLiquidationAuctionDuration()` to update the base duration of the auction outside of the quiet-ending mechanic. <br/><br/> The owner of the `AuctionLoanLiquidator` contract has access to: 1. `addLoanContract()` and `removeLoanContract()` that maintains a list of approved loan contracts that this contract can perform liquidations for. 2. `updateTriggerFee()`, which enables the liquidator to specify the fees transferred to the initiators and finalizers of the liquidation process, with an upper bound of 0.5% for both. <br/><br/> The owner of the `AddressManager` contract has access to: 1. `add()`, `addtoWhiteList()`, `removeFromWhitelist()`, which maintains a list of whitelisted addresses. It is leveraged to maintain a whitelist of ERC20 tokens approved for principal/payments and a whitelist of ERC721 token addresses approved as collateral. The `Leverage` contract also maintains a list of the approved external marketplaces that can be used in loans emitted together with hooks. <br/><br/> The owner of the `Leverage` contract has access to: 1. `updateMultiSourceLoanAddressFirst()` and `finalUpdateMultiSourceLoanAddress()`, offering a two-step update mechanism to overwrite the address able to access the hook functions. 2. `updateSeaportAddressFirst()` and `finalUpdateSeaportAddress()`, offering a two-step update mechanism to update the `_seaport` address that can be used in external hooks.

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.8.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked".