Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `Governance::registerEmitterAndDomain` function is responsible for registering an emitter addres. The `Governance::registerEmitterAndDomain` function is responsible for registering an emitter address and corresponding CCTP domain for a given foreign chain. While the function performs a check to ensure that the registered CCTP domain of the foreign chain is not equal to that of the local chain, i...

Vulnerable code:
```\nfunction registerEmitterAndDomain(bytes memory encodedVaa) public {\n    /* parsing of Governance VAA payload */\n\n    require(registeredEmitters[foreignChain] == 0, "chain already registered");\n\n    /* additional parsing of Governance VAA payload */\n\n    registeredEmitters[foreignChain] = foreignAddress;\n\n    getChainToDomain()[foreignChain] = cctpDomain;\n    getDomainToChain()[cctpDomain] = foreignChain;\n}\n```
MEDIUM severity: The Auctioneer Cannot Be Removed From The Protocol vulnerability arises when an attacker successfull. The Auctioneer Cannot Be Removed From The Protocol vulnerability arises when an attacker successfully exploits a vulnerable Auctioneer, and there is no mechanism to remove the compromised Auctioneer from the protocol. This is due to the absence of a feature to remove an Auctioneer from the whitelist...

Vulnerable code:
```\nFile: BondAggregator.sol\n\nfunction registerAuctioneer(IBondAuctioneer auctioneer_) external requiresAuth {\n    // Restricted to authorized addresses\n\n    if (_whitelist[address(auctioneer_)]) {\n        revert Aggregator_AlreadyRegistered(address(auctioneer_));\n    }\n\n    // Add the auctioneer to the whitelist\n    auctioneers.push(auctioneer_);\n    _whitelist[address(auctioneer_)] = true;\n}\n```
MEDIUM severity: The `getPositionRisk()` function in the system calculates the value of the underlying position by us. The `getPositionRisk()` function in the system calculates the value of the underlying position by using the `underlyingAmount`, which represents the initial deposit of tokens. However, this calculation does not take into account the interest earned on the deposit, which can significantly impact the...

Vulnerable code:
```\n((borrowsValue - collateralValue) / underlyingValue) >= underlyingLiqThreshold\n```\n```\nuint256 cv = oracle.getUnderlyingValue(\n    pos.underlyingToken,\n    pos.underlyingAmount\n);\n```
MEDIUM severity: The `JUSDBank` smart contract's `repay` function allows users to repay their JUSD debt and interest . The `JUSDBank` smart contract's `repay` function allows users to repay their JUSD debt and interest by transferring JUSD tokens to the contract. However, the contract lacks a burn mechanism, which means that the JUSD tokens received as repayment are not removed from circulation. This can lead to an...

Vulnerable code:
```\nfunction _repay(\n    DataTypes.UserInfo storage user,\n    address payer,\n    address to,\n    uint256 amount,\n    uint256 tRate\n) internal returns (uint256) {\n    require(amount!= 0, JUSDErrors.REPAY_AMOUNT_IS_ZERO);\n    uint256 JUSDBorrowed = user.t0BorrowBalance * tRate;\n    uint256 tBorrowAmount;\n    uint256 t0Amount;\n    if (JUSDBorrowed <= amount) {\n        tBorrowAmount = JUSDBorrowed;\n        t0Amount = user.t0BorrowBalance;\n    } else {\n        tBorrowAmount = amount;\n        t0Amount = amount / tRate;\n    }\n    IERC20(JUSD).safeTransferFrom(payer, address(this), tBorrowAmount);\n    user.t0BorrowBalance -= t0Amount;\n    t0TotalBorrowAmount -= t0Amount;\n    emit Repay(payer, to, tBorrowAmount);\n    return tBorrowAmount;\n```
MEDIUM severity: The `SdtRewardReceiver` contract's `withdrawRewards` function has a critical flaw in its slippage pr. The `SdtRewardReceiver` contract's `withdrawRewards` function has a critical flaw in its slippage protection mechanism. The `_min_dy` parameter is set via the `poolCvgSDT.get_dy` method, which is a relative output that is executed at runtime. This means that the slippage check is inherently flawed,...

