Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability lies in the `CurveAdapter._exactInSingle` function, which relies on the `CURVE_REG. The vulnerability lies in the `CurveAdapter._exactInSingle` function, which relies on the `CURVE_REGISTRY.find_pool_for_coins` function to identify the available pools for exchanging two coins. The `find_pool_for_coins` function returns the first pool in its list of available pools, which may not ne...

Vulnerable code:
```\nFile: CurveAdapter.sol\n\nfunction _exactInSingle(Trade memory trade)\n    internal\n    view\n    returns (address target, bytes memory executionCallData)\n{\n    address sellToken = _getTokenAddress(trade.sellToken);\n    address buyToken = _getTokenAddress(trade.buyToken);\n    ICurvePool pool = ICurvePool(\n        Deployments.CURVE_REGISTRY.find_pool_for_coins(sellToken, buyToken)\n    );\n\n    if (address(pool) == address(0)) {\n        revert InvalidTrade();\n    }\n\n    int128 i = -1;\n    int128 j = -1;\n    for (int128 c = 0; c < MAX_TOKENS; c++) {\n        address coin = pool.coins(uint256(int256(c)));\n        if (coin == sellToken) {\n            i = c;\n        }\n        if (coin == buyToken) {\n            j = c;\n        }\n        if (i > -1 && j > -1) {\n            break;\n        }\n    }\n\n    if (i == -1 || j == -1) {\n        revert InvalidTrade();\n    }\n\n    return (\n        address(pool),\n        abi.encodeWithSelector(\n            ICurvePool.exchange.selector,\n            i,\n            j,\n            trade.amount,\n            trade.limit\n        )\n    );\n}\n```\n```\n@view\n@external\ndef find_pool_for_coins(_from: address, _to: address, i: uint256 = 0) -> address:\n    """\n    Find an available pool for exchanging two coins\n    @param _from Address of coin to be sent\n    @param _to Address of coin to be received\n    @param i Index value. When multiple pools are available\n            this value is used to return then'th address.\n    @return Pool address\n    """\n    key: uint256 = bitwise_xor(convert(_from, uint256), convert(_to, uint256))\n    return self.markets[key][i]\n```
MEDIUM severity: The Lyra vault's collateral value estimation process is flawed due to the incorrect application of w. The Lyra vault's collateral value estimation process is flawed due to the incorrect application of withdrawal fees. The `priceCollateralToUSD()` function, located at `Vault_Lyra.sol#L77`, calculates the user's collateral value by subtracting the withdrawal fee from the token price. However, this app...

Vulnerable code:
```\nfunction priceCollateralToUSD(bytes32 _currencyKey, uint256 _amount) public view override returns (uint256) {\n    ILiquidityPoolAvalon LiquidityPool = ILiquidityPoolAvalon(collateralBook.liquidityPoolOf(_currencyKey));\n    uint256 tokenPrice = LiquidityPool.getTokenPrice();\n    uint256 withdrawalFee = _getWithdrawalFee(LiquidityPool);\n    uint256 USDValue = (_amount * tokenPrice) / LOAN_SCALE;\n    uint256 USDValueAfterFee = USDValue * (LOAN_SCALE - withdrawalFee) / LOAN_SCALE;\n    return USDValueAfterFee;\n}\n```\n```\nfunction _getTotalBurnableTokens()\n    internal\n    returns (\n        uint tokensBurnable,\n        uint tokenPriceWithFee,\n        bool stale\n    ) {\n    uint burnableLiquidity;\n    uint tokenPrice;\n    (tokenPrice, stale, burnableLiquidity) = _getTokenPriceAndStale();\n\n    if (optionMarket.getNumLiveBoards()!= 0) {\n        tokenPriceWithFee = tokenPrice.multiplyDecimal(DecimalMath.UNIT - lpParams.withdrawalFee);\n    } else {\n        tokenPriceWithFee = tokenPrice;\n    }\n\n    return (burnableLiquidity.divideDecimal(tokenPriceWithFee), tokenPriceWithFee, stale);\n}\n```
MEDIUM severity: The `TokenSaleProposalCreate::createTier` function allows a DAO Pool owner to create a new token sal. The `TokenSaleProposalCreate::createTier` function allows a DAO Pool owner to create a new token sale tier by transferring a specified amount of DAO tokens to the `TokenSaleProposal` contract. However, the current implementation fails to verify the token balances before and after the transfer, which...

