Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The TransactionDecoder library in the ZkEvmV2 library fails to account for missing elements while de. The TransactionDecoder library in the ZkEvmV2 library fails to account for missing elements while decoding a transaction. Specifically, when attempting to decode calldata from different transaction types, the library uses the RLPReader to skip to the desired element in the encoding. However, it does...

Vulnerable code:
```\ndata = it._skipTo(8)._toBytes()\n```\n```\ndata = it._skipTo(7)._toBytes()\n```\n```\ndata = it._skipTo(6)._toBytes()\n```\n```\nfunction _skipTo(Iterator memory _self, uint256 _skipToNum) internal pure returns (RLPItem memory item) {\n    uint256 ptr = _self.nextPtr;\n    uint256 itemLength = _itemLength(ptr);\n    _self.nextPtr = ptr + itemLength;\n\n    for (uint256 i = 0; i < _skipToNum - 1; i++) {\n        ptr = _self.nextPtr;\n        itemLength = _itemLength(ptr);\n        _self.nextPtr = ptr + itemLength;\n    }\n\n    item.len = itemLength;\n    item.memPtr = ptr;\n}\n```\n```\nCodecV2._extractXDomainAddHashes(\n    TransactionDecoder.decodeTransaction(_transactions[_batchReceptionIndices[i]])\n)\n```
MEDIUM severity: The ArrakisV2Router's `addLiquidityPermit2` function contains a critical vulnerability that can resu. The ArrakisV2Router's `addLiquidityPermit2` function contains a critical vulnerability that can result in the unintended refund of ETH to users. Specifically, the `isToken0Weth` variable is incorrectly set to `false`, which leads to the incorrect calculation of the amount of ETH to be refunded to th...

Vulnerable code:
```\nbool isToken0Weth;\n_permit2Add(params_, amount0, amount1, token0, token1);\n\n_addLiquidity(\n    params_.addData.vault,\n    amount0,\n    amount1,\n    sharesReceived,\n    params_.addData.gauge,\n    params_.addData.receiver,\n    token0,\n    token1\n);\n\nif (msg.value > 0) {\n    if (isToken0Weth && msg.value > amount0) {\n        payable(msg.sender).sendValue(msg.value - amount0);\n    } else if (!isToken0Weth && msg.value > amount1) {\n        payable(msg.sender).sendValue(msg.value - amount1);\n    }\n}\n```
MEDIUM severity: The Forta rewards system is based on epochs, with a privileged address responsible for distributing . The Forta rewards system is based on epochs, with a privileged address responsible for distributing rewards to accounts based on their stake and delegation. The system utilizes a `DelegatedAccRewards` storage struct to track the accumulated rewards for each share ID. To manage the accumulated rate o...