Vulnerable code:
```\nif (isMint) {\n    cvgSdt.mint(receiver, rewardAmount);\n} else {\n    ICrvPoolPlain _poolCvgSDT = poolCvgSDT;\n    _poolCvgSDT.exchange(0, 1, rewardAmount, _poolCvgSDT.get_dy(0, 1, rewardAmount), receiver);\n}\n```\n```\n@view\n@external\ndef get_dy(\n    i: int128, \n    j: int128, \n    dx: uint256\n) -> uint256:\n    """\n    Calculate the current output dy given input dx\n    Index values can be found via the `coins` public getter method\n    @param i Index value for the coin to send\n    @param j Index value of the coin to receive\n    @param dx Amount of `i` being exchanged\n    @return Amount of `j` predicted\n    """\n    rates: uint256[N_COINS] = self.rate_multipliers\n    xp: uint256[N_COINS] = self._xp_mem(rates, self.balances)\n\n    x: uint256 = xp[i] + (dx * rates[i] / PRECISION)\n    y: uint256 = self.get_y(i, j, x, xp, 0, 0)\n    dy: uint256 = xp[j] - y - 1\n    fee: uint256 = self.fee * dy / FEE_DENOMINATOR\n    return (dy - fee) * PRECISION / rates[j]\n```
MEDIUM severity: The vulnerability arises from a combination of conditions that allow an attacker to steal temporaril. The vulnerability arises from a combination of conditions that allow an attacker to steal temporarily held ether during a transaction. The exchange proxy, which typically holds no ether balance, can temporarily hold a balance during a transaction. This balance is vulnerable to theft if the following...

Vulnerable code:
```\nmodifier refundsAttachedEth() {\n    _;\n    uint256 remainingBalance = LibSafeMathV06.min256(msg.value, address(this).balance);\n    if (remainingBalance > 0) {\n        msg.sender.transfer(remainingBalance);\n    }\n}\n```\n```\nif (inputToken == ETH_TOKEN_ADDRESS) {\n    provider.transfer(sellAmount);\n```
MEDIUM severity: The provided assembly code is used to access the parent blockhash within the RLP-encoded blockheader. The provided assembly code is used to access the parent blockhash within the RLP-encoded blockheader. The code first checks if the `first` variable is greater than 0xf7, and if not, it raises an error. If the condition is met, it calculates the `offset` variable by subtracting 0xf7 from `first` and...

Vulnerable code:
```\nrequire(first > 0xf7, "invalid offset");\nuint8 offset = first - 0xf7 + 2;\n\nassembly {\n    mstore(0x20, _blockheader)\n\n    parentHash := mload(\n        add(\n            add(\n                mstore(0x20),\n                0x20\n            ),\n            offset\n        )\n    )\n}\n```
MEDIUM severity: The vulnerability arises from the lack of approval to 0 when using OpenZeppelin's `safeApprove` func. The vulnerability arises from the lack of approval to 0 when using OpenZeppelin's `safeApprove` function to approve the fee manager to spend the basetoken in the DVP contract. This oversight occurs during the minting and selling/burning of DVPs through the PositionManager. The `mint` and `sell` func...

Vulnerable code:
```\nfunction safeApprove(\n    IERC20 token,\n    address spender,\n    uint256 value\n) internal {\n    require(\n        (value == 0) || (token.allowance(address(this), spender) == 0),\n        "SafeERC20: approve from non-zero to non-zero allowance"\n    );\n    _callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n}\n```
MEDIUM severity: The `mint` function in the `InfinityPool` contract is vulnerable to incorrect value emission due to . The `mint` function in the `InfinityPool` contract is vulnerable to incorrect value emission due to its recomputation of the assets before emitting the event. This function assumes that the result of `previewMint` and `convertToAssets` will always be equal, which is only true when the `totalAssets`...

