Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The validation mechanism for operator transfers in the provided code snippet appears to be insuffici. The validation mechanism for operator transfers in the provided code snippet appears to be insufficient, as it does not ensure that the sender is indeed an operator for the relevant partition. The current implementation relies on a logical `or` condition, which allows the transfer to proceed as long...

Vulnerable code:
```\nrequire(\n    _isOperatorForPartition(_partition, msg.sender, _from) ||\n        (_value <= _allowedByPartition[_partition][_from][msg.sender]),\n    EC_53_INSUFFICIENT_ALLOWANCE\n);\n```
MEDIUM severity: The Gluwacoin wrapper token's `decimals` function is currently hard-coded to return a fixed value of. The Gluwacoin wrapper token's `decimals` function is currently hard-coded to return a fixed value of 6, which is a limitation in terms of flexibility and maintainability. This hardcoded value is not dynamically determined based on the wrapped ERC-20 token's actual number of decimals, which may lead...

Vulnerable code:
```\nfunction decimals() public pure override returns (uint8) {\n    return 6;\n}\n```
MEDIUM severity: The vulnerability allows a depositor of the GMXVault to bypass paying the fee when depositing into t. The vulnerability allows a depositor of the GMXVault to bypass paying the fee when depositing into the GMXVault. This occurs due to a logic error in the GMXDeposit#processDeposit() function, where the amount of shares (svTokens) minted to the depositor is not adjusted to account for the fee-minted i...

Vulnerable code:
```\n/**\n * @notice @inheritdoc GMXVault\n * @param self GMXTypes.Store\n * @param isNative Boolean as to whether user is depositing native asset (e.g. ETH, AVAX, etc.)\n */\nfunction deposit(\n    GMXTypes.Store storage self,\n    GMXTypes.DepositParams memory dp,\n    bool isNative\n) external {\n    self.status = GMXTypes.Status.Deposit;\n\n    self.vault.mintFee();\n    // rest of code\n}\n```\n```\n/**\n * @notice Mint vault token shares as management fees to protocol treasury\n*/\n\nfunction mintFee() public {\n    _mint(_store.treasury, GMXReader.pendingFee(_store));\n    _store.lastFeeCollected = block.timestamp;\n}\n```\n```\n/**\n * @notice @inheritdoc GMXVault\n * @param self GMXTypes.Store\n */\nfunction processDeposit(\n    GMXTypes.Store storage self\n) external {\n    GMXChecks.beforeProcessDepositChecks(self);\n\n    try {\n        GMXProcessDeposit.processDeposit(self);\n    } catch {\n        // If there are any issues, a DepositFailed event will be emitted and processDepositFailure()\n        // should be triggered to refund assets accordingly and reset the vault status to Open again.\n        // Mint shares to depositor\n        self.vault.mint(self.depositCache.user, self.depositCache.sharesToUser); ///<------------- @audit\n        // rest of code\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the limited support for a specific subset of ERC20 tokens, which can lead . The vulnerability lies in the limited support for a specific subset of ERC20 tokens, which can lead to unnoticed transfer errors or successful transfers being treated as failed. The buffer's current implementation only verifies the return values of transfer(), transferFrom(), and approve() functions...

Vulnerable code:
```\nfunction transferFrom(address _from, address _to, uint _value) public onlyPayloadSize(3 * 32) {\n    var _allowance = allowed[_from][msg.sender];\n\n    uint fee = (_value.mul(basisPointsRate)).div(10000);\n    if (fee > maximumFee) {\n        fee = maximumFee;\n    }\n    if (_allowance < MAX_UINT) {\n        allowed[_from][msg.sender] = _allowance.sub(_value);\n    }\n    uint sendAmount = _value.sub(fee);\n    balances[_from] = balances[_from].sub(_value);\n    balances[_to] = balances[_to].add(sendAmount);\n    if (fee > 0) {\n        balances[owner] = balances[owner].add(fee);\n        Transfer(_from, owner, fee);\n    }\n    Transfer(_from, _to, sendAmount);\n}\n```\n```\nfunction transferFrom(address _from, address _to, uint _value) returns (bool) {\n    if (balances[_from] >= _value \n        && allowed[_from][msg.sender] >= _value \n        && balances[_to] + _value >= balances[_to]) {\n        balances[_to] += _value;\n        balances[_from] -= _value;\n        allowed[_from][msg.sender] -= _value;\n        Transfer(_from, _to, _value);\n        return true;\n    } else {\n        return false;\n    }\n}\n```
MEDIUM severity: The system's unit conversion mechanisms are overly complex, making it prone to errors and potential . The system's unit conversion mechanisms are overly complex, making it prone to errors and potential financial losses. The codebase contains multiple instances of unit conversions that are implemented in a convoluted manner, increasing the likelihood of calculation mistakes.\n\nFor instance, the `get...