Vulnerable code:
```\nfunction createTier(\n    mapping(uint256 => ITokenSaleProposal.Tier) storage tiers,\n    uint256 newTierId,\n    ITokenSaleProposal.TierInitParams memory _tierInitParams\n) external {\n    // rest of code.\n\n    tierInitParams.saleTokenAddress.call(\n        abi.encodeWithSelector(\n            IERC20.transferFrom.selector,\n            msg.sender,\n            address(this),\n            totalTokenProvided\n        )\n    );\n}\n```
MEDIUM severity: The vulnerability lies in the lack of a sufficient minimum withdrawal amount to prevent denial-of-se. The vulnerability lies in the lack of a sufficient minimum withdrawal amount to prevent denial-of-service (DoS) attacks on the VUSD contract. Specifically, the `_withdrawTo` function allows a malicious user to repeatedly call the withdrawal function with a minimum amount of 5 VUSD, effectively clogg...

Vulnerable code:
```\nfunction _withdrawTo(address to, uint amount) internal {\n    require(amount >= 5 * (10 ** 6), "min withdraw is 5 vusd");\n    burn(amount);\n    withdrawals.push(Withdrawal(to, amount * 1e12));\n```\n```\nuint public maxWithdrawalProcesses = 100;\n\nfunction withdrawalQueue() external view returns (Withdrawal[] memory queue) {\n    uint l = _min(withdrawals.length - start, maxWithdrawalProcesses);\n    queue = new Withdrawal[](l);\n\n    for (uint i = 0; i < l; i++) {\n        queue[i] = withdrawals[start + i];\n    }\n}\n```
MEDIUM severity: The `calculateNextDueDate` and `_canLiquidateLoan` functions in the TellerV2.sol contract exhibit in. The `calculateNextDueDate` and `_canLiquidateLoan` functions in the TellerV2.sol contract exhibit inconsistent time calculation methods, which can lead to unexpected and potentially harmful consequences for borrowers. The `calculateNextDueDate` function is responsible for determining the next repaym...

Vulnerable code:
```\nFile: TellerV2.sol\n\nfunction calculateNextDueDate(uint256 _bidId)\n    public\n    view\n    returns (uint32 dueDate_)\n{\n    Bid storage bid = bids[_bidId];\n    if (bids[_bidId].state!= BidState.ACCEPTED) return dueDate_;\n\n    uint32 lastRepaidTimestamp = lastRepaidTimestamp(_bidId);\n\n    if (bidPaymentCycleType[_bidId] == PaymentCycleType.Monthly) {\n        // Calculate the cycle number the last repayment was made\n        uint256 lastPaymentCycle = BPBDTL.diffMonths(\n            bid.loanDetails.acceptedTimestamp,\n            lastRepaidTimestamp\n        );\n\n        // Calculate the next due date\n        dueDate_ = bid.loanDetails.acceptedTimestamp\n            + (lastPaymentCycle * 30 days);\n    }\n}\n```\n```\nFile: TellerV2.sol\n\nfunction _canLiquidateLoan(uint256 _bidId, uint32 _liquidationDelay)\n    internal\n    view\n    returns (bool)\n{\n    Bid storage bid = bids[_bidId];\n\n    // Make sure loan cannot be liquidated if it is not active\n    if (bid.state!= BidState.ACCEPTED) {\n        return false;\n    }\n\n    if (bidDefaultDuration[_bidId] == 0) {\n        return false;\n    }\n\n    return (\n        uint32(block.timestamp) -\n        _liquidationDelay -\n        lastRepaidTimestamp(_bidId) >\n        bidDefaultDuration[_bidId]\n    );\n}\n```
MEDIUM severity: The `calculateSwap` function in the `withdrawalPoolById` contract, which is responsible for simulati. The `calculateSwap` function in the `withdrawalPoolById` contract, which is responsible for simulating arbitrage buybacks in the Dynamic Withdrawal Pool (DWP), utilizes the cumulative un-stake balance (`cumBal`) instead of the ETH debt when determining the arbitrage profit. This discrepancy can lead...

Vulnerable code:
```\nuint256 arb = \n    withdrawalPoolById(DATASTORE, poolId)\n   .calculateSwap(0, 1, cumBal);\n```
MEDIUM severity: The `_updateWithdrawalQueue` function is responsible for processing withdrawal requests from a queue. The `_updateWithdrawalQueue` function is responsible for processing withdrawal requests from a queue when new liquidity is added to the system. The function iterates through the withdrawal queue, checking if there are sufficient funds to fulfill each request. However, the function has a critical fla...