Vulnerable code:
```\nfunction mint(uint256 shares, address receiver) public isOpen returns (uint256 assets) {\n    if (shares == 0) {\n        revert InvalidParams();\n    }\n    assets = previewMint(shares);\n    asset.transferFrom(msg.sender, address(this), assets);\n    liquidStakingToken.mint(receiver, shares);\n    assets = convertToAssets(shares);\n    emit Deposit(msg.sender, receiver, assets, shares);\n}\n```
MEDIUM severity: The `permit` function in the `Base` contract, as well as its counterparts in `MSD` and `MSDS`, utili. The `permit` function in the `Base` contract, as well as its counterparts in `MSD` and `MSDS`, utilizes a deployment-time approach to incorporate the chain ID into the `DOMAIN_SEPARATOR`. This `DOMAIN_SEPARATOR` is a hash of various values, including the chain ID, which is obtained using the `CHAINI...

Vulnerable code:
```\nfunction _initialize(\n    string memory _name,\n    string memory _symbol,\n    uint8 _decimals,\n    IControllerInterface _controller,\n    IInterestRateModelInterface _interestRateModel\n) internal virtual {\n    controller = _controller;\n    interestRateModel = _interestRateModel;\n    accrualBlockNumber = block.number;\n    borrowIndex = BASE;\n    flashloanFeeRatio = 0.0008e18;\n    protocolFeeRatio = 0.25e18;\n    __Ownable_init();\n    __ERC20_init(_name, _symbol, _decimals);\n    __ReentrancyGuard_init();\n\n    uint256 chainId;\n\n    assembly {\n        chainId := chainid()\n    }\n    DOMAIN_SEPARATOR = keccak256(\n        abi.encode(\n            keccak256(\n                "EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"\n            ),\n            keccak256(bytes(_name)),\n            keccak256(bytes("1")),\n            chainId,\n            address(this)\n        )\n    );\n```\n```\nbytes32 _digest = \n    keccak256(\n        abi.encodePacked(\n            "\x19\x01",\n            DOMAIN_SEPARATOR,\n            keccak256(\n                abi.encode(\n                    PERMIT_TYPEHASH,\n                    _owner,\n                    _spender,\n                    _value,\n                    _currentNonce,\n                    _deadline\n                )\n            )\n        )\n    );\n\naddress _recoveredAddress = ecrecover(_digest, _v, _r, _s);\nrequire(\n    _recoveredAddress!= address(0) && _recoveredAddress == _owner,\n    "permit: INVALID_SIGNATURE!"\n);\n```
MEDIUM severity: This vulnerability is characterized by the unnecessary inheritance of contracts `BlacklistableV1` an. This vulnerability is characterized by the unnecessary inheritance of contracts `BlacklistableV1` and `RescuableV1` by the `FiatTokenV1` contract. Specifically, these contracts extend `ContextUpgradeable` and `ERC20Upgradeable`, which are not utilized in any of the functions within `FiatTokenV1`. Th...

Vulnerable code:
```\nabstract contract BlacklistableV1 is\n    Initializable,\n    ContextUpgradeable,\n    ERC20Upgradeable {\n}\n```\n```\nabstract contract RescuableV1 is\n    Initializable,\n    ContextUpgradeable,\n    ERC20Upgradeable {\n}\n```\n```\ncontract FiatTokenV1 is\n    Initializable,\n    ERC20Upgradeable,\n    ERC20PausableUpgradeable,\n    ERC20BurnableUpgradeable,\n    AccessControlUpgradeable,\n    ERC20PermitUpgradeable,\n    UUPSUpgradeable,\n    BlacklistableV1,\n    RescuableV1\n{\n```
MEDIUM severity: The `StakingController` contract lacks sufficient protection against replay attacks, which can compr. The `StakingController` contract lacks sufficient protection against replay attacks, which can compromise the integrity of the domain bidding process. The `approvedBids` mapping provides limited mitigation, as it does not prevent an attacker from replaying a previously submitted bid in a new contrac...

Vulnerable code:
```\nfunction createBid(\n    uint256 parentId,\n    uint256 bidAmount,\n    string memory bidIPFSHash,\n    string memory name\n) public pure returns (bytes32) {\n    return keccak256(abi.encode(parentId, bidAmount, bidIPFSHash, name));\n}\n```
MEDIUM severity: The vulnerability lies in the `executeOpen` function of the LeverageModule, specifically in the `exe. The vulnerability lies in the `executeOpen` function of the LeverageModule, specifically in the `executeOpen` and `executeAdjust` functions. The `vault.checkSkewMax` function is not being called after updating the global position data, which can lead to an insecure and potentially exploitable situat...

Vulnerable code:
```\nfunction executeOpen(\n    address _account,\n    address _keeper,\n    FlatcoinStructs.Order calldata _order\n) external whenNotPaused onlyAuthorizedModule returns (uint256 _newTokenId) {\n    vault.checkSkewMax({additionalSkew: announcedOpen.additionalSize});\n\n    vault.updateGlobalPositionData({\n        price: entryPrice,\n        marginDelta: int256(announcedOpen.margin),\n        additionalSizeDelta: int256(announcedOpen.additionalSize)\n    });\n}\n```\n```\nstableCollateralTotal = 90e18\n\n_globalPositions = {\n    sizeOpenedTotal: 100e18,\n    lastPrice: 1800e18,\n}\n\nnew_position = {\n    size: 5e18,\n    price: 2000e18\n}\n```\n```\nlongSkewFraction = (_globalPositions.sizeOpenedTotal + additionalSize) * 1e18 / stableCollateralTotal\n                 = (100e18 + 5e18) * 1e18 / 90e18\n                 = 1.16667e18 < skewFractionMax(1.2e18)\nso checkSkewMax will be passed\n```\n```\ndef updateGlobalPositionData():\n    profitLossTotal = _globalPositions.sizeOpenedTotal * (int256(price) - int256(globalPosition.lastPrice)) / int256(price)\n    profitLossTotal = 100e18 * (2000e18 - 1800e18) / 2000e18\n    profitLossTotal = 10e18\n\n    _updateStableCollateralTotal(-profitLossTotal)\n    stableCollateralTotal = 90e18 - 10e18\n    stableCollateralTotal = 80e18\n\n    checkSkewMax()\n    longSkewFraction = (_globalPositions.sizeOpenedTotal + additionalSize) * 1e18 / stableCollateralTotal\n    longSkewFraction = (100e18 + 5e18) * 1e18 / 80e18\n    longSkewFraction = 1.3125e18\n    if longSkewFraction > skewFractionMax(1.2e18):\n        # code\n```
MEDIUM severity: The FrankenDAO staking contract contains a vulnerability in its implementation of the `stakedTimeBon. The FrankenDAO staking contract contains a vulnerability in its implementation of the `stakedTimeBonus` calculation. Specifically, the `stakedTimeBonus` is hardcoded to use a fixed value based on the `monsterMultiplier` when calculating the bonus for `Frankenmonsters`. This hardcoded value is not up...

Vulnerable code:
```\nfunction getTokenVotingPower(uint _tokenId) public override view returns (uint) {\n    if (ownerOf(_tokenId) == address(0)) {\n        revert NonExistentToken();\n    }\n\n    uint multiplier = _tokenId < 10_000? PERCENT : monsterMultiplier;\n\n    return ((baseVotes * multiplier) / PERCENT) + stakedTimeBonus[_tokenId] + evilBonus(_tokenId);\n}\n```\n```\nfunction setMonsterMultiplier(uint _monsterMultiplier) external onlyExecutor {\n    emit MonsterMultiplierChanged(_monsterMultiplier);\n}\n```\n```\nfunction stake(uint[] calldata _tokenIds, uint _unlockTime) \n{\n    function _stakeToken(uint _tokenId, uint _unlockTime) internal returns (uint) {\n        if (_unlockTime > 0) {\n            stakedTimeBonus[_tokenId] = _tokenId < 10000? fullStakedTimeBonus : fullStakedTimeBonus / 2;\n        }\n    }\n```
MEDIUM severity: The Solidity version pragmas in the source files specify a requirement for compiler version 0.8.10, . The Solidity version pragmas in the source files specify a requirement for compiler version 0.8.10, either exactly or at least. This outdated version of the Solidity compiler has known security vulnerabilities, making it a potential risk for the smart contract. It is recommended to use the latest ve...

Vulnerable code:
```\npragma solidity ^0.8.10;\n```\n```\npragma solidity ^0.8.10;\n```
MEDIUM severity: The presence of debugging code in the repository is a vulnerability that can compromise the integrit. The presence of debugging code in the repository is a vulnerability that can compromise the integrity and security of the codebase. Debugging code, such as the event logs and test halting mechanisms, is typically used during the development stage to aid in the debugging process. However, it is cruci...

Vulnerable code:
```\nevent log(bytes32);\nevent log_int(bytes32, int256);\nevent log_ints(bytes32, int256[]);\nevent log_uint(bytes32, uint256);\nevent log_uints(bytes32, uint256[]);\n```\n```\nevent log(bytes32);\nevent log_uint(bytes32, uint256);\nevent log_int(bytes32, int256);\n```\n```\nevent log(bytes32);\nevent log_int(bytes32, int128);\nevent log_int(bytes32, int);\nevent log_uint(bytes32, uint);\nevent log_addr(bytes32, address);\n```\n```\nevent log(bytes32);\n```\n```\nevent log(bytes32);\nevent log_int(bytes32, int256);\nevent log_ints(bytes32, int256[]);\nevent log_uint(bytes32, uint256);\nevent log_uints(bytes32, uint256[]);\n```\n```\nevent log_int(bytes32, int);\nevent log_ints(bytes32, int128[]);\nevent log_uint(bytes32, uint);\nevent log_uints(bytes32, uint[]);\nevent log_addrs(bytes32, address[]);\n```\n```\nevent log_uint(bytes32, uint256);\nevent log_int(bytes32, int256);\n```\n```\nevent Log_uint(bytes32, uint256);\n```\n```\nshell.testHalts = true;\n```\n```\nfunction setTestHalts(bool _testOrNotToTest) public {\n    shell.testHalts = _testOrNotToTest;\n}\n```\n```\nbool testHalts;\n```
MEDIUM severity: The `FixedStrikeOptionTeller` contract's `create` function allows for the minting of new option toke. The `FixedStrikeOptionTeller` contract's `create` function allows for the minting of new option tokens when the current block timestamp equals the expiry timestamp. However, this minting process is vulnerable to a scenario where the option tokens are created, but cannot be exercised in the same tran...

Vulnerable code:
```\nif (uint256(expiry) < block.timestamp) {\n    revert Teller_OptionExpired(expiry);\n}\n```\n```\nif (uint48(block.timestamp) >= expiry) {\n    revert Teller_OptionExpired(expiry);\n}\n```
MEDIUM severity: The `ValidateSPV.validateHeaderChain` function in the Bitcoin implementation is responsible for vali. The `ValidateSPV.validateHeaderChain` function in the Bitcoin implementation is responsible for validating a sequence of Bitcoin headers and calculating the total accumulated difficulty across the entire sequence. While the function performs a preliminary check to ensure the input headers are relati...

Vulnerable code:
```\nif (_headers.length % 80!= 0):\n    return ERR_BAD_LENGTH\n```
MEDIUM severity: The protocol's implementation of time delays is flawed due to the use of incorrect constants. Specif. The protocol's implementation of time delays is flawed due to the use of incorrect constants. Specifically, the `ISOUSD_TIME_DELAY` constant in `isoUSDToken.sol` is set to `3`, which is equivalent to 3 seconds, whereas it should be set to `3 days`. This discrepancy can lead to unintended consequence...

Vulnerable code:
```\nuint256 constant ISOUSD_TIME_DELAY = 3;\n```\n```\nuint256 public constant CHANGE_COLLATERAL_DELAY = 200;\n```
MEDIUM severity: The current implementation of the `_claimRewards` function in the SecondaryRewarder contract introdu. The current implementation of the `_claimRewards` function in the SecondaryRewarder contract introduces a vulnerability that could be exploited by malicious users to manipulate the outcome of the reward token transfer. This is due to the "push" approach used, where the reward tokens are sent to the...

Vulnerable code:
```\nFile: SecondaryRewarder.sol\n\nfunction _claimRewards(address account, uint256 nTokenBalanceBefore, uint256 nTokenBalanceAfter) private {\n    uint256 rewardToClaim = _calculateRewardToClaim(account, nTokenBalanceBefore, accumulatedRewardPerNToken);\n\n    rewardDebtPerAccount[account] = nTokenBalanceAfter\n       .mul(accumulatedRewardPerNToken)\n       .div(uint256(Constants.INTERNAL_TOKEN_PRECISION))\n       .toUint128();\n\n    if (0 < rewardToClaim) {\n        GenericToken.safeTransferOut(REWARD_TOKEN, account, rewardToClaim);\n        emit RewardTransfer(REWARD_TOKEN, account, rewardToClaim);\n    }\n```\n```\n_claimRewards -> claimRewardsDirect\n\n_claimRewards -> claimRewards -> Incentives.claimIncentives\n_claimRewards -> claimRewards -> Incentives.claimIncentives -> BalancerHandler._finalize\n_claimRewards -> claimRewards -> Incentives.claimIncentives -> BalancerHandler._finalize -> Used by many functions\n\n_claimRewards -> claimRewards -> Incentives.claimIncentives -> BalancerHandler.claimIncentivesManual\n_claimRewards -> claimRewards -> Incentives.claimIncentives -> BalancerHandler.claimIncentivesManual -> nTokenAction.nTokenClaimIncentives\n_claimRewards -> claimRewards -> Incentives.claimIncentives -> BalancerHandler.claimIncentivesManual -> nTokenAction.nTokenClaimIncentives -> claimNote\n```
MEDIUM severity: The governor's ability to permanently prevent withdrawals, despite being restricted, is a critical v. The governor's ability to permanently prevent withdrawals, despite being restricted, is a critical vulnerability in the protocol's design. The governor's role is intended to be restricted, with limited access to the `Factory` contract's `governMarketConfig` function, to prevent malicious activities...

Vulnerable code:
```\nIs the admin/owner of the protocol/contracts TRUSTED or RESTRICTED?\n\nRestricted. The governor address should not be able to steal funds or prevent users from withdrawing. It does have access to the govern methods in Factory, and it could trigger liquidations by increasing nSigma. We consider this an acceptable risk, and the governor itself will have a timelock.\n```
MEDIUM severity: The vulnerability is related to the use of modifiers in the code, specifically the `onlyGovernance` . The vulnerability is related to the use of modifiers in the code, specifically the `onlyGovernance` and `onlyStrategist` modifiers. These modifiers are used to restrict access to certain functions or methods, but they are implemented using internal functions `_checkGovernance` and `_checkStrategist`...

Vulnerable code:
```\nmodifier onlyGovernance {\n    _checkGovernance();\n}\n```\n```\nfunction _checkGovernance() internal view {\n    require(msg.sender == governance, "not governance");\n}\n```\n```\nfunction _checkStrategist() internal view {\n    require(msg.sender == governance || strategists[msg.sender], "not strategist");\n}\n\nmodifier onlyStrategist {\n    _checkStrategist();\n    _;\n}\n```\n```\nfunction _checkGovernance() internal view {\n    require(msg.sender == governance, "not governance");\n}\n\nmodifier onlyGovernance() {\n    _checkGovernance();\n    _;\n}\n```\n```\nfunction _checkGovernance() internal view {\n    require(msg.sender == IGaugeController(controller).governance(), "not governance");\n}\n\nmodifier onlyGovernance() {\n    _checkGovernance();\n    _;\n}\n```
MEDIUM severity: The `openPosition` function in the `PartyBFacetImpl.sol` contract contains a critical vulnerability . The `openPosition` function in the `PartyBFacetImpl.sol` contract contains a critical vulnerability that can lead to the immediate liquidation of a user's account, resulting in a loss of Collateral Value Adjustment (CVA) and liquidation fee. The issue arises from the insolvency check, `isSolventAfte...

Vulnerable code:
```\nFile: PartyBFacetImpl.sol\n\nfunction openPosition(\n    uint256 quoteId,\n    uint256 filledAmount,\n    uint256 openedPrice,\n    PairUpnlAndPriceSig memory upnlSig\n) internal returns (uint256 currentId) {\n    LibSolvency.isSolventAfterOpenPosition(quoteId, filledAmount, upnlSig);\n\n    accountLayout.partyANonces[quote.partyA] += 1;\n    accountLayout.partyBNonces[quote.partyB][quote.partyA] += 1;\n    quote.modifyTimestamp = block.timestamp;\n\n    LibQuote.removeFromPendingQuotes(quote);\n\n    if (quote.quantity == filledAmount) {\n        accountLayout.pendingLockedBalances[quote.partyA].subQuote(quote);\n        accountLayout.partyBPendingLockedBalances[quote.partyB][quote.partyA].subQuote(quote);\n\n        if (quote.orderType == OrderType.LIMIT) {\n            quote.lockedValues.mul(openedPrice).div(quote.requestedOpenPrice);\n        }\n        accountLayout.lockedBalances[quote.partyA].addQuote(quote);\n        accountLayout.partyBLockedBalances[quote.partyB][quote.partyA].addQuote(quote);\n    }\n```