xanoutas/solidity-security-findings huggingface dataset:
Deposits can take more assets than 
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L843
https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L475
https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L482
https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L524
https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L475


# Vulnerability details

## Impact

_depositAndMint(https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L843) function transfers the passed assets to itself, but then calls _mint(_receiver, _shares) which calls twabController.mint(_receiver, SafeCast.toUint96(_amount)), minting is executed on uint96(amount). Hence if the caller calls :
 - deposit: https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L475
 - mint: https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L482
 - depositWithPermit: https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L524
 - sponsor: https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L475

with assets more than type(uint96).max. So the user will lose assets as he deposits more but the minted amount does not correspond to the assets. 
## Proof of Concept
Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

## Tools Used
Manual review

## Recommended Mitigation Steps
Make sure that the PrizeVault transfers relevant amount to itself so the minting is executed based on the same amount of assets. The assets can be limited to type(uint96).max before proceeding with transfer and minting:
```
function _depositAndMint(address _caller, address _receiver, uint256 _assets, uint256 _shares) internal {
        ...
        _asset.safeTransferFrom(
            _caller,
            address(this),
            _assets > type(uint96).max ? type(uint96).max : _assets
        );
        ...
        _mint(_receiver, _shares);
        ...
}
```


## Assessed type

Token-Transfer
Incorrect Deduction of  '_yieldFeeBalance'  from  'yieldFeeBalance'.
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L617


# Vulnerability details

```solidity
function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
        if (_shares == 0) revert MintZeroShares();

        uint256 _yieldFeeBalance = yieldFeeBalance;
        if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

    /** here the deduction of _yieldFeeBalance from yieldFeeBalance is incorrect 
    because _yieldFeeBalance catch yieldFeeBalance value and yieldFeeBalance -= _yieldFeeBalance will set yieldFeeBalance to 		 
        zero
        yieldFeeBalance -= _yieldFeeBalance;
        */

        _mint(msg.sender, _shares);

        emit ClaimYieldFeeShares(msg.sender, _shares);
    }
```

**Description**:- In the line `yieldFeeBalance -= _yieldFeeBalance`; it appears that `_yieldFeeBalance` is mistakenly being deducted from `'yieldFeeBalance';`. This would result in deducting the entire balance of `yieldFeeBalance` instead of deducting _shares. as a result , the function would incorrectly reduce the entire balance instead of deducting specified  _shares.

**Mitigation Steps**:- Update the line `yieldFeeBalance-=_yieldFeeBalance;` to deduct _shares instead of `_yieldFeeBalance;` the corrected line would be.

```solidity
function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
        if (_shares == 0) revert MintZeroShares();

        uint256 _yieldFeeBalance = yieldFeeBalance;
        if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

        --yieldFeeBalance -= _yieldFeeBalance;
        ++yieldFeeBalance -= _shares; 

        _mint(msg.sender, _shares);

        emit ClaimYieldFeeShares(msg.sender, _shares);
    }
```

**Tools Used: Remix, Manual review**


## Assessed type

Other
yielVault might not be reachable or paused, which can lead to the prize vault not minting shares correctly
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L835-L877


# Vulnerability details

# yielVault might not be reachable or paused, which can lead to the prize vault not minting shares correctly

HIGH

## Issue

If the yieldVault is paused or unreachable, users can deposit and mint shares without the protocol minting shares.

This vulnerability is due to the fact that the `PrizeVault` contract does not check the output of the yield vault before minting shares. This can lead to the prize vault not minting shares correctly, as the yield vault may not be able to mint shares accurately.

This vulnerability is present in the `_depositAndMint`, ` _maxYieldVaultWithdraw()`, `_withdraw` and more function of the `PrizeVault` contract.

[https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L835-L877](https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L835-L877)

