Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: This vulnerability occurs when tokens with more than 18 decimal points are used in the `getSellRate`. This vulnerability occurs when tokens with more than 18 decimal points are used in the `getSellRate` function. The function is designed to handle tokens with a maximum of 18 decimal points, as assumed by the developers. However, in rare cases, tokens with more than 18 decimal points, such as YAMv2 w...

Vulnerable code:
```\nfunction getSellRate(address _srcAddr, address _destAddr, uint _srcAmount, bytes memory) public override view returns (uint rate) {\n    (rate, ) = KyberNetworkProxyInterface(KYBER_INTERFACE)\n       .getExpectedRate(IERC20(_srcAddr), IERC20(_destAddr), _srcAmount);\n\n    rate = rate * (10 ** (18 - getDecimals(_srcAddr)));\n    rate = rate / (10 ** (18 - getDecimals(_destAddr)));\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of pool IDs, which are currently represented as `bytes3. The vulnerability lies in the implementation of pool IDs, which are currently represented as `bytes32` values that increment by `2**128`. This design was initially intended to accommodate a feature that was ultimately not used. As a result, the pool IDs are not incrementing integers as expected.\n\n...

Vulnerable code:
```\nbytes32 constant internal INITIAL_POOL_ID = 0x0000000000000000000000000000000100000000000000000000000000000000;\n\nuint256 constant internal POOL_ID_INCREMENT_AMOUNT = 0x0000000000000000000000000000000100000000000000000000000000000000;\n```\n```\nfunction _computeNextStakingPoolId(bytes32 poolId)\n    internal\n    pure\n    returns (bytes32)\n{\n    return bytes32(uint256(poolId).add(POOL_ID_INCREMENT_AMOUNT));\n}\n```
MEDIUM severity: The `OrchidDirectory.pull()` method is responsible for reattaching a child node from a removed tree . The `OrchidDirectory.pull()` method is responsible for reattaching a child node from a removed tree node. However, a critical issue arises in the code responsible for reattaching the child node. The condition `name(stake.left_) == key` is always false, as `key` is the key associated with the `stake`...

Vulnerable code:
```\nif (name(stake.left_) == key):\n    current.right_ = stake.right_\n    current.after_ = stake.after_\nelse:\n    current.left_ = stake.left_\n    current.before_ = stake.before_\n```
MEDIUM severity: The vulnerability arises from an incorrect assumption made in the migration of withdrawals from the . The vulnerability arises from an incorrect assumption made in the migration of withdrawals from the legacy system to the new Bedrock system. Specifically, the CrossDomainMessenger's gas limit is set to zero, which is an incorrect assumption as it is not replayable. This can lead to a situation where...

Vulnerable code:
```\nfunc MigrateWithdrawal(withdrawal *LegacyWithdrawal, l1CrossDomainMessenger *common.Address) (*Withdrawal, error) {\n    value, err := withdrawal.Value()\n    if err!= nil {\n        return nil, fmt.Errorf("cannot migrate withdrawal: %w", err)\n    }\n\n    abi, err := bindings.L1CrossDomainMessengerMetaData.GetAbi()\n    if err!= nil {\n        return nil, err\n    }\n\n    versionedNonce := EncodeVersionedNonce(withdrawal.XDomainNonce, new(big.Int))\n\n    data, err := abi.Pack(\n        "relayMessage",\n        versionedNonce,\n        withdrawal.XDomainSender,\n        withdrawal.XDomainTarget,\n        value,\n        new(big.Int),  // <= THIS IS THE INNER GAS LIMIT BEING SET TO ZERO\n        []byte(withdrawal.XDomainData),\n    )\n    if err!= nil {\n        return nil, fmt.Errorf("cannot abi encode relayMessage: %w", err)\n    }\n\n    gasLimit := MigrateWithdrawalGasLimit(data)\n\n    w := NewWithdrawal(\n        versionedNonce,\n        &predeploys.L2CrossDomainMessengerAddr,\n        l1CrossDomainMessenger,\n        value,\n        new(big.Int).SetUint64(gasLimit),  // <= THIS IS THE OUTER GAS LIMIT BEING SET\n        data,\n    )\n    return w, nil\n}\n```\n```\nfunc MigrateWithdrawalGasLimit(data []byte) uint64 {\n    dataCost := uint64(0)\n    for _, b := range data {\n        if b == 0 {\n            dataCost += params.TxDataZeroGas\n        } else {\n            dataCost += params.TxDataNonZeroGasEIP2028\n        }\n    }\n\n    gasLimit := dataCost + 200000\n    if gasLimit > 25000000 {\n        gasLimit = 25000000\n    }\n\n    return gasLimit\n```
MEDIUM severity: The `_isActive()` and `_isEligible()` functions, which are utilized by the `balanceOf()` and other f. The `_isActive()` and `_isEligible()` functions, which are utilized by the `balanceOf()` and other functions, are critical components of the smart contract's logic. However, these functions perform ABI decoding from external inputs, which can lead to a potential vulnerability if not properly sanitiz...

Vulnerable code:
```\nfunction _isActive(Hat memory _hat, uint256 _hatId) internal view returns (bool) {\n    bytes memory data = abi.encodeWithSignature("getHatStatus(uint256)", _hatId);\n    (bool success, bytes memory returnData) = _hat.toggle.staticcall(data);\n    if (success && returnData.length > 0) {\n        return abi.decode(returnData, (bool));\n    } else {\n        return _getHatStatus(_hat);\n    }\n}\n```
MEDIUM severity: The Centralization risk vulnerability arises from the lack of proper validation and logging mechanis. The Centralization risk vulnerability arises from the lack of proper validation and logging mechanisms in the protocol's admin functions. Specifically, the `onlyOwner` modifier allows the owner to modify critical settings, such as fee values, reward handlers, and token addresses, without adequate ch...

Vulnerable code:
```\nfunction setFeeValue(uint256 feeValue) external onlyOwner {\n    require(feeValue < _feeDenominator, "Fee percentage must be less than 1");\n    _feeValue = feeValue;\n}\n\nfunction setFixedFee(uint256 fixedFee) external onlyOwner {\n    _fixedFee = fixedFee;\n}\n```\n```\npragma solidity ^0.8.0;\n\ncontract FeeData {\n    function setFeeValue(uint256 feeValue) external onlyOwner {\n        // Set the fee value\n    }\n\n    function setMaxHops(uint256 maxHops) external onlyOwner {\n        // Set the maximum hops\n    }\n\n    function setMaxSwaps(uint256 maxSwaps) external onlyOwner {\n        // Set the maximum swaps\n    }\n\n    function setFixedFee(uint256 fixedFee) external onlyOwner {\n        // Set the fixed fee\n    }\n\n    function setFeeToken(address feeTokenAddress) public onlyOwner {\n        // Set the fee token address\n    }\n\n    function setFeeTokens(address[] memory feeTokenAddresses) public onlyOwner {\n        // Set the fee token addresses\n    }\n\n    function clearFeeTokens() public onlyOwner {\n        // Clear the fee tokens\n    }\n}\n```\n```\npragma solidity ^0.8.0;\n\ncontract TransferHelper {\n    address public rewardAddress;\n\n    function setRewardHandler(address rewardAddress) external onlyOwner {\n        rewardAddress = rewardAddress;\n    }\n\n    function setRewardsActive(bool _rewardsActive) external onlyOwner {\n        // Add your code here\n    }\n}\n```
MEDIUM severity: The vulnerability allows malicious keepers to manipulate the price when executing an order, potentia. The vulnerability allows malicious keepers to manipulate the price when executing an order, potentially leading to a loss of assets for the victim's party. This is achieved by bypassing the requirement to update the Pyth price to the latest one available off-chain. The keeper can do this by passing...

Vulnerable code:
```\nFile: DelayedOrder.sol\n\nfunction executeOrder(\n    address account,\n    bytes[] calldata priceUpdateData\n)\n    external\n    payable\n    nonReentrant\n    whenNotPaused\n    updatePythPrice(vault, msg.sender, priceUpdateData)\n    orderInvariantChecks(vault)\n{\n    settleFundingFees();\n    //...\n```\n```\nFile: OracleModifiers.sol\n\nmodifier updatePythPrice(\n    IFlatcoinVault vault,\n    address sender,\n    bytes[] calldata priceUpdateData\n) {\n    IOracleModule(vault.moduleAddress(FlatcoinModuleKeys._ORACLE_MODULE_KEY)).updatePythPrice{value: msg.value}(\n        sender,\n        priceUpdateData\n    );\n    _\n}\n```\n```\nFile: OracleModule.sol\n\nfunction updatePythPrice(address sender, bytes[] calldata priceUpdateData) external payable nonReentrant {\n    uint256 fee = offchainOracle.oracleContract.getUpdateFee(priceUpdateData);\n\n    offchainOracle.oracleContract.updatePriceFeeds{value: fee}(priceUpdateData);\n\n    if (msg.value - fee > 0) {\n        (bool success,) = sender.call{value: msg.value - fee}("");\n        if (success == false) revert FlatcoinErrors.RefundFailed();\n    }\n}\n```\n```\nfunction updatePriceFeeds(\n    bytes[] calldata updateData\n) public payable override {\n    uint totalNumUpdates = 0;\n    for (uint i = 0; i < updateData.length; i++) {\n        if (updateData[i].length > 4 &&\n            UnsafeCalldataBytesLib.toUint32(updateData[i], 0) ==\n            ACCUMULATOR_MAGIC) {\n            totalNumUpdates += updatePriceInfosFromAccumulatorUpdate(updateData[i]);\n        } else {\n            updatePriceBatchFromVm(updateData[i]);\n            totalNumUpdates += 1;\n        }\n    }\n    uint requiredFee = getTotalFee(totalNumUpdates);\n    if (msg.value < requiredFee) revert PythErrors.InsufficientFee();\n```
MEDIUM severity: The zDAO Token implementation is vulnerable due to a specification violation, where the `_snapshot(). The zDAO Token implementation is vulnerable due to a specification violation, where the `_snapshot()` method is not being called, thereby preventing the creation of snapshots. This is a critical issue, as the zDAO Token specification explicitly requires that any transfer, mint, or burn operation sho...

Vulnerable code:
```\ncontract ZeroDAOToken is\n    OwnableUpgradeable,\n    ERC20Upgradeable,\n    ERC20PausableUpgradeable,\n    ERC20SnapshotUpgradeable\n{\n```\n```\n_updateAccountSnapshot(sender)\n```
MEDIUM severity: The PerpDepository contract's rebalancing mechanism, which aims to maintain delta neutrality by exch. The PerpDepository contract's rebalancing mechanism, which aims to maintain delta neutrality by exchanging base to quote, inadvertently creates an irretrievable USDC holding. This occurs when negative PNL is rebalanced into USDC, which is then added to the system's vault. Although this preserves the...

Vulnerable code:
```\nfunction withdrawInsurance(uint256 amount, address to)\n    external\n    nonReentrant\n    onlyOwner\n{\n    if (amount == 0) {\n        revert ZeroAmount();\n    }\n\n    insuranceDeposited -= amount;\n\n    vault.withdraw(insuranceToken(), amount);\n\n    IERC20(insuranceToken()).transfer(to, amount);\n\n    emit InsuranceWithdrawn(msg.sender, to, amount);\n}\n```
MEDIUM severity: The `reinvestReward()` function in the smart contract is vulnerable to a potential issue that can ca. The `reinvestReward()` function in the smart contract is vulnerable to a potential issue that can cause the vault to enter an abnormal state. This occurs when the first user deposits a small amount, resulting in a loss of precision due to the conversion to `INTERNAL_TOKEN_PRECISION`. This can lead t...

Vulnerable code:
```\nfunction _mintVaultShares(uint256 lpTokens) internal returns (uint256 vaultShares) {\n    StrategyVaultState memory state = VaultStorage.getStrategyVaultState();\n    if (state.totalPoolClaim == 0) {\n        vaultShares = (lpTokens * uint256(Constants.INTERNAL_TOKEN_PRECISION)) / POOL_PRECISION();\n    } else {\n        vaultShares = (lpTokens * state.totalVaultSharesGlobal) / state.totalPoolClaim;\n    }\n\n    state.totalPoolClaim += lpTokens;\n    state.totalVaultSharesGlobal += vaultShares.toUint80();\n    state.setStrategyVaultState();\n}\n```\n```\nfunction reinvestReward(\n    SingleSidedRewardTradeParams[] calldata trades,\n    uint256 minPoolClaim\n) external whenNotLocked onlyRole(REWARD_REINVESTMENT_ROLE) returns (\n    address rewardToken,\n    uint256 amountSold,\n    uint256 poolClaimAmount\n) {\n    _checkPriceAndCalculateValue();\n\n    require(trades.length == NUM_TOKENS());\n\n    uint256[] memory amounts;\n    (rewardToken, amountSold, amounts) = _executeRewardTrades(trades);\n\n    poolClaimAmount = _joinPoolAndStake(amounts, minPoolClaim);\n\n    StrategyVaultState memory state = VaultStorage.getStrategyVaultState();\n    state.totalPoolClaim += poolClaimAmount;\n    state.setStrategyVaultState();\n\n    emit RewardReinvested(rewardToken, amountSold, poolClaimAmount);\n}\n```
MEDIUM severity: The vulnerability in the RocketRewardPool system allows for unpredictable staking rewards, as nodes . The vulnerability in the RocketRewardPool system allows for unpredictable staking rewards, as nodes can add stake just before claiming rewards, potentially earning rewards for periods they did not provide a service to the system. This can lead to unfair outcomes for other participants, as the effect...

Vulnerable code:
```\n-- reward period ends -- front-run other claimers to maximize profits\n\n[create x minipools]\n\n[stake to max effective RPL for amount of minipools; locked for 14 days]\n\n[claim rewards for inflated effective RPL stake]\n\n[dissolve(), close() minipools -> refund NETH]\n\n[burn NETH for ETH]\n\n// rest of code\nwait 14 days\n\n[withdraw stake\n  OR\nstart again\n  creating Minipools, claiming rewards\n  while the Minipools are dissolved\n  right after, freeing the ETH]\n```\n```\n[stake max effective amount for the number of minipools]\n\n[claim() to claim the previous period even though we did not provide any stake for the duration]\n\n[optionally dissolve Minipools unlocking ETH]\n\n-- stake is locked for at least 14 days --\n\n-- 14 days forward - new reward period started --\n[claim() the period]\n\n[withdraw() (leaving min pool stake OR everything if we dissolve all the Minipools)]\n\n[lend RPL to other platforms and earn interest]\n\n-- 14 days forward - new reward period started --\n[get RPL back from another platform]\n\n[stake & create minipools to inflate effective stake]\n\n[claim()]\n\n[optionally dissolve Minipools to unlock node ETH]\n\n-- stake is locked for at least 14 days --\n\n-- 14 days forward - new reward period started --\n[claim() the period]\n\n[withdraw() (leaving min pool stake OR everything if we dissolve all the Minipools)]\n\n[lend RPL to other platforms and earn interest]\n```\n```\nrequire(block.number.sub(getNodeRPLStakedBlock(msg.sender)) >= rocketDAOProtocolSettingsRewards.getRewardsClaimIntervalBlocks(), "The withdrawal cooldown period has not passed");\nrequire(getNodeRPLStakedBlock(msg.sender) >= rocketDAOProtocolSettingsRewards.getRewardsClaimIntervalBlocks(), "The withdrawal cooldown period has not passed");\n```
MEDIUM severity: The `PolicyBook` contract's `approveAllDaiTokensForStakingAndVotingAndTransferOwnership` function gr. The `PolicyBook` contract's `approveAllDaiTokensForStakingAndVotingAndTransferOwnership` function grants unrestricted allowance over DAI tokens to two other contracts, `bmiDaiStaking` and `claimVoting`, by approving them to spend an unlimited amount (`MAX_INT`) of DAI tokens. Additionally, the funct...

Vulnerable code:
```\nfunction approveAllDaiTokensForStakingAndVotingAndTransferOwnership() internal {\n    daiToken.approve(address(bmiDaiStaking), uint256(MAX_INT));\n    daiToken.approve(address(claimVoting), uint256(MAX_INT));\n\n    transferOwnership(address(bmiDaiStaking));\n}\n```
MEDIUM severity: The `claimERC20Prize()` function in the FootiumPrizeDistributor contract allows whitelisted users to. The `claimERC20Prize()` function in the FootiumPrizeDistributor contract allows whitelisted users to claim ERC20 tokens. However, when a no-revert-on-failure token is used, this function can lead to a critical issue. Specifically, if a user attempts to claim a token amount that exceeds the contract'...

Vulnerable code:
```\nif (value > 0) {\n    totalERC20Claimed[_token][_to] += value;\n    _token.transfer(_to, value);\n}\n```
MEDIUM severity: The `Pod` contract's `drop` storage field and mapping of different `TokenDrops` (token => `TokenDrop. The `Pod` contract's `drop` storage field and mapping of different `TokenDrops` (token => `TokenDrop`) exhibit an inconsistency. Specifically, when a new `TokenDrop` is added to the mapping, the `drop` field is updated to reference the newly added `TokenDrop`. This behavior is problematic because it...

Vulnerable code:
```\nfunction setTokenDrop(address _token, address _tokenDrop)\n    external\n    returns (bool)\n{\n    require(\n        msg.sender == factory || msg.sender == owner(),\n        "Pod:unauthorized-set-token-drop"\n    );\n\n    require(\n        drops[_token] == TokenDrop(0),\n        "Pod:target-tokendrop-mapping-exists"\n    );\n\n    drop = TokenDrop(_tokenDrop);\n\n    drops[_token] = drop;\n\n    return true;\n}\n```
MEDIUM severity: The BufferBinaryPool's exchange rate calculation mechanism is vulnerable to manipulation, allowing e. The BufferBinaryPool's exchange rate calculation mechanism is vulnerable to manipulation, allowing early depositors to exploit the system and steal funds from later depositors. The exchange rate is determined by dividing the total supply of shares by the total `tokenXBalance` of the vault. However,...

Vulnerable code:
```\nfunction totalTokenXBalance()\n    public\n    view\n    override\n    returns (uint256 balance)\n{\n    return tokenX.balanceOf(address(this)) - lockedPremium;\n}\n```
MEDIUM severity: The ChainlinkAdapterOracle, a crucial component in many popular yield strategies, is incompatible wi. The ChainlinkAdapterOracle, a crucial component in many popular yield strategies, is incompatible with wstETH due to its design limitations. Specifically, the oracle is only capable of retrieving single-asset price data, which is not sufficient for wstETH, a wrapped version of ETH that tracks the pr...

Vulnerable code:
```\nuint256 decimals = registry.decimals(token, USD);\n\n(\n    uint80 roundID,\n    int256 answer,\n   ,\n    uint256 updatedAt,\n    uint80 answeredInRound\n) = registry.latestRoundData(token, USD);\n\nif (updatedAt < block.timestamp - maxDelayTime)\n    revert Errors.PRICE_OUTDATED(token_);\n\nif (answer <= 0)\n    revert Errors.PRICE_NEGATIVE(token_);\n\nif (answeredInRound < roundID)\n    revert Errors.PRICE_OUTDATED(token_);\n\nreturn (answer.toUint256() * Constants.PRICE_PRECISION) / (10 ** decimals);\n```
MEDIUM severity: A malicious user can bypass limit order trading fees by exploiting a re-entrancy vulnerability in th. A malicious user can bypass limit order trading fees by exploiting a re-entrancy vulnerability in the `LeverageModule` contract. This vulnerability arises from the `_safeMint` function's external call to the receiver of the NFT, which allows an attacker to manipulate the state of the `_positions` ma...

Vulnerable code:
```\nuint256 tradeFee = \nILeverageModule(vault.moduleAddress(FlatcoinModuleKeys._LEVERAGE_MODULE_KEY)).getTradeFee(\n    vault.getPosition(tokenId).additionalSize\n);\n```
MEDIUM severity: The setPositionRouter function in GMXFuturesPoolHedger allows the owner to update the positionRouter. The setPositionRouter function in GMXFuturesPoolHedger allows the owner to update the positionRouter, which is responsible for managing GMX positions. This update involves replacing the existing positionRouter with a new one, which is approved by the contract. However, the approval to the previous p...

Vulnerable code:
```\nfunction setPositionRouter(IPositionRouter _positionRouter) external onlyOwner {\n    positionRouter = _positionRouter;\n    router.approvePlugin(address(positionRouter));\n    emit PositionRouterSet(_positionRouter);\n}\n```
MEDIUM severity: The `BTCUtils` library in the Bitcoin SPV implementation exhibits an inefficient memory allocation p. The `BTCUtils` library in the Bitcoin SPV implementation exhibits an inefficient memory allocation pattern when working with byte arrays. Specifically, it relies heavily on the `BytesLib.slice` function, which creates a new, freshly-allocated slice of an existing bytes array. This approach is often...

Vulnerable code:
```\nfunction extractInputTxIdLE(bytes memory _input) internal pure returns (bytes32) {\n    return _input.slice(0, 32).toBytes32();\n}\n```\n```\nuint _idx = _index;\nbytes32 _root = _proof.slice(_proof.length - 32, 32).toBytes32();\nbytes32 _current = _proof.slice(0, 32).toBytes32();\n\nfor (uint i = 1; i < (_proof.length / 32) - 1; i++) {\n    if (_idx % 2 == 1) {\n        _current = _hash256MerkleStep(_proof.slice(i * 32, 32), abi.encodePacked(_current));\n    } else {\n        _current = _hash256MerkleStep(abi.encodePacked(_current), _proof.slice(i * 32, 32));\n    }\n    _idx = _idx + 1;\n}\nreturn _current == _root;\n```
MEDIUM severity: The `Fliquidator` contract's `batchLiquidate` function is vulnerable to a funds loss issue when proc. The `Fliquidator` contract's `batchLiquidate` function is vulnerable to a funds loss issue when processing transactions involving the native token `FTM`. Specifically, if a caller provides more `FTM` tokens than the required `debtTotal` amount, the excess funds are not returned to the caller and rem...

Vulnerable code:
```\nif (vAssets.borrowAsset == FTM) {\n    require(msg.value >= debtTotal, Errors.VL_AMOUNT_ERROR);\n} else {\n    //...\n```
MEDIUM severity: This vulnerability occurs when the unlocked capital in a pool falls below the minimum required capit. This vulnerability occurs when the unlocked capital in a pool falls below the minimum required capital, allowing protection to be purchased at a minimum premium. This is a critical issue as it can lead to unexpected and potentially catastrophic consequences.\n\nThe issue arises in the `PremiumCalcul...

Vulnerable code:
```\nif (\n  RiskFactorCalculator.canCalculateRiskFactor(\n    _totalCapital,\n    _leverageRatio,\n    _poolParameters.leverageRatioFloor,\n    _poolParameters.leverageRatioCeiling,\n    _poolParameters.minRequiredCapital\n  )\n) {\n  // rest of code\n} else {\n  _isMinPremium = true;\n}\n```\n```\nfunction canCalculateRiskFactor(\n    uint256 _totalCapital,\n    uint256 _leverageRatio,\n    uint256 _leverageRatioFloor,\n    uint256 _leverageRatioCeiling,\n    uint256 _minRequiredCapital\n) external pure returns (bool _canCalculate) {\n    if (\n        _totalCapital < _minRequiredCapital ||\n        _leverageRatio < _leverageRatioFloor ||\n        _leverageRatio > _leverageRatioCeiling\n    ) {\n        _canCalculate = false;\n    } else {\n        _canCalculate = true;\n    }\n}\n```