Staking Funds vault's LP holder cannot claim EIP1559 rewards after derivatives are minted for a new BLS public key that is not the first BLS public key registered for syndicate
Audit: 2022-11-stakehouse-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2022-11-stakehouse/blob/main/contracts/liquid-staking/StakingFundsVault.sol#L113-L143
https://github.com/code-423n4/2022-11-stakehouse/blob/main/contracts/liquid-staking/StakingFundsVault.sol#L62-L64
https://github.com/code-423n4/2022-11-stakehouse/blob/main/contracts/liquid-staking/SyndicateRewardsProcessor.sol#L76-L90
https://github.com/code-423n4/2022-11-stakehouse/blob/main/contracts/liquid-staking/SyndicateRewardsProcessor.sol#L93-L95
https://github.com/code-423n4/2022-11-stakehouse/blob/main/contracts/liquid-staking/StakingFundsVault.sol#L199-L233
https://github.com/code-423n4/2022-11-stakehouse/blob/main/contracts/liquid-staking/StakingFundsVault.sol#L360-L368


# Vulnerability details

## Impact
After the derivatives are minted for the first BLS public key registered for the syndicate, the Staking Funds vault's LP holder can claim the corresponding EIP1559 rewards received by the syndicate. However, after the derivatives are minted for a new BLS public key that is registered after the first one for the syndicate, the Staking Funds vault's LP holder is unable to claim any new EIP1559 rewards received by the syndicate.

When the `StakingFundsVault.depositETHForStaking` function is called for the first BLS public key, executing `updateAccumulatedETHPerLP()` would not update any states since `totalShares` is 0 at that moment. Yet, when `StakingFundsVault.depositETHForStaking` function is called for the new BLS public key, `totalShares` is already a positive number, and executing `updateAccumulatedETHPerLP()` would eventually execute `totalETHSeen = received`, where `received` is `address(this).balance + totalClaimed` returned by `totalRewardsReceived()`; at that moment, `address(this).balance` includes the ETH amount deposted for staking, which is not the rewards, so `totalETHSeen` also includes such ETH amount that is deposited for staking and not the rewards. Later, when the Staking Funds vault's LP holder calls the `StakingFundsVault.claimRewards` function, which further calls the `_claimFundsFromSyndicateForDistribution` function that also executes `updateAccumulatedETHPerLP()`, executing `received - totalETHSeen` can underflow and revert because `totalETHSeen` includes the ETH amount that was deposited for staking and not the rewards while `received` includes the rewards and not the amount deposited for staking, and the amount deposited for staking can be larger than the rewards. Since calling the `StakingFundsVault.claimRewards` function reverts, the Staking Funds vault's LP holder is unable to receive and essentially loses the EIP1559 rewards that she or he deserves.

https://github.com/code-423n4/2022-11-stakehouse/blob/main/contracts/liquid-staking/StakingFundsVault.sol#L113-L143
```solidity
    function depositETHForStaking(bytes calldata _blsPublicKeyOfKnot, uint256 _amount) public payable returns (uint256) {
        require(liquidStakingNetworkManager.isBLSPublicKeyBanned(_blsPublicKe