Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability in the profit and loss (PnL) calculations arises from the asymmetry in the relativ. The vulnerability in the profit and loss (PnL) calculations arises from the asymmetry in the relative price changes, which leads to differing PnL outcomes despite equivalent absolute price shifts in rETH. This discrepancy emerges when adjustments to a position result in varying PnL outcomes, causing...

Vulnerable code:
```\nPnL = Position Size * Price Shift / Current Price\nPnL = Position Size * (Current Price - Last Price) / Current Price\nPnL = Position Size * (2000 - 1000) / 2000\nPnL = 40 * (2000 - 1000) / 2000\nPnL = 40 * 1000 / 2000\nPnL = 40000 / 2000\nPnL = 20\n```\n```\nPnL = Position Size * Price Shift / Current Price\nPnL = Position Size * (Current Price - Last Price) / Current Price\nPnL = Position Size * (Current Price - Last Price) / Current Price\nPnL = 40 * (500 - 1000) / 500\nPnL = 40 * (-500) / 500\nPnL = -40\n```\n```\nFile: LeverageModule.sol\n\nuint256 newMargin = (marginAdjustment +\n    PerpMath._getPositionSummary({\n        position: position,\n        nextFundingEntry: cumulativeFunding,\n        price: adjustPrice\n    }.marginAfterSettlement).toUint256();\n\nvault.setPosition(\n    FlatcoinStructs.Position({\n        lastPrice: adjustPrice,\n        marginDeposited: newMargin,\n        additionalSize: newAdditionalSize,\n        entryCumulativeFunding: cumulativeFunding\n    }),\n    announcedAdjust.tokenId\n);\n```\n```\nPnL = Position Size * Price Shift / Current Price\nPnL = Position Size * (Current Price - Last Price) / Current Price\nPnL = Position Size * (Current Price - Last Price) / Current Price\nPnL = 40 * ((2000 - 500) / 500)\nPnL = 40 * (1500 / 500)\nPnL = 40 * 3\nPnL = 120\nPnL = 120\nPnL = 120\nPnL = 120\n```\n```\npriceShift = $750 - $1000\npriceShift = -$250\n\nprofitLossTotal = (globalPosition.sizeOpenedTotal * priceShift) / price\nprofitLossTotal = (150 * -250) / 750\nprofitLossTotal = -50\n```\n```\npriceShift = $500 - $750 = -$250\nprofitLossTotal = (globalPosition.sizeOpenedTotal * priceShift) / price\nprofitLossTotal = (150 * -250) / 500 = -75\n```\n```\nAlice's PNL\npriceShift = current price - entry price = $500 - $1000 = -$500\nPnL = (position size * priceShift) / current price\nPnL = (100 ETH * -500) / 500 = -100 ETH\n\nBob's PNL\npriceShift = current price - entry price = $500 - $1000 = -$500\nPnL = (position size * priceShift) / current price\nPnL = (50 ETH * -500) / 500 = -50 ETH\n```
MEDIUM severity: The AragonFundraisingController's `toReset` list is intended to contain addresses of tapped tokens t. The AragonFundraisingController's `toReset` list is intended to contain addresses of tapped tokens that are to be reset when trading opens after the presale. However, this list is initialized during the contract's creation, whereas the tapped tokens are added later through the `addCollateralToken` f...

Vulnerable code:
```\nfor (uint256 i = 0; i < _toReset.length; i++) {\n    require(_tokenIsContractOrETH(_toReset[i]), ERROR_INVALID_TOKENS);\n    toReset.push(_toReset[i]);\n}\n```\n```\nfunction openTrading() external auth(OPEN_TRADING_ROLE) {\n    for (uint256 i = 0; i < toReset.length; i++) {\n        tap.resetTappedToken(toReset[i]);\n    }\n\n    marketMaker.open();\n}\n```
MEDIUM severity: The code contains several instances of assembly code used to access and decode byte arrays, which re. The code contains several instances of assembly code used to access and decode byte arrays, which reduces the readability and maintainability of the code. Specifically, the assembly code is used to load memory locations and decode byte arrays, which is typically done using high-level programming lan...