```js
        function _depositAndMint(address _caller, address _receiver, uint256 _assets, uint256 _shares) internal {
            if (_shares == 0) revert MintZeroShares();
            if (_assets == 0) revert DepositZeroAssets();

            // If _asset is ERC777, `transferFrom` can trigger a reentrancy BEFORE the transfer happens through the
            // `tokensToSend` hook. On the other hand, the `tokenReceived` hook that is triggered after the transfer
            // calls the vault which is assumed to not be malicious.
            //
            // Conclusion: we need to do the transfer before we mint so that any reentrancy would happen before the
            // assets are transferred and before the shares are minted, which is a valid state.

            _asset.safeTransferFrom(
                _caller,
                address(this),
                _assets
            );

            // Previously accumulated dust is swept into the yield vault along with the deposit.
            uint256 _assetsWithDust = _asset.balanceOf(address(this));
            _asset.approve(address(yieldVault), _assetsWithDust);

            // The shares are calculated and then minted directly to mitigate rounding error loss.
            // ANSWER : Yield vault can be anything, it's choosen by the owner and deployer of the prizevault
            uint256 _yieldVaultShares = yieldVault.previewDeposit(_assetsWithDust);
            uint256 _assetsUsed = yieldVault.mint(_yieldVaultShares, address(this));
            if (_assetsUsed != _assetsWithDust) {
                _asset.approve(address(yieldVault), 0);
            }

            _mint(_receiver, _shares);

            if (totalAssets() < totalDebt()) revert LossyDeposit(totalAssets(), totalDebt());

            emit Deposit(_caller, _receiver, _assets, _shares);
        }
```

For example, some specific implementations
`YieldFeebalance` can be non-withdrawable in specific edge case
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L611


# Vulnerability details

## Impact
In scenario where totaldebt > totalasset. such as when where is loss of asset in the underlying yieldvault. The conversion from underlying token to prize vault shares changes from 1:1 with more prize vault share required to be exchanged for underlying token. In the function Implementation 
```
 function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
        if (_shares == 0) revert MintZeroShares();

        uint256 _yieldFeeBalance = yieldFeeBalance;

 >>>>       if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

        yieldFeeBalance -= _yieldFeeBalance;

        _mint(msg.sender, _shares);

        emit ClaimYieldFeeShares(msg.sender, _shares);
    }
```
the function takes in number of shares as parameter and also has a logic causing a revert when  `if (_shares > _yieldFeeBalance) revert` This assumes conversion rate will always be 1:1. The implication here is yield fee recipient will be force to convert just a portion of their Yield fee balance to avoid a revert. leaving behind the rest of the yeild fee balance.

also there is a poor implementation here `yieldFeeBalance -= _yieldFeeBalance;` causing the yeildfee recipient to loose all balance regardless of the number of shares he decides to mint loosing his entire fees either the tokens are minted or not

## Proof of Concept
https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L611

## Tools Used
manual

## Recommended Mitigation Steps
```
++  function claimYieldFeeShares(uint256 _Yieldfeebalancetowithdraw) external onlyYieldFeeRecipient {
        if (_shares == 0) revert MintZeroShares();

        uint256 _yieldFeeBalance = yieldFeeBalance;
   +    uint256 Yieldfeeshare = convertToshare(_Yieldfeebalancetowithdraw)
   +     yieldFeeBalance -= _Yieldfeebalancetowithdraw

   +     _mint(msg.sender, Yieldfeeshare);

        emit ClaimYieldFeeShares(msg.sender,  Yieldfeeshare);
    }

```








## Assessed type

Other
Prize Vault can overinflate contributions to the Prize Pool
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L703-L714


# Vulnerability details

## Impact
A malicious actor can deploy a vault, then set themselves as the owner of the vault. Once set as the owner of the vault, the malicious actor can set themselves as the liquidation pair. Next, they can continuously call `PrizeVault::verifyTokensIn()` without donating tokens to the prize pool. This will trick the prize pool into thinking that the vault has contributed to the prize pool, boosting the prize vault's chances of winning. Additionally, the malicious actor can then transfer the tokens that were supposed to be sent to the prize pool to themself via `PrizeVault::transferTokensOut()`.