Vulnerable code:
```\nfunction _updateWithdrawalQueue() internal {\n    uint256 _availableLiquidity = totalLiquidity.sub(totalCoverTokens);\n    uint256 _countToRemoveFromQueue;\n\n    for (uint256 i = 0; i < withdrawalQueue.length; i++) {\n        uint256 _tokensToWithdraw = withdrawalsInfo[withdrawalQueue[i]].amount;\n        uint256 _amountInDai = _tokensToWithdraw.mul(getDAIToDAIxRatio()).div(PERCENTAGE_100);\n\n        if (balanceOf(withdrawalQueue[i]) < _tokensToWithdraw) {\n            _countToRemoveFromQueue++;\n            continue;\n        }\n\n        if (_availableLiquidity >= _amountInDai) {\n            _withdrawLiquidity(withdrawalQueue[i], _tokensToWithdraw);\n            _availableLiquidity = _availableLiquidity.sub(_amountInDai);\n            _countToRemoveFromQueue++;\n        } else {\n            break;\n        }\n    }\n\n    _removeFromQueue(_countToRemoveFromQueue);\n}\n```
MEDIUM severity: The `deposit` function in the smart contract specifies a hard-coded minimum deposit amount of 1e12 u. The `deposit` function in the smart contract specifies a hard-coded minimum deposit amount of 1e12 units of the base token, which is equivalent to 1 million USD in the case of USDC. This minimum amount is enforced by the `require` statement, which checks that the deposited amount is greater than or...

Vulnerable code:
```\nuint256 constant AMOUNT_PER_SHARE = 1e18;\n```\n```\nfunction deposit(\n    uint256 amount\n) external {\n    require(enabled, "Not enabled");\n    require(amount >= AMOUNT_PER_SHARE / 1000000, "Less than minimum");\n```
MEDIUM severity: The `ICHI` vault spell position size calculation is vulnerable to arbitrary size increase due to a f. The `ICHI` vault spell position size calculation is vulnerable to arbitrary size increase due to a flaw in the `curPosSize` calculation. This flaw allows for repeated deposits into an `ICHI` vault spell position, exceeding the intended maximum position size limit.\n\nThe `curPosSize` variable, which...

Vulnerable code:
```\ndiff --git a/test/spell/ichivault.spell.test.ts b/test/spell/ichivault.spell.test.ts\nindex 258d653..551a6eb 100644\n--- a/test/spell/ichivault.spell.test.ts\nb/test/spell/ichivault.spell.test.ts\n@@ -163,6 @@ describe('ICHI Angel Vaults Spell', () => {\n    afterTreasuryBalance.sub(beforeTreasuryBalance)\n       .to.be.equal(depositAmount.mul(50).div(10000))\n})\n\nit("should revert when exceeds max pos size due to increasing position", async () => {\n    await ichi.approve(bank.address, ethers.constants.MaxUint256);\n    await bank.execute(\n        0,\n        spell.address,\n        iface.encodeFunctionData("openPosition", [\n            0, ICHI, USDC, depositAmount.mul(4), borrowAmount.mul(6) // Borrow 1.800e6 USDC\n        ])\n    );\n    await expect(\n        bank.execute(\n            0,\n            spell.address,\n            iface.encodeFunctionData("openPosition", [\n                0, ICHI, USDC, depositAmount.mul(1), borrowAmount.mul(2) // Borrow 300e6 USDC\n            ])\n        )\n    ).to.be.revertedWith("EXCEED_MAX_POS_SIZE"); // 1_800e6 // 300e6 = 2_100e6 > 2_000e6 strategy max position size limit\n})\n\nit("should be able to return position risk ratio", async () => {\n    let risk = await bank.getPositionRisk(1);\n    console.log('Prev Position Risk', utils.formatUnits(risk, 2), '%');\n```\n```\nyarn hardhat test --grep "should revert when exceeds max pos size due to increasing position"\n```
MEDIUM severity: This vulnerability arises when the protocol's state is such that the long trader's profit exceeds th. This vulnerability arises when the protocol's state is such that the long trader's profit exceeds the LP's stable collateral total. This discrepancy occurs when the `_updateStableCollateralTotal` function is triggered, causing the `stableCollateralTotal` to become negative. As a result, the `collate...

