`deleverageAccount` can be used by an address to enter a vault that would otherwise be restricted by the `requireValidAccount` check in `enterVault`
`deleverageAccount` can be used by an address to enter a vault that would otherwise be restricted by the `requireValidAccount` check in `enterVault`\\nWhen `enterVault` in `VaultAccountAction.sol` is called, the first function that is called is `requireValidAccount`. This function checks to ensure that the passed-in `account` parameter is not a system-level `account` address:\\n```\\nrequire(account != Constants.RESERVE); // Reserve address is address(0)\\nrequire(account != address(this));\\n(\\n    uint256 isNToken,\\n    /* incentiveAnnualEmissionRate */,\\n    /* lastInitializedTime */,\\n    /* assetArrayLength */,\\n    /* parameters */\\n) = nTokenHandler.getNTokenContext(account);\\nrequire(isNToken == 0);\\n```\\n\\nWith the above checks, `requireValidAccount` ensures that any Notional system-level account cannot enter a vault. However, `deleverageAccount` in `VaultAccountAction.sol` allows liquidators to transfer vault shares from a liquidated account into their own account. In the case that a liquidator is not already entered into a vault, then `deleverageAccount` will instantiate a vault account for them (using _transferLiquidatorProfits) before depositing the liquidated account's vault shares into the newly-instantiated account. This effectively circumvents the `requireValidAccount` check in `enterVault`.
Consider updating the `require` statement in `_transferLiquidatorProfits` to the following:\\n```\\nrequire(liquidator.maturity == maturity, "Vault Shares Mismatch"); // dev: has vault shares\\n```\\n\\nRemoving the option of allowing addresses that do not have a maturity in the respective vault to receive shares and therefore implicitly enter a vault prevents Notional system accounts from being able to enter into vaults.
Any address that would otherwise be restricted from entering vaults via the `requireValidAccount` check would be able to circumvent that function using `deleverageAccount`. I assume these system-level accounts are restricted from entering vaults as they have access to internal Notional state and are used across the protocol, so having them be able to enter vaults could negatively impact Notional.\\nAssuming that all the relevant Notional system accounts are smart contracts that do not allow arbitrary calls, then having any of the system accounts themselves trigger this issue is infeasible. However, as a result of another issue it is possible for a vault to force an arbitrary address to deleverage accounts, which could be used to force a Notional system account to enter into a vault.
```\\nrequire(account != Constants.RESERVE); // Reserve address is address(0)\\nrequire(account != address(this));\\n(\\n    uint256 isNToken,\\n    /* incentiveAnnualEmissionRate */,\\n    /* lastInitializedTime */,\\n    /* assetArrayLength */,\\n    /* parameters */\\n) = nTokenHandler.getNTokenContext(account);\\nrequire(isNToken == 0);\\n```\\n