## Proof of Concept
In `PrizeVaultFactory::deployVault()` it is observed that the deployer can set the `_owner` parameter:
```
function deployVault(
    string memory _name,
    string memory _symbol,
    IERC4626 _yieldVault,
    PrizePool _prizePool,
    address _claimer,
    address _yieldFeeRecipient,
    uint32 _yieldFeePercentage,
    address _owner
) external returns (PrizeVault) {
    // rest of code omitted for not being pertinent
}
```
Then in `PrizeVault::constructor()` we see the `_owner` paramarer is set to the owner of the smart contract:
```
constructor(
    string memory name_,
    string memory symbol_,
    IERC4626 yieldVault_,
    PrizePool prizePool_,
    address claimer_,
    address yieldFeeRecipient_,
    uint32 yieldFeePercentage_,
    uint256 yieldBuffer_,
    address owner_
) TwabERC20(name_, symbol_, prizePool_.twabController()) Claimable(prizePool_, claimer_) Ownable(owner_) {
    // rest of code omitted for not being pertinent
}
```
Now the owner of the prize vault is free to set themself as the liquidation pair, since `PrizeVault::setLiquidationPair()` is guarded by the `onlyOwner()` modifier:
```
function setLiquidationPair(address _liquidationPair) external onlyOwner {
    // rest of code omitted for not being pertinent
}
```
Finally, we see `PrizeVault::verifyTokensIn()` makes a call to prize pool updating the amount without any verification of the amount:
```
function verifyTokensIn(
    address _tokenIn,
    uint256 _amountIn,
    bytes calldata
) external onlyLiquidationPair {
    address _prizeToken = address(prizePool.prizeToken());
    if (_tokenIn != _prizeToken) {
        revert LiquidationTokenInNotPrizeToken(_tokenIn, _prizeToken);
    }

    prizePool.contributePrizeTokens(address(this), _amountIn);
}
```
`PrizePool::contributePrizeTokens()` has the following comment:
```
The tokens should have already been transferred to the prize pool.
```
As long as the malicious actor waits for another vault to contribute, they can then call `PrizeVault::verifyTokensIn()` to claim them for their own vault.

## Tools Used
Manual Analysis

## Recommended Mitigation Steps
Inside of `PrizeVault::transferTokensOut()` add a check that the tokens ar
Loss of Funds Due to Incorrect Deduction in `claimYieldFeeShares` Function
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/main/pt-v5-vault/src/PrizeVault.sol#L611-L622


# Vulnerability details

## Issue Description

The `claimYieldFeeShares` function in the contract is responsible for allowing the yield fee recipient to claim their shares of the yield fee. However, a critical issue has been identified in the deduction logic within the function:

```solidity
function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
    if (_shares == 0) revert MintZeroShares();

    uint256 _yieldFeeBalance = yieldFeeBalance;
    if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

    //@audit will decrease all fee balance regardless of amount of shares claimed
    yieldFeeBalance -= _yieldFeeBalance;

    _mint(msg.sender, _shares);

    emit ClaimYieldFeeShares(msg.sender, _shares);
}
```

As it can be seen the function decrease the yield fee balance (`yieldFeeBalance`) not based on the `_shares` parameter provided to the function, but instead the entire balance (`_yieldFeeBalance`) is deducted, which can result in a loss of funds for the fee recipient because the remaining yield shares (`yieldFeeBalance - _shares`) will be removed and the recipient will never be able to mint them again.

## Impact

The incorrect deduction logic in the `claimYieldFeeShares` function can lead to a significant loss of funds for the yield fee recipient.

## Tools Used

Manual review, VS Code

## Recommended Mitigation

Review and correct the deduction logic within the `claimYieldFeeShares` function to ensure that only the appropriate amount of yield fee is deducted based on the `_shares` parameter provided.

```diff
function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
    if (_shares == 0) revert MintZeroShares();

    uint256 _yieldFeeBalance = yieldFeeBalance;
    if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

--  yieldFeeBalance -= _yieldFeeBalance;
++  yieldFeeBalance -= _shares;

    _mint(msg.sender, _shares);

    emit ClaimYieldFeeShares(msg.sender, _shares);
}
```



## Assessed type