Vulnerable code:
```\nfunction didAllocate(\n    uint8 subjectType,\n    uint256 subject,\n    uint256 stakeAmount,\n    uint256 sharesAmount,\n    address staker\n) external onlyRole(ALLOCATOR_CONTRACT_ROLE) {\n    bool delegated = getSubjectTypeAgency(subjectType) == SubjectStakeAgency.DELEGATED;\n    if (delegated) {\n        uint8 delegatorType = getDelegatorSubjectType(subjectType);\n        uint256 shareId = FortaStakingUtils.subjectToActive(delegatorType, subject);\n        DelegatedAccRewards storage s = _rewardsAccumulators[shareId];\n        s.delegated.addRate(stakeAmount);\n    }\n```\n```\nfunction addRate(Accumulator storage acc, uint256 rate) internal {\n    setRate(acc, latest(acc).rate + rate);\n}\n```\n```\nfunction setRate(Accumulator storage acc, uint256 rate) internal {\n    EpochCheckpoint memory ckpt = EpochCheckpoint({\n        timestamp: SafeCast.toUint32(block.timestamp),\n        rate: SafeCast.toUint224(rate),\n        value: getValue(acc)\n    });\n    uint256 length = acc.checkpoints.length;\n    if (length > 0 && isCurrentEpoch(acc.checkpoints[length - 1].timestamp)) {\n        acc.checkpoints[length - 1] = ckpt;\n    } else {\n        acc.checkpoints.push(ckpt);\n    }\n}\n```\n```\nfunction getCurrentEpochTimestamp() internal view returns (uint256) {\n    return ((block.timestamp / EPOCH_LENGTH) * EPOCH_LENGTH) + TIMESTAMP_OFFSET;\n}\n\nfunction isCurrentEpoch(uint256 timestamp) internal view returns (bool) {\n    uint256 currentEpochStart = getCurrentEpochTimestamp();\n    return timestamp > currentEpochStart;\n}\n```\n```\nfunction getEpochNumber(uint256 timestamp) internal pure returns (uint32) {\n    return SafeCast.toUint32((timestamp - TIMESTAMP_OFFSET) / EPOCH_LENGTH);\n}\n```\n```\nfunction getCurrentEpochTimestamp() public view returns (uint256) {\n    return (getEpochNumber(block.timestamp) * EPOCH_LENGTH) + TIMESTAMP_OFFSET;\n}\n```\n```\nif (length > 0 && isCurrentEpoch(acc.checkpoints[length - 1].timestamp)) {\n    acc.checkpoints[length - 1] = ckpt;\n} else {\n    acc.checkpoints.push(ckpt);\n}\n```\n```\nfunction getEpochEndTimestamp(uint256 epochNumber) public pure returns (uint256) {\n    return ((epochNumber + 1) * EPOCH_LENGTH) + TIMESTAMP_OFFSET - 1; // so it is 23:59:59 instead of next day 00:00:00\n}\n\nfunction isCurrentEpoch(uint256 timestamp) public view returns (bool) {\n    uint256 currentEpochStart = getCurrentEpochTimestamp();\n    return timestamp >= currentEpochStart; // for the first second on Monday\n}\n```
MEDIUM severity: The vulnerability lies in the `_fillQuote()` function, which is responsible for handling swaps invol. The vulnerability lies in the `_fillQuote()` function, which is responsible for handling swaps involving the `0x` protocol. Specifically, when the `buyToken` is ETH, the function is intended to return any remaining protocol fee (in ETH) to the sender, aka `msg.sender`. However, there is a scenario w...

Vulnerable code:
```\ncontract RollerPeriphery {\n    function boughtAmount() public view returns (uint256) {\n        boughtAmount = address(quote.buyToken) == ETH? address(this).balance : quote.buyToken.balanceOf(address(this));\n    }\n}\n```\n```\npragma solidity ^0.8.0;\n\ncontract RollerPeriphery {\n    // Refund any unspent protocol fees (paid in ether) to the sender.\n    uint256 public refundAmt = address(this).balance;\n}\n```\n```\nif (address(quote.buyToken) == ETH) {\n    refundAmt = refundAmt - boughtAmount;\n}\npayable(msg.sender).transfer(refundAmt);\n```\n```\naddress(quote.buyToken) == ETH\n   ? payable(receiver).transfer(amtOut)\n    : ERC20(address(quote.buyToken)).safeTransfer(receiver, amtOut);\n```
MEDIUM severity: The `setPayoutScheduleFixed` function is designed to resize the payout schedule by copying the conte. The `setPayoutScheduleFixed` function is designed to resize the payout schedule by copying the contents of the existing arrays (`tierWinners`, `invoiceComplete`, and `supportingDocumentsComplete`) to new arrays of the same length as the updated payout schedule. However, if the new payout schedule ha...

Vulnerable code:
```\nfunction setPayoutScheduleFixed(\n    uint256[] calldata _payoutSchedule,\n    address _payoutTokenAddress\n) external onlyOpenQ {\n    require(\n        bountyType == OpenQDefinitions.TIERED_FIXED,\n        Errors.NOT_A_FIXED_TIERED_BOUNTY\n    );\n    payoutSchedule = _payoutSchedule;\n    payoutTokenAddress = _payoutTokenAddress;\n\n    string[] memory newTierWinners = new string[](payoutSchedule.length);\n    bool[] memory newInvoiceComplete = new bool[](payoutSchedule.length);\n    bool[] memory newSupportingDocumentsCompleted = new bool[](payoutSchedule.length);\n\n    for (uint256 i = 0; i < tierWinners.length; i++) {\n        newTierWinners[i] = tierWinners[i];\n    }\n    tierWinners = newTierWinners;\n\n    for (uint256 i = 0; i < invoiceComplete.length; i++) {\n        newInvoiceComplete[i] = invoiceComplete[i];\n    }\n    invoiceComplete = newInvoiceComplete;\n\n    for (uint256 i = 0; i < supportingDocumentsComplete.length; i++) {\n        newSupportingDocumentsCompleted[i] = supportingDocumentsComplete[i];\n    }\n    supportingDocumentsComplete = newSupportingDocumentsCompleted;\n```
MEDIUM severity: The `reportRelayEntryTimeout` function in the Keep protocol creates an unintended incentive for node. The `reportRelayEntryTimeout` function in the Keep protocol creates an unintended incentive for nodes to race for rewards, potentially wasting gas and enabling front-running opportunities. This function is responsible for informing about the timeout of a new relay entry generation operation, resulti...

