Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `BondBaseSDA.setDefaults` function in the provided smart contract code does not perform any inpu. The `BondBaseSDA.setDefaults` function in the provided smart contract code does not perform any input validation, which can lead to incorrect initialization of new markets. This vulnerability allows an attacker to manipulate the default values of various market parameters, potentially breaking the m...

Vulnerable code:
```\nfunction setDefaults(uint32[6] memory defaults_) external override requiresAuth {\n    defaultTuneInterval = defaults_[0];\n    defaultTuneAdjustment = defaults_[1];\n    minDebtDecayInterval = defaults_[2];\n    minDepositInterval = defaults_[3];\n    minMarketDuration = defaults_[4];\n    minDebtBuffer = defaults_[5];\n}\n```
MEDIUM severity: The `checkTransaction()` function in HatsSignerGateBase, responsible for approving transactions on a. The `checkTransaction()` function in HatsSignerGateBase, responsible for approving transactions on a Gnosis safe, contains a critical vulnerability. The function performs two checks to ensure the transaction is valid: first, it verifies that the number of registered owners on the safe meets the mini...

Vulnerable code:
```\nuint256 safeOwnerCount = safe.getOwners().length;\nif (safeOwnerCount < minThreshold) {\n    revert BelowMinThreshold(minThreshold, safeOwnerCount);\n}\n```\n```\nuint256 validSigCount = countValidSignatures(txHash, signatures, signatures.length / 65);\n\nif (validSigCount < safe.getThreshold()) {\n    revert InvalidSigners();\n}\n```
MEDIUM severity: The vulnerability allows malicious users to exploit the Tellor system by retrieving old values, whic. The vulnerability allows malicious users to exploit the Tellor system by retrieving old values, which can be used to manipulate the system and gain economic benefits. This is possible due to the lack of measures to prevent the retrieval of old values, which are not removed from the system after a di...

Vulnerable code:
```\nFile: TellorOracle.sol\n\nfunction getPriceInEth(address tokenToPrice) external returns (uint256) {\n    TellorInfo memory tellorInfo = _getQueryInfo(tokenToPrice);\n    uint256 timestamp = block.timestamp;\n\n    (bytes memory value, uint256 timestampRetrieved) = getDataBefore(tellorInfo.queryId, timestamp - 30 minutes);\n\n    uint256 tellorStoredTimeout = uint256(tellorInfo.pricingTimeout);\n    uint256 tokenPricingTimeout = tellorStoredTimeout == 0? DEFAULT_PRICING_TIMEOUT : tellorStoredTimeout;\n\n    if (timestampRetrieved == 0 || timestamp - timestampRetrieved > tokenPricingTimeout) {\n        revert InvalidDataReturned();\n    }\n\n    uint256 price = abi.decode(value, (uint256));\n    return _denominationPricing(tellorInfo.denomination, price, tokenToPrice);\n}\n```
MEDIUM severity: The vulnerability lies in the way Socket's routes and controllers integrate with third-party APIs to. The vulnerability lies in the way Socket's routes and controllers integrate with third-party APIs to create the payload for their actions. The payload, which is generated off-chain, is not thoroughly checked for correctness or consistency with the user-provided arguments. This lack of verification c...