Vulnerable code:
```\nFile: InvariantChecks.sol\n\nfunction _getCollateralNet(IFlatcoinVault vault) private view returns (uint256 netCollateral) {\n    uint256 collateralBalance = vault.collateral().balanceOf(address(vault));\n    uint256 trackedCollateral = vault.stableCollateralTotal() + vault.getGlobalPositions().marginDepositedTotal;\n\n    if (collateralBalance < trackedCollateral) {\n        revert FlatcoinErrors.InvariantViolation("collateralNet");\n    }\n\n    return collateralBalance - trackedCollateral;\n}\n```\n```\nprofitLossTotal = 51 ETH  # gain by long\n\nnewMarginDepositedTotal = marginDepositedTotal + marginDelta + profitLossTotal\nnewMarginDepositedTotal = 50 ETH + 0 + 51 ETH = 101 ETH\n\n_updateStableCollateralTotal(-51 ETH)\nnewStableCollateralTotal = stableCollateralTotal + _stableCollateralAdjustment\nnewStableCollateralTotal = 50 ETH + (-51 ETH) = -1 ETH\nstableCollateralTotal = (newStableCollateralTotal > 0)? newStableCollateralTotal : 0;\nstableCollateralTotal = 0\n```
MEDIUM severity: The capping mechanism for Panther token's transfer sizes, implemented in the `gulp` function, inadve. The capping mechanism for Panther token's transfer sizes, implemented in the `gulp` function, inadvertently leads to increased fees. The mechanism, which is designed to limit transfer sizes, inadvertently creates a scenario where tokens are taxed multiple times, resulting in increased fees.\n\nThe i...

Vulnerable code:
```\nfunction gulp(uint256 _minRewardAmount) external onlyEOAorWhitelist nonReentrant {\n    uint256 _pendingReward = _getPendingReward();\n    if (_pendingReward > 0) {\n        _withdraw(0);\n    }\n    uint256 __totalReward = Transfers._getBalance(rewardToken);\n    (uint256 _feeReward, uint256 _retainedReward) = _capFeeAmount(__totalReward.mul(performanceFee) / 1e18);\n    Transfers._pushFunds(rewardToken, buyback, _feeReward);\n\n    if (rewardToken!= routingToken) {\n        require(exchange!= address(0), "exchange not set");\n        uint256 _totalReward = Transfers._getBalance(rewardToken);\n        _totalReward = _capTransferAmount(rewardToken, _totalReward, _retainedReward);\n        Transfers._approveFunds(rewardToken, exchange, _totalReward);\n        IExchange(exchange).convertFundsFromInput(rewardToken, routingToken, _totalReward, 1);\n    }\n\n    if (routingToken!= reserveToken) {\n        require(exchange!= address(0), "exchange not set");\n        uint256 _totalRouting = Transfers._getBalance(routingToken);\n        _totalRouting = _capTransferAmount(routingToken, _totalRouting, _retainedReward);\n        Transfers._approveFunds(routingToken, exchange, _totalRouting);\n        IExchange(exchange).joinPoolFromInput(reserveToken, routingToken, _totalRouting, 1);\n    }\n\n    uint256 _totalBalance = Transfers._getBalance(reserveToken);\n    _totalBalance = _capTransferAmount(reserveToken, _totalBalance, _retainedReward);\n    require(_totalBalance >= _minRewardAmount, "high slippage");\n    _deposit(_totalBalance);\n}\n```\n```\n(uint256 _feeReward, uint256 _retainedReward) = _capFeeAmount(_totalReward.mul(performanceFee) / 1e18);\n```
MEDIUM severity: The vulnerability allows an attacker to steal a portion of the ETH rewards by exploiting the delayed. The vulnerability allows an attacker to steal a portion of the ETH rewards by exploiting the delayed withdrawal mechanism in the protocol. The attacker can mint a significant amount of LRTTokens by depositing an accepted asset, then claim the delayed withdrawals, and finally request a withdrawal for...

