Token Liquidity Foundation security record

In the contract `ERC3643Liquid`, the role `_owner` has authority over the following functions: - `initialize()` to initialize the `ERC3643Liquid` token contract. - `finalize()` to prevent changes to initialization parameters and active token. - `enableBridging()` to update the state of `bridgingEnabled`. - `active()` to set the state of `isActive` as true. - `allowPreactive()` to set the `allowedPreactive` state for the input `account`. - `approveBridgeMintBurn()` to approve mint/burn limits for bridging. - `transferExternalTokens()` to transfer tokens sent to the contract address. - `resetCounters()` to reset the counter variables. - `setNetLiqueficationLimit()` to set the value of `netLiquifiedByWalletLimit`. - `setSolidTokenAddress()` to change the solid token address. In addition, approved bridges have authority over the following functions: - `mint()` to mint liquid tokens to an address. - `burn()` to burn liquid tokens from an address. --- In the contract `ERC3643LiquidDeployer`, the role `_owner` has authority over the following functions: - `updateVaultAddress()` to update the vault address for the solid tokens. - `updateDeployers()` to update the allowed token deployers. - `transferExternalTokens()` to transfer tokens from the current contract to the address associated with the input `to`. In addition, approved deployers have authority over the following functions: - `deployLiquidTokenWithVault()` to deploy, initialize, and finalize a liquid token. - `deployLiquidToken()` to deploy and initialize a liquid token. --- In the contract `LiquidVault` the role `_owner` has authority over the following functions: - `updateDeployerAddress()` to change the liquid token deployer. - `deployAndRegisterToken()` to register new solid token and deploy corresponding liquid token. - `registerToken()` to register new token pair. - `updateFees()` to update fees. - `updateFeeReceiver()` to update the recipient of fees. - `transferTokenOwnership()` to transfer the ownership to a new address associated with `newOwner`. - `transferEth()` to transfer fees to the fee recipient. - `transferExtraTokens()` to transfer extra tokens from the vault to a recipient. In addition, the `liquidToken` role has authority over the following functions: - `solidifyTo()` to transfer solid tokens to a recipient. - `liquifyTo()` to check for fees and the contract's balance when a user liquifies. Any compromise a privileged account may allow the hacker to take advantage of this authority, modify the sensitive state variables and transfer tokens to a malicious account.

The `_owner` role has the authority to update the underlying `solidToken` in an `ERC3643Liquid` contract. Moreover, it possesses the capability to transfer any token aside from the solid token from the vault to its own account, without any restrictions. In particular, the `_owner` can acquire the balance of the old `solidToken`. This implies that if the `_owner` account is compromised, an attacker could exploit this privilege, change the `solidToken`, and transfer all the balances from the old `solidToken` to their own account. Another observation regarding this finding is that if a user witnesses a transaction involving the `updateSolidToken()` function in the mempool, they may take advantage of this situation by issuing a transaction to call `liquify()`, transferring all of their old `solidToken` to the `ERC3643Liquid` contract, and front-running the `_owner`'s transaction to ensure their own transaction is confirmed earlier. Furthermore, there is a concern that once the `_owner` updates the `solidToken`, users will no longer be able to call `liquify()` using their old `solidToken`. If a user has already converted some of their liquid tokens into solid tokens by calling `solidify()`, the tokens they receive will correspond to the old solid tokens, rendering them unusable in this contract. This situation poses a potential financial loss for the affected users.