Vulnerable code:
```\n/**\n * @dev Function used to inform about the fact that the currently ongoing\n * new relay entry generation operation timed out. As a result, the group\n * which was supposed to produce a new relay entry is immediately\n * terminated and a new group is selected to produce a new relay entry.\n * All members of the group are punished by seizing minimum stake of\n * their tokens. The submitter of the transaction is rewarded with a\n * tattletale reward which is limited to min(1, 20 / group_size) of the\n * maximum tattletale reward.\n */\nfunction reportRelayEntryTimeout() public {\n    require(hasEntryTimedOut(), "Entry did not time out");\n    groups.reportRelayEntryTimeout(signingRequest.groupIndex, groupSize, minimumStake);\n\n    if (numberOfGroups() > 0) {\n        signRelayEntry(\n            signingRequest.relayRequestId,\n            signingRequest.previousEntry,\n            signingRequest.serviceContract,\n            signingRequest.entryVerificationAndProfitFee,\n            signingRequest.callbackFee\n        );\n    }\n}\n```
MEDIUM severity: When a node attempts to exit, the `nodeExit` function is called, which should be executed as many ti. When a node attempts to exit, the `nodeExit` function is called, which should be executed as many times as there are schains associated with the node. Each iteration of the function freezes all active schains for a period of 12 hours. This freezing mechanism is implemented in the `freezeSchains` fun...

Vulnerable code:
```\nfunction freezeSchains(uint nodeIndex) external only("SkaleManager") {\n    SchainsInternal schainsInternal = SchainsInternal(contractManager.getContract("SchainsInternal"));\n    bytes32[] memory schains = schainsInternal.getActiveSchains(nodeIndex);\n\n    for (uint i = 0; i < schains.length; i++) {\n        Rotation memory rotation = rotations[schains[i]];\n        if (rotation.nodeIndex == nodeIndex && now < rotation.freezeUntil) {\n            continue;\n        }\n\n        string memory schainName = schainsInternal.getSchainName(schains[i]);\n        string memory revertMessage = "Node cannot rotate on Schain ";\n        revertMessage = string.concat(revertMessage, schainName);\n        revertMessage = string.concat(revertMessage, ", occupied by Node ");\n        revertMessage = string.concat(revertMessage, rotation.nodeIndex.toString());\n        string memory dkgRevert = "DKG process did not finish on schain ";\n        ISkaleDKG skaleDKG = ISkaleDKG(contractManager.getContract("SkaleDKG"));\n        require(\n            skaleDKG.isLastDKGSuccessful(keccak256(abi.encodePacked(schainName))),\n            string.concat(dkgRevert, schainName)\n        );\n        require(rotation.freezeUntil < now, revertMessage);\n        _startRotation(schains[i], nodeIndex);\n    }\n}\n```
MEDIUM severity: The `_generateGroup` function is responsible for selecting a group of nodes to run a new schain. Thi. The `_generateGroup` function is responsible for selecting a group of nodes to run a new schain. This process involves iterating over all nodes that can be used for this purpose and selecting a random subset of nodes. The selection is based on a random number generated using the blockhash and the sc...

