Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The create fee discount feature in the protocol is found to be broken due to the absence of initiali. The create fee discount feature in the protocol is found to be broken due to the absence of initialization for the `createFeeDiscount` state variable. This variable is crucial in determining the fee to be discounted from the protocol fee. Without proper initialization, the `createFeeDiscount` variab...

Vulnerable code:
```\nFile: BondFixedExpiryTeller.sol\n\nif (protocolFee > createFeeDiscount) {\n    uint256 feeAmount = amount_.mulDiv(protocolFee - createFeeDiscount, FEE_DECIMALS);\n    rewards[_protocol][underlying_] += feeAmount;\n\n    bondToken.mint(msg.sender, amount_ - feeAmount);\n\n    return (bondToken, amount_ - feeAmount);\n} else {\n    bondToken.mint(msg.sender, amount_);\n\n    return (bondToken, amount_);\n}\n```\n```\nFile: BondFixedTermTeller.sol\n\nif (protocolFee > createFeeDiscount) {\n    uint256 feeAmount = amount_.mulDiv(protocolFee - createFeeDiscount, FEE_DECIMALS);\n    rewards[_protocol][underlying_] += feeAmount;\n\n    _mintToken(msg.sender, tokenId, amount_ - feeAmount);\n\n    return (tokenId, amount_ - feeAmount);\n} else {\n    _mintToken(msg.sender, tokenId, amount_);\n\n    return (tokenId, amount_);\n}\n```
MEDIUM severity: The vulnerability lies in the lack of validation against the decimal of the secondary token in the `. The vulnerability lies in the lack of validation against the decimal of the secondary token in the `TwoTokenPoolMixin` contract. Specifically, a typo in Line 65 causes the validation check to be performed against the `primaryDecimals` variable instead of the intended `secondaryDecimals` variable. Th...

Vulnerable code:
```\nFile: TwoTokenPoolMixin.sol\n\nconstructor(\n    NotionalProxy notional_,\n    AuraVaultDeploymentParams memory params\n) PoolMixin(notional_, params) {\n    // If the underlying is ETH, primaryBorrowToken will be rewritten as WETH\n    uint256 primaryDecimals = IERC20(primaryAddress).decimals();\n    // Do not allow decimal places greater than 18\n    require(primaryDecimals <= 18);\n    PRIMARY_DECIMALS = uint8(primaryDecimals);\n\n    uint256 secondaryDecimals = address(SECONDARY_TOKEN) == \n        Deployments.ETH_ADDRESS\n       ? 18\n        : SECONDARY_TOKEN.decimals();\n    require(secondaryDecimals <= 18);\n    SECONDARY_DECIMALS = uint8(secondaryDecimals);\n```\n```\nFile: Stable2TokenOracleMath.sol\n\nfunction _getSpotPrice(\n    StableOracleContext memory oracleContext, \n    TwoTokenPoolContext memory poolContext, \n    uint256 tokenIndex\n) internal view returns (uint256 spotPrice) {\n    require(poolContext.primaryDecimals < 19); \n    require(poolContext.secondaryDecimals < 19); \n    require(tokenIndex < 2);\n```
MEDIUM severity: The `Funds.update()` function allows users to modify various fields related to a specific fund, incl. The `Funds.update()` function allows users to modify various fields related to a specific fund, including `minLoanamt`, `maxLoanAmt`, `minLoanDur`, `interest`, `penalty`, `fee`, and `liquidationRatio`. However, these fields only have an effect if the `bools[fund].custom` flag is set. If this flag is...

Vulnerable code:
```\nfunction update(\n    bytes32  fund,\n    uint256  minLoanAmt_,\n    uint256  maxLoanAmt_,\n    uint256  minLoanDur_,\n    uint256  maxLoanDur_,\n    uint256  maxFundDur_,\n    uint256  interest_,\n    uint256  penalty_,\n    uint256  fee_,\n    uint256  liquidationRatio_,\n    address  arbiter_\n) external {\n    require(msg.sender == lender(fund));\n    funds[fund].minLoanAmt = minLoanAmt_;\n    funds[fund].maxLoanAmt = maxLoanAmt_;\n    funds[fund].minLoanDur = minLoanDur_;\n    funds[fund].maxLoanDur = maxLoanDur_;\n    funds[fund].maxFundDur = maxFundDur_;\n    funds[fund].interest = interest_;\n    funds[fund].penalty = penalty_;\n    funds[fund].fee = fee_;\n    funds[fund].liquidationRatio = liquidationRatio_;\n    funds[fund].arbiter = arbiter_;\n}\n```
MEDIUM severity: The `claim` function in the `TokenDrop` contract is vulnerable to re-entrancy attacks due to its des. The `claim` function in the `TokenDrop` contract is vulnerable to re-entrancy attacks due to its design. Specifically, the function allows for a re-entrant call to the `drop` function within the `transfer` operation, which can lead to unexpected and unintended consequences.\n\nWhen the `asset` token...

Vulnerable code:
```\nfunction claim(address user) external returns (uint256) {\n    drop();\n    _captureNewTokensForUser(user);\n    uint256 balance = userStates[user].balance;\n    userStates[user].balance = 0;\n    totalUnclaimed = uint256(totalUnclaimed).sub(balance).toUint112();\n\n    // Transfer asset/reward token to user\n    asset.transfer(user, balance);\n\n    emit Claimed(user, balance);\n\n    return balance;\n}\n```
MEDIUM severity: The vulnerability arises from the mismatch between the previous milestone stem representation and th. The vulnerability arises from the mismatch between the previous milestone stem representation and the new gauge point system, which utilizes untruncated values. The previous milestone stem, stored in its truncated form, is not compatible with the new system's requirement for untruncated values. This...

Vulnerable code:
```\n_stemTipForToken = s.ss[token].milestoneStem + \\n    int96(s.ss[token].stalkEarnedPerSeason).mul(\n        int96(s.season.current).sub(int96(s.ss[token].milestoneSeason))\n    )\n```
MEDIUM severity: The `cachedUserRewards` variable, used to track the rewards owed to a user, is not properly reset af. The `cachedUserRewards` variable, used to track the rewards owed to a user, is not properly reset after a reward claim. This allows a user to exploit this vulnerability by repeatedly claiming rewards, effectively stealing the entire balance of a token.\n\nWhen a user initiates a reward withdrawal, t...

Vulnerable code:
```\nif (rewardDebtDiff > userRewardDebts[msg.sender][rewardToken.token]) {\n    userRewardDebts[msg.sender][rewardToken.token] = 0;\n    cachedUserRewards[msg.sender][rewardToken.token] += \n        rewardDebtDiff - \n        userRewardDebts[msg.sender][rewardToken.token];\n} else {\n    userRewardDebts[msg.sender][rewardToken.token] -= rewardDebtDiff;\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of the `PriceOracle` contract, specifically in the `_se. The vulnerability lies in the implementation of the `PriceOracle` contract, specifically in the `_setAggregators()` and `getPrice()` functions. When a PToken market is created for WstETH, the `if (asset==wsteth)` check is bypassed, and the `getPrice()` function retrieves the price from the chainlink...

Vulnerable code:
```\nrequire(\n    aggrs[i].quote == Denominations.ETH ||\n    aggrs[i].quote == Denominations.USD,\n    "unsupported quote"\n);\n```\n```\n//PriceOracle.sol\nfunction getPrice(address asset) external view returns (uint256) {\n    if (asset == wsteth) {\n        uint256 stEthPrice = getPriceFromChainlink(\n            steth,\n            Denominations.USD\n        );\n        uint256 stEthPerToken = WstEthInterface(wsteth).stEthPerToken();\n        uint256 wstEthPrice = (stEthPrice * stEthPerToken) / 1e18;\n        return getNormalizedPrice(wstEthPrice, asset);\n    }\n    AggregatorInfo memory aggregatorInfo = aggregators[asset];\n    uint256 price = getPriceFromChainlink(\n        aggregatorInfo.base,\n        aggregatorInfo.quote\n    );\n```
MEDIUM severity: The vulnerability lies in the `_marginFeeHandler` function, specifically in the handling of the prim. The vulnerability lies in the `_marginFeeHandler` function, specifically in the handling of the primary short liquidation fee distribution. The function is responsible for distributing fees to the TAPP (Total Asset Protection Program) and the caller (liquidator) during the primary short liquidation...

Vulnerable code:
```\nfunction _marginFeeHandler(MTypes.MarginCallPrimary memory m) private {\n    STypes.VaultUser storage VaultUser = s.vaultUser[m.vault][msg.sender];\n    STypes.VaultUser storage TAPP = s.vaultUser[m.vault][address(this)];\n\n    uint88 tappFee = m.ethFilled.mulU88(m.tappFeePct);\n    uint88 callerFee = m.ethFilled.mulU88(m.callerFeePct) + m.gasFee;\n    m.totalFee += tappFee + callerFee;\n\n    if (TAPP.ethEscrowed >= callerFee) {\n        TAPP.ethEscrowed -= callerFee;\n        VaultUser.ethEscrowed += callerFee;\n    } else {\n        VaultUser.ethEscrowed += callerFee - m.gasFee + tappFee;\n        m.totalFee -= m.gasFee;\n        // TAPP.ethEscrowed -= m.totalFee;\n    }\n}\n```
MEDIUM severity: The `configurator.getEUSDMaxLocked()` condition in the `convertToPeUSD` function can be bypassed dur. The `configurator.getEUSDMaxLocked()` condition in the `convertToPeUSD` function can be bypassed during a flash loan transaction. This vulnerability allows an attacker to manipulate the amount of `EUSD` tokens that can be converted to `peUSD` by temporarily reducing the visible balance of `EUSD` tok...

Vulnerable code:
```\nfunction convertToPeUSD(address user, uint256 eusdAmount) public {\n    require(_msgSender() == user || _msgSender() == address(this), "MDM");\n    require(eusdAmount!= 0, "ZA");\n    require(EUSD.balanceOf(address(this)) + eusdAmount <= configurator.getEUSDMaxLocked(), "ESL");\n```
MEDIUM severity: The UpdateCommitment function in the LenderCommitmentForwarder contract allows malicious users to cr. The UpdateCommitment function in the LenderCommitmentForwarder contract allows malicious users to create commitments for other users, enabling them to drain funds from the targeted user. This vulnerability arises from the lack of validation of the `_commitment.lender` address in the `updateCommitmen...

Vulnerable code:
```\nfunction updateCommitment(\n    uint256 _commitmentId,\n    Commitment calldata _commitment\n) public commitmentLender(_commitmentId) {\n    require(\n        _commitment.principalTokenAddress ==\n            commitments[_commitmentId].principalTokenAddress,\n        "Principal token address cannot be updated."\n    );\n    require(\n        _commitment.marketId == commitments[_commitmentId].marketId,\n        "Market Id cannot be updated."\n    );\n\n    commitments[_commitmentId] = _commitment;\n\n    validateCommitment(commitments[_commitmentId]);\n}\n```
MEDIUM severity: The AgentRegistryCore's `createAgent` function allows anyone to mint an `agentID` for a desired owne. The AgentRegistryCore's `createAgent` function allows anyone to mint an `agentID` for a desired owner address, which can lead to a denial-of-service (DoS) vulnerability. This vulnerability can occur when the Front Running Protection is disabled or the `frontRunningDelay` is set to 0, enabling anyone...

Vulnerable code:
```\nfunction createAgent(\n    uint256 agentId,\n    address owner,\n    string calldata metadata,\n    uint256[] calldata chainIds\n) public\n    onlySorted(chainIds)\n    frontrunProtected(keccak256(abi.encodePacked(agentId, owner, metadata, chainIds)), frontRunningDelay)\n{\n    _mint(owner, agentId);\n    _beforeAgentUpdate(agentId, metadata, chainIds);\n    _agentUpdate(agentId, metadata, chainIds);\n    _afterAgentUpdate(agentId, metadata, chainIds);\n}\n```
MEDIUM severity: The `notifyDepositExpiryCourtesyCall` function is no longer necessary and should be removed from the. The `notifyDepositExpiryCourtesyCall` function is no longer necessary and should be removed from the system, as it is a leftover from a previous version of the deposit contract. This function was likely intended to notify the system when a deposit is about to expire, but its removal will not have a...

Vulnerable code:
```\nfunction exitCourtesyCall(DepositUtils.Deposit storage _d) public {\n    require(_d.inCourtesyCall(), "Not currently in courtesy call");\n    require(block.timestamp <= _d.fundedAt + TBTCConstants.getDepositTerm(), "Deposit is expiring");\n    require(getCollateralizationPercentage(_d) >= _d.undercollateralizedThresholdPercent, "Deposit is still undercollateralized");\n    _d.setActive();\n    _d.logExitedCourtesyCall();\n}\n```
MEDIUM severity: The Sense PT redemption mechanism in the Redeemer code does not account for known loss scenarios, wh. The Sense PT redemption mechanism in the Redeemer code does not account for known loss scenarios, which can lead to principal losses. Specifically, the code assumes that any losses during redemption are due to malicious adapter behavior and requires that there be no losses. However, there are legiti...

Vulnerable code:
```\n- Slashing risk\n\n    ETH 2.0 validators risk staking penalties, with up to 100% of staked funds at risk if validators fail. To minimize this risk, Lido stakes across multiple professional and reputable node operators with heterogeneous setups, with additional mitigation in the form of insurance that is paid from Lido fees.\n\n- stETH price risk\n\n    Users risk an exchange price of stETH which is lower than inherent value due to withdrawal restrictions on Lido, making arbitrage and risk-free market-making impossible.\n\n    The Lido DAO is driven to mitigate above risks and eliminate them entirely to the extent possible. Despite this, they may still exist and, as such, it is our duty to communicate them.\n```
MEDIUM severity: The presence of commented-out code in the codebase is a significant issue that can lead to confusion. The presence of commented-out code in the codebase is a significant issue that can lead to confusion, complexity, and potential security vulnerabilities. Commented-out code can make it challenging for developers to understand the system's logic and functionality, as it can create ambiguity and hide...

Vulnerable code:
```\nstruct LiquidationVars {\n    uint256 borrowerCollateralValue;\n}\n```\n```\nif (token!= ETH_ADDR) {\n    divisor = 10 ** uint256(globalConfig.tokenInfoRegistry().getTokenDecimals(token));\n}\n\npower = power.add(getDepositBalanceCurrent(token, _borrower))\n```\n```\nif totalBorrow.mul(100) <= totalCollateral.mul(liquidationDiscountRatio) {\n    // "Collateral is not sufficient to be liquidated."\n}\n```\n```\nfunction _isETH(address _token) public view returns (bool) {\n    return globalConfig.constants().ETH_ADDR() == _token;\n}\n\nfunction getDivisor(address _token) public view returns (uint256) {\n    if (_isETH(_token)) {\n        return INT_UNIT;\n    }\n    return 10 ** uint256(getTokenDecimals(_token));\n}\n```\n```\nrequire(_borrowLTV!= 0, "Borrow LTV is zero");\nrequire(_borrowLTV < SCALE, "Borrow LTV must be less than Scale");\n```
MEDIUM severity: The `WethAdapter` code calculates the fee for a transaction by subtracting the amount of funds to be. The `WethAdapter` code calculates the fee for a transaction by subtracting the amount of funds to be transferred from the total value received in the message. This calculation is performed to determine the amount of ether that should be used as a fee versus the amount that should be transferred into...

Vulnerable code:
```\nuint256 fee = msg.value;\n\nif (address(tokenFrom) == Constants.ETH) {\n    require(amountFrom <= fee, "MSG_VAL_INSUFFICIENT");\n    fee -= amountFrom;\n    IWETH weth = getWETH();\n    weth.deposit{value: amountFrom}();\n    _approveSpender(weth, spender, amountFrom);\n} else {\n    _approveSpender(tokenFrom, spender, amountFrom);\n}\n\naggregator.functionCallWithValue(abi.encodePacked(method, data), fee);\n```
MEDIUM severity: The `TradingModule.getOraclePrice` function returns a value that is used in various calculations wit. The `TradingModule.getOraclePrice` function returns a value that is used in various calculations within the protocol. The function is designed to validate that the returned values are positive, ensuring that the protocol operates correctly. However, there is a possibility that the returned values co...

Vulnerable code:
```\nrequire(oraclePrice >= 0);\n```\n```\noraclePrice = (oracleDecimals * oracleDecimals) / oraclePrice\n```\n```\nrequire(decimals >= 0);\n\nif (uint256(decimals)!= BalancerConstants.BALANCER_PRECISION) {\n    rate = (rate * int256(BalancerConstants.BALANCER_PRECISION)) / decimals;\n}\n```\n```\nrequire(oracleDecimals >= 0);\n```\n```\nlimitAmount = (\n    (oraclePrice + \n        ((oraclePrice * uint256(slippageLimit)) / \n            Constants.SLIPPAGE_LIMIT_PRECISION)) * \n    amount) / \n    oracleDecimals;\n```\n```\nreturn (pvInternal * borrowTokenDecimals * rate) / \n    (rateDecimals * int256(Constants.INTERNAL_TOKEN_PRECISION));\n```
MEDIUM severity: The WithdrawPeriphery contract's `_convertToToken` function is designed to apply a fixed slippage th. The WithdrawPeriphery contract's `_convertToToken` function is designed to apply a fixed slippage threshold to redeem junior share vaults to any token available on GMX. The function calculates the minimum token output by multiplying the output GLP amount by the GLP price and the token price, and the...

Vulnerable code:
```\nfunction _convertToToken(address token, address receiver) internal returns (uint256 amountOut) {\n    uint256 outputGlp = fsGlp.balanceOf(address(this));\n\n    uint256 glpPrice = _getGlpPrice(false);\n\n    uint256 tokenPrice = gmxVault.getMaxPrice(token);\n\n    uint256 minTokenOut = outputGlp.mulDiv(glpPrice * (MAX_BPS - slippageThreshold), tokenPrice * MAX_BPS);\n\n    amountOut = rewardRouter.unstakeAndRedeemGlp(address(token), outputGlp, minTokenOut, receiver);\n}\n```
MEDIUM severity: The `createBridge` function in the OwnerFacet.sol contract lacks a crucial check to verify if a brid. The `createBridge` function in the OwnerFacet.sol contract lacks a crucial check to verify if a bridge already exists, which can lead to a critical vulnerability in the yield generation process. Specifically, the absence of this check enables the creation of duplicate bridges, resulting in double ac...

Vulnerable code:
```\nfunction getZethTotal(uint256 vault) internal view returns (uint256 zethTotal) {\n    AppStorage storage s = appStorage();\n    address[] storage bridges = s.vaultBridges[vault];\n    uint256 bridgeCount = bridges.length;\n\n    for (uint256 i = 0; i < bridgeCount) {\n        zethTotal += IBridge(bridges[i]).getZethValue();\n        unchecked {\n            i++;\n        }\n    }\n}\n```\n```\nfunction test_double_bridge_push() public {\n    vm.prank(owner);\n    diamond.createBridge(_bridgeReth, Vault.CARBON, 0, 0);\n    diamond.getUndistributedYield(Vault.CARBON);\n    assert(diamond.getUndistributedYield(Vault.CARBON) > 0); // As no yield was generated, this should not be true\n}\n```
MEDIUM severity: The vulnerability lies in the FRAX admin's ability to disrupt the redemption process of the Adaptor,. The vulnerability lies in the FRAX admin's ability to disrupt the redemption process of the Adaptor, thereby preventing Napier users from withdrawing their funds. This is achieved by executing the `recoverEther` function, which transfers out all the native ETH residing in the `FraxEtherRedemptionQue...

Vulnerable code:
```\nFile: SFrxETHAdapter.sol\n\nfunction claimWithdrawal() external override {\n    uint256 _requestId = requestId;\n    uint256 _withdrawalQueueEth = withdrawalQueueEth;\n    if (_requestId == 0) {\n        revert NoPendingWithdrawal();\n    }\n\n    delete withdrawalQueueEth;\n    delete requestId;\n    bufferEth += _withdrawalQueueEth;\n\n    uint256 balanceBefore = address(this).balance;\n    REDEMPTION_QUEUE.burnRedemptionTicketNft(_requestId, payable(this));\n    if (address(this).balance < balanceBefore + _withdrawalQueueEth) {\n        revert InvariantViolation();\n    }\n\n    IWETH9(Constants.WETH).deposit{value: _withdrawalQueueEth}();\n```\n```\nFile: FraxEtherRedemptionQueue.sol\n\nfunction burnRedemptionTicketNft(uint256 _nftId, address payable _recipient) external nonReentrant {\n    // Effects: Burn frxEth to match the amount of ether sent to user 1:1\n    FRX_ETH.burn(_redemptionQueueItem.amount);\n\n    // Interactions: Transfer ETH to recipient, minus the fee\n    (bool _success, ) = _recipient.call{ value: _redemptionQueueItem.amount }("");\n    if (!_success) revert InvalidEthTransfer();\n```\n```\nFile: FraxEtherRedemptionQueue.sol\n\nfunction recoverEther(uint256 _amount) external {\n    _requireSenderIsTimelock();\n\n    (bool _success, ) = address(msg.sender).call{ value: _amount }("");\n    if (!_success) revert InvalidEthTransfer();\n\n    emit RecoverEther({ recipient: msg.sender, amount: _amount });\n}\n```
MEDIUM severity: The `D3VaultFunding#checkBadDebtAfterAccrue` function in the D3VaultFunding smart contract contains . The `D3VaultFunding#checkBadDebtAfterAccrue` function in the D3VaultFunding smart contract contains a critical flaw that can lead to severe consequences for both liquidity providers (LPs) and market makers (MMs). The function incorrectly assumes that a collateral ratio less than 1e18 indicates the p...

Vulnerable code:
```\nif (balance >= borrows) {\n    collateral += Math.min(balance - borrows, info.maxCollateralAmount).mul(info.collateralWeight).mul(price);\n} else {\n    debt += (borrows - balance).mul(info.debtWeight).mul(price);\n}\n```\n```\nAssume a pool has the following balances and debts:\n\nToken A - 100 borrows 125, balance\nToken B - 100 borrows 80, balance\n\nPrice A = 1\ncollateralWeightA = 0.8\n\nPrice B = 1\ndebtWeightB = 1.2\n\ncollateral = 25 * 1 * 0.8\ncollateral = 20\n\ndebt = 20 * 1 * 1.2\ndebt = 24\n\ncollateralRatio = 20 / 24\ncollateralRatio = 0.83\n```\n```\nExcessCollateral = 125 - 100\nExcessCollateral = 25\n\nExcessCollateral = 25 * 1 * 0.95\nExcessCollateral = 23.75\n\nExcessDebt = 100 - 80\nExcessDebt = 20\n\nExcessDebt = 20 * 1\nExcessDebt = 20\n```
MEDIUM severity: The `GMXWithdraw.withdraw` function calculates the amount of LP-tokens to be withdrawn by multiplyin. The `GMXWithdraw.withdraw` function calculates the amount of LP-tokens to be withdrawn by multiplying the `shareRatio` with the `lpAmt` and dividing the result by a constant `SAFE_MULTIPLIER`. This calculation is performed before the `mintFee` function is called. The `mintFee` function, in turn, inc...

Vulnerable code:
```\nfunction mintFee() public {\n    _mint(_store.treasury, GMXReader.pendingFee(_store));\n    _store.lastFeeCollected = block.timestamp;\n}\n```\n```\n67    _wc.shareRatio = wp.shareAmt * SAFE_MULTIPLIER / IERC20(address(self.vault)).totalSupply()\n70    _wc.lpAmt = _wc.shareRatio * GMXReader.lpAmt(self) / SAFE_MULTIPLIER\n```
MEDIUM severity: The `DepositRedemption.provideRedemptionSignature` function in the Bitcoin-based smart contract is r. The `DepositRedemption.provideRedemptionSignature` function in the Bitcoin-based smart contract is responsible for verifying and processing signatures used to redeem deposits. This function accepts a signature `s` value in the upper half of the secp256k1 curve, which is a characteristic of the secp2...

Vulnerable code:
```\nfunction provideRedemptionSignature(\n    DepositUtils.Deposit storage _d,\n    uint8 _v,\n    bytes32 _r,\n    bytes32 _s\n) public {\n    require(_d.inAwaitingWithdrawalSignature(), "Not currently awaiting a signature");\n\n    // If we're outside of the signature window, we could punish signers here\n    // Instead, we consider this a no-harm-no-foul situation.\n    // The signers have not stolen funds. Most likely they've just inconvenienced someone\n\n    require(\n        _d.signerPubkey().checkSig(\n            _d.lastRequestedDigest,\n            _v,\n            _r,\n            _s\n        ),\n        "Invalid signature"\n    );\n```
MEDIUM severity: The `UniversalBuyback` contract's `gulp` and `pendingBurning` functions utilize hardcoded, constant . The `UniversalBuyback` contract's `gulp` and `pendingBurning` functions utilize hardcoded, constant values `DEFAULT_REWARD_BUYBACK1_SHARE` and `DEFAULT_REWARD_BUYBACK2_SHARE` to calculate the ratio in which the trade value is split. This hardcoded ratio is used to determine the proportion of the `_b...

Vulnerable code:
```\nuint256 _amount1 = _balance.mul(DEFAULT_REWARD_BUYBACK1_SHARE) / 1e18;\nuint256 _amount2 = _balance.mul(DEFAULT_REWARD_BUYBACK2_SHARE) / 1e18;\n```\n```\nuint256 _amount1 = _balance.mul(DEFAULT_REWARD_BUYBACK1_SHARE) / 1e18;\nuint256 _amount2 = _balance.mul(DEFAULT_REWARD_BUYBACK2_SHARE) / 1e18;\n```