Token Liquidity Foundation security record

The function `setSolidTokenAddress()` in this context restricts access only to the `_owner` role, allowing them to modify the solid token address associated with the current liquid token. It is important to note that if the `_owner` changes the `solidToken` address without promptly updating the new address information in the `LiquidVault` contract, users' transactions may fail due to inconsistencies between the new record in this contract and the outdated `solidToken` address in the `LiquidVault` contract. In the `LiquidVault` contract, the `upgradeSolidToken()` function handles the update of the `solidToken` address. However, a concern arises regarding whether the `LiquidVault` contract has the `_owner` role necessary to call `liquidToken.setSolidTokenAddress()`. If the vault contract is meant to be the owner of the liquid token contract, then it should also be able to call the other functions in `LiquidVault` with the `onlyOwner` modifier.

The function `upgradeSolidToken()` is missing the update on `_fees[]` for the new solid token address. Additionally, the old solid token address, `originalSolidTokenAddress`, has not been set to zero in `_fees[]`. It is crucial to update the `_fees` mapping accordingly to avoid potential financial losses for the project.

The functions `_solidify()` and `_liquify()` include `msg.value` checks to ensure that `msg.value` is not less than the specified `fee`. However, if `msg.value` is greater than the `fee`, the excess Ether held in this contract will not be returned to the user's account. Consequently, the user will end up paying more than what is actually required.

A number of issues that arise by allowing the upgrade of a solid token. We assume the upgraded solid token's address is different from the old solid token's address. 1. The function `ERC3643LiquidDeployer.getLiquidTokenAddress()` will produce the incorrect address when used with the new solid token, which may confuse users who do not know that the new solid token is an upgraded one. 2. It is possible to deploy a new liquid token for an upgraded solid token, resulting in two liquid token contracts for one solid token.

It is crucial to validate the linked parameters to ensure they fall within the acceptable value ranges. ```solidity=163 _fees[solidTokenAddress] = Fees( _solidifyMinimumFeeGwei, _liquifyMinimumFeeGwei, _solidifyFeeRateGwei, _liquifyFeeRateGwei ); ``` ```solidity=197 _fees[solidToken] = Fees( _solidifyMinimumFeeGwei, _liquifyMinimumFeeGwei, _solidifyFeeRateGwei, _liquifyFeeRateGwei ); ```

The cited address input is missing a check that it is not `address(0)`. ```solidity=561 solidToken = IERC20(solidTokenAddress); ```

In the linked the `if` statement, `_decreaseAllowanceInternal()` always returns `true` regardless of the conditions. The `_decreaseAllowanceInternal()` function contains a `require` statement, which reverts the transaction if the statement is not satisfied. It does not reach the `return` statement, and the function never returns `false`. Therefore, the `_decreaseAllowanceInternal()` function will never explicitly return `false`, and the corresponding `if` branch in the code is never executed.