Error
Incorrect handling of yieldFeeBalance in `PrizeVault.sol#claimYieldFeeBalance()` function. Because `yieldFeeBalance` was processed incorrectly in the  `PrizeVault.sol#claimYieldFeeBalance()` function, the `recipient` of the `yieldFee` suffers a loss.
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/main/pt-v5-vault/src/PrizeVault.sol#L611-L622


# Vulnerability details

## Impact
The `recipient` of the `yieldfee` might suffer a loss of the yield fee.

## Proof of Concept
The `PrizeVault.sol#claimYieldFeeBalance()` function is as follows.

```solidity
    function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
        if (_shares == 0) revert MintZeroShares();

        uint256 _yieldFeeBalance = yieldFeeBalance;
        if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

617     yieldFeeBalance -= _yieldFeeBalance;

        _mint(msg.sender, _shares);

        emit ClaimYieldFeeShares(msg.sender, _shares);
    }
```

As observed in the code snippet on the right, in `L617`, `yieldFeeBalance` is initialized to 0 irrespective of the amount of shares to be minted to the yield fee recipient.
Therefore, the recipient of the yield fee loses the fee when `_shares < _yieldFeeBalance`.
## Tools Used
Manual Review
## Recommended Mitigation Steps
Modify the `PrizeVault.sol/claimYieldFeeBalance()` function as follows.

```solidity
    function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
        if (_shares == 0) revert MintZeroShares();

        uint256 _yieldFeeBalance = yieldFeeBalance;
        if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

--      yieldFeeBalance -= _yieldFeeBalance;
++      yieldFeeBalance -= _shares;

        _mint(msg.sender, _shares);

        emit ClaimYieldFeeShares(msg.sender, _shares);
    }
```


## Assessed type

Other
The sponsored amount can be revoked by prize vault owner to deceive users
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L552-L565


# Vulnerability details

## Impact
When `sponsor` function is called, it seems that the delegate balance has been burned. It's typically called by the prize vault owner to promote a campaign and attract more users to use the vault. However, this design is flawed, as the vault owner can easily revoke the sponsorship, deceiving users to use the vault.

## Proof of Concept
According to the sponsor, `Sponsor is intended as another option for prize vault promotion. If an org or prize vault creator wants to juice up their user's chance of winning, they could sponsor it. Doing this will increase the odds of winnings for the vault users. In other words, it's typically called by the prize vault owner to promote a campaign and attract more users to use the vault`.

```solidity
    function sponsor(uint256 _assets) external returns (uint256) {
        address _owner = msg.sender;

        uint256 _shares = previewDeposit(_assets);
        _depositAndMint(_owner, _owner, _assets, _shares);

        if (twabController.delegateOf(address(this), _owner) != SPONSORSHIP_ADDRESS) {
            twabController.sponsor(_owner);
        }

        emit Sponsor(_owner, _assets, _shares);

        return _shares;
    }
```

However, this design is flawed as the vault owner can easily revoke the sponsorship via interacting with `twabController::delegate` directly at any time, thereby deceiving users to use the vault.

The PoC is shown below:
```
    function testSponsor_revoke() public {
        underlyingAsset.mint(address(this), 100);
        underlyingAsset.approve(address(vault), 100);
        vault.deposit(100, address(this));
        // sponsor the vault
        twabController.delegate(address(vault),address(2));
        uint256 assets = 4e18;
        underlyingAsset.mint(address(this), assets);
        underlyingAsset.approve(address(vault), assets);
        vm.expectEmit();
        emit Sponsor(address(this), assets, assets); // 1:1
        uint256 shares = vault.sponsor(assets);
        emit log_named_uint("delegate before revoke",twabController.delegateBalanceOf(address(vault),address(2)));
        twabController.delegate(address(vault),address(2));
        emit log_named_uint("delegate after revoke",twabController.delegateBalanceOf(address(vault),address(2)));
    }
```

The log:

```solidity
[PASS] testSponsor_revoke() (gas: 558092)
Logs:
  delegate before revoke: 0
  delegate after revoke: 4000000000000000100
```