Vulnerable code:
```\nassembly {\n    flag := mload(add(_data, 32))\n}\n\nif (flag == CHANGE_PARTITION_FLAG) {\n    assembly {\n        toPartition := mload(add(_data, 64))\n    }\n}\n```\n```\nassembly {\n    toPartition := mload(add(_data, 64))\n}\n```\n```\nfor (uint256 i = 116; i <= _operatorData.length; i = i + 32) {\n    bytes32 temp;\n    assembly {\n        temp := mload(add(_operatorData, i))\n    }\n    proof[index] = temp;\n    index++;\n}\n```
MEDIUM severity: The code contains inconsistent comments that may lead to confusion for developers attempting to unde. The code contains inconsistent comments that may lead to confusion for developers attempting to understand and maintain the code. Specifically, some comments are duplicated across functions, while others are incorrect or outdated. For instance, the `swapAndBridge` function has a comment that is iden...

Vulnerable code:
```\nfunction swapAndBridge(\n    uint256 swapId,\n    bytes calldata swapData,\n    bytes calldata stargateBridgeData\n) public payable {\n    // code here\n}\n```\n```\nfunction setAddressForTransferId(\n    uint256 transferId,\n    address transferIdAddress\n) public payable {\n    // code here\n}\n```\n```\n/**\n * @notice function to store the transferId and message-sender of a bridging activity\n * @notice This method is payable because the caller is doing token transfer and bridging operation\n * @dev for usage, refer to controller implementations\n * encodedData for bridge should follow the sequence of properties in CelerBridgeData struct\n */\nfunction deleteTransferId(bytes32 transferId) external payable {\n```
MEDIUM severity: The contract's initialization process sets the global and operator fees, as well as their correspond. The contract's initialization process sets the global and operator fees, as well as their corresponding commission limits. However, the checks implemented to validate these values are overly simplistic, as they only ensure that the fees or commission limits do not exceed 100%. This is an impractical...

Vulnerable code:
```\nif (_globalFee > BASIS_POINTS) {\n    revert InvalidFee();\n}\nStakingContractStorageLib.setGlobalFee(_globalFee);\n\nif (_operatorFee > BASIS_POINTS) {\n    revert InvalidFee();\n}\nStakingContractStorageLib.setOperatorFee(_operatorFee);\n```\n```\nfunction initialize_2(uint256 globalCommissionLimitBPS, uint256 operatorCommissionLimitBPS) public init(2) {\n    if (globalCommissionLimitBPS > BASIS_POINTS) {\n        revert InvalidFee();\n    }\n    StakingContractStorageLib.setGlobalCommissionLimit(globalCommissionLimitBPS);\n\n    if (operatorCommissionLimitBPS > BASIS_POINTS) {\n        revert InvalidFee();\n    }\n    StakingContractStorageLib.setOperatorCommissionLimit(operatorCommissionLimitBPS);\n}\n```\n```\nfunction setGlobalFee(uint256 _globalFee) external onlyAdmin {\n    if (_globalFee > StakingContractStorageLib.getGlobalCommissionLimit()) {\n        revert InvalidFee();\n    }\n    StakingContractStorageLib.setGlobalFee(_globalFee);\n    emit ChangedGlobalFee(_globalFee);\n}\n```\n```\nfunction setOperatorFee(uint256 _operatorFee) external onlyAdmin {\n    if (_operatorFee > StakingContractStorageLib.getOperatorCommissionLimit()) {\n        revert InvalidFee();\n    }\n    StakingContractStorageLib.setOperatorFee(_operatorFee);\n    emit ChangedOperatorFee(_operatorFee);\n}\n```
MEDIUM severity: The existing control mechanism designed to prevent the sale of ETH during reinvestment can be bypass. The existing control mechanism designed to prevent the sale of ETH during reinvestment can be bypassed, allowing malicious or accidental selling of non-reward assets from the vault. This vulnerability is present in multiple instances, including Curve's and Balancer's implementations.\n\nIn Curve's i...

