Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The revoking of a vesting plan can inadvertently trigger a taxable event, resulting in the burning o. The revoking of a vesting plan can inadvertently trigger a taxable event, resulting in the burning of an NFT and the transfer of vested funds to the vesting plan holder. This unintended consequence arises from the current implementation, which does not provide the vesting plan holder with control ov...

Vulnerable code:
```\nfunction _revokePlan(address vestingAdmin, uint256 planId) internal {\n    Plan memory plan = plans[planId];\n    require(vestingAdmin == plan.vestingAdmin, '!vestingAdmin');\n\n    (uint256 balance, uint256 remainder,) = planBalanceOf(planId, block.timestamp, block.timestamp);\n    require(remainder > 0, '!Remainder');\n\n    address holder = ownerOf(planId);\n    delete plans[planId];\n    _burn(planId);\n    TransferHelper.withdrawTokens(plan.token, vestingAdmin, remainder);\n    TransferHelper.withdrawTokens(plan.token, holder, balance);\n    emit PlanRevoked(planId, balance, remainder);\n}\n```\n```\nfunction _revokePlan(address vestingAdmin, uint256 planId) internal {\n    Plan memory plan = plans[planId];\n    require(vestingAdmin == plan.vestingAdmin, '!vestingAdmin');\n\n    (uint256 balance, uint256 remainder,) = planBalanceOf(planId, block.timestamp, block.timestamp);\n    require(remainder > 0, '!Remainder');\n\n    address holder = ownerOf(planId);\n    delete plans[planId];\n    _burn(planId);\n\n    address vault = votingVaults[planId];\n    if (vault == address(0)) {\n        TransferHelper.withdrawTokens(plan.token, vestingAdmin, remainder);\n        TransferHelper.withdrawTokens(plan.token, holder, balance);\n    } else {\n        delete votingVaults[planId];\n        VotingVault(vault).withdrawTokens(vestingAdmin, remainder);\n        VotingVault(vault).withdrawTokens(holder, balance);\n    }\n\n    emit PlanRevoked(planId, balance, remainder);\n}\n```
MEDIUM severity: The `DKGResultVerification.verify` function in the provided code is vulnerable to an unsafe packing . The `DKGResultVerification.verify` function in the provided code is vulnerable to an unsafe packing issue in signed data. This vulnerability allows an attacker to manipulate the `groupPubKey` and `misbehaved` variables by moving bytes between them, which can lead to unauthorized modifications of the...

Vulnerable code:
```\nbytes32 resultHash = keccak256(abi.encodePacked(groupPubKey, misbehaved));\n```
MEDIUM severity: The vulnerability lies in the way the protocol handles the staking and reward mechanism for users. S. The vulnerability lies in the way the protocol handles the staking and reward mechanism for users. Specifically, when a user stakes their tokens, the protocol does not distinguish between the balance of the stake token and the balance of the payout token. This can lead to unintended consequences, pa...

Vulnerable code:
```\nstakeBalance[msg.sender] = userBalance + amount_\ntotalBalance += amount_\n\nstakedToken.safeTransferFrom(msg.sender, address(this), amount_)\n```\n```\npayoutToken.approve(address(optionTeller), rewards);\noptionTeller.create(optionToken, rewards);\n\nERC20(address(optionToken)).safeTransfer(msg.sender, rewards);\n```
MEDIUM severity: The Oracle.sol contract's `getUnderlyingPrice()` function retrieves the latest round data from Chain. The Oracle.sol contract's `getUnderlyingPrice()` function retrieves the latest round data from Chainlink, but it lacks a crucial mechanism to ensure that the returned price is within a reasonable range. Specifically, the function does not check if the retrieved price falls within the `minAnswer` and...

Vulnerable code:
```\nfunction getLatestRoundData(AggregatorV3Interface _aggregator)\n    internal\n    view\n    returns (\n        uint80,\n        uint256,\n        uint256\n    ) {\n    (\n        uint80 round,\n        int256 latestPrice,\n       ,\n        uint256 latestTimestamp,\n        uint256\n    ) = _aggregator.latestRoundData();\n    finalPrice = uint256(latestPrice);\n    if (latestPrice <= 0) {\n        requireEnoughHistory(round);\n        (\n            round,\n            finalPrice,\n            latestTimestamp\n        ) = getRoundData(_aggregator, round - 1);\n    }\n    return (\n        round,\n        finalPrice,\n        latestTimestamp\n    );\n}\n```
MEDIUM severity: The `linkNodeAddress` function allows validators to associate a node address with their own, effecti. The `linkNodeAddress` function allows validators to associate a node address with their own, effectively linking the two entities. This linking process is facilitated through the `_validatorAddressToId` mapping, which stores the validator ID corresponding to a given node address.\n\nThe `unlinkNodeA...

Vulnerable code:
```\nfunction linkNodeAddress(address validatorAddress, address nodeAddress) external allow("DelegationService") {\n    uint validatorId = getValidatorId(validatorAddress);\n    require(_validatorAddressToId[nodeAddress] == 0, "Validator cannot override node address");\n    _validatorAddressToId[nodeAddress] = validatorId;\n}\n\nfunction unlinkNodeAddress(address validatorAddress, address nodeAddress) external allow("DelegationService") {\n    uint validatorId = getValidatorId(validatorAddress);\n    require(_validatorAddressToId[nodeAddress] == validatorId, "Validator hasn't permissions to unlink node");\n    _validatorAddressToId[nodeAddress] = 0;\n}\n```
MEDIUM severity: The implementation of settlement slippage in the Boosted3TokenAuraHelper contract is flawed, as it f. The implementation of settlement slippage in the Boosted3TokenAuraHelper contract is flawed, as it fails to correctly apply the intended max slippage values based on the settlement type. Instead, the contract always limits the max slippage to the value of `balancerPoolSlippageLimitPercent`, which is...

Vulnerable code:
```\nparams.minPrimary = poolContext._getTimeWeightedPrimaryBalance(\n    oracleContext,\n    strategyContext,\n    bptToSettle\n);\n\nparams.minPrimary = params.minPrimary * strategyContext.vaultSettings.balancerPoolSlippageLimitPercent / uint256(BalancerConstants.VAULT_PERCENT_BASIS);\n```
MEDIUM severity: The `previewRedeem` and `redeem` functions in the LMPVault contract deviate from the ERC4626 specifi. The `previewRedeem` and `redeem` functions in the LMPVault contract deviate from the ERC4626 specification. Specifically, the `redeem` function may return fewer assets than the number of assets previewed by the `previewRedeem` function, which is not compliant with the specification.\n\nThe ERC4626 s...

Vulnerable code:
```\nFile: LMPVault.sol\n\nfunction redeem(\n    uint256 shares,\n    address receiver,\n    address owner\n) public virtual override nonReentrant noNavDecrease ensureNoNavOps returns (uint256 assets) {\n    uint256 maxShares = maxRedeem(owner);\n    if (shares > maxShares) {\n        revert ERC4626ExceededMaxRedeem(owner, shares, maxShares);\n    }\n    uint256 possibleAssets = previewRedeem(shares); // round down, which is correct because user won't get too many\n\n    assets = _withdraw(possibleAssets, shares, receiver, owner);\n}\n```\n```\nFile: LMPVault.sol\n\nfunction _withdraw(\n    uint256 assets,\n    uint256 shares,\n    address receiver,\n    address owner\n) internal virtual returns (uint256) {\n    uint256 idle = totalIdle;\n    WithdrawInfo memory info = WithdrawInfo({\n        currentIdle: idle,\n        assetsFromIdle: assets >= idle? idle : assets,\n        totalAssetsToPull: assets - (assets >= idle? idle : assets),\n        totalAssetsPulled: 0,\n        idleIncrease: 0,\n        debtDecrease: 0\n    });\n\n    if (info.totalAssetsToPull > 0) {\n        uint256 totalVaultShares = totalSupply();\n\n        uint256 withdrawalQueueLength = withdrawalQueue.length;\n        for (uint256 i = 0; i < withdrawalQueueLength; ++i) {\n            IDestinationVault destVault = IDestinationVault(withdrawalQueue[i]);\n            (uint256 sharesToBurn, uint256 totalDebtBurn) = _calcUserWithdrawSharesToBurn(\n                destVault,\n                shares,\n                info.totalAssetsToPull - Math.max(info.debtDecrease, info.totalAssetsPulled),\n                totalVaultShares\n            );\n\n            //...SNIP...\n\n        }\n\n        // At this point should have all the funds we need sitting in the vault\n        uint256 returnedAssets = info.assetsFromIdle + info.totalAssetsPulled;\n```
MEDIUM severity: The vulnerability lies in the state transition logic of a lending pool, specifically when the pool i. The vulnerability lies in the state transition logic of a lending pool, specifically when the pool is in a late state and has expired. The `_getLendingPoolStatus` function is responsible for determining the current state of the lending pool, which is used to determine whether capital should be locke...

Vulnerable code:
```\nfunction _getLendingPoolStatus(address _lendingPoolAddress)\n    internal\n    view\n    returns (LendingPoolStatus)\n{\n    if (!_isReferenceLendingPoolAdded(_lendingPoolAddress)) {\n        return LendingPoolStatus.NotSupported;\n    }\n\n    ILendingProtocolAdapter _adapter = _getLendingProtocolAdapter(_lendingPoolAddress);\n\n    if (_adapter.isLendingPoolExpired(_lendingPoolAddress)) {\n        return LendingPoolStatus.Expired;\n    }\n\n    if (\n        _adapter.isLendingPoolLateWithinGracePeriod(\n            _lendingPoolAddress,\n            Constants.LATE_PAYMENT_GRACE_PERIOD_IN_DAYS\n        )\n    ) {\n        return LendingPoolStatus.LateWithinGracePeriod;\n    }\n\n    if (_adapter.isLendingPoolLate(_lendingPoolAddress)) {\n        return LendingPoolStatus.Late;\n    }\n\n    return LendingPoolStatus.Active;\n}\n```
MEDIUM severity: This vulnerability allows a borrower to pay an excessive amount of fees and potentially be unfairly . This vulnerability allows a borrower to pay an excessive amount of fees and potentially be unfairly liquidated. When a borrower becomes partially liquidated, they can increase their collateral balance to avoid further liquidation. However, if they do so without updating the accrued loan rate per sec...

Vulnerable code:
```\n(borrowing.borrowedAmount,\n                borrowing.accLoanRatePerSeconds,\n                borrowing.dailyRateCollateralBalance,\n                accLoanRatePerSeconds\n            ) = _calculateCollateralBalance(\n                borrowing.borrowedAmount,\n                borrowing.accLoanRatePerSeconds,\n                borrowing.dailyRateCollateralBalance,\n                accLoanRatePerSeconds\n            );\n\nif (collateralBalance > 0) {\n    // rest of code\n} else {\n    currentFees = borrowing.dailyRateCollateralBalance; //entire collateral amount\n}\nborrowing.feesOwed += _pickUpPlatformFees(borrowing.holdToken, currentFees);\n```
MEDIUM severity: The vulnerability lies in the implementation of proxy contracts in the system, which allows for pote. The vulnerability lies in the implementation of proxy contracts in the system, which allows for potential front-running attacks. Specifically, the initialization of these contracts can be performed in a separate transaction, leaving them vulnerable to being claimed or front-run by malicious actors....

Vulnerable code:
```\nfunction initialize(\n    address _fujiadmin,\n    address _oracle,\n    address _collateralAsset,\n    address _borrowAsset\n) external initializer {\n```\n```\n"deployer": "0xb98d4D4e205aFf4d4755e9Df19bD0b8BD4e0f148",\n```\n```\n{\n"FujiAdmin": {\n    "address": "0xaAb2AAfBFf7419Ff85181d3A846bA9045803dd67",\n    "deployer": "0xb98d4D4e205afF4d4755E9Df19BD0B8BD4e0f148",\n    "abi": [\n        {\n            "anonymous": false,\n            //... rest of the code...\n        }\n    ]\n}\n```
MEDIUM severity: The `withdrawFromInsuranceFund` function in the Perpetual smart contract is responsible for allowing. The `withdrawFromInsuranceFund` function in the Perpetual smart contract is responsible for allowing administrators to withdraw funds from the insurance fund. The function checks that the requested withdrawal amount, `rawAmount`, is less than or equal to the current balance of the insurance fund, `i...

Vulnerable code:
```\nfunction withdrawFromInsuranceFund(uint256 rawAmount) public onlyWhitelistAdmin {\n    require(rawAmount > 0, "invalid amount");\n    require(insuranceFundBalance > 0, "insufficient funds");\n    require(rawAmount <= uint256(insuranceFundBalance), "insufficient funds");\n\n    int256 wadAmount = toWad(rawAmount);\n    insuranceFundBalance = insuranceFundBalance.sub(wadAmount);\n    withdrawFromProtocol(msg.sender, rawAmount);\n\n    require(insuranceFundBalance >= 0, "insurance fund balance is negative");\n\n    emit UpdateInsuranceFund(insuranceFundBalance);\n}\n```\n```\nawait perpetual.withdrawFromInsuranceFund(toWad(10.111));\n\nfund = await perpetual.insuranceFundBalance();\nassert.equal(fund.toString(), "0");\n```
MEDIUM severity: The `TransactionManager`'s `prepare`, `cancel`, and `fulfill` functions contain a common section tha. The `TransactionManager`'s `prepare`, `cancel`, and `fulfill` functions contain a common section that is executed on both the sending and receiving chains, as well as side-specific sections that are executed only on the sending or receiving side. This common section is intended to be executed on the...

Vulnerable code:
```\nrequire(relayerFee <= txData.amount, "#F:023")\n```
MEDIUM severity: The PeriodicPrizeStrategy contract's random number generation (RNG) mechanism is vulnerable to a sit. The PeriodicPrizeStrategy contract's random number generation (RNG) mechanism is vulnerable to a situation where user funds can become permanently locked. This occurs when a requested random number enters the mempool, and the contract is waiting for its execution between the `startAward()` and `comp...

Vulnerable code:
```\nfunction beforeTokenTransfer(address from, address to, uint256 amount, address controlledToken) external override onlyPrizePool {\n    if (controlledToken == address(ticket)) {\n        _requireNotLocked();\n    }\n}\n```\n```\nfunction _requireNotLocked() internal view {\n    uint256 currentBlock = _currentBlock();\n    require(rngRequest.lockBlock == 0 || currentBlock < rngRequest.lockBlock, "PeriodicPrizeStrategy/rng-in-flight");\n}\n```\n```\nfunction setRngService(RNGInterface rngService) external onlyOwner {\n    require(!isRngRequested(), "PeriodicPrizeStrategy/rng-in-flight");\n```
MEDIUM severity: The transfer of ERC-20 tokens with blacklist functionality within process functions in the system ca. The transfer of ERC-20 tokens with blacklist functionality within process functions in the system can lead to a denial-of-service (DoS) of the strategy vault. This vulnerability arises from the potential for blacklisted users to withdraw funds, causing the system to become stuck in a specific status...

Vulnerable code:
```\nfunction processDepositCancellation(\n    GMXTypes.Store storage self\n) external {\n    GMXChecks.beforeProcessDepositCancellationChecks(self);\n\n    // Transfer requested withdraw asset to user\n    IERC20(self.depositCache.depositParams.token).safeTransfer(\n        self.depositCache.user,\n        self.depositCache.depositParams.amt\n    );\n\n    self.status = GMXTypes.Status.Open;\n\n    emit DepositCancelled(self.depositCache.user);\n}\n```\n```\nfunction processDepositFailureLiquidityWithdrawal(\n  GMXTypes.Store storage self\n) public {\n  GMXChecks.beforeProcessAfterDepositFailureLiquidityWithdrawal(self);\n\n  // Refund user the rest of the remaining withdrawn LP assets\n  // Will be in tokenA/tokenB only; so if user deposited LP tokens\n  // they will still be refunded in tokenA/tokenB\n  self.tokenA.safeTransfer(self.depositCache.user, self.tokenA.balanceOf(address(this)));\n  self.tokenB.safeTransfer(self.depositCache.user, self.tokenB.balanceOf(address(this)));\n\n  self.status = GMXTypes.Status.Open;\n}\n```\n```\nfunction processWithdraw(\n  GMXTypes.Store storage self\n) external {\n  GMXChecks.beforeProcessWithdrawChecks(self);\n\n  try {\n    GMXProcessWithdraw.processWithdraw(self);\n  } catch {\n    if (self.withdrawCache.withdrawParams.token == address(self.WNT)) {\n      // rest of code\n    } else {\n      // Transfer requested withdraw asset to user\n      IERC20(self.withdrawCache.withdrawParams.token).safeTransfer(\n        self.withdrawCache.user,\n        self.withdrawCache.tokensToUser\n      );\n    }\n\n    // Transfer any remaining tokenA/B that was unused (due to slippage) to user as well\n    self.tokenA.safeTransfer(self.withdrawCache.user, self.tokenA.balanceOf(address(this)));\n    self.tokenB.safeTransfer(self.withdrawCache.user, self.tokenB.balanceOf(address(this)));\n  }\n\n  self.status = GMXTypes.Status.Open;\n}\n```
MEDIUM severity: The LinearVesting contract's `_sendPayout` function is designed to facilitate the transfer of payout. The LinearVesting contract's `_sendPayout` function is designed to facilitate the transfer of payouts to bidders. However, a critical validation check in the `mint` function of the LinearVesting derivative can lead to the failure of bidder payout claims when the derivative's expiry timestamp has bee...

Vulnerable code:
```\nfunction _sendPayout(\n    address recipient_,\n    uint256 payoutAmount_,\n    Routing memory routingParams_,\n    bytes memory\n) internal {\n    if (fromVeecode(derivativeReference) == bytes7("")) {\n        Transfer.transfer(baseToken, recipient_, payoutAmount_, true);\n    } else {\n        DerivativeModule module = DerivativeModule(_getModuleIfInstalled(derivativeReference));\n        Transfer.approve(baseToken, address(module), payoutAmount_);\n        module.mint(\n            recipient_,\n            address(baseToken),\n            routingParams_.derivativeParams,\n            payoutAmount_,\n            routingParams_.wrapDerivative\n        );\n    }\n```\n```\nfunction mint(\n    address to_,\n    address underlyingToken_,\n    bytes memory params_,\n    uint256 amount_,\n    bool wrapped_\n)\n    external\n    virtual\n    override\n    returns (uint256 tokenId_, address wrappedAddress_, uint256 amountCreated_)\n{\n    if (amount_ == 0) {\n        revert InvalidParams();\n    }\n\n    VestingParams memory params = _decodeVestingParams(params_);\n\n    if (_validate(underlyingToken_, params) == false) {\n        revert InvalidParams();\n    }\n```\n```\nfunction _validate(\n    address underlyingToken_,\n    VestingParams memory data_\n) internal view returns (bool) {\n    if (data_.expiry < block.timestamp) {\n        return false;\n    }\n\n    if (underlyingToken_ == address(0)) {\n        return false;\n    }\n\n    return true;\n}\n```
MEDIUM severity: The vulnerability arises when a loan is fully repaid, as the `loan` storage is deleted, which in tur. The vulnerability arises when a loan is fully repaid, as the `loan` storage is deleted, which in turn deletes the `loan` reference. This results in `loan.lender` being set to `address(0)`, causing the debt payment to be sent to an unintended recipient, potentially leading to the loss of the payment.

Vulnerable code:
```\nfunction repay(uint256 loanID, uint256 repaid) external {\n    Loan storage loan = loans[loanID];\n\n    if (block.timestamp > loan.expiry) {\n        revert Default();\n    }\n\n    uint256 decollateralized = loan.collateral * repaid / loan.amount;\n\n    if (repaid == loan.amount) {\n        delete loans[loanID];\n    } else {\n        loan.amount -= repaid;\n        loan.collateral -= decollateralized;\n    }\n\n    debt.transferFrom(msg.sender, loan.lender, repaid);\n    collateral.transfer(owner, decollateralized);\n}\n```
MEDIUM severity: The vulnerability allows malicious users to block liquidators from liquidating their accounts, creat. The vulnerability allows malicious users to block liquidators from liquidating their accounts, creating unfairness in the system and resulting in a loss of profits to the counterparty. This is achieved by incrementing the nonce of the account being liquidated, thereby rendering the liquidation trans...

Vulnerable code:
```\nFile: LiquidationFacetImpl.sol\n\nfunction liquidatePartyA(address partyA, SingleUpnlSig memory upnlSig) internal {\n    MAStorage.Layout storage maLayout = MAStorage.layout();\n\n    LibMuon.verifyPartyAUpnl(upnlSig, partyA);\n\n    int256 availableBalance = \n        LibAccount.partyAAvailableBalanceForLiquidation(\n            upnlSig.upnl,\n            partyA\n        );\n\n    require(availableBalance < 0, "LiquidationFacet: PartyA is solvent");\n\n    maLayout.liquidationStatus[partyA] = true;\n    maLayout.liquidationTimestamp[partyA] = upnlSig.timestamp;\n    AccountStorage.layout().liquidators[partyA].push(msg.sender);\n}\n```\n```\nfunction verifyPartyAUpnl(SingleUpnlSig memory upnlSig, address partyA) internal view {\n    MuonStorage.Layout storage muonLayout = MuonStorage.layout();\n    bytes32 hash = keccak256(\n        abi.encodePacked(\n            muonLayout.muonAppId,\n            upnlSig.reqId,\n            address(this),\n            partyA,\n            AccountStorage.layout().partyANonces[partyA],\n            upnlSig.upnl,\n            upnlSig.timestamp,\n            getChainId()\n        )\n    );\n    verifyTSSAndGateway(hash, upnlSig.sigs, upnlSig.gatewaySignature);\n}\n```\n```\nfunction liquidatePartyB(\n    //...SNIP...\n    LibMuon.verifyPartyBUpnl(upnlSig, partyB, partyA);\n```
MEDIUM severity: The ERC20 compatibility of the Amp token's implementation is unclear due to the use of both the `def. The ERC20 compatibility of the Amp token's implementation is unclear due to the use of both the `default` partition and separate fields for aggregated balances and allowances. This redundancy raises questions about the relevance of each field in different contexts.\n\nThe `default` partition is util...

Vulnerable code:
```\nemit ApprovalByPartition(\n    _partition,\n    _tokenHolder,\n    _spender,\n    _amount\n);\n```
MEDIUM severity: The `DecimalSafeMath` library, used in the 3 FairSwap repositories, exhibits an inconsistency in its. The `DecimalSafeMath` library, used in the 3 FairSwap repositories, exhibits an inconsistency in its implementation of the `decimalDiv` function. This function is responsible for performing safe division operations on decimal values, ensuring that the result is accurate and reliable.\n\nThe first im...

Vulnerable code:
```\nlibrary DecimalSafeMath {\n    function decimalDiv(uint256 a, uint256 b) internal pure returns (uint256) {\n        uint256 a_ = a * 1000000000000000000;\n        uint256 c = a_ / b;\n        return c;\n    }\n}\n```\n```\nlibrary DecimalSafeMath {\n\n    function decimalDiv(uint256 a, uint256 b) internal pure returns (uint256) {\n        assert(b > 0);\n        uint256 c = (a * 1000000000000000000) / b;\n        return c;\n    }\n}\n```
MEDIUM severity: The vulnerability allows an attacker to manipulate the subaccount allocation process, making it extr. The vulnerability allows an attacker to manipulate the subaccount allocation process, making it extremely expensive for users to create strategies. In the Console architecture, users can deploy spare subaccounts (Gnosis Safes) to optimize gas spending during strategy subscription. However, an attack...

Vulnerable code:
```\nfunction deploySpareSubAccount(address _wallet) external {\n    address subAccount = SafeDeployer(addressProvider.safeDeployer()).deploySubAccount(_wallet);\n    subAccountToWalletMap[subAccount] = _wallet;\n    walletToSubAccountMap[_wallet].push(subAccount);\n    emit SubAccountAllocated(_wallet, subAccount);\n}\n```\n```\nfunction requestSubAccount(address _wallet) external returns (address) {\n    if (msg.sender!= subscriptionRegistry) \n        revert OnlySubscriptionRegistryCallable();\n    address[] memory subAccountList = walletToSubAccountMap[_wallet];\n}\n```