Vulnerable code:
```\nreceive() external payable {\n    (bool success,) = address(rewardDistributor()).call{value: msg.value}('');\n    require(success);\n}\n```\n```\nimport { IRioLRTWithdrawalQueue } from 'contracts/interfaces/IRioLRTWithdrawalQueue.sol';\nimport { IRioLRTOperatorRegistry } from 'contracts/interfaces/IRioLRTOperatorRegistry.sol';\nimport { CredentialsProofs, BeaconWithdrawal } from 'test/utils/beacon-chain/MockBeaconChain.sol';\n```\n```\nfunction test_stealRewards() public {\n    address alice = makeAddr("alice");\n    address bob = makeAddr("bob");\n    uint256 aliceInitialBalance = 40e18;\n    uint256 bobInitialBalance = 40e18;\n    deal(alice, aliceInitialBalance);\n    deal(bob, bobInitialBalance);\n    vm.prank(alice);\n    reETH.token.approve(address(reETH.coordinator), type(uint256).max);\n    vm.prank(bob);\n    reETH.token.approve(address(reETH.coordinator), type(uint256).max);\n\n    uint8 operatorId = addOperatorDelegator(reETH.operatorRegistry, address(reETH.rewardDistributor));\n    RioLRTOperatorDelegator operatorDelegator = RioLRTOperatorDelegator(payable(reETH.operatorRegistry.getOperatorDetails(operatorId).delegator));\n\n    vm.prank(alice);\n    reETH.coordinator.depositETH{value: aliceInitialBalance}();\n\n    vm.prank(EOA, EOA);\n    reETH.coordinator.rebalance(ETH_ADDRESS);\n\n    uint40[] memory validatorIndices = new uint40[](1);\n    IRioLRTOperatorRegistry.OperatorPublicDetails memory details = reETH.operatorRegistry.getOperatorDetails(operatorId);\n    bytes32 withdrawalCredentials = operatorDelegator.withdrawalCredentials();\n    beaconChain.setNextTimestamp(block.timestamp);\n    CredentialsProofs memory proofs;\n    (validatorIndices[0], proofs) = beaconChain.newValidator({\n        balanceWei: 40 ether,\n        withdrawalCreds: abi.encodePacked(withdrawalCredentials)\n    });\n\n    vm.prank(details.manager);\n    reETH.operatorRegistry.verifyWithdrawalCredentials(\n        operatorId,\n        proofs.oracleTimestamp,\n        proofs.stateRootProof,\n        proofs.validatorIndices,\n        proofs.validatorFieldsProofs,\n        proofs.validatorFields\n    );\n\n    verifyAndProcessWithdrawalsForValidatorIndexes(address(operatorDelegator), validatorIndices);\n\n    {\n        vm.startPrank(bob);\n        reETH.coordinator.depositETH{value: bobInitialBalance}();\n\n        uint256 TVLBefore = reETH.assetRegistry.getTVL();\n        delayedWithdrawalRouter.claimDelayedWithdrawals(address(operatorDelegator), 1);\n        uint256 TVLAfter = reETH.assetRegistry.getTVL();\n\n        assertEq(TVLAfter - TVLBefore, 7.2e18);\n\n        reETH.coordinator.requestWithdrawal(ETH_ADDRESS, reETH.token.balanceOf(bob\n```
MEDIUM severity: The vulnerability lies in the `DepositStableCoinToDealer` and `GeneralRepay` contracts, which are de. The vulnerability lies in the `DepositStableCoinToDealer` and `GeneralRepay` contracts, which are designed to facilitate token swaps and repayments between users. Specifically, the contracts utilize the `safeTransferFrom` function to transfer tokens from the user's account to the contract, and then...

Vulnerable code:
```\nIERC20(asset).safeTransferFrom(msg.sender, address(this), amount);\n(address approveTarget, address swapTarget, bytes memory data) = abi.decode(param, (address, address, bytes));\n\nif (asset == "USDT") {\n    IERC20(asset).approve(approveTarget, 0);\n    IERC20(asset).approve(approveTarget, amount);\n}\n\n(bool success,) = swapTarget.call(data);\nif (success == false) {\n    assembly {\n        let ptr := mload(0x40)\n        let size := returndatasize()\n        returndatacopy(ptr, 0, size)\n        revert(ptr, size)\n    }\n}\n```
MEDIUM severity: The instantiation process for a Dandelion organization involves two primary functions: `installDande. The instantiation process for a Dandelion organization involves two primary functions: `installDandelionApps` and `newTokenAndBaseInstance`. The latter is a wrapper around two publicly accessible functions: `newToken` and `newBaseInstance`. These functions are responsible for deploying a new `MiniMe...