Vulnerable code:
```\nFile: ConvexStakingMixin.sol\n\nfunction _isInvalidRewardToken(address token) internal override view returns (bool) {\n    return (\n        token == TOKEN_1 ||\n        token == TOKEN_2 ||\n        token == address(CURVE_POOL_TOKEN) ||\n        token == address(CONVEX_REWARD_POOL) ||\n        token == address(CONVEX_BOOSTER) ||\n        token == Deployments.ALT_ETH_ADDRESS\n    );\n}\n```\n```\naddress internal constant ALT_ETH_ADDRESS = 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE;\n```\n```\nFile: TradingUtils.sol\n\nfunction _executeTrade(\n    address target,\n    uint256 msgValue,\n    bytes memory params,\n    address spender,\n    Trade memory trade\n) private {\n    uint256 preTradeBalance;\n\n    if (trade.buyToken == address(Deployments.WETH)) {\n        preTradeBalance = address(this).balance;\n    } else if (trade.buyToken == Deployments.ETH_ADDRESS || _needsToUnwrapExcessWETH(trade, spender)) {\n        preTradeBalance = IERC20(address(Deployments.WETH)).balanceOf(address(this));\n    }\n```\n```\nFile: AuraStakingMixin.sol\n\nfunction _isInvalidRewardToken(address token) internal override view returns (bool) {\n    return (\n        token == TOKEN_1 ||\n        token == TOKEN_2 ||\n        token == TOKEN_3 ||\n        token == TOKEN_4 ||\n        token == TOKEN_5 ||\n        token == address(AURA_BOOSTER) ||\n        token == address(AURA_REWARD_POOL) ||\n        token == address(Deployments.WETH)\n    );\n}\n```
MEDIUM severity: The ABDK Libraries for Solidity, a math library, has been forked and modified to introduce a set of . The ABDK Libraries for Solidity, a math library, has been forked and modified to introduce a set of `unsafe_*` functions. Specifically, the `unsafe_add`, `unsafe_sub`, `unsafe_mul`, `unsafe_div`, and `unsafe_abs` functions have been added. However, a closer examination reveals that `unsafe_add` is,...

Vulnerable code:
```\n/**\n * Calculate x + y. Revert on overflow.\n *\n * @param x signed 64.64-bit fixed point number\n * @param y signed 64.64-bit fixed point number\n * @return signed 64.64-bit fixed point number\n */\nfunction add(int128 x, int128 y) internal pure returns (int128) {\n    int256 result = int256(x) + y;\n    require(result >= MIN_64x64 && result <= MAX_64x64);\n    return int128(result);\n}\n```\n```\n/**\n * Calculate x + y. Revert on overflow.\n *\n * @param x signed 64.64-bit fixed point number\n * @param y signed 64.64-bit fixed point number\n * @return signed 64.64-bit fixed point number\n */\nfunction unsafe_add(int128 x, int128 y) internal pure returns (int128) {\n    int256 result = int256(x) + y;\n    require(result >= MIN_64x64 && result <= MAX_64x64);\n    return int128(result);\n}\n```\n```\n/**\n * Calculate |x|. Revert on overflow.\n *\n * @param x signed 64.64-bit fixed point number\n * @return signed 64.64-bit fixed point number\n */\nfunction abs(int128 x) internal pure returns (int128) {\n    require(x!= MIN_64x64);\n    return x < 0? -x : x;\n}\n```\n```\n/**\n * Calculate |x|. Revert on overflow.\n *\n * @param x signed 64.64-bit fixed point number\n * @return signed 64.64-bit fixed point number\n */\nfunction unsafe_abs(int128 x) internal pure returns (int128) {\n    return x < 0? -x : x;\n}\n```\n```\nrequire(x!= MIN_64x64);\n```\n```\nint128 private constant MIN_64x64 = -0x80000000000000000000000000000000;\n```
MEDIUM severity: The `TrufVesting` contract contains a logic flaw in its `claimable` function, which allows any user . The `TrufVesting` contract contains a logic flaw in its `claimable` function, which allows any user to drain the contract's funds. The issue arises from the calculation of the `claimable` amount, which is determined by the `initialRelease` value. \n\nThe `claimable` function calculates the `claimabl...