Vulnerable code:
```\nfunction getBorrowRatePerBlock(address _token) public view returns(uint) {\n    if (!globalConfig.tokenInfoRegistry().isSupportedOnCompound(_token)) {\n        return getCapitalUtilizationRatio(_token).mul(globalConfig.rateCurveSlope()).div(INT_UNIT).add(globalConfig.rateCurveConstant()).div(BLOCKS_PER_YEAR);\n    }\n    return (compoundPool[_token].depositRatePerBlock).mul(globalConfig.compoundSupplyRateWeights()).add((compoundPool[_token].borrowRatePerBlock).mul(globalConfig.compoundBorrowRateWeights())).div(10);\n}\n```\n```\ncompoundPool[token].depositRatePerBlock = \n    cTokenExchangeRate.mul(UNIT).div(lastCTokenExchangeRate[token])\n   .sub(UNIT).div(blockNumber.sub(lastCheckpoint[token]));\n```\n```\nreturn lastDepositeRateIndex.mul(getBlockNumber().sub(lcp).mul(depositRatePerBlock).add(INT_UNIT)).div(INT_UNIT);\n```
MEDIUM severity: This vulnerability allows an attacker to manipulate the calculation of the netPnLE36 value by exploi. This vulnerability allows an attacker to manipulate the calculation of the netPnLE36 value by exploiting the fact that unused assets are sent to dustVault as dust, which are not subtracted from the inputAmt. This occurs when opening a position, where the unused assets are included in the calculation...

Vulnerable code:
```\nuint inputTotalUSDValueE36;\n\nfor (uint i = 0; i < openTokenInfos.length; i++) {\n    inputTotalUSDValueE36 += openTokenInfos[i].inputAmt * tokenPriceE36s[i];\n    borrowTotalUSDValueE36 += openTokenInfos[i].borrowAmt * tokenPriceE36s[i];\n}\n\nunchecked {\n    i++;\n}\n\npositionOpenUSDValueE36 = inputTotalUSDValueE36 + borrowTotalUSDValueE36;\nnetPnLE36 = positionCurUSDValueE36.toInt256() - positionOpenUSDValueE36.toInt256();\n```
MEDIUM severity: The MerkleReserveMinter's minting methodology is incompatible with the current governance structure,. The MerkleReserveMinter's minting methodology is incompatible with the current governance structure, which relies on tokens being minted individually and time-locked after minting by the auction. This incompatibility can lead to a critical vulnerability, where a malicious user can create a proposal...