## Tools Used
Foundry

## Recommended Mitigation Steps
It's more like a design issue, so it's better to revise the design, or add restrictions on certain functions.


## Assessed type

Other
Incorrect yield fee calculation will charge more on transferring tokens out than expected
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/480d58b9e8611c13587f28811864aea138a0021a/pt-v5-vault/src/PrizeVault.sol#L675


# Vulnerability details

## Impact
The protocol has a fee mechanism which accumulates fees when  tokens are transferred out of the protocol. However the yield calculation is wrong and charges more fee than anticipated.

## Proof of Concept
At `FEE_PERCISION` = `1e9`
Assume `yieldFeePercentage_` is `1e8` or in other words 10% fee
Assume `_amountOut` is `1e18`

The fee should be equal to `1e18 / 10` or `1e17`.

However calculated by the current formula the result is `1.1111(1)e17`: 
`_yieldFee = (_amountOut * FEE_PRECISION) / (FEE_PRECISION - _yieldFeePercentage) - _amountOut;`

(1e18 * 1e9) / (1e9 - 1e8) - 1e18
1e27 / 10e8 - 1e18
1.1111111e+18 - 1e18
1.1111111e17

## Tools Used
Manual Review

## Recommended Mitigation Steps
In `PrizeVault::transferTokensOut` do the following change
```diff
...
        uint256 _availableYield = availableYieldBalance();
        uint32 _yieldFeePercentage = yieldFeePercentage;

        // Determine the proportional yield fee based on the amount being liquidated:
        uint256 _yieldFee;
        if (_yieldFeePercentage != 0) {
            // The yield fee is calculated as a portion of the total yield being consumed, such that
            // `total = amountOut + yieldFee` and `yieldFee / total = yieldFeePercentage`.
-            _yieldFee = (_amountOut * FEE_PRECISION) / (FEE_PRECISION - _yieldFeePercentage) - _amountOut;
+            _yieldFee = (_amountOut * _yieldFeePercentage) / FEE_PRECISION;
        }

        // Ensure total liquidation amount does not exceed the available yield balance:
        if (_amountOut + _yieldFee > _availableYield) {
            revert LiquidationExceedsAvailable(_amountOut + _yieldFee, _availableYield);
        }
...
```


## Assessed type

Math
function claimYieldFeeShares doesnt update yieldFeeBalance accurately
Audit: 2024-03-pooltogether-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-pooltogether/blob/main/pt-v5-vault/src/PrizeVault.sol#L611-L622


# Vulnerability details

## Impact
YieldFeeRecipient could lose part of his yield fee

## Proof of Concept
https://github.com/code-423n4/2024-03-pooltogether/blob/main/pt-v5-vault/src/PrizeVault.sol#L611-L622
```Solidity
    function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
        if (_shares == 0) revert MintZeroShares();

        uint256 _yieldFeeBalance = yieldFeeBalance;
        if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

        yieldFeeBalance -= _yieldFeeBalance;

        _mint(msg.sender, _shares);

        emit ClaimYieldFeeShares(msg.sender, _shares);
    }
```

Lets say `yieldFeeBalance` is 100 and the yield fee recipient wants to claim 50. The `yieldFeeBalance` becomes 0 but the `msg.sender` gets minted only 50. The other 50 shares will be lost since the yield fee recipient won't be able to claim them.
## Tools Used
Manual Review
## Recommended Mitigation Steps
Change `yieldFeeBalance -= _yieldFeeBalance;` to `yieldFeeBalance -= _shares;`
```Solidity
    function claimYieldFeeShares(uint256 _shares) external onlyYieldFeeRecipient {
        if (_shares == 0) revert MintZeroShares();

        uint256 _yieldFeeBalance = yieldFeeBalance;
        if (_shares > _yieldFeeBalance) revert SharesExceedsYieldFeeBalance(_shares, _yieldFeeBalance);

        yieldFeeBalance -= _shares;

        _mint(msg.sender, _shares);

        emit ClaimYieldFeeShares(msg.sender, _shares);
    }
```



## Assessed type

Math