Blueberry Base GLP Compounder

One or more parameters with `memory` data location are never modified in their functions and those functions are never called internally within the contract. Thus, their data location can be changed to `calldata` to avoid the gas consumption copying from calldata to memory. ```solidity=40 function initialize(address _asset, string memory _name, string memory _symbol, address _weth) initializer public { ``` `initialize` has memory location parameters: `_name`, `_symbol` that are never modified afterwards.

The function `setShouldCompound()` allows for repeated setting of the same value for `shouldCompound` and lacks a check to ensure that the function is run only for cases where the value is being changed.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. The addresses `_asset` and `_weth` are not zero-checked before being used.

Due to the inheritance of the ERC4626 implementation, the GLP vault contract is vulnerable to an inflation attack. Malicious actors can exploit this vulnerability to steal initial deposits made into the pools, leading to substantial losses for unsuspecting investors. This issue is also highlighted in the ERC4626 contract: ```text * CAUTION: When the vault is empty or nearly empty, deposits are at high risk of being stolen through frontrunning with * a "donation" to the vault that inflates the price of a share. This is variously known as a donation or inflation * attack and is essentially a problem of slippage. Vault deployers can protect against this attack by making an initial * deposit of a non-trivial amount of the asset, such that price manipulation becomes infeasible. Withdrawals may * similarly be affected by slippage. Users can protect against this attack as well unexpected slippage in general by * verifying the amount received is as expected, using a wrapper that performs these checks such as * https://github.com/fei-protocol/ERC4626#erc4626router-and-base[ERC4626Router]. ```

The depositing and withdrawing operation may be affected by slippage. Users can protect against this unexpected slippage in general by verifying the amount received is as expected.

Users can deposit their `sGLP` tokens into the `GLPVault` contract and utilize the `compound()` function to reinvest rewards on an as-needed basis. The contract also allows users to withdraw their assets at any time. However, it's important to note that the `_compound()` operation will not be triggered automatically when a user withdraws their assets. If the user fails to manually call the `compound()` function before withdrawing the assets, they may end up losing some rewards in the form of sGLP tokens.

The following variable is declared but not used in the code. ```solidity=25 uint public lastCompoundTimestamp; // Unused storage slot from previous implementation uint public minimumCompoundInterval; // Unused storage slot from previous implementation ```

If the `shouldCompound` is set as `false`, the contract will not trigger the re-staking operation. Therefore, the users' share may be incorrectly updated upon calling `deposit` and `mint`. ```solidity=102 function deposit(uint256 assets, address receiver) public override whenNotPaused returns (uint256) { if (shouldCompound) { _compound(); } return super.deposit(assets, receiver); } function mint(uint256 shares, address receiver) public override whenNotPaused returns (uint256) { if (shouldCompound) { _compound(); } return super.mint(shares, receiver); } ``` Additionally, if the `shouldCompound` is set as `false`, it could lead to a potential flashloan attack, leading to the reward of being stolen.