Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability arises when a hat is sent to the address `0`, which can trick the multisig into ac. The vulnerability arises when a hat is sent to the address `0`, which can trick the multisig into accepting phony signatures on its behalf. This occurs because the `HatsSignerGateBase.sol` contract's `countValidSignatures()` function relies on the `ecrecover` function to recover the signer for each...

Vulnerable code:
```\nfunction isValidSigner(address _account) public view override returns (bool valid) {\n    valid = HATS.isWearerOfHat(_account, signersHatId);\n}\n```\n```\nfunction isWearerOfHat(address _user, uint256 _hatId) public view returns (bool isWearer) {\n    isWearer = (balanceOf(_user, _hatId) > 0);\n}\n```\n```\nfunction balanceOf(address _wearer, uint256 _hatId)\n    public\n    view\n    override(ERC1155, IHats)\n    returns (uint256 balance)\n{\n    Hat storage hat = _hats[_hatId];\n\n    balance = 0;\n\n    if (_isActive(hat, _hatId) && _isEligible(_wearer, hat, _hatId)) {\n        balance = super.balanceOf(_wearer, _hatId);\n    }\n}\n```\n```\nfunction balanceOf(address owner, uint256 id) public view virtual returns (uint256 balance) {\n    balance = _balanceOf[owner][id];\n}\n```
MEDIUM severity: The `claimMessage` transaction on both L1 and L2 is vulnerable to front-running attacks. This occurs. The `claimMessage` transaction on both L1 and L2 is vulnerable to front-running attacks. This occurs when an attacker, acting as the "front-runner", can manipulate the transaction to claim the message before the intended recipient, known as the postman, has the opportunity to do so. This is possible...

Vulnerable code:
```\nif (_fee > 0) {\n    address feeReceiver = _feeRecipient == address(0)? msg.sender : _feeRecipient;\n    (bool feePaymentSuccess, ) = feeReceiver.call{ value: _fee }("");\n    if (!feePaymentSuccess) {\n        revert FeePaymentFailed(feeReceiver);\n    }\n}\n```\n```\nif (_fee > 0) {\n    address feeReceiver = _feeRecipient == address(0)? msg.sender : _feeRecipient;\n    (bool feePaymentSuccess, ) = feeReceiver.call{ value: _fee }("");\n    if (!feePaymentSuccess) {\n        revert FeePaymentFailed(feeReceiver);\n    }\n}\n```
MEDIUM severity: The `dstGasForCall` parameter for transferring ERC20 tokens through Stargate is hardcoded to 0 in th. The `dstGasForCall` parameter for transferring ERC20 tokens through Stargate is hardcoded to 0 in the `Balancer` contract, leading to the `sgReceive` function not being called during the Stargate swap process. This results in the `cachedSwapLookup` mapping not being cleared, allowing an attacker to...

Vulnerable code:
```\nfunction swap(\n    uint16 _chainId,\n    uint256 _srcPoolId,\n    uint256 _dstPoolId,\n    address payable _refundAddress,\n    Pool.CreditObj memory _c,\n    Pool.SwapObj memory _s,\n    IStargateRouter.lzTxObj memory _lzTxParams,\n    bytes calldata _to,\n    bytes calldata _payload\n) external payable onlyRouter {\n    bytes memory payload = abi.encode(\n        TYPE_SWAP_REMOTE,\n        _srcPoolId,\n        _dstPoolId,\n        _lzTxParams.dstGasForCall,\n        _c,\n        _s,\n        _to,\n        _payload\n    );\n    _call(_chainId, TYPE_SWAP_REMOTE, _refundAddress, _lzTxParams, payload);\n}\n\nfunction _call(\n    uint16 _chainId,\n    uint8 _type,\n    address payable _refundAddress,\n    IStargateRouter.lzTxObj memory _lzTxParams,\n    bytes memory _payload\n) internal {\n    bytes memory lzTxParamBuilt = _txParamBuilder(_chainId, _type, _lzTxParams);\n    uint64 nextNonce = layerZeroEndpoint.getOutboundNonce(_chainId, address(this)) + 1;\n    layerZeroEndpoint.send{value: msg.value}(\n        _chainId,\n        bridgeLookup[_chainId],\n        _payload,\n        _refundAddress,\n        address(this),\n        lzTxParamBuilt\n    );\n    emit SendMsg(_type, nextNonce);\n}\n```\n```\n## Bridge.sol\n\nfunction lzReceive(\n    uint16 _srcChainId,\n    bytes memory _srcAddress,\n    uint64 _nonce,\n    bytes memory _payload\n) external override {\n    if (functionType == TYPE_SWAP_REMOTE) {\n        (\n           ,\n            uint256 srcPoolId,\n            uint256 dstPoolId,\n            uint256 dstGasForCall,\n            Pool.CreditObj memory c,\n            Pool.SwapObj memory s,\n            bytes memory to,\n            bytes memory payload\n        ) = abi.decode(_payload, (uint8, uint256, uint256, uint256, Pool.CreditObj, Pool.SwapObj, bytes, bytes));\n```\n```\nfunction clearCachedSwap(\n    uint16 _srcChainId,\n    bytes calldata _srcAddress,\n    uint256 _nonce\n) external {\n    CachedSwap memory cs = cachedSwapLookup[_srcChainId][_srcAddress][_nonce];\n    require(cs.to!= address(0), "Stargate: cache already cleared");\n    // clear the data\n    cachedSwapLookup[_srcChainId][_srcAddress][_nonce] = CachedSwap(address(0), 0, address(0), "");\n    IStargateReceiver(cs.to).sgReceive(_srcChainId, _srcAddress, _nonce, cs.token, cs.amountLD, cs.payload);\n}\n```\n```\nfunction sgReceive(\n    uint16,\n    bytes memory,\n    uint256,\n    address,\n    uint256 amountLD,\n    bytes memory\n) external payable {\n    if (msg.sender!= _stargateRouter) {\n        revert mTOFT_NotAuthorized();\n    }\n\n    if (erc20 == address(0)) {\n        vault.depositNative{value: amountLD}();\n    } else {\n        IERC20(erc20).safeTransfer(address(vault), amountLD);\n    }\n}\n```
MEDIUM severity: The `StoredBalance` and `Pool` structs contain fields that are only written to and never read, speci. The `StoredBalance` and `Pool` structs contain fields that are only written to and never read, specifically `isInitialized` and `initialized`, respectively. These fields are not utilized in the codebase, and their presence can potentially introduce unnecessary complexity and security risks.\n\nThe `...

Vulnerable code:
```\nbool isInitialized;\n```\n```\nbool initialized;\n```
MEDIUM severity: This vulnerability is a potential re-entrancy attack in the Crowdinvesting contract, which can be ex. This vulnerability is a potential re-entrancy attack in the Crowdinvesting contract, which can be exploited by the owner of the contract. The attack requires a specific set of conditions to be met, including the presence of a re-entrancy opportunity in the token transfer mechanism and the owner's in...

Vulnerable code:
```\nfunction buy(uint256 _amount, address _tokenReceiver) public whenNotPaused nonReentrant {\n    uint256 currencyAmount = Math.ceilDiv(_amount * getPrice(), 10 ** token.decimals());\n\n    (uint256 fee, address feeCollector) = _getFeeAndFeeReceiver(currencyAmount);\n    if (fee!= 0) {\n        currency.safeTransferFrom(_msgSender(), feeCollector, fee);\n    }\n\n    currency.safeTransferFrom(_msgSender(), _tokenReceiver, currencyAmount - fee);\n    _checkAndDeliver(_amount, _tokenReceiver);\n\n    emit TokensBought(_msgSender(), _amount, currencyAmount);\n}\n```
MEDIUM severity: The `maxSigners` mechanism, intended to limit the number of signers in a Hats Signer Gate (HSG), is . The `maxSigners` mechanism, intended to limit the number of signers in a Hats Signer Gate (HSG), is vulnerable to bypass. This is due to the fact that the `signerCount` variable, which tracks the current number of registered signers, is not accurately updated in real-time. Specifically, the `reconci...

Vulnerable code:
```\nfunction claimSigner() public virtual {\n    if (signerCount == maxSigners) {\n        revert MaxSignersReached();\n    }\n    if (safe.isOwner(msg.sender)) {\n        revert SignerAlreadyClaimed(msg.sender);\n    }\n    if (!isValidSigner(msg.sender)) {\n        revert NotSignerHatWearer(msg.sender);\n    }\n    _grantSigner(msg.sender);\n}\n```
MEDIUM severity: The `unstakeProcessed` function in the `StakedLyxToken` contract contains an unnecessary matching pr. The `unstakeProcessed` function in the `StakedLyxToken` contract contains an unnecessary matching process when `unstakeAmount` exceeds `totalPendingUnstake`. This occurs when the function is called with an `unstakeAmount` greater than the total pending unstake requests. In this scenario, the functio...

Vulnerable code:
```\nif (unstakeAmount > totalPendingUnstake) {\n    pool.receiveWithoutActivation{value: unstakeAmount - totalPendingUnstake}();\n    unstakeAmount = totalPendingUnstake;\n}\n\ntotalPendingUnstake -= unstakeAmount;\ntotalUnstaked += unstakeAmount;\n\nuint256 amountToFill = unstakeAmount;\n\nfor (uint256 i = unstakeRequestCurrentIndex; i <= unstakeRequestCount; i++) {\n    UnstakeRequest storage request = _unstakeRequests[i];\n    if (amountToFill > (request.amount - request.amountFilled)) {\n        amountToFill -= (request.amount - request.amountFilled);\n        continue;\n    } else {\n        if (amountToFill == (request.amount - request.amountFilled) && i < unstakeRequestCount) {\n            unstakeRequestCurrentIndex = i + 1;\n        } else {\n            request.amountFilled += uint128(amountToFill);\n            unstakeRequestCurrentIndex = i;\n        }\n        break;\n    }\n}\n```
MEDIUM severity: The `Perpetual.liquidateFrom` function, which is currently publicly accessible, allows anyone to liq. The `Perpetual.liquidateFrom` function, which is currently publicly accessible, allows anyone to liquidate an account on behalf of another user. This is a critical issue, as it enables unauthorized parties to assume the liquidated account's position, including any associated penalty collateral, and...

Vulnerable code:
```\nfunction isSafeWithPrice(address guy, uint256 currentMarkPrice) public returns (bool) {\n    return marginBalanceWithPrice(guy, currentMarkPrice) >=\n        uint256(maintenanceMarginWithPrice(guy, currentMarkPrice));\n}\n```\n```\nfunction liquidateFrom(address from, address guy, uint256 maxAmount) public returns (uint256, uint256) {\n    return (\n        // Check if the from address is the same as the guy address\n        from == guy\n           ? // If true, return the maxAmount\n                (maxAmount, 0)\n            : // If false, calculate the amount to liquidate\n                (maxAmount, calculateAmountToLiquidate(from, guy, maxAmount))\n    );\n}\n```\n```\nfunction liquidate(address guy, uint256 maxAmount) public returns (uint256, uint256) {\n    require(status!= LibTypes.Status.SETTLED, "wrong perpetual status");\n    return liquidateFrom(msg.sender, guy, maxAmount);\n}\n```
MEDIUM severity: The Corruptible Upgradability Pattern vulnerability affects the Boosted3TokenAuraVault and MetaStabl. The Corruptible Upgradability Pattern vulnerability affects the Boosted3TokenAuraVault and MetaStable2TokenAuraVault vaults, which are designed to be upgradeable. However, their inheritance structure is flawed, as they inherit contracts that are not upgrade-safe. Specifically, the `BaseStrategyVault...

Vulnerable code:
```\ngraph BT;\n  classDef nogap fill:#f96;\n  classDef hasgap fill:#99cc00;\n\n  MetaStable2TokenAuraVault-->MetaStable2TokenVaultMixin::nogap\n  MetaStable2TokenVaultMixin::nogap-->TwoTokenPoolMixin::nogap\n  MetaStable2TokenVaultMixin::nogap-->BalancerOracleMixin::nogap\n  TwoTokenPoolMixin::nogap-->PoolMixin::nogap\n  PoolMixin::nogap-->AuraStakingMixin::nogap\n  PoolMixin::nogap-->BalancerStrategyBase\n  BalancerStrategyBase::hasgap-->BaseStrategyVault::hasgap\n  BalancerStrategyBase::hasgap-->UUPSUpgradeable\n```\n```\ngraph BT;\nclassDef nogap fill:#f96;\nclassDef hasgap fill:#99cc00;\n\n    Boosted3TokenAuraVault-->Boosted3TokenPoolMixin::nogap\n    Boosted3TokenPoolMixin::nogap-->PoolMixin::nogap\n    PoolMixin::nogap-->BalancerStrategyBase\n    PoolMixin::nogap-->AuraStakingMixin::nogap\n    BalancerStrategyBase::hasgap-->BaseStrategyVault::hasgap\n    BalancerStrategyBase::hasgap-->UUPSUpgradeable\n```\n```\nabstract contract BaseStrategyVault is Initializable, IStrategyVault {\n    using TokenUtils for IERC20;\n    using TradeHandler for Trade;\n\n    // Storage gap for future potential upgrades\n    uint256[45] private __gap;\n}\n```\n```\nabstract contract BalancerStrategyBase is BaseStrategyVault, UUPSUpgradeable {\n    /**\n     * Immutables\n     */\n    uint32 internal immutable SETTLEMENT_PERIOD_IN_SECONDS;\n\n    // Storage gap for future potential upgrades\n    uint256[100] private __gap;\n}\n```
MEDIUM severity: The use of an outdated compiler version, specifically Solidity 0.5.2, in the codebase poses a signif. The use of an outdated compiler version, specifically Solidity 0.5.2, in the codebase poses a significant risk. This is because the current compiler version has publicly disclosed bugs and issues that may affect the functionality and security of the deployed contract. The codebase's reliance on the...

Vulnerable code:
```\npragma solidity ^0.5.2;\npragma experimental ABIEncoderV2;\n```
MEDIUM severity: The `_multiSwap` function in the `dodoMultiswap` function is prone to rounding errors when calculati. The `_multiSwap` function in the `dodoMultiswap` function is prone to rounding errors when calculating the proportion of tokens to be transferred to each adapter. This is due to the fact that the calculation of `curAmount` using the formula `curAmount = curTotalAmount * weight / totalWeight` does no...

Vulnerable code:
```\nif (assetFrom[i - 1] == address(this)) {\n    uint256 curAmount = curTotalAmount * curPoolInfo.weight / curTotalWeight;\n\n    if (curPoolInfo.poolEdition == 1) {\n        IERC20(midToken[i]).transfer(curPoolInfo.adapter, curAmount);\n    } else {\n        IERC20(midToken[i]).transfer(curPoolInfo.pool, curAmount);\n    }\n}\n```
MEDIUM severity: The `IchiLPOracle` is vulnerable to manipulation due to its reliance on the `UniV3Pool.slot0` data p. The `IchiLPOracle` is vulnerable to manipulation due to its reliance on the `UniV3Pool.slot0` data point, which is easily manipulable. The `slot0` data point is used by `IchiVault` to determine the number of tokens in its position, and this information is then used by `IchiLPOracle` to calculate the...

Vulnerable code:
```\nfunction _amountsForLiquidity(\n    int24 tickLower,\n    int24 tickUpper,\n    uint128 liquidity\n) internal view returns (uint256, uint256) {\n    (uint160 sqrtRatioX96,,,,,, ) = IUniswapV3Pool(pool).slot0();\n    return (\n        UV3Math.getAmountsForLiquidity(\n            sqrtRatioX96,\n            UV3Math.getSqrtRatioAtTick(tickLower),\n            UV3Math.getSqrtRatioAtTick(tickUpper),\n            liquidity\n        )\n    );\n}\n```
MEDIUM severity: The vesting contract is designed to operate with a specific token, but it is unable to do so when th. The vesting contract is designed to operate with a specific token, but it is unable to do so when the `token` variable is set to the address of the native token, ETH. This is because the `updateUserDeposit` function, which is responsible for updating the user's deposit amount, attempts to perform a...

Vulnerable code:
```\nfunction claim() external {\n    address sender = msg.sender;\n\n    UserDetails storage s = userdetails[sender];\n    require(s.userDeposit!= 0, "No Deposit");\n    require(s.index!= vestingPoints.length, "already claimed");\n\n    uint256 pctAmount;\n    uint256 i = s.index;\n    for (i; i <= vestingPoints.length - 1; i++) {\n        if (block.timestamp >= vestingPoints[i][0]) {\n            pctAmount += (s.userDeposit * vestingPoints[i][1]) / 10000;\n        } else {\n            break;\n        }\n    }\n\n    if (pctAmount!= 0) {\n        if (address(token) == address(1)) {\n            (bool sent, ) = payable(sender).call{value: pctAmount}("");\n            require(sent, "Failed to send BNB to receiver");\n        } else {\n            token.safeTransfer(sender, pctAmount);\n        }\n        s.index = uint128(i);\n        s.amountClaimed += pctAmount;\n    }\n```\n```\nfunction updateUserDeposit(\n    address[] memory _users,\n    uint256[] memory _amount\n) public onlyRole(DEFAULT_ADMIN_ROLE) {\n    require(_users.length <= 250, "array length should be less than 250");\n    require(_users.length == _amount.length, "array length should match");\n    uint256 amount;\n    for (uint256 i = 0; i < _users.length; i++) {\n        userdetails[_users[i]].userDeposit = _amount[i];\n        amount += _amount[i];\n    }\n    token.safeTransferFrom(distributionWallet, address(this), amount);\n}\n```
MEDIUM severity: The `MultipleWinners` mechanism allows for the distribution of awards through a `SortitionSumTree` p. The `MultipleWinners` mechanism allows for the distribution of awards through a `SortitionSumTree` process, where a constant interval is used to distribute additional award drawings. This process is controlled by the `_distribute()` function, which calculates a `ticketSplit` value based on the total...

Vulnerable code:
```\nuint256 ticketSplit = totalSupply.div(_numberOfWinners);\nuint256 nextRandom = randomNumber.add(ticketSplit);\n\nfor (uint256 winnerCount = 1; winnerCount < _numberOfWinners; winnerCount++) {\n    winners[winnerCount] = ticket.draw(nextRandom);\n    nextRandom = nextRandom.add(ticketSplit);\n```
MEDIUM severity: This vulnerability occurs when a contract uses the `call()` function to interact with another contra. This vulnerability occurs when a contract uses the `call()` function to interact with another contract, but does not require the returned data. In such cases, the returned data is still copied into memory, which can lead to gas griefing attacks. Gas griefing attacks occur when an attacker intentiona...

Vulnerable code:
```\n(bool status, ) = payable(receiver).call{value: amount}("");\nrequire(status, "Gov: failed to send eth");\n```\n```\n(bool status, bytes memory data) = payable(receiver).call{value: amount}("");\nrequire(status, "Gov: failed to send eth");\n```
MEDIUM severity: The `VotingVault.withdrawTokens` function employs the `selfdestruct` operation as a mechanism to pre. The `VotingVault.withdrawTokens` function employs the `selfdestruct` operation as a mechanism to prevent the vault from being reused when it becomes empty. This approach is utilized within the `withdrawTokens` function, which is accessible only to the `Controller` contract. The function transfers to...

Vulnerable code:
```\nfunction withdrawTokens(address to, uint256 amount) external onlyController {\n    TransferHelper.withdrawTokens(token, to, amount);\n    if (IERC20(token).balanceOf(address(this)) == 0) {\n        selfdestruct();\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the absence of a minimum borrow size check against secondary debts during . The vulnerability lies in the absence of a minimum borrow size check against secondary debts during the exit process of a vault account. This oversight allows for the possibility of secondary debts falling below the minimum borrow size, potentially leading to accounts becoming insolvent and the prot...

Vulnerable code:
```\nFile: VaultAccount.sol\n\nfunction _setVaultAccount(\n    // An account must maintain a minimum borrow size in order to enter the vault. If the account\n    // wants to exit under the minimum borrow size it must fully exit so that we do not have dust\n    // accounts that become insolvent.\n    if (\n        vaultAccount.accountDebtUnderlying.neg() < vaultConfig.minAccountBorrowSize &&\n        // During local currency liquidation and settlement, the min borrow check is skipped\n        checkMinBorrow\n    ) {\n        // NOTE: use 1 to represent the minimum amount of vault shares due to rounding in the\n        // vaultSharesToLiquidator calculation\n        require(vaultAccount.accountDebtUnderlying == 0 || vaultAccount.vaultShares <= 1, "Min Borrow");\n    }\n```
MEDIUM severity: The `Staking.unstake()` function does not accurately update the original voting power that was used . The `Staking.unstake()` function does not accurately update the original voting power that was used in the `Staking.stake()` function. This discrepancy arises from the fact that the `getTokenVotingPower()` function, which is used to calculate the voting power, relies on external parameters such as `...

Vulnerable code:
```\nfunction getTokenVotingPower(uint _tokenId) public override view returns (uint) {\n    if (ownerOf(_tokenId) == address(0)) revert NonExistentToken();\n\n    uint multiplier = _tokenId < 10_000? PERCENT : monsterMultiplier;\n\n    return ((baseVotes * multiplier) / PERCENT) + stakedTimeBonus[_tokenId] + evilBonus(_tokenId);\n}\n```
MEDIUM severity: The `_withdraw()` function in the LMPVault contract is vulnerable to an arithmetic underflow, which . The `_withdraw()` function in the LMPVault contract is vulnerable to an arithmetic underflow, which can cause the function to revert unexpectedly. This occurs when the `maxAssetsToPull` argument is calculated as `info.totalAssetsToPull - Math.max(info.debtDecrease, info.totalAssetsPulled)`, and the...

Vulnerable code:
```\nfunction test_revert_underflow() public {\n    _accessController.grantRole(Roles.SOLVER_ROLE, address(this));\n    _accessController.grantRole(Roles.LMP_FEE_SETTER_ROLE, address(this));\n\n    // User is going to deposit 1500 asset\n    _asset.mint(address(this), 1500);\n    _asset.approve(address(_lmpVault), 1500);\n    _lmpVault.deposit(1500, address(this));\n\n    // Deployed 700 asset to DV1\n    _underlyerOne.mint(address(this), 700);\n    _underlyerOne.approve(address(_lmpVault), 700);\n    _lmpVault.rebalance(\n        address(_destVaultOne),\n        address(_underlyerOne), // tokenIn\n        700,\n        address(0), // destinationOut, none when sending out baseAsset\n        address(_asset), // baseAsset, tokenOut\n        700\n    );\n\n    // Deploy 600 asset to DV2\n    _underlyerTwo.mint(address(this), 600);\n    _underlyerTwo.approve(address(_lmpVault), 600);\n    _lmpVault.rebalance(\n        address(_destVaultTwo),\n        address(_underlyerTwo), // tokenIn\n        600,\n        address(0), // destinationOut, none when sending out baseAsset\n        address(_asset), // baseAsset, tokenOut\n        600\n    );\n\n    // Deployed 200 asset to DV3\n    _underlyerThree.mint(address(this), 200);\n    _underlyerThree.approve(address(_lmpVault), 200);\n    _lmpVault.rebalance(\n        address(_destVaultThree),\n        address(_underlyerThree), // tokenIn\n        200,\n        address(0), // destinationOut, none when sending out baseAsset\n        address(_asset), // baseAsset, tokenOut\n        200\n    );\n\n    // Drop the price of DV2 to 70% of original, so that 600 we transferred out is now only worth 420\n    _mockRootPrice(address(_underlyerTwo), 7e17);\n\n    // Revert because of an arithmetic underflow\n    vm.expectRevert();\n    uint256 assets = _lmpVault.redeem(1000, address(this), address(this));\n}\n```
MEDIUM severity: The `MaxWithdraw` method in the `InfinityPool` contract, which implements the ERC4626 standard, fail. The `MaxWithdraw` method in the `InfinityPool` contract, which implements the ERC4626 standard, fails to accurately account for the available funds in the ramp. Specifically, the method returns the maximum amount of IOU tokens that can be withdrawn, rather than the maximum amount of the asset token...

Vulnerable code:
```\nfunction maxWithdraw(address owner) public view returns (uint256) {\n    return convertToAssets(liquidStakingToken.balanceOf(owner));\n}\n```
MEDIUM severity: The `tickToToken0PriceInverted()` function performs arithmetic calculations, which are critical to t. The `tickToToken0PriceInverted()` function performs arithmetic calculations, which are critical to the functionality of the contract. Specifically, it is called by `_getTicksAndMeanPriceFromWei()`, which is, in turn, called by `hedgeDelta()`. However, the calculations performed by `tickToToken0Price...

Vulnerable code:
```\nuint256 intermediate = inWei.div(10 ** (token1.decimals() - token0.decimals()));\n```\n```\nmeanPrice = OptionsCompute.convertFromDecimals(meanPrice, \n    token0.decimals(), token1.decimals())\n```\n```\nfunction convertFromDecimals(uint256 value, uint8 decimalsA, uint8 decimalsB) internal pure returns (uint256) {\n    if (decimalsA > decimalsB) {\n        revert();\n    }\n   ...\n```