After Macro audit, there was a finding identifying that the depsitCap was ineffective due to constructor effectively defining it as a type(uint256).max.
Further, during internal discussions it was determined that we were using this cap redundant to the idea of pausing deposits for the vault however defined at a certain threshold. Regardless, the cap for vaults that interact with lending markets makes with existing caps will result in a reverted transaction.
In addition, the depositCap was also introducing complexity and overall removing it will simplify the vault logic overall.
If a "virtual" deposit cap is desired, the governing entity or admin owner of the vault through a timelock can specifically pause deposit of the vault.
TLDR:
This issue should remove the associated logic that handles the depositCap parameter from the BaseVault.sol contract and all contracts that inherit from it.
After Macro audit, there was a finding identifying that the depsitCap was ineffective due to constructor effectively defining it as a
type(uint256).max. Further, during internal discussions it was determined that we were using this cap redundant to the idea of pausing deposits for the vault however defined at a certain threshold. Regardless, the cap for vaults that interact with lending markets makes with existing caps will result in a reverted transaction. In addition, the depositCap was also introducing complexity and overall removing it will simplify the vault logic overall. If a "virtual" deposit cap is desired, the governing entity or admin owner of the vault through a timelock can specifically pause deposit of the vault.TLDR: This issue should remove the associated logic that handles the
depositCapparameter from the BaseVault.sol contract and all contracts that inherit from it.