LendrR security record

In the contract `BorrowerWrappersScript` it approves `LNDR` before staking. However, in the contract `LQTYStaking`, `lqtyToken.sendToLQTYStaking()` is called, which does not consume or require any approval.

In your documentation you state: "A secondary redundancy oracle does not exist for our custom inflation index yet. As such we have hard-coded safeties in place to limit the rate at which the target peg can move. We will be searching for a backup oracle to create redundancy, similar to how we use both Chainlink and Binance oracles for price data. We will renounce ownership of the inflationFeed contract when redundancy is in place, until then it will be owned by the Lendr Network multisig requiring multiple signatures to control (2/3)." We would like more information on how the backup oracle will be implemented as the `InflationFeed` contract address cannot be changed after the contracts are initialized and the `InflationFeed` contract does not have any logic allowing for another oracle to be implemented. Is it intended to create a custom chainlink oracle that has this functionality and will return a value based on two separate oracles? In addition, please inform us of how you will handle the situation when the oracle breaks and is no longer returning an accurate price.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

If the `newPeg` rises or falls by more than 2% for the contract `InflationFeed` or 1% for `InflationFeedV2`, then the `targetPeg` will not be updated. While this helps ensure unreasonable variance is not reflected by the peg, it makes it possible for the peg to not be updated for an extended period of time if the `newPeg` continues to be outside the acceptable variance. If the new peg remains outside the acceptable variance for a long enough period, it would be desired to adjust to target peg gradually so that it accurately accounts for inflation.

In the contract `PriceFeed`, the function `fetchPrice()` makes the external call `inflationFeed.getTargetPeg()`, which returns the stored value of `targetPeg`. However, the return value is never used and this call will not update the `targetPeg` as the comment states.

The comment for `MAX_PEG_VARIENCE` states that "This would prevent the peg from moving more than 1% in either direction". However, with the current value it would prevent it from moving more than 2% in either direction. In the contract `LQTYToken`, there are many lines of code commented out related to functionality that will not be used. We recommend removing the commented out lines before deployment to improve the readability of the codebase. In the contract `PriceFeed`, it states "to be connected to Chainlink's live ETH:USD aggregator", when it should be their BNB:USD aggregator. Throughout the codebase `LUSD` is used in place of `USDL` and `LQTY` is used in place of `LNDR`. While this is likely intended to reduce the amount of changes need to the codebase, we recommend adding a disclaimer that throughout the codebase `LUSD` refers to `USDL` and that `LQTY` refers to `LNDR`.

The variable `ETHUSD_TELLOR_REQ_ID` is not used in the `PriceFeed` contract. It can be removed to decrease the size of the deployed bytecode and save gas.

In the contracts `TroveManager` and `InflationFeed` the magic number `1e18` is used.