Vulnerable code:
```\nunchecked {\n    for (uint256 i = 0; i < claimCount; ++i) {\n        MerkleClaim memory claim = claims[i];\n\n        if (!MerkleProof.verify(claim.merkleProof, settings.merkleRoot, keccak256(abi.encode(claim.mintTo, claim.tokenId)))) {\n            revert INVALID_MERKLE_PROOF(claim.mintTo, claim.merkleProof, settings.merkleRoot);\n        }\n\n        IToken(tokenContract).mintFromReserveTo(claim.mintTo, claim.tokenId);\n    }\n}\n```\n```\nproposal.voteStart = SafeCast.toUint32(snapshot);\nproposal.voteEnd = SafeCast.toUint32(deadline);\nproposal.proposalThreshold = SafeCast.toUint32(currentProposalThreshold);\nproposal.quorumVotes = SafeCast.toUint32(quorum());\nproposal.proposer = msg.sender;\nproposal.timeCreated = SafeCast.toUint32(block.timestamp);\n\nemit ProposalCreated(proposalId, _targets, _values, _calldatas, _description, descriptionHash, proposal);\n```\n```\nfunction quorum() public view returns (uint256) {\n    unchecked {\n        return (settings.token.totalSupply() * settings.quorumThresholdBps) / BPS_PER_100_PERCENT;\n    }\n}\n```
MEDIUM severity: The Unused Error Codes vulnerability refers to a situation where a set of error codes, such as `erro. The Unused Error Codes vulnerability refers to a situation where a set of error codes, such as `error RouteAlreadyExist();`, `error ContractContainsNoCode();`, `error ControllerAlreadyExist();`, and others, are defined but not utilized in the current architecture. These error codes were likely creat...

Vulnerable code:
```\nerror RouteAlreadyExist();\nerror SwapFailed();\nerror UnsupportedInterfaceId();\nerror ContractContainsNoCode();\nerror InvalidCelerRefund();\nerror CelerAlreadyRefunded();\nerror ControllerAlreadyExist();\nerror ControllerAddressIsZero();\n```
MEDIUM severity: The `IdleCDO.harvest()` function, responsible for liquidating rewards earned by the contract's strat. The `IdleCDO.harvest()` function, responsible for liquidating rewards earned by the contract's strategy and updating internal accounting, can be vulnerable to price manipulation attacks. Although the function is permissioned to only be called by the contract owner or designated rebalancer, and requi...

Vulnerable code:
```\nfunction harvest(\n    bool _skipRedeem,\n    bool _skipIncentivesUpdate,\n    bool[] calldata _skipReward,\n    uint256[] calldata _minAmount\n) external {\n    require(msg.sender == rebalancer || msg.sender == owner(), "IDLE:!AUTH");\n```\n```\nIERC20Detailed(rewardToken).safeIncreaseAllowance(address(_uniRouter), _currentBalance);\n\n_uniRouter.swapExactTokensForTokensSupportingFeeOnTransferTokens(\n    _currentBalance,\n    _minAmount[i],\n    _path,\n    address(this),\n    block.timestamp + 1\n)\n```
MEDIUM severity: The `redeemToken` function in the Sushi protocol contains a vulnerability due to unnecessary balance. The `redeemToken` function in the Sushi protocol contains a vulnerability due to unnecessary balance queries. Specifically, the `barBalanceDiff` variable is always equal to `requiredShares` because the `leave` function of the SushiBar contract burns exactly `requiredShares` units of xSUSHI. This mea...

Vulnerable code:
```\nuint256 barBeforeBalance = bar.balanceOf(address(this));\nuint256 sushiBeforeBalance = sushi.balanceOf(address(this));\n\nbar.leave(requiredShares);\n\nuint256 barAfterBalance = bar.balanceOf(address(this));\nuint256 sushiAfterBalance = sushi.balanceOf(address(this));\n\nuint256 barBalanceDiff = barBeforeBalance.sub(barAfterBalance);\nuint256 sushiBalanceDiff = sushiAfterBalance.sub(sushiBeforeBalance);\n\nbalances[msg.sender] = balances[msg.sender].sub(barBalanceDiff);\n```
MEDIUM severity: AuraSpell, a smart contract, is vulnerable to a security issue that forces users to swap their rewar. AuraSpell, a smart contract, is vulnerable to a security issue that forces users to swap their reward tokens with no slippage protection. This vulnerability occurs when the contract attempts to swap all reward tokens with a debt token, but fails to provide any control over the slippage tolerance.\n\...

Vulnerable code:
```\nfor (uint256 i = 0; i < rewardTokens.length; i++) {\n    uint256 rewards = _doCutRewardsFee(rewardTokens[i]);\n    _ensureApprove(rewardTokens[i], address(swapRouter), rewards);\n    swapRouter.swapExactTokensForTokens(\n        rewards,\n        0,\n        swapPath[i],\n        address(this),\n        type(uint256).max\n    );\n}\n```
MEDIUM severity: The vulnerability allows users to exploit the time gap between the archiving of signed prices and th. The vulnerability allows users to exploit the time gap between the archiving of signed prices and the storage of new prices for the next block to gain a "free look" into the future. This is achieved by continually updating limit orders to execute with oracle prices that have not yet been archived, b...

Vulnerable code:
```\nthe oracle process:\n\n    1. the oracle node checks the latest price from reference exchanges and stores it with the oracle node's timestamp, e.g. time: 1000\n    2. the oracle node checks the latest block of the blockchain, e.g. block 100, it stores this with the oracle node's timestamp as well\n    3. the oracle node signs\n        minOracleBlockNumber: 100\n        maxOracleBlockNumber: 100\n        timestamp: 1000\n        price: <price>\n    4. the next time the loop runs is at time 1001, if the latest block of the blockchain is block 105, e.g. if 5 blocks were produced in that one second, then the oracle would sign\n        minOracleBlockNumber: 101\n        maxOracleBlockNumber: 105\n        timestamp: 1001\n        price: <price>\n```
MEDIUM severity: The `LibProxy.proxyCall()` function in the provided code is vulnerable to memory corruption due to i. The `LibProxy.proxyCall()` function in the provided code is vulnerable to memory corruption due to its unsafe handling of memory allocation. The function copies call data to memory, starting at address 0, which can potentially overwrite important memory regions. Specifically, the first 64 bytes of m...

Vulnerable code:
```\nassembly {\n    let freeMemPtr := 0\n    if gt(customEgressSelector, 0) {\n        mstore(0x0, customEgressSelector)\n        freeMemPtr := add(freeMemPtr, 4)\n    }\n\n    let calldataOffset := 0\n    if gt(ignoreIngressSelector, 0) {\n        calldataOffset := 4\n    }\n\n    calldatacopy(\n        freeMemPtr,\n        calldataOffset,\n        calldatasize()\n    )\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of the `_checkIfCollateralIsActive` function, which is . The vulnerability lies in the implementation of the `_checkIfCollateralIsActive` function, which is responsible for verifying the status of Lyra vault positions before allowing users to interact with them. Specifically, the function checks if the price is stale or if the circuit breaker is tripped,...

Vulnerable code:
```\nfunction _checkIfCollateralIsActive(bytes32 _currencyKey) internal view override {\n    ILiquidityPoolAvalon LiquidityPool = ILiquidityPoolAvalon(collateralBook.liquidityPoolOf(_currencyKey));\n    bool isStale;\n    uint circuitBreakerExpiry;\n\n    (, isStale, circuitBreakerExpiry) = LiquidityPool.getTokenPriceWithCheck();\n\n    require(!(isStale), "Global Cache Stale, can't trade");\n    require(circuitBreakerExpiry < block.timestamp, "Lyra Circuit Breakers active, can't trade");\n}\n```
MEDIUM severity: The Notional Strategy Vaults may allow for secondary currencies to be borrowed as part of the same s. The Notional Strategy Vaults may allow for secondary currencies to be borrowed as part of the same strategy, which can lead to a critical vulnerability in the collateral ratio checks performed by the Notional Controller. When a user enters a vault, they deposit a primary borrow currency, and the col...

Vulnerable code:
```\nfunction checkCollateralRatio(\n    VaultConfig memory vaultConfig,\n    VaultState memory vaultState,\n    VaultAccount memory vaultAccount\n) internal view {\n    (int256 collateralRatio,) = calculateCollateralRatio(\n        vaultConfig,\n        vaultState,\n        vaultAccount.account,\n        vaultAccount.vaultShares,\n        vaultAccount.fCash\n)\n```\n```\nfunction calculateCollateralRatio(\n    VaultConfig memory vaultConfig,\n    VaultState memory vaultState,\n    address account,\n    uint256 vaultShares,\n    int256 fCash\n) internal view returns (int256 collateralRatio, int256 vaultShareValue) {\n    vaultShareValue = vaultState.getCashValueOfShare(vaultConfig, account, vaultShares);\n\n    int256 debtOutstanding = vaultConfig.assetRate.convertFromUnderlying(fCash.neg());\n\n    // Convert fCash to a positive amount of asset cash\n    // We do not discount fCash to present value so that we do not introduce interest\n    // rate risk in this calculation. The economic benefit of discounting will be very\n    // minor relative to the added complexity of accounting for interest rate risk.\n```\n```\nfunction getCashValueOfShare(\n    VaultState memory vaultState,\n    VaultConfig memory vaultConfig,\n    address account,\n    uint256 vaultShares\n) internal view returns (int256 assetCashValue) {\n    if (vaultShares == 0) {\n        return 0;\n    }\n    (\n        uint256 assetCash,\n        uint256 strategyTokens\n    ) = getPoolShare(vaultState, vaultShares);\n    int256 underlyingInternalStrategyTokenValue = _getStrategyTokenValueUnderlyingInternal(\n        vaultConfig.borrowCurrencyId,\n        vaultConfig.vault,\n        account,\n        strategyTokens,\n        vaultState.maturity\n    );\n}\n```\n```\nfunction _getStrategyTokenValueUnderlyingInternal(\n    uint16 currencyId,\n    address vault,\n    address account,\n    uint256 strategyTokens,\n    uint256 maturity\n) private view returns (int256) {\n    Token memory token = TokenHandler.getUnderlyingToken(currencyId);\n    if (token.decimals == 0) {\n        token = TokenHandler.getAssetToken(currencyId);\n    }\n    return token.convertToInternal(\n        IStrategyVault(vault).convertStrategyToUnderlying(account, strategyTokens, maturity)\n    );\n}\n```
MEDIUM severity: The vulnerability allows the owner to execute a frontrunning attack, which enables them to manipulat. The vulnerability allows the owner to execute a frontrunning attack, which enables them to manipulate the deposit fees and steal tokens. This attack vector is possible due to the lack of proper fee management and the ability to modify the `exchange` parameter.\n\nThe owner can exploit this vulnerabi...

Vulnerable code:
```\nuint256 constant MAXIMUM_DEPOSIT_FEE = 5e16; // 5%\nuint256 constant DEFAULT_DEPOSIT_FEE = 0e16; // 0%\n\nuint256 constant MAXIMUM_PERFORMANCE_FEE = 50e16; // 50%\nuint256 constant DEFAULT_PERFORMANCE_FEE = 10e16; // 10%\n```\n```\nfunction gulp(uint256 _minRewardAmount) external onlyEOAorWhitelist nonReentrant {\n    uint256 _pendingReward = _getPendingReward();\n    if (_pendingReward > 0) {\n        _withdraw(0);\n    }\n\n    uint256 _totalReward = Transfers._getBalance(rewardToken);\n    uint256 _feeReward = _totalReward.mul(performanceFee) / 1e18;\n    Transfers._pushFunds(rewardToken, collector, _feeReward);\n\n    if (rewardToken!= routingToken) {\n        require(exchange!= address(0), "exchange not set");\n        uint256 _totalReward = Transfers._getBalance(rewardToken);\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        Transfers._approveFunds(routingToken, exchange, _totalRouting);\n        IExchange(exchange).joinPoolFromInput(reserveToken, routingToken, _totalRouting, 1);\n    }\n\n    uint256 _totalBalance = Transfers._getBalance(reserveToken);\n    require(_totalBalance >= _minRewardAmount, "high slippage");\n    _deposit(_totalBalance);\n}\n```
MEDIUM severity: The `Stream` contract, designed to receive ETH, lacks the implementation of a withdrawal function. T. The `Stream` contract, designed to receive ETH, lacks the implementation of a withdrawal function. This oversight allows ETH sent by users to become stuck in the contract, rendering it inaccessible for withdrawal. The contract's `Stream` instances can receive ETH normally, as demonstrated by the pro...

Vulnerable code:
```\ncontract StreamReceiveETHTest is StreamTest {\n    function setUp() public override {\n        super.setUp();\n    }\n\n    function test_receiveETH() public {\n        s = Stream(\n            factory.createStream(\n                payer, recipient, STREAM_AMOUNT, address(token), startTime, stopTime\n            )\n        );\n\n        vm.deal(payer, 10 ether);\n        vm.prank(payer);\n        (bool success, ) = address(s).call{value: 1 ether}("");\n        assertEq(success, true);\n        assertEq(address(s).balance, 1 ether);\n    }\n}\n```\n```\nRunning 1 test for test/Stream.t.sol:StreamReceiveETHTest\n[PASS] test_receiveETH() (gas: 167691)\nTest result: ok. 1 passed; 0 failed; finished in 1.25ms\n```
MEDIUM severity: The vulnerability lies in the initialization of all roles in the `__DramAccessControl_init_unchained. The vulnerability lies in the initialization of all roles in the `__DramAccessControl_init_unchained` function, where all roles are granted to the same `admin` address. This means that all roles are currently held by the same entity, which may not be the intended design. This could lead to potential...

Vulnerable code:
```\nfunction __DramAccessControl_init_unchained(\n    address admin\n) internal onlyInitializing {\n    _grantRole(ADMIN_ROLE, admin);\n    _grantRole(ROLE_MANAGER_ROLE, admin);\n    _grantRole(SUPPLY_MANAGER_ROLE, admin);\n}\n```
MEDIUM severity: The `supplyTokenTo` function in the Yearn contract is vulnerable to a re-entrancy attack during the . The `supplyTokenTo` function in the Yearn contract is vulnerable to a re-entrancy attack during the deposit process. Specifically, the function first mints shares based on the deposited amount, then transfers the tokens to the contract, and finally deposits the tokens into the yearn vault.\n\nThe is...

Vulnerable code:
```\nfunction supplyTokenTo(uint256 _amount, address to) override external {\n    uint256 shares = _tokenToShares(_amount);\n\n    _mint(to, shares);\n\n    // we have to deposit after calculating shares to mint\n    token.safeTransferFrom(msg.sender, address(this), _amount);\n\n    _depositInVault();\n\n    emit SuppliedTokenTo(msg.sender, shares, _amount, to);\n}\n```
MEDIUM severity: The `onFlag` function in the `VoteKickPolicy` contract, located in the `OperatorTokenomics` director. The `onFlag` function in the `VoteKickPolicy` contract, located in the `OperatorTokenomics` directory, contains a potential vulnerability related to front-running attacks. Specifically, an attacker could exploit the function's logic to manipulate the flagging process and potentially steal funds from...

Vulnerable code:
```\nFile: contracts/OperatorTokenomics/SponsorshipPolicies/VoteKickPolicy.sol\n\nfunction onFlag(address target, address flagger) external {\n    require(flagger!= target, "error_cannotFlagSelf");\n    require(voteStartTimestamp[target] == 0 && block.timestamp > protectionEndTimestamp[target], "error_cannotFlagAgain"); \n    require(stakedWei[flagger] >= minimumStakeOf(flagger), "error_notEnoughStake");\n    require(stakedWei[target] > 0, "error_flagTargetNotStaked");\n```
MEDIUM severity: The upgradeability of the contracts is compromised due to the absence of a proxy contract or factory. The upgradeability of the contracts is compromised due to the absence of a proxy contract or factory in the repository. Although the README mentions the use of OpenZeppelin's Proxy Upgrade Pattern, the implementation falls short of best practices. \n\nThe contracts are designed as standalone smart c...

Vulnerable code:
```\nEvery Pool is a standalone smart contract. It is made upgradeable with OpenZeppelin's Proxy Upgrade Pattern.\n```\n```\nAnd there will be multiple proxies and one implementation of the Pools, and one proxy and one implementation of EventAggregator.\n```
MEDIUM severity: The PythOracle's `_recordPrice` function is vulnerable to a significant price deviation issue when p. The PythOracle's `_recordPrice` function is vulnerable to a significant price deviation issue when processing prices with negative exponents. The function multiplies the `price` value by a factor that is calculated using the `expo` value. However, if the `expo` value is negative, the multiplication...

Vulnerable code:
```\nfunction _recordPrice(uint256 oracleVersion, PythStructs.Price memory price) private {\n    _prices[oracleVersion] = Fixed6Lib.from(price.price).mul(\n        Fixed6Lib.from(SafeCast.toInt256(\n            10 ** SafeCast.toUint256(price.expo > 0? price.expo : -price.expo)\n        ))\n    );\n    _publishTimes[oracleVersion] = price.publishTime;\n}\n```