LendeXe Finance security record

The visibility of the function `transfer()` is public, which allows anyone to transfer tokens from the `from` address to the `to` address. The visibility of the function `approve()` is public, which allows anyone to set allowance of `spender` over the `owner's` token. The visibility of the function `spendAllowance()` is public, which allows anyone to update the `owner's` allowance for `spender` based on the spent `amount`.

In the history of the compound protocol, the calculation of the Comp rewards becomes incorrect after proposal 062（`Split COMP rewards distribution and bug fixes`） is executed. In response to this problem, the function `fixBadAccruals()` has been temporarily added in proposal 065(`Correct Over-Accrued COMP`) and removed later. The function `fixBadAccruals()` is a centralized function. It will update the users' unclaimed Comp rewards to decrease the incorrect rewards, and record the COMP debt in the variable `compReceivable` for the users whose unclaimed Comp rewards are not enough to decrease. The function `fixBadAccruals()` is only used to handle the error caused by this upgrade migration in the Compound protocol, which is useless in the newly deployed Compound forks. Refer to: - https://compound.finance/governance/proposals/62 - https://compound.finance/governance/proposals/65

The function `_setSwapHelperAddress()` is `external` and can be called by anyone as long as the contract is deployed.

The function `_setSwapRouter()` is `external` and can be called by anyone as long as the contract is deployed.

The input variable `nftAmount` is not validated in the function `supply()`, so the user can input the arbitrary `nft` amount to mint the maximum allowed XSD tokens.

The user can provide assets by calling the function provide() in the contract `UltimateLoan` and then directly call the function `burn()`/`burnShares()` in the contract `XSDStabilizer` to perform an arbitrage attack. The steps can be as follows, 1. call function `supply()` to lock xLEXE tokens as collateral, then receive XSD tokens, which is 150% of locked XLEXE tokens in value. 2. call the function `burn()`/`burnShares()` in the contract `XSDStabilizer` instead of the function `repay()` to burn XSD tokens will eventually receive 50% of the locked XLEXE tokens value in profit. ```solidity=240 (uint256 mintAmount, ) = stabilizer.mintShares(xsdAmount, supplyTokens); //UL will gain double the xsd amount that was set as input because it locks an equal amount of LEXE uint256 portionOfOwnerMint = mul_(mintAmount, Exp({mantissa: 0.75e18})); ``` In an extreme case, the user can give up repaying the loan, and receive 50% of the locked `xLEXE` tokens value in profit.

The contract deployer can input himself as the admin to pass the validation. ```solidity=349 constructor( XSDStabilizer XSDStabilizer_, address lexeVault_, address payable admin_, Lexe lexe_, XToken xLEXE_, XToken[] memory supplyTokens_, uint256[] memory supplyTokenShares_, XSDInterface xsd_, PriceOracle oracle_ ) public { // Creator of the contract is admin during initialization admin = msg.sender; require(msg.sender == admin, "only admin may initialize the UL"); // Set initial exchange rate ULPercentage = uint256(50); stabilizer = XSDStabilizer(XSDStabilizer_); ... ```

There is no validation to ensure the `lockEndBlocks[i]` is larger than the `_lockingPeriodEndBlock`.

There's no sanity check to validate if a `lockTime` is existing. If the `lockTime` does not exist, the user who locked assets will not get the rewards.

The user has locked their `xLEXE` tokens in the contract `UltimateLoanLock` for at least 3 months, with the expectation of minting `XDS` tokens through the function `supply()` in the contract `UltimateLoan` at the end of the lock period. However, if XDS's market share exceeds a certain threshold after three months, they may be unable to mint additional `XDS` tokens. - Contract `XSDStabilizer.sol` ```solidity=242 require( getHypotheticalLendexeShare(amount) < 0.6e18, "Market share of XSD is too high!" );