Vulnerable code:
```\nbool success, bytes memory result = ONEINCH_AGGREGATOR.call(swapExtraData);\n```\n```\nemit SocketSwapTokens(\n    fromToken,\n    toToken,\n    returnAmount,\n    amount,\n    OneInchIdentifier,\n    receiverAddress\n);\n```
MEDIUM severity: The vulnerability lies in the fact that an inactive vault can send its total underlying amount to th. The vulnerability lies in the fact that an inactive vault can send its total underlying amount to the `XChainController`, disrupting the rebalancing of active vaults. This can occur when the `pushTotalUnderlyingToController` function is called on an inactive vault, which increments the `underlyingRe...

Vulnerable code:
```\nmodifier onlyWhenUnderlyingsReceived(uint256 _vaultNumber) {\n    require(\n        vaultStage[_vaultNumber].underlyingReceived == vaultStage[_vaultNumber].activeVaults,\n        "Not all underlyings received"\n    );\n}\n```
MEDIUM severity: The vulnerability lies in the way the `totalDeposit` accounting is tied to deposit addresses in the . The vulnerability lies in the way the `totalDeposit` accounting is tied to deposit addresses in the `Vault` contract, which inherits from the ERC20 standard. The `transfer` and `transferFrom` functions, which are publicly accessible, allow users to transfer vault shares to other users, breaking the...

Vulnerable code:
```\ncontract Vault is\n    IVault,\n    ERC20,\n    EpochControls,\n    AccessControl,\n    Pausable {\n    // code here\n}\n```\n```\nfunction transfer(address to, uint256 amount) public virtual override returns (bool) {\n    address owner = _msgSender();\n    _transfer(owner, to, amount);\n    return true;\n}\n```\n```\nif (_state.liquidity.totalDeposit > maxDeposit) {\n    revert ExceedsMaxDeposit();\n}\n\nif (amount > maxDeposit - _state.liquidity.totalDeposit) {\n    revert ExceedsMaxDeposit();\n}\n```
MEDIUM severity: The DynamicLiquidTokenConverter in zBanc introduces significant changes to the underlying bancorprot. The DynamicLiquidTokenConverter in zBanc introduces significant changes to the underlying bancorprotocol base, which may lead to increased complexity and potentially introduce software misbehavior. This complexity can increase the attack surface, making it more vulnerable to attacks.\n\nThe DynamicL...

Vulnerable code:
```\nfunction converterType() public pure returns (uint16) {\n    return 3;\n}\n```\n```\n{\n    DSToken token = new DSToken(_name, _symbol, _decimals);\n\n    token.issue(msg.sender, _initialSupply);\n\n    emit NewToken(token);\n\n    createConverter(\n        token,\n        _reserveToken,\n        _reserveWeight,\n        _reserveBalance,\n        _registry,\n        _maxConversionFee,\n        _minimumWeight,\n        _stepWeight,\n        _marketCapThreshold\n    );\n\n    return token;\n}\n```\n```\nfunction upgradeOld(DynamicLiquidTokenConverter _converter, bytes32 _version) public {\n    DynamicLiquidTokenConverter converter = DynamicLiquidTokenConverter(_converter);\n    address prevOwner = converter.owner();\n    acceptConverterOwnership(converter);\n    DynamicLiquidTokenConverter newConverter = createConverter(converter);\n\n    copyReserves(converter, newConverter);\n    copyConversionFee(converter, newConverter);\n    transferReserveBalances(converter, newConverter);\n    IConverterAnchor anchor = converter.token();\n\n    bool activate = isV28OrHigherConverter(converter) && converter.isActive();\n\n    if (anchor.owner() == address(converter)) {\n        converter.transferTokenOwnership(address(newConverter));\n        newConverter.acceptAnchorOwnership();\n    }\n\n    handleTypeSpecificData(converter, newConverter, activate);\n    converter.transferOwnership(prevOwner);\n\n    newConverter.transferOwnership(prevOwner);\n\n    emit ConverterUpgrade(address(converter), address(newConverter));\n```\n```\nfunction upgradeOld(\n    IConverter _converter,\n    bytes32 _version\n) public {\n    upgrade(_converter, 0);\n}\n```
MEDIUM severity: The vulnerability allows the auction creator to claim the proceeds before bidders can claim their bi. The vulnerability allows the auction creator to claim the proceeds before bidders can claim their bids, resulting in bidders being unable to retrieve their funds. This occurs when the auction creator sets the auction status to "Claimed" before bidders have had the opportunity to claim their bids. On...

Vulnerable code:
```\nfunction _claimProceeds(uint96 lotId_)\n    internal\n    override\n    returns (uint96 purchased, uint96 sold, uint96 payoutSent)\n{\n    auctionData[lotId_].status = Auction.Status.Claimed;\n}\n```\n```\nfunction claimBids(\n    uint96 lotId_,\n    uint64[] calldata bidIds_\n)\n    external\n    override\n    onlyInternal\n    returns (BidClaim[] memory bidClaims, bytes memory auctionOutput)\n{\n    _revertIfLotInvalid(lotId_);\n    _revertIfLotNotSettled(lotId_);\n\n    return _claimBids(lotId_, bidIds_);\n}\n```\n```\nfunction test_claimProceeds_before_claimBids()\n    external\n{\n    givenLotIsCreated;\n    givenLotHasStarted;\n    givenBidIsCreated(_BID_AMOUNT_UNSUCCESSFUL, _BID_AMOUNT_OUT_UNSUCCESSFUL);\n    givenBidIsCreated(_BID_PRICE_TWO_AMOUNT, _BID_PRICE_TWO_AMOUNT_OUT);\n    givenBidIsCreated(_BID_PRICE_TWO_AMOUNT, _BID_PRICE_TWO_AMOUNT_OUT);\n    givenBidIsCreated(_BID_PRICE_TWO_AMOUNT, _BID_PRICE_TWO_AMOUNT_OUT);\n    givenBidIsCreated(_BID_PRICE_TWO_AMOUNT, _BID_PRICE_TWO_AMOUNT_OUT);\n    givenBidIsCreated(_BID_PRICE_TWO_AMOUNT, _BID_PRICE_TWO_AMOUNT_OUT);\n    givenBidIsCreated(_BID_PRICE_TWO_AMOUNT, _BID_PRICE_TWO_AMOUNT_OUT);\n    givenLotHasConcluded;\n    givenPrivateKeyIsSubmitted;\n    givenLotIsDecrypted;\n    givenLotIsSettled;\n\n    uint64 bidId = 1;\n\n    uint64[] memory bidIds = new uint64[](1);\n    bidIds[0] = bidId;\n\n    // Call the function\n    vm.prank(address(_auctionHouse));\n    _module.claimProceeds(_lotId);\n\n    bytes memory err = abi.encodeWithSelector(EncryptedMarginalPriceAuctionModule.Auction_WrongState.selector, _lotId);\n    vm.expectRevert(err);\n    vm.prank(address(_auctionHouse));\n    _module.claimBids(_lotId, bidIds);\n}\n```
MEDIUM severity: The emergency processing mechanism is designed to mitigate the risk of token transfers being blocked. The emergency processing mechanism is designed to mitigate the risk of token transfers being blocked in the Pull Pattern. This mechanism is triggered when a sender or receiver is listed in the USDC blacklist, which could potentially block the transfer of tribute tokens back to the user. In such case...

Vulnerable code:
```\nif (!emergencyProcessing) {\n    require(\n        proposal.tributeToken.transfer(\n            proposal.proposer,\n            proposal.tributeOffered\n        ),\n        "failing vote token transfer failed"\n    );\n```
MEDIUM severity: The `BLACKLISTER_ROLE`-designated accounts are capable of bypassing the intended effects of blacklis. The `BLACKLISTER_ROLE`-designated accounts are capable of bypassing the intended effects of blacklisting, allowing them to continue engaging in transactions with `Stablecoin` despite being flagged as blacklisted. This is due to the current implementation of the `_onceBlacklisted` function, which tra...

Vulnerable code:
```\nfunction _onceBlacklisted(address user) internal override {\n    _transfer(user, _msgSender(), balanceOf(user));\n}\n```
MEDIUM severity: The router's compatibility with fee-on-transfers tokens is severely lacking, leading to potential is. The router's compatibility with fee-on-transfers tokens is severely lacking, leading to potential issues and losses. Specifically, the router fails to account for the fees charged when transferring tokens, resulting in the recipient receiving less than the intended amount.\n\nFor instance, in the `r...

Vulnerable code:
```\naddress pair = GoatV1Factory(FACTORY).getPool(token);\n\nIERC20(pair).safeTransferFrom(msg.sender, pair, liquidity)\n\n(amountWeth, amountToken) = GoatV1Pair(pair).burn(to)\n\nif (amountWeth < wethMin):\n    revert GoatErrors.InsufficientWethAmount()\nif (amountToken < tokenMin):\n    revert GoatErrors.InsufficientTokenAmount()\n```
MEDIUM severity: The vulnerability "Missing events" refers to the absence of event emissions in certain state-changin. The vulnerability "Missing events" refers to the absence of event emissions in certain state-changing functions within the Pool contract. This oversight can lead to off-chain services being unaware of critical changes to the pool's state, resulting in potential inconsistencies and disruptions to the...

Vulnerable code:
```\nfunction setEventAggregator(address eventAggregator_) external onlyPoolManager {\n    eventAggregator = eventAggregator_;\n}\n```\n```\nfunction enablePool(bool enabled_) external onlyPoolManager {\n    enabled_ = enabled_;\n}\n```\n```\nif (eventAggregator!= address(0)) {\n    IEventAggregator(eventAggregator).execute(\n        requestIndex_\n    );\n}\n```
MEDIUM severity: The protocol's flag generation mechanism is vulnerable to a denial-of-service (DoS) attack, which co. The protocol's flag generation mechanism is vulnerable to a denial-of-service (DoS) attack, which could potentially disrupt the primary liquidation process. The issue arises from the fact that the maximum number of flags that can exist simultaneously is limited by the maximum value of a 16-bit unsig...

Vulnerable code:
```\nuint24 flaggerIdCounter;\n```\n```\n} else if (s.flaggerIdCounter < uint16.max) {\n    short.flaggerId = flagStorage.g_flaggerId = s.flaggerIdCounter;\n    s.flaggerIdCounter++;\n} else {\n    revert Errors.InvalidFlaggerHint();\n}\n```
MEDIUM severity: The vulnerability allows a malicious staker to exploit the reward system by manipulating the reward . The vulnerability allows a malicious staker to exploit the reward system by manipulating the reward multiplier calculation. This is achieved by staking an amount of tokens, waiting for a short period, and then vouching for another member. The malicious staker then borrows from the vouched member, al...

Vulnerable code:
```\nit("PoC: staker with locked balance gets more rewards even when just locked", async () => {\n    const trustAmount = parseUnits("2000");\n    const borrowAmount = parseUnits("1800");\n    const [account, staker, borrower] = members;\n\n    const [accountStaked, borrowerStaked, stakerStaked] = await helpers.getStakedAmounts(\n        account,\n        staker,\n        borrower,\n    );\n\n    expect(accountStaked).eq(borrowerStaked);\n    expect(borrowerStaked).eq(stakerStaked);\n\n    await helpers.updateTrust(staker, borrower, trustAmount);\n\n    await roll(10);\n    await helpers.borrow(borrower, borrowAmount); // borrows just after withdrawing\n\n    const [accountMultiplier, stakerMultiplier] = await helpers.getRewardsMultipliers(account, staker);\n    console.log("accountMultiplier: ", accountMultiplier);\n    console.log("StakerMultiplier: ", stakerMultiplier);\n    expect(accountMultiplier).lt(stakerMultiplier);  // the multiplier is larger even if just locked\n});\n```
MEDIUM severity: The `_fundPool` function, responsible for funding a pool with a specified amount, contains a vulnera. The `_fundPool` function, responsible for funding a pool with a specified amount, contains a vulnerability that allows users to circumvent the fee mechanism. The fee amount is calculated as a percentage of the deposited amount, using the `percentFee` variable and the `getFeeDenominator` function, wh...

Vulnerable code:
```\nfunction _fundPool(uint256 _amount, uint256 _poolId, IStrategy _strategy) internal {\n    uint256 feeAmount;\n    uint256 amountAfterFee = _amount;\n\n    Pool storage pool = pools[_poolId];\n    address _token = pool.token;\n\n    if (percentFee > 0) {\n        feeAmount = (_amount * percentFee) / getFeeDenominator();\n        amountAfterFee -= feeAmount;\n\n        _transferAmountFrom(_token, TransferData({from: msg.sender, to: treasury, amount: feeAmount}));\n    }\n\n    _transferAmountFrom(_token, TransferData({from: msg.sender, to: address(_strategy), amount: amountAfterFee}));\n    _strategy.increasePoolAmount(amountAfterFee);\n\n    emit PoolFunded(_poolId, amountAfterFee, feeAmount);\n}\n```\n```\nfeeAmount = (_amount * percentFee) / getFeeDenominator()\n```
MEDIUM severity: This vulnerability occurs when a token has a small decimal value and a high price, combined with a s. This vulnerability occurs when a token has a small decimal value and a high price, combined with a small kBid. In the provided code, the `d3MakerWithPool` contract is used to set the tokens' prices and amounts, and the `d3MM` contract is used to retrieve the token's price information. The `d3Proxy`...

Vulnerable code:
```\nfunction testQueryFail() public {\n    token1ChainLinkOracle.feedData(30647 * 1e18);\n    token2ChainLinkOracle.feedData(1 * 1e18);\n    vm.startPrank(maker);\n    uint32[] memory tokenKs = new uint32[](2);\n    tokenKs[0] = 0;\n    tokenKs[1] = (1 << 16) + 1;\n    address[] memory tokens = new address[](2);\n    tokens[0] = address(token2);\n    tokens[1] = address(token1);\n    address[] memory slotIndex = new address[](2);\n    slotIndex[0] = address(token1);\n    slotIndex[1] = address(token2);\n    uint80[] memory priceSlot = new uint80[](2);\n    priceSlot[0] = 2191925019632266903652;\n    priceSlot[1] = 720435765840878108682;\n\n    uint64[] memory amountslot = new uint64[](2);\n    amountslot[0] = stickAmount(10, 8, 400000, 18);\n    amountslot[1] = stickAmount(400000, 18, 400000, 18);\n    d3MakerWithPool.setTokensKs(tokens, tokenKs);\n    d3MakerWithPool.setTokensPrice(slotIndex, priceSlot);\n    d3MakerWithPool.setTokensAmounts(slotIndex, amountslot);\n    vm.stopPrank();\n\n    (uint256 askDownPrice, uint256 askUpPrice, uint256 bidDownPrice, uint256 bidUpPrice, uint256 swapFee) =\n        d3MM.getTokenMMPriceInfoForRead(address(token1));\n    assertEq(askDownPrice, 304555028000000000000000000000000);\n    assertEq(askUpPrice, 307231900000000000000000000000000);\n    assertEq(bidDownPrice, 3291);\n    assertEq(bidUpPrice, 3320);\n    assertEq(swapFee, 1200000000000000);\n\n    (uint256 askDownPrice2, uint256 askUpPrice2, uint256 bidDownPrice2, uint256 bidUpPrice2, uint256 swapFee2) =\n        d3MM.getTokenMMPriceInfoForRead(address(token2));\n    assertEq(askDownPrice2, 999999960000000000);\n```
MEDIUM severity: The UniswapFeature contract contains two instances of unchecked returndatasize in low-level external. The UniswapFeature contract contains two instances of unchecked returndatasize in low-level external calls, which can lead to the usage of dirty memory under the assumption that it contains data returned from the most recent call. This vulnerability is present in the calls to `UniswapV2Pair.getReser...

Vulnerable code:
```\nmstore(0xB00, UNISWAP_PAIR_RESERVES_CALL_SELECTOR_32)\nif iszero(staticcall(gas(), pair, 0xB00, 0x4, 0xC00, 0x40)) {\n    bubbleRevert()\n}\n```\n```\nmstore(0xB00, ALLOWANCE_CALL_SELECTOR_32)\nmstore(0xB04, caller())\nmstore(0xB24, address())\nlet success := call(gas(), token, 0, 0xB00, 0x44, 0xC00, 0x20)\n```
MEDIUM severity: The `load_wire_commitments_commit_api` function is responsible for loading wire commitments from a p. The `load_wire_commitments_commit_api` function is responsible for loading wire commitments from a provided proof into a memory array. The array, `wire_commitments`, is initialized to hold 2 values per commitment, which corresponds to the x and y coordinates of the commitments. The size of the array...

Vulnerable code:
```\nuint256[] memory wire_committed_commitments = new uint256[](2 * vk_nb_commitments_commit_api);\nload_wire_commitments_commit_api(wire_committed_commitments, proof);\n```\n```\nfor (let i = 0; i < mul(vk_nb_commitments_commit_api, 2); i = add(i, 1)) {\n}\n```
MEDIUM severity: The `_buildFeeExecutable()` function in BrahRouter calculates the total fee charged to the wallet by. The `_buildFeeExecutable()` function in BrahRouter calculates the total fee charged to the wallet by multiplying the gas used and gas price specified by the bot. The gas price is obtained from the `tx.gasprice` variable. This calculation is performed separately for ETH and ERC20 tokens.\n\nThe funct...

Vulnerable code:
```\nif (feeToken == ETH) {\n    uint256 totalFee = (gasUsed + GAS_OVERHEAD_NATIVE) * tx.gasprice;\n    totalFee = _applyMultiplier(totalFee);\n    return (totalFee, recipient, TokenTransfer._nativeTransferExec(recipient, totalFee));\n} else {\n    uint256 totalFee = (gasUsed + GAS_OVERHEAD_ERC20) * tx.gasprice;\n    uint256 feeToCollect = PriceFeedManager(_addressProvider.priceFeedManager()).getTokenXPriceInY(totalFee, ETH, feeToken);\n    feeToCollect = _applyMultiplier(feeToCollect);\n    return (feeToCollect, recipient, TokenTransfer._erc20TransferExec(feeToken, recipient, feeToCollect));\n```
MEDIUM severity: The `resetRewards` function, part of the TribalChief smart contract, is responsible for resetting th. The `resetRewards` function, part of the TribalChief smart contract, is responsible for resetting the allocation points of a specific pool to zero and unlocking the pool. This function can only be executed by the governor or guardian. \n\nThe function takes a pool ID as input, which is used to ident...

Vulnerable code:
```\nfunction resetRewards(uint256 _pid) public onlyGuardianOrGovernor {\n    totalAllocPoint = (totalAllocPoint - poolInfo[_pid].allocPoint);\n    poolInfo[_pid].allocPoint = 0;\n\n    poolInfo[_pid].unlocked = true;\n\n    rewarder[_pid] = IRewarder(address(0));\n}\n```
MEDIUM severity: The `reportUnauthorizedSigning` function in the `keep-core` contract allows an attacker to monitor t. The `reportUnauthorizedSigning` function in the `keep-core` contract allows an attacker to monitor the function for fraud reports and attempt to front-run the original call, thereby becoming the first to report the fraud and receive a reward of 5% of the total seized amount. This vulnerability arise...

Vulnerable code:
```\n/**\n * Reports unauthorized signing for the provided group. Must provide\n * a valid signature of the group address as a message. Successful signature\n * verification means the private key has been leaked and all group members\n * should be punished by seizing their tokens. The submitter of this proof is\n * rewarded with 5% of the total seized amount scaled by the reward adjustment\n * parameter and the rest 95% is burned.\n */\n\nfunction reportUnauthorizedSigning(\n    uint256 groupIndex,\n    bytes memory signedGroupPubKey\n) public {\n    groups.reportUnauthorizedSigning(groupIndex, signedGroupPubKey, minimumStake);\n}\n```
MEDIUM severity: The `reviewSlashProposalParameters` function in the `SlashingController` contract allows the address. The `reviewSlashProposalParameters` function in the `SlashingController` contract allows the address with the `SLASHING_ARBITER_ROLE` to modify the slashing proposal's `_subjectId` and `_subjectType`. This function does not include a crucial check to verify that the subject associated with the `_sub...

Vulnerable code:
```\nif (subjectGateway.totalStakeFor(_subjectType, _subjectId) == 0):\n    revert ZeroAmount("subject stake")\n```\n```\nif (_subjectType!= proposals[_proposalId].subjectType || _subjectId!= proposals[_proposalId].subjectId) {\n    _unfreeze(_proposalId);\n    _freeze(_subjectType, _subjectId);\n}\n```
MEDIUM severity: The `CollateralizationOracle` contract's `pcvStats` function calculates the `userCirculatingFei` by . The `CollateralizationOracle` contract's `pcvStats` function calculates the `userCirculatingFei` by subtracting the accumulated resistant FEI balances from the total FEI supply. However, this calculation is flawed because it includes FEI balances from excluded deposits, which are not considered "fre...

Vulnerable code:
```\nfunction pcvStats() public override view returns (\n    uint256 protocolControlledValue,\n    uint256 userCirculatingFei,\n    int256 protocolEquity,\n    bool validityStatus\n) {\n    uint256 _protocolControlledFei = 0;\n    validityStatus =!paused();\n\n    for (uint256 i = 0; i < tokensInPcv.length(); i++) {\n        address _token = tokensInPcv.at(i);\n        uint256 _totalTokenBalance = 0;\n\n        for (uint256 j = 0; j < tokenToDeposits[_token].length(); j++) {\n            address _deposit = tokenToDeposits[_token].at(j);\n\n            if (!excludedDeposits[_deposit]) {\n                (uint256 _depositBalance, uint256 _depositFei) = IPCVDepositBalances(_deposit).resistantBalanceAndFei();\n                _totalTokenBalance += _depositBalance;\n                _protocolControlledFei += _depositFei;\n            }\n        }\n\n        if (_totalTokenBalance!= 0) {\n            (Decimal.D256 memory _oraclePrice, bool _oracleValid) = IOracle(tokenToOracle[_token]).read();\n            if (!_oracleValid) {\n                validityStatus = false;\n            }\n            protocolControlledValue += _oraclePrice.mul(_totalTokenBalance).asUint256();\n        }\n    }\n\n    userCirculatingFei = fei().totalSupply() - _protocolControlledFei;\n    protocolEquity = int256(protocolControlledValue) - int256(userCirculatingFei);\n}\n```