Vulnerable code:
```\nfunction claimable(uint256 categoryId, uint256 vestingId, address user)\n    public\n    view\n    returns (uint256 claimableAmount)\n{\n    UserVesting memory userVesting = userVestings[categoryId][vestingId][user];\n\n    VestingInfo memory info = vestingInfos[categoryId][vestingId];\n\n    uint64 startTime = userVesting.startTime + info.initialReleasePeriod;\n\n    if (startTime > block.timestamp) {\n        return 0;\n    }\n\n    uint256 totalAmount = userVesting.amount;\n\n    uint256 initialRelease = (totalAmount * info.initialReleasePct) / DENOMINATOR;\n\n    startTime += info.cliff;\n\n    if (startTime > block.timestamp) {\n        return initialRelease;\n    }\n}\n```\n```\nfunction claim(address user, uint256 categoryId, uint256 vestingId, uint256 claimAmount) public {\n    if (user!= msg.sender && (!categories[categoryId].adminClaimable || msg.sender!= owner())) {\n        revert Forbidden(msg.sender);\n    }\n\n    uint256 claimableAmount = claimable(categoryId, vestingId, user);\n    if (claimAmount == type(uint256).max) {\n        claimAmount = claimableAmount;\n    } else if (claimAmount > claimableAmount) {\n        revert ClaimAmountExceed();\n    }\n    if (claimAmount == 0) {\n        revert ZeroAmount();\n    }\n\n    categories[categoryId].totalClaimed += claimAmount;\n    userVestings[categoryId][vestingId][user].claimed += claimAmount;\n    trufToken.safeTransfer(user, claimAmount);\n\n    emit Claimed(categoryId, vestingId, user, claimAmount);\n}\n```
MEDIUM severity: The `reclaimContract()` function in the protocol's smart contract allows an attacker to transfer ass. The `reclaimContract()` function in the protocol's smart contract allows an attacker to transfer assets to the address `0` by creating a fake order that meets specific conditions. The function checks that the contract has expired (`block.timestamp > order.expiry`), has not been settled (`!settledCon...

Vulnerable code:
```\nfunction reclaimContract(Order calldata order) public nonReentrant {\n    bytes32 orderHash = hashOrder(order);\n\n    uint contractId = uint(orderHash);\n\n    address bull = bulls[contractId];\n\n    require(block.timestamp > order.expiry, "NOT_EXPIRED_CONTRACT");\n    require(!settledContracts[contractId], "SETTLED_CONTRACT");\n    require(!reclaimedContracts[contractId], "RECLAIMED_CONTRACT");\n\n    uint bullAssetAmount = order.premium + order.collateral;\n    if (bullAssetAmount > 0) {\n        IERC20(order.asset).safeTransfer(bull, bullAssetAmount);\n    }\n\n    reclaimedContracts[contractId] = true;\n\n    emit ReclaimedContract(orderHash, order);\n}\n```
MEDIUM severity: The introduction of verifiers in the `OrchidLottery` code, specifically the `OrchidVerifier` contrac. The introduction of verifiers in the `OrchidLottery` code, specifically the `OrchidVerifier` contract, has raised concerns about the difficulty in validating the purity of these verifiers. The `good()` function, which accepts three parameters - `shared`, `target`, and `receipt` - returns a boolean i...

Vulnerable code:
```\nfunction good(bytes calldata shared, address target, bytes calldata receipt) external pure returns (bool) {\n    return true;\n}\n```
MEDIUM severity: The vulnerability arises when a single coordinator is responsible for posting messages from Layer 1 . The vulnerability arises when a single coordinator is responsible for posting messages from Layer 1 (L1) to Layer 2 (L2). This process involves anchoring the message hashes in the `addL1L2MessageHashes` function on L2. The user or Postman can claim the message on L2 once it is posted. However, if th...

Vulnerable code:
```\nuint256 messageNumber = nextMessageNumber;\nuint256 valueSent = msg.value - _fee;\n\nbytes32 messageHash = keccak256(abi.encode(msg.sender, _to, _fee, valueSent, messageNumber, _calldata));\n```\n```\nfunction addL1L2MessageHashes(bytes32[] calldata _messageHashes) external onlyRole(L1_L2_MESSAGE_SETTER_ROLE) {\n    uint256 messageHashesLength = _messageHashes.length;\n\n    if (messageHashesLength > 100) {\n        revert MessageHashesListLengthHigherThanOneHundred(messageHashesLength);\n    }\n\n    for (uint256 i = 0; i < messageHashesLength; ) {\n        bytes32 messageHash = _messageHashes[i];\n        if (inboxL1L2MessageStatus[messageHash] == INBOX_STATUS_UNKNOWN) {\n            inboxL1L2MessageStatus[messageHash] = INBOX_STATUS_RECEIVED;\n        }\n        unchecked {\n            i++;\n        }\n    }\n\n    emit L1L2MessageHashesAddedToInbox(_messageHashes);\n}\n```
MEDIUM severity: The vulnerability arises from the discrepancy between the actual total assets owned by a LMPVault on. The vulnerability arises from the discrepancy between the actual total assets owned by a LMPVault on-chain and the cached total assets returned by the `LMPVault.totalAssets()` function. The actual total assets can be calculated using the formula `totalAssets_{actual} = sum(debtValue(DV_n))`, whereas...

Vulnerable code:
```\nFile: LMPVault.sol\n\nfunction totalAssets() public view override returns (uint256) {\n    return totalIdle + totalDebt;\n}\n```
MEDIUM severity: The vulnerability lies in the handling of price and refund changes for gold cards in the commit, min. The vulnerability lies in the handling of price and refund changes for gold cards in the commit, mint, and refund processes. Specifically, the code uses the same `weave` tokens spent during the commit phase, which are then burned `rngDelay` blocks later. This creates a potential issue when the price...

Vulnerable code:
```\nfunction _commit(uint256 _weaveAmount, GoldOrder memory _order)\n    internal\n{\n    // Check if weave sent is sufficient for order\n    uint256 total_cost = _order.cardAmount.mul(goldPrice).add(_order.feeAmount);\n    uint256 refund_amount = _weaveAmount.sub(total_cost);\n```\n```\nuint256 weave_to_burn = (_order.cardAmount.mul(goldPrice)).sub(_order.cardAmount.mul(goldRefund));\nweaveContract.burn(weaveID, weave_to_burn);\n```
MEDIUM severity: The `ISignatureValidator` contract defines an enum `SignatureType` to categorize the various signatu. The `ISignatureValidator` contract defines an enum `SignatureType` to categorize the various signature types recognized within the exchange. The `NSignatureTypes` enum value, however, is not a legitimate signature type. Instead, it is employed by `MixinSignatureValidator` to verify that the value re...

Vulnerable code:
```\nif (uint8(signatureType) >= uint8(SignatureType.NSignatureTypes)):\n    LibRichErrors.rrevert(LibExchangeRichErrors.SignatureError(\n        LibExchangeRichErrors.SignatureErrorCodes.UNSUPPORTED,\n        hash,\n        signerAddress,\n        signature\n    ))\n```
MEDIUM severity: The vulnerability is located in the `mTOFTReceiver._toftCustomComposeReceiver` function, specificall. The vulnerability is located in the `mTOFTReceiver._toftCustomComposeReceiver` function, specifically in the handling of the `_msgType` variable. When `_msgType` is equal to `MSG_XCHAIN_LEND_XCHAIN_LOCK`, the function does not correctly return `true`, which causes the execution to fail and trigger t...

Vulnerable code:
```\nfunction _lzCompose(address srcChainSender_, bytes32 _guid, bytes memory oftComposeMsg_) internal {\n    // Decode OFT compose message.\n    (uint16 msgType_,,, bytes memory tapComposeMsg_, bytes memory nextMsg_) = \n        TapiocaOmnichainEngineCodec.decodeToeComposeMsg(oftComposeMsg_);\n\n    // Call Permits/approvals if the msg type is a permit/approval.\n    // If the msg type is not a permit/approval, it will call the other receivers.\n    if (msgType_ == MSG_REMOTE_TRANSFER) {\n        _remoteTransferReceiver(srcChainSender_, tapComposeMsg_);\n    } else if (!_extExec(msgType_, tapComposeMsg_)) {\n        // Check if the TOE extender is set and the msg type is valid. If so, call the TOE extender to handle msg.\n        if (address(tapiocaOmnichainReceiveExtender)!= address(0) \n            && tapiocaOmnichainReceiveExtender.isMsgTypeValid(msgType_)) {\n            bytes memory callData = abi.encodeWithSelector(\n                ITapiocaOmnichainReceiveExtender.toeComposeReceiver.selector, \n                msgType_, \n                srcChainSender_, \n                tapComposeMsg_\n            );\n            (bool success, bytes memory returnData) = \n                address(tapiocaOmnichainReceiveExtender).delegatecall(callData);\n            if (!success) {\n                revert(_getTOEExtenderRevertMsg(returnData));\n            }\n        } else {\n            // If no TOE extender is set or msg type doesn't match extender, try to call the internal receiver.\n            if (!_toeComposeReceiver(msgType_, srcChainSender_, tapComposeMsg_)) {\n                revert InvalidMsgType(msgType_);\n            }\n        }\n    }\n}\n```\n```\ncontract mTOFTReceiver is BaseTOFTReceiver {\n    constructor(TOFTInitStruct memory _data) BaseTOFTReceiver(_data) {}\n\n    function _toftCustomComposeReceiver(uint16 _msgType, address, bytes memory _toeComposeMsg)\n        internal\n        override\n        returns (bool success)\n    {\n        if (_msgType == MSG_LEVERAGE_UP) {\n            _executeModule(\n                uint8(ITOFT.Module.TOFTMarketReceiver),\n                abi.encodeWithSelector(TOFTMarketReceiverModule.leverageUpReceiver.selector, _toeComposeMsg),\n                false\n            );\n            return true;\n        } else if (_msgType == MSG_XCHAIN_LEND_XCHAIN_LOCK) {\n            _executeModule(\n                uint8(ITOFT.Module.TOFTOptionsReceiver),\n                abi.encodeWithSelector(\n                    TOFTOptionsReceiverModule.mintLendXChainSGLXChainLockAndParticipateReceiver.selector, _toeComposeMsg\n                ),\n                false\n            );\n            return true;\n        } else {\n            return false;\n        }\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of signature validation for orders with signatures that. The vulnerability lies in the implementation of signature validation for orders with signatures that require regular validation. Specifically, the validation process is bypassed if an order has already been partially filled, allowing an attacker to provide an invalid signature and avoid re-validatio...

Vulnerable code:
```\naddress makerAddress = order.makerAddress;\nif (orderInfo.orderTakerAssetFilledAmount == 0 ||\n    _doesSignatureRequireRegularValidation(\n        orderInfo.orderHash,\n        makerAddress,\n        signature\n    )\n) {\n```\n```\nfunction _doesSignatureRequireRegularValidation(\n    bytes32 hash,\n    address signerAddress,\n    bytes memory signature\n)\n    internal\n    pure\n    returns (bool needsRegularValidation)\n{\n    SignatureType signatureType = _readSignatureType(\n        hash,\n        signerAddress,\n        signature\n    );\n\n    needsRegularValidation = \n        signatureType == SignatureType.Wallet ||\n        signatureType == SignatureType.Validator ||\n        signatureType == SignatureType.EIP1271Wallet;\n    return needsRegularValidation;\n}\n```
MEDIUM severity: The Covalent protocol's validator freeze mechanism is designed to prevent malicious behavior by temp. The Covalent protocol's validator freeze mechanism is designed to prevent malicious behavior by temporarily disabling validators who engage in malicious activities. However, a vulnerability has been identified that allows a malicious validator to exploit this mechanism and withdraw tokens unfairly.\...

Vulnerable code:
```\nrequire (!v.frozen, "Validator is frozen");\n```\n```\nrequire(_validators[validatorId]!= null, "Invalid validator");\nrequire(_validators[validatorId].unstakings[msg.sender].length > unstakingId, "Unstaking does not exist");\n\nUnstaking storage us = _validators[validatorId].unstakings[msg.sender][unstakingId];\n\nrequire(us.amount >= amount, "Unstaking has less tokens");\n```
MEDIUM severity: The TribalChief smart contract's block reward mechanism is susceptible to a retrospective applicatio. The TribalChief smart contract's block reward mechanism is susceptible to a retrospective application of new block rewards for pools that have not been updated recently. This occurs when the governor updates the block reward `tribalChiefTribePerBlock` and the update is applied to the outstanding dur...

Vulnerable code:
```\nif (virtualSupply > 0) {\n    uint256 blocks = block.number - pool.lastRewardBlock;\n    uint256 tribeReward = (blocks * tribePerBlock() * pool.allocPoint) / totalAllocPoint;\n    pool.accTribePerShare = uint128(pool.accTribePerShare + ((tribeReward * ACC_TRIBE_PRECISION) / virtualSupply));\n}\n```\n```\nfunction updateBlockReward(uint256 newBlockReward) external onlyGovernor {\n    tribalChiefTribePerBlock = newBlockReward;\n    emit NewTribePerBlock(newBlockReward);\n}\n```