Vulnerable code:
```\n/**\n * @dev Create a new MiniMe token and save it for the user\n * @param _name String with the name for the token used by share holders in the organization\n * @param _symbol String with the symbol for the token used by share holders in the organization\n */\nfunction newToken(string memory _name, string memory _symbol) public returns (MiniMeToken) {\n    MiniMeToken token = _createToken(_name, _symbol, TOKEN_DECIMALS);\n    _saveToken(token);\n    return token;\n}\n```\n```\n/**\n * @dev Deploy a Dandelion Org DAO using a previously saved MiniMe token\n * @param _id String with the name for org, will assign `[id].aragonid.eth`\n * @param _holders Array of token holder addresses\n * @param _stakes Array of token stakes for holders (token has 18 decimals, multiply token amount * 10^18)\n * @param _useAgentAsVault Boolean to tell whether to use an Agent app as a more advanced form of Vault app\n */\nfunction newBaseInstance(\n    string memory _id,\n    address[] memory _holders,\n    uint256[] memory _stakes,\n    uint64 _financePeriod,\n    bool _useAgentAsVault\n) public {\n    _validateId(_id);\n    _ensureBaseSettings(_holders, _stakes);\n\n    (Kernel dao, ACL acl) = _createDAO();\n    _setupBaseApps(dao, acl, _holders, _stakes, _financePeriod, _useAgentAsVault);\n}\n```\n```\nfunction _setupBaseApps(\n    Kernel _dao,\n    ACL _acl,\n    address[] memory _holders,\n    uint256[] memory _stakes,\n    uint64 _financePeriod,\n    bool _useAgentAsVault\n) internal {\n    MiniMeToken token = _getToken();\n    Vault agentOrVault = _useAgentAsVault? _installDefaultAgentApp(_dao) : _installVaultApp(_dao);\n    TokenManager tokenManager = _installTokenManagerApp(_dao, token, TOKEN_TRANSFERABLE, TOKEN_MAX_PER_ACCOUNT);\n    Finance finance = _installFinanceApp(_dao, agentOrVault, _financePeriod == 0? DEFAULT_Finance_PERIOD : _financePeriod);\n\n    _mintTokens(_acl, tokenManager, _holders, _stakes);\n    _saveBaseApps(_dao, finance, tokenManager, agentOrVault);\n    _saveAgentAsVault(_dao, _useAgentAsVault);\n}\n```\n```\nfunction _saveToken(MiniMeToken _token) internal {\n    DeployedContracts storage senderDeployedContracts = deployedContracts[msg.sender];\n\n    senderDeployedContracts.token = address(_token);\n}\n```\n```\nfunction _getToken() internal returns (MiniMeToken) {\n    DeployedContracts storage senderDeployedContracts = deployedContracts[msg.sender];\n    require(senderDeployedContracts.token!= address(0), ERROR_MISSING_TOKEN_CONTRACT);\n\n    MiniMeToken token = MiniMeToken(senderDeployedContracts.token);\n    return token;\n}\n```
MEDIUM severity: The `IdleCDO.virtualPrice()` and `_updatePrices()` functions are responsible for calculating and sto. The `IdleCDO.virtualPrice()` and `_updatePrices()` functions are responsible for calculating and storing the current prices of a tranche in the IdleCDO system. However, a discrepancy has been identified in the way these functions handle the calculation of prices, leading to differences in the prices...

Vulnerable code:
```\nif (BBTotSupply == 0):\n    AAGain = gain\nelse if (AATotSupply == 0):\n    BBGain = gain\nelse:\n    AAGain = gain * trancheAPRSplitRatio / FULL_ALLOC\n    BBGain = gain - AAGain\n```\n```\nif (_tranche == AATranche) {\n    trancheNAV = lastNAVAA + (gain * _trancheAPRSplitRatio / FULL_ALLOC);\n} else {\n    trancheNAV = lastNAVBB + (gain * (FULL_ALLOC - _trancheAPRSplitRatio) / FULL_ALLOC);\n}\n```
MEDIUM severity: The vulnerability lies in the Tranche contract's design, which allows the admin/owner to pause the c. The vulnerability lies in the Tranche contract's design, which allows the admin/owner to pause the contract, rendering users unable to collect their earned yield. This restriction is enforced through the `pause()` and `unpause()` functions, which can only be executed by the management, as indicated...

Vulnerable code:
```\nFile: Tranche.sol\n\nfunction pause() external onlyManagement {\n    _pause();\n}\n\n/// @notice Unpause issue, collect and updateUnclaimedYield\n/// @dev only callable by management\nfunction unpause() external onlyManagement {\n    _unpause();\n}\n```\n```\nfunction collect() public nonReentrant whenNotPaused returns (uint256) {\n    uint256 _lscale = lscales[msg.sender];\n    uint256 accruedInTarget = unclaimedYields[msg.sender];\n}\n```