Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability occurs when the `JalaMasterRouter` incorrectly calculates the amount of wrapped to. The vulnerability occurs when the `JalaMasterRouter` incorrectly calculates the amount of wrapped tokens to be swapped with ETH, resulting in the wrapped tokens getting stuck in the contract. This happens because the `swapExactTokensForETH` function passes the amount of underlying tokens to be swapp...

Vulnerable code:
```\nfunction testswapExactTokensForETHStuckTokens() public {\n    address wrappedTokenA = IChilizWrapperFactory(wrapperFactory).wrappedTokenFor(address(tokenA));\n\n    tokenA.approve(address(wrapperFactory), type(uint256).max);\n    wrapperFactory.wrap(address(this), address(tokenA), 100);\n\n    IERC20(wrappedTokenA).approve(address(router), 100 ether);\n    router.addLiquidityETH{value: 100 ether}(wrappedTokenA, 100 ether, 0, 0, address(this), type(uint40).max);\n\n    address pairAddress = factory.getPair(address(WETH), wrapperFactory.wrappedTokenFor(address(tokenA)));\n\n    uint256 pairBalance = IJalaPair(pairAddress).balanceOf(address(this));\n\n    address[] memory path = new address[](2);\n    path[0] = wrappedTokenA;\n    path[1] = address(WETH);\n\n    vm.startPrank(user0);\n    console.log("ETH user balance before:       ", user0.balance);\n    console.log("TokenA user balance before:    ", tokenA.balanceOf(user0));\n    console.log("WTokenA router balance before: ", IERC20(wrappedTokenA).balanceOf(address(masterRouter)));\n\n    tokenA.approve(address(masterRouter), 550);\n    masterRouter.swapExactTokensForETH(address(tokenA), 550, 0, path, user0, type(uint40).max);\n    vm.stopPrank();\n\n    console.log("ETH user balance after:       ", user0.balance);\n    console.log("TokenA user balance after:    ", tokenA.balanceOf(user0));\n    console.log("WTokenA router balance after: ", IERC20(wrappedTokenA).balanceOf(address(masterRouter)));\n}\n```
MEDIUM severity: The vulnerability arises when the SdtStakingPositionService attempts to process rewards and bribes f. The vulnerability arises when the SdtStakingPositionService attempts to process rewards and bribes from the buffer. The buffer returns a list of tokens and amounts owed, which is used to set the rewards eligible for distribution. However, since the list is not checked for duplicate tokens, a shared...

Vulnerable code:
```\nICommonStruct.TokenAmount[] memory bribeTokens = _sdtBlackHole.pullSdStakingBribes(\n    processor,\n    _processorRewardsPercentage\n);\n\nuint256 rewardAmount = _gaugeAsset.reward_count();\n\nICommonStruct.TokenAmount[] memory tokenAmounts = new ICommonStruct.TokenAmount[](\n    rewardAmount + bribeTokens.length\n);\n\nuint256 counter;\naddress _processor = processor;\nfor (uint256 j = 0; j < rewardAmount; j++) {\n    IERC20 token = _gaugeAsset.reward_tokens(j);\n    uint256 balance = token.balanceOf(address(this));\n    if (balance!= 0) {\n        uint256 fullBalance = balance;\n        token.transfer(sdtRewardsReceiver, balance);\n        tokenAmounts[counter++] = ICommonStruct.TokenAmount({token: token, amount: balance});\n    }\n}\n\nfor (uint256 j = 0; j < bribeTokens.length; j++) {\n    IERC20 token = bribeTokens[j].token;\n    uint256 amount = bribeTokens[j].amount;\n    if (amount!= 0) {\n        tokenAmounts[counter++] = ICommonStruct.TokenAmount({token: token, amount: amount});\n    }\n}\n```\n```\nfor (uint256 i; i < _rewardAssets.length; ) {\n    IERC20 _token = _rewardAssets[i].token;\n    uint256 erc20Id = _tokenToId[_token];\n    if (erc20Id == 0) {\n        uint256 _numberOfSdtRewards = ++numberOfSdtRewards;\n        _tokenToId[_token] = _numberOfSdtRewards;\n        erc20Id = _numberOfSdtRewards;\n    }\n\n    _sdtRewardsByCycle[_cvgStakingCycle][erc20Id] = ICommonStruct.TokenAmount({\n        token: _token,\n        amount: _rewardAssets[i].amount\n    });\n    unchecked {\n        ++i;\n    }\n}\n```
MEDIUM severity: The `issue` function in the Tranche contract lacks a mechanism to control slippage, which can result. The `issue` function in the Tranche contract lacks a mechanism to control slippage, which can result in a loss of assets for affected users. When a user initiates an issuance, they deposit underlying assets (e.g., ETH) to the Tranche contract, which then forwards them to the Adaptor contract for dep...

Vulnerable code:
```\nFile: Tranche.sol\n\nfunction issue(\n    address to,\n    uint256 underlyingAmount\n) external nonReentrant whenNotPaused notExpired returns (uint256 issued) {\n    // Transfer underlying from user to adapter and deposit it into adapter to get target token\n    _underlying.safeTransferFrom(msg.sender, address(adapter), underlyingAmount);\n    (, uint256 sharesMinted) = adapter.prefundedDeposit();\n\n    // Deduct the issuance fee from the amount of target token minted + reinvested yield\n    uint256 sharesUsed = sharesMinted + accruedInTarget;\n    uint256 fee = sharesUsed.mulDivUp(issuanceFeeBps, MAX_BPS);\n    issued = (sharesUsed - fee).mulWadDown(_maxscale);\n\n    // Accumulate issueance fee in units of target token\n    issuanceFees += fee;\n    // Mint PT and YT to user\n    _mint(to, issued);\n    _yt.mint(to, issued);\n\n    emit Issue(msg.sender, to, issued, sharesUsed);\n}\n```
MEDIUM severity: The vulnerability arises from an incorrect implementation of the `_withoutSettlementFeeGlobal` formu. The vulnerability arises from an incorrect implementation of the `_withoutSettlementFeeGlobal` formula in the Vault contract. This formula is responsible for calculating the settlement fee for global shares and assets. The issue lies in the fact that the formula subtracts the settlement fee in full...

Vulnerable code:
```\nfunction update(\n    Account memory self,\n    uint256 currentId,\n    UFixed6 assets,\n    UFixed6 shares,\n    UFixed6 deposit,\n    UFixed6 redemption\n) internal pure {\n    self.current = currentId;\n    (self.assets, self.shares) = (self.assets.sub(assets), self.shares.sub(shares));\n    (self.deposit, self.redemption) = (self.deposit.add(deposit), self.redemption.add(redemption));\n}\n```
MEDIUM severity: The `_transferETH` function, responsible for processing Ethereum (ETH) transfers, contains a vulnera. The `_transferETH` function, responsible for processing Ethereum (ETH) transfers, contains a vulnerability that can lead to a catastrophic failure of the entire payout process. This function is part of the `_payment` method, which settles transactions in an `ExchangeBox`. \n\nThe issue arises when t...

Vulnerable code:
```\nfunction _transferETH(address _recipient, uint256 _amount) private {\n    (bool success, ) = _recipient.call{value: _amount}(\n        abi.encodeWithSignature("")\n    );\n    require(success, "Transfer Failed");\n}\n```
MEDIUM severity: The Exchange owner's ability to call `executeTransaction` or `batchExecuteTransaction` can lead to u. The Exchange owner's ability to call `executeTransaction` or `batchExecuteTransaction` can lead to unintended consequences, as the `onlyOwner` modifier is bypassed. This occurs because the `delegatecall` resulting from these function calls passes the `onlyOwner` modifier, even if the transaction sig...

Vulnerable code:
```\naddress signerAddress = transaction.signerAddress;\n_setCurrentContextAddressIfRequired(signerAddress, signerAddress);\n```\n```\nfunction registerAssetProxy(address assetProxy)\n    external\n    onlyOwner\n{\n    bytes4 assetProxyId = IAssetProxy(assetProxy).getProxyId();\n    address currentAssetProxy = _assetProxies[assetProxyId];\n    if (currentAssetProxy!= address(0)) {\n        LibRichErrors.revert(LibExchangeRichErrors.AssetProxyExistsError(\n            assetProxyId,\n            currentAssetProxy\n        ));\n    }\n\n    _assetProxies[assetProxyId] = assetProxy;\n    emit AssetProxyRegistered(assetProxyId, assetProxy);\n}\n```\n```\nfunction _assertSenderIsOwner() internal view {\n    if (msg.sender!= owner) {\n        LibRichErrors.revert(LibOwnableRichErrors.OnlyOwnerError(msg.sender, owner));\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the `_openSellOrder()` function, which relies on the `_poolBalanceIsSuffic. The vulnerability lies in the `_openSellOrder()` function, which relies on the `_poolBalanceIsSufficient` function to check if there are sufficient tokens in the reserve before processing a sell order. However, the `collateralsToBeClaimed` variable, which determines the amount of tokens that can be...

Vulnerable code:
```\nfunction _poolBalanceIsSufficient(address _collateral) internal view returns (bool) {\n    return controller.balanceOf(address(reserve), _collateral) >= collateralsToBeClaimed[_collateral];\n}\n```\n```\nfunction balanceOf(address _who, address _token) public view isInitialized returns (uint256) {\n    uint256 balance = _token == ETH? _who.balance : ERC20(_token).staticBalanceOf(_who);\n\n    if (_who == address(reserve)) {\n        return balance.sub(tap.getMaximumWithdrawal(_token));\n    } else {\n        return balance;\n    }\n}\n```\n```\nfunction _tappedAmount(address _token) internal view returns (uint256) {\n    uint256 toBeKept = controller.collateralsToBeClaimed(_token).add(floors[_token]);\n    uint256 balance = _token == ETH\n       ? address(reserve).balance\n        : ERC20(_token).staticBalanceOf(reserve);\n    uint256 flow = (_currentBatchId().sub(lastTappedAmountUpdates[_token])).mul(rates[_token]);\n    uint256 tappedAmount = tappedAmounts[_token].add(flow);\n\n    if (balance <= toBeKept) {\n        return 0;\n    }\n\n    if (balance <= toBeKept.add(tappedAmount)) {\n        return balance.sub(toBeKept);\n    }\n\n    return tappedAmount;\n}\n```
MEDIUM severity: The vulnerability allows attackers to drain the funds in the assetManager by exploiting a logical er. The vulnerability allows attackers to drain the funds in the assetManager by exploiting a logical error in the UToken.redeem() function. Specifically, the function does not check whether the uTokenAmount is zero before redeeming the underlying tokens. This allows attackers to redeem a large amount o...

Vulnerable code:
```\nif (amountIn > 0) {\n    uTokenAmount = amountIn;\n    underlyingAmount = (amountIn * exchangeRate) / WAD;\n} else {\n    uTokenAmount = (amountOut * WAD) / exchangeRate;\n    underlyingAmount = amountOut;\n}\n```
MEDIUM severity: The UniProxy contract's price manipulation protection mechanism is susceptible to a re-entrancy atta. The UniProxy contract's price manipulation protection mechanism is susceptible to a re-entrancy attack, which can be exploited in conjunction with a flash loan attack to invalidate the price check. The protection mechanism involves a conditional check for the `twapCheck` and `positions[pos].twapOver...

Vulnerable code:
```\nif (twapCheck || positions[pos].twapOverride) {\n    checkPriceChange(\n        pos,\n        positions[pos].twapOverride? positions[pos].twapInterval : twapInterval,\n        positions[pos].twapOverride? positions[pos].priceThreshold : priceThreshold\n    );\n}\n```
MEDIUM severity: The cvgControlTower and veCVG locking mechanisms exhibit a timing disparity, leading to yield loss s. The cvgControlTower and veCVG locking mechanisms exhibit a timing disparity, leading to yield loss scenarios. When creating a locked CVG position, two independent locks are created: one in lockingPositionService and the other in veCVG. The former operates on cycles, which are not finite in length, w...

Vulnerable code:
```\n(1,400,000 + 2 * 604,800) / 604,800 = 4\n\n    4 * 604,800 = 2,419,200\n```\n```\n612,000 * 95 = 58,140,000\n```\n```\n612,000 * 96 = 58,060,800\n```
MEDIUM severity: The `roundHalfUp` function in the `LibMath` library appears to be incomplete, as it does not fully e. The `roundHalfUp` function in the `LibMath` library appears to be incomplete, as it does not fully execute the rounding process. The function takes two integer parameters, `x` and `y`, and returns the result of rounding `x` up to the base `y`. However, the implementation only performs a partial roun...

Vulnerable code:
```\nfunction roundHalfUp(int256 x, int256 y) internal pure returns (int256) {\n    require(y > 0, "roundHalfUp only supports y > 0");\n    if (x >= 0) {\n        return x + y / 2;\n    }\n    return x - y / 2;\n}\n```
MEDIUM severity: The `daoNamespace` variable is not properly formatted, as it lacks a trailing dot (`.`) in its decla. The `daoNamespace` variable is not properly formatted, as it lacks a trailing dot (`.`) in its declaration. This can lead to issues when concatenating the namespace with other strings, potentially resulting in incorrect or unexpected behavior.\n\nIn the provided code, the `daoNameSpace` variable is...

Vulnerable code:
```\nfunction getMemberAt(uint256 _index) override public view returns (address) {\n    AddressSetStorageInterface addressSetStorage = AddressSetStorageInterface(getContractAddress("addressSetStorage"));\n    return addressSetStorage.getItem(keccak256(abi.encodePacked(daoNameSpace, "member.index")), _index);\n}\n```\n```\nstring private daoNameSpace = 'dao.trustednodes';\n```\n```\nuint256 private calcBase = 1 ether;\n\nstring private daoNameSpace = 'dao.trustednodes';\n```\n```\nstring private daoNameSpace = 'dao.protocol';\n```
MEDIUM severity: The Factory contract's signature validation mechanism lacks a crucial feature - expiration time. Spe. The Factory contract's signature validation mechanism lacks a crucial feature - expiration time. Specifically, once a signature is provided to the NftPort, it cannot be revoked or updated without modifying the `SIGNER_ROLE` address. This means that the signature remains valid indefinitely, effective...

Vulnerable code:
```\nsignedOnly(\n    abi.encodePacked(msg.sender, instance, data),\n    signature\n)\n```
MEDIUM severity: This vulnerability is related to inconsistent interfaces for functions within the same group. Specif. This vulnerability is related to inconsistent interfaces for functions within the same group. Specifically, the `add` and `sub` functions in the library have different numbers of arguments and error handling mechanisms. The `add` function takes two arguments, `x` and `y`, and uses an implicit error...

Vulnerable code:
```\nfunction add(uint x, uint y) internal pure returns (uint z) {\n    require(x + y >= x, "add-overflow");\n    return x + y;\n}\n```\n```\nfunction sub(uint x, uint y, string memory _errorMessage) internal pure returns (uint z) {\n    require((z = x - y) <= x, _errorMessage);\n}\n```
MEDIUM severity: The vulnerability allows an attacker to fake the amount of liquidity held in a Uniswap V3 position, . The vulnerability allows an attacker to fake the amount of liquidity held in a Uniswap V3 position, making the protocol believe the position has more liquidity than the actual liquidity deposited. This is achieved by exploiting the caching of liquidity values in the `assetToLiquidity` mapping during...

Vulnerable code:
```\nfunction _deposit(\n    address[] memory assetAddresses,\n    uint256[] memory assetIds,\n    uint256[] memory assetAmounts,\n    address from\n) internal {\n    uint256[] memory assetTypes = \n        IRegistry(registry).batchProcessDeposit(creditor, assetAddresses, assetIds, assetAmounts);\n\n    for (uint256 i = 0; i < assetAddresses.length; i++) {\n        // Skip if amount is 0 to prevent storing addresses that have 0 balance.\n        if (assetAmounts[i] == 0) continue;\n\n        if (assetTypes[i] == 0) {\n            if (assetIds[i]!= 0) {\n                revert AccountErrors.InvalidERC20Id();\n            }\n            _depositERC20(from, assetAddresses[i], assetAmounts[i]);\n        } else if (assetTypes[i] == 1) {\n            if (assetAmounts[i]!= 1) {\n                revert AccountErrors.InvalidERC721Amount();\n            }\n            _depositERC721(from, assetAddresses[i], assetIds[i]);\n        } else if (assetTypes[i] == 2) {\n            _depositERC1155(from, assetAddresses[i], assetIds[i], assetAmounts[i]);\n        } else {\n            revert AccountErrors.UnknownAssetType();\n        }\n    }\n\n    if (erc20Stored.length + erc721Stored.length + erc1155Stored.length > ASSET_LIMIT) {\n        revert AccountErrors.TooManyAssets();\n    }\n}\n```\n```\nfunction processDirectDeposit(\n    address creditor,\n    address asset,\n    uint256 assetId,\n    uint256 amount\n) public override returns (uint256 recursiveCalls, uint256 assetType) {\n    // Amount deposited of a Uniswap V3 LP can be either 0 or 1 (checked in the Account).\n    // For uniswap V3 every id is a unique asset -> on every deposit the asset must added to the Asset Module.\n    if (amount == 1) {\n        _addAsset(assetId);\n    }\n    // rest of code\n}\n```\n```\nfunction _addAsset(uint256 assetId) internal {\n    (,, address token0, address token1,,,, uint128 liquidity,,,,) = NON_FUNGIBLE_POSITION_MANAGER.positions(assetId);\n\n    if (liquidity == 0) {\n        revert ZeroLiquidity();\n    }\n\n    assetToLiquidity[assetId] = liquidity;\n}\n```\n```\nfunction _getPosition(uint256 assetId)\n    internal\n    view\n    returns (address token0, address token1, int24 tickLower, int24 tickUpper, uint128 liquidity)\n{\n    liquidity = uint128(assetToLiquidity[assetId]);\n\n    if (liquidity > 0) {\n        (,, token0, token1,, tickLower, tickUpper,,,,) = NON_FUNGIBLE_POSITION_MANAGER.positions(assetId);\n    } else {\n        (,, token0, token1,, tickLower, tickUpper, liquidity,,,) = NON_FUNGIBLE_POSITION_MANAGER.positions(assetId);\n    }\n}\n```
MEDIUM severity: The `reduce_position` function is designed to decrease the margin amount of a position while maintai. The `reduce_position` function is designed to decrease the margin amount of a position while maintaining the same leverage by proportionally reducing the debt amount. However, this function fails to update the margin mapping correctly, making it impossible for users to withdraw their margin.\n\nThe...

Vulnerable code:
```\ndef _reduce_position(self, _position_uid, _reduce_by_amount, min_amount_out):\n    debt_amount: uint256 = self._debt(_position_uid)\n    margin_debt_ratio: uint256 = position.margin_amount * PRECISION / debt_amount\n\n    amount_out_received: uint256 = self._swap(\n        position.position_token, position.debt_token, _reduce_by_amount, min_amount_out\n    )\n\n    reduce_margin_by_amount: uint256 = (amount_out_received * margin_debt_ratio / PRECISION)\n    reduce_debt_by_amount: uint256 = amount_out_received - reduce_margin_by_amount\n\n    position.margin_amount -= reduce_margin_by_amount\n\n    burnt_debt_shares: uint256 = self._repay(position.debt_token, reduce_debt_by_amount)\n    position.debt_shares -= burnt_debt_shares\n    position.position_amount -= _reduce_by_amount\n```
MEDIUM severity: The `isFTM` and `isETH` checks in the `LibUniversalERC20` library are inconsistent, as they use diff. The `isFTM` and `isETH` checks in the `LibUniversalERC20` library are inconsistent, as they use different methods to identify native assets. The `isFTM` function checks for the FTM asset by matching against two distinct addresses, whereas the `isETH` function uses a single address to identify the ET...

Vulnerable code:
```\nfunction callFunction(\n    address sender,\n    Account.Info calldata account,\n    bytes calldata data\n) external override {\n    require(msg.sender == _dydxSoloMargin && sender == address(this), Errors.VL_NOT_AUTHORIZED);\n\n    account;\n\n    FlashLoan.Info memory info = abi.decode(data, (FlashLoan.Info));\n\n    uint256 _value;\n    if (info.asset == _ETH) {\n        // Convert WETH to ETH and assign amount to be set as msg.value\n        _convertWethToEth(info.amount);\n        _value = info.amount;\n    } else {\n        // Transfer to Vault the flashloan Amount\n        // _value is 0\n        IERC20(info.asset).univTransfer(payable(info.vault), info.amount);\n    }\n}\n```\n```\nlibrary LibUniversalERC20 {\n    using SafeERC20 for IERC20;\n\n    IERC20 private constant _ETH_ADDRESS = IERC20(0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE);\n    IERC20 private constant _ZERO_ADDRESS = IERC20(0x0000000000000000000000000000000000000000);\n\n    function isETH(IERC20 token) internal pure returns (bool) {\n        return (token == _ZERO_ADDRESS || token == _ETH_ADDRESS);\n    }\n}\n```\n```\nfunction univTransfer(\n    IERC20 token,\n    address payable to,\n    uint256 amount\n) internal {\n    if (amount > 0) {\n        if (isETH(token)) {\n            (bool sent, ) = to.call{ value: amount }("");\n            require(sent, "Failed to send Ether");\n        } else {\n            token.safeTransfer(to, amount);\n        }\n    }\n}\n```\n```\nuint256 _value = vAssets.borrowAsset == ETH? debtTotal : 0;\n```
MEDIUM severity: The `TransferHelper` library's methods enable direct token transfers or transfers on behalf of a dif. The `TransferHelper` library's methods enable direct token transfers or transfers on behalf of a different wallet that has previously authorized the transfer. These functions verify the sender's balance before executing the transfer. However, in the latter scenario, where the transfer is performed o...

Vulnerable code:
```\nfunction transferTokens(\n    address token,\n    address from,\n    address to,\n    uint256 amount\n) internal {\n    uint256 priorBalance = IERC20(token).balanceOf(address(to));\n    require(IERC20(token).balanceOf(msg.sender) >= amount, 'THL01');\n}\n```
MEDIUM severity: The collateral manager's withdrawal functionality lacks a crucial nonce check, which can lead to pot. The collateral manager's withdrawal functionality lacks a crucial nonce check, which can lead to potential issues with the ordering of withdrawals. Specifically, when updating the per-address withdrawal nonce, the code does not verify that the new nonce is indeed one greater than the previous one. T...

Vulnerable code:
```\naddressToWithdrawalNonce[_partition][supplier] = withdrawalRootNonce;\n```\n```\naddressToWithdrawalNonce[_partition][supplier] = maxWithdrawalRootNonce\n```\n```\nmaxWithdrawalRootNonce = _nonce;\n```
MEDIUM severity: The `stake()` function in the smart contract does not properly initialize the `lastEpochClaimed` var. The `stake()` function in the smart contract does not properly initialize the `lastEpochClaimed` variable when the user's balance is zero. This leads to a scenario where new stakeholders are required to loop through all previous epochs to claim their rewards, starting from epoch 0. As the epoch coun...

Vulnerable code:
```\nfunction stake(\n    uint256 amount_,\n    bytes calldata proof_\n) external nonReentrant requireInitialized updateRewards tryNewEpoch {\n    uint256 userBalance = stakeBalance[msg.sender];\n    if (userBalance > 0) {\n        _claimRewards();\n    } else {\n        rewardsPerTokenClaimed[msg.sender] = rewardsPerTokenStored;\n    }\n\n    stakeBalance[msg.sender] = userBalance + amount_;\n    totalBalance += amount_;\n\n    stakedToken.safeTransferFrom(msg.sender, address(this), amount_);\n}\n```\n```\nfunction _claimRewards() internal returns (uint256) {\n    // Claims all outstanding rewards for the user across epochs\n    // If there are unclaimed rewards from epochs where the option token has expired, the rewards are lost\n\n    uint48 userLastEpoch = lastEpochClaimed[msg.sender];\n\n    if (userLastEpoch == epoch) {\n        return _claimEpochRewards(epoch);\n    }\n\n    uint256 totalRewardsClaimed;\n    for (uint48 i = userLastEpoch; i <= epoch; i++) {\n        totalRewardsClaimed += _claimEpochRewards(i);\n    }\n\n    return totalRewardsClaimed;\n}\n```