Vulnerable code:
```\nfunction _generateGroup(bytes32 schainId, uint numberOfNodes) private returns (uint[] memory nodesInGroup) {\n    Nodes nodes = Nodes(contractManager.getContract("Nodes"));\n    uint8 space = schains[schainId].partOfNode;\n    nodesInGroup = new uint[](numberOfNodes);\n\n    uint[] memory possibleNodes = isEnoughNodes(schainId);\n    require(possibleNodes.length >= nodesInGroup.length, "Not enough nodes to create Schain");\n\n    uint ignoringTail = 0;\n    uint random = uint(keccak256(abi.encodePacked(uint(blockhash(block.number.sub(1))), schainId)));\n\n    for (uint i = 0; i < nodesInGroup.length; i++) {\n        uint index = random % (possibleNodes.length.sub(ignoringTail));\n        uint node = possibleNodes[index];\n        nodesInGroup[i] = node;\n        _swap(possibleNodes, index, possibleNodes.length.sub(ignoringTail).sub(1));\n        ++ignoringTail;\n\n        _exceptionsForGroups[schainId][node] = true;\n        addSchainForNode(node, schainId);\n        require(nodes.removeSpaceFromNode(node, space), "Could not remove space from Node");\n    }\n}\n```
MEDIUM severity: The `depositAndAllocateForAccount` function in the MultiAccount contract is vulnerable to an arithme. The `depositAndAllocateForAccount` function in the MultiAccount contract is vulnerable to an arithmetic scaling issue when allocating funds. The function fails to correctly scale the allocated amount, which can lead to incorrect accounting and potential financial losses.\n\nThe issue arises from the...

Vulnerable code:
```\nAccountFacetImpl.deposit(msg.sender, amount);\nuint256 amountWith18Decimals = (amount * 1e18) / (10 ** IERC20Metadata(GlobalAppStorage.layout().collateral).decimals());\nAccountFacetImpl.allocate(amountWith18Decimals);\n```\n```\nISymmio(symmioAddress).depositFor(account, amount);\nbytes memory _callData = abi.encodeWithSignature(\n    "allocate(uint256)",\n    amount\n);\ninnerCall(account, _callData);\n```
MEDIUM severity: The vulnerability lies in the initialization of the `Redemptions` and `TokenRequest` contracts, whic. The vulnerability lies in the initialization of the `Redemptions` and `TokenRequest` contracts, which do not perform uniqueness checks on the input tokens. This allows for duplicate tokens to be passed, leading to unintended consequences.\n\nIn the `Redemptions` contract, the `redeemableTokens` list...

Vulnerable code:
```\nfor (uint256 i = 0; i < redeemableTokens.length; i++) {\n    vaultTokenBalance = vault.balance(redeemableTokens[i]);\n\n    redemptionAmount = _burnableAmount.mul(vaultTokenBalance).div(burnableTokenTotalSupply);\n    totalRedemptionAmount = totalRedemptionAmount.add(redemptionAmount);\n\n    if (redemptionAmount > 0) {\n        vault.transfer(redeemableTokens[i], msg.sender, redemptionAmount);\n    }\n}\n```
MEDIUM severity: The system's administrators have the ability to make changes to the system without warning, which ca. The system's administrators have the ability to make changes to the system without warning, which can lead to unpredictable behavior and potential security violations. This is particularly concerning because privileged roles can use this power to make malicious changes just before incoming transacti...

Vulnerable code:
```\nfunction setNumberOfWinners(uint256 count) external onlyOwner {\n    _numberOfWinners = count;\n\n    emit NumberOfWinnersSet(count);\n}\n```\n```\nfunction setRngService(RNGInterface rngService) external onlyOwner {\n    require(!isRngRequested(), "PeriodicPrizeStrategy/rng-in-flight");\n\n    rng = rngService;\n    emit RngServiceUpdated(address(rngService));\n}\n```\n```\nfunction setRngRequestTimeout(uint32 _rngRequestTimeout) external onlyOwner {\n    _setRngRequestTimeout(_rngRequestTimeout);\n}\n```\n```\nfunction setTokenListener(TokenListenerInterface _tokenListener) external onlyOwner {\n    tokenListener = _tokenListener;\n\n    emit TokenListenerUpdated(address(tokenListener));\n}\n```\n```\nfunction setPeriodicPrizeStrategyListener(address _periodicPrizeStrategyListener) external onlyOwner {\n    periodicPrizeStrategyListener = PeriodicPrizeStrategyListener(_periodicPrizeStrategyListener);\n\n    emit PeriodicPrizeStrategyListenerSet(_periodicPrizeStrategyListener);\n}\n```\n```\nfunction setPrizeStrategy(address _prizeStrategy) external override onlyOwner {\n    _setPrizeStrategy(TokenListenerInterface(_prizeStrategy));\n}\n```\n```\nfunction removeExternalErc20Award(address _externalErc20, address _prevExternalErc20) external onlyOwner {\n    externalErc20s.removeAddress(_prevExternalErc20, _externalErc20);\n    emit ExternalErc20AwardRemoved(_externalErc20);\n}\n```\n```\nfunction removeExternalErc721Award(address _externalErc721, address _prevExternalErc721) external onlyOwner {\n    externalErc721s.removeAddress(_prevExternalErc721, _externalErc721);\n    delete externalErc721TokenIds[_externalErc721];\n    emit ExternalErc721AwardRemoved(_externalErc721);\n}\n```\n```\nfunction transferExternalERC20(\n    address to,\n    address externalToken,\n    uint256 amount\n)\n    external\n    onlyOwner\n{\n    prizePool.transferExternalERC20(to, externalToken, amount);\n}\n```
MEDIUM severity: The `TokenVesting` contract allows the owner to revoke the vesting of tokens for a designated `benef. The `TokenVesting` contract allows the owner to revoke the vesting of tokens for a designated `beneficiary`. When revocation occurs, the contract transfers the already vested and unreleased tokens to the `beneficiary`, and the remaining unvested tokens are returned to the owner. However, there is a...

Vulnerable code:
```\nfunction release(address beneficiary) public {\n    uint256 unreleased = getReleasableAmount(beneficiary);\n    require(unreleased > 0, "Nothing to release");\n\n    TokenAward storage award = getTokenAwardStorage(beneficiary);\n    award.released += unreleased;\n\n    targetToken.safeTransfer(beneficiary, unreleased);\n\n    emit Released(beneficiary, unreleased);\n}\n\nfunction revoke(address beneficiary) public onlyOwner {\n    TokenAward storage award = getTokenAwardStorage(beneficiary);\n\n    require(award.revocable, "Cannot be revoked");\n    require(!award.revoked, "Already revoked");\n\n    uint256 unreleased = getReleasableAmount(beneficiary);\n    award.released += unreleased;\n\n    uint256 refund = award.amount - award.released;\n\n    award.revoked = true;\n    award.amount = award.released;\n\n    targetToken.safeTransfer(beneficiary, unreleased);\n    targetToken.safeTransfer(owner(), refund);\n\n    emit Released(beneficiary, unreleased);\n    emit Revoked(beneficiary, refund);\n}\n```
MEDIUM severity: This vulnerability occurs when calculating the current stage price in a contract that has been froze. This vulnerability occurs when calculating the current stage price in a contract that has been frozen. The issue arises from the fact that the `frozenPeriod` is subtracted twice during the calculation, resulting in an incorrect price calculation.\n\nThe `getCurrentBlockNumber()` function subtracts t...

Vulnerable code:
```\nfunction getCurrentStage() public view returns (uint8) {\n    return getStageAtBlock(getCurrentBlockNumber());\n}\n```\n```\nfunction getCurrentBlockNumber() public view returns (uint256) {\n    return uint256(block.number).sub(frozenPeriod);\n}\n```\n```\nfunction getStageAtBlock(uint256 _blockNumber) public view returns (uint8) {\n    uint256 blockNumber = _blockNumber.sub(frozenPeriod); // adjust the block by the frozen period\n}\n```
MEDIUM severity: The Oracle.sol contract's `consult` function allows for manipulation of Uniswap V3 pool observations. The Oracle.sol contract's `consult` function allows for manipulation of Uniswap V3 pool observations through increasing the `observationCardinality`. This concept is a circular array of variable size, which can be expanded by anyone via the `Pool.increaseObservationCardinalityNext` function. The `Or...

Vulnerable code:
```\nstruct Observation {\n    uint32 blockTimestamp;\n    int56 tickCumulative;\n    uint160 secondsPerLiquidityCumulativeX128;\n    bool initialized;\n}\n```\n```\nAssume we are looking for the target=10 timestamp.\n\nAnd the observations array looks like this (element values are timestamps):\n\nobservations = [12, 20, 25, 30, 1, 1, 1]\n\nThe length of the array is 7.\n\nLet's say we provide the index 6 as the seed and the current observationIndex is 3 (i.e. pointing to timestamp 30)\n\nThe Oracle.observe function then chooses 1 as the left timestamp and 12 as the right timestamp.\n\nThis means the invalid and uninitialized element at index 6 with timestamp 1 will be used to calculate the Oracle values.\n```
MEDIUM severity: The BlueBerryBank#withdrawLend functionality in BlueBerryBank's smart contract is vulnerable to a to. The BlueBerryBank#withdrawLend functionality in BlueBerryBank's smart contract is vulnerable to a token accounting error when a soft or hard vault has a withdraw fee. This error occurs when the withdraw fee is deducted from the user's withdrawal amount, but the corresponding decrease in the underlyi...

Vulnerable code:
```\nif (\n    block.timestamp <\n    config.withdrawVaultFeeWindowStartTime() +\n        config.withdrawVaultFeeWindow()\n) {\n    uint256 fee = (withdrawAmount * config.withdrawVaultFee()) / DENOMINATOR;\n    uToken.safeTransfer(config.treasury(), fee);\n    withdrawAmount -= fee;\n}\n```\n```\nuint256 wAmount;\n\nif (address(ISoftVault(bank.softVault).uToken()) == token) {\n    ISoftVault(bank.softVault).approve(\n        bank.softVault,\n        type(uint256).max\n    );\n    wAmount = ISoftVault(bank.softVault).withdraw(shareAmount);\n} else {\n    wAmount = IHardVault(bank.hardVault).withdraw(token, shareAmount);\n}\n\nwAmount = wAmount > pos.underlyingAmount\n   ? pos.underlyingAmount\n    : wAmount;\n\npos.underlyingVaultShare -= shareAmount;\npos.underlyingAmount -= wAmount;\nbank.totalLend -= wAmount;\n```\n```\nuint256 cv = oracle.getUnderlyingValue(\n    pos.underlyingToken,\n    pos.underlyingAmount\n);\n```
MEDIUM severity: The `switchMaintainerFee` and `switchWithdrawalBoost` functions introduce a latency period of approx. The `switchMaintainerFee` and `switchWithdrawalBoost` functions introduce a latency period of approximately three days, during which the new value is intended to take effect. However, this latency period is not limited to a single occurrence. A malicious maintainer can exploit this vulnerability by...

Vulnerable code:
```\nfunction switchMaintainerFee(\n    DataStoreUtils.DataStore storage DATASTORE,\n    uint256 id,\n    uint256 newFee\n) external {\n    DATASTORE.writeUintForId(\n        id,\n        "priorFee",\n        DATASTORE.readUintForId(id, "fee")\n    );\n    DATASTORE.writeUintForId(\n        id,\n        "feeSwitch",\n        block.timestamp + FEE_SWITCH_LATENCY\n    );\n    DATASTORE.writeUintForId(id, "fee", newFee);\n\n    emit MaintainerFeeSwitched(\n        id,\n        newFee,\n        block.timestamp + FEE_SWITCH_LATENCY\n    );\n}\n```\n```\nfunction getMaintainerFee(\n    DataStoreUtils.DataStore storage DATASTORE,\n    uint256 id\n) internal view returns (uint256 fee) {\n    if (DATASTORE.readUintForId(id, "feeSwitch") > block.timestamp) {\n        return DATASTORE.readUintForId(id, "priorFee");\n    }\n    return DATASTORE.readUintForId(id, "fee");\n}\n```
MEDIUM severity: The "Gold order size should be limited" vulnerability occurs when a user is able to submit an order . The "Gold order size should be limited" vulnerability occurs when a user is able to submit an order to purchase an excessive amount of gold cards, potentially exceeding the available gas supply. This is due to the `_commit` function utilizing less gas than the `mineGolds` function, which is responsi...

Vulnerable code:
```\nskyweaverAssets.batchMint(\n    _order.cardRecipient,\n    _ids,\n    amounts,\n    ""\n)\n```
MEDIUM severity: The `ROUSG::burn` function is a critical component of the system, allowing administrators to burn `r. The `ROUSG::burn` function is a critical component of the system, allowing administrators to burn `rOUSG` tokens from any account for regulatory purposes. Currently, this function is restricted to burning a minimum amount of `rOUSG` tokens, which is equivalent to `OUSG_TO_ROUSG_SHARES_MULTIPLIER` ti...

Vulnerable code:
```\nif (ousgSharesAmount < OUSG_TO_ROUSG_SHARES_MULTIPLIER):\n    revert UnwrapTooSmall()\n```