Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `DynamicContractRegistry` is a wrapper registry that enables the use of a custom upgrader contra. The `DynamicContractRegistry` is a wrapper registry that enables the use of a custom upgrader contract while still providing access to the standard bancor registry. This registry is owned by zer0 admins, which raises concerns about the potential for malicious activity. The registry owner has the abi...

Vulnerable code:
```\nfunction registerAddress(bytes32 _contractName, address _contractAddress)\n    public\n    ownerOnly\n    validAddress(_contractAddress)\n{\n    // Code here\n}\n```\n```\nfunction addressOf(bytes32 _contractName) public view override returns (address) {\n    if (items[_contractName].contractAddress!= address(0)) {\n        return items[_contractName].contractAddress;\n    } else {\n        return contractRegistry.addressOf(_contractName);\n    }\n}\n```\n```\n/**\n * @dev returns the number of items in the registry\n *\n * @return number of items\n */\nfunction itemCount() public view returns (uint256) {\n    return contractNames.length;\n}\n```
MEDIUM severity: The vulnerability arises when users approve the `dnGmxJuniorVault` contract to the `WithdrawPeripher. The vulnerability arises when users approve the `dnGmxJuniorVault` contract to the `WithdrawPeriphery` contract without properly restricting the approved amount. This allows anyone to withdraw or redeem tokens on behalf of the user, without the user's explicit consent. \n\nWhen a user approves the `...

Vulnerable code:
```\nfunction withdrawToken(\n    address from,\n    address token,\n    address receiver,\n    uint256 sGlpAmount\n) external returns (uint256 amountOut) {\n    dnGmxJuniorVault.withdraw(sGlpAmount, address(this), from);\n}\n\nfunction redeemToken(\n    address from,\n    address token,\n    address receiver,\n    uint256 sharesAmount\n) external returns (uint256 amountOut) {\n    dnGmxJuniorVault.redeem(sharesAmount, address(this), from);\n}\n```
MEDIUM severity: The vulnerability allows an adversary to intentionally brick an AutoRoller by creating a second Auto. The vulnerability allows an adversary to intentionally brick an AutoRoller by creating a second AutoRoller on the same adapter, targeting a maturity that coincides with the first AutoRoller's desired maturity. This is achieved by exploiting the fact that each adapter can only have one series at a gi...

Vulnerable code:
```\nuint256 _maturity = utils.getFutureMaturity(targetDuration);\n\nfunction getFutureMaturity(uint256 monthsForward) public view returns (uint256) {\n    (\n        uint256 year,\n        uint256 month,\n        uint256 day\n    ) = DateTime.timestampToDate(\n        DateTime.addMonths(\n            block.timestamp,\n            monthsForward\n        )\n    );\n    return DateTime.timestampFromDateTime(\n        year,\n        month,\n        1,  // top of the month\n        0,\n        0,\n        0\n    );\n}\n```\n```\n(ERC20 _pt, YTLike _yt) = periphery.sponsorSeries(address(adapter), _maturity, true);\n```\n```\nfunction sponsorSeries(\n    address adapter,\n    uint256 maturity,\n    bool withPool\n) external returns (address pt, address yt) {\n    (, address stake, uint256 stakeSize) = Adapter(adapter).getStakeAndTarget();\n\n    ERC20(stake).safeTransferFrom(msg.sender, address(this), stakeSize);\n\n    ERC20(stake).approve(address(divider), stakeSize);\n\n    (pt, yt) = divider.initSeries(adapter, maturity, msg.sender);\n\n    if (verified[adapter]) {\n        poolManager.queueSeries(adapter, maturity, spaceFactory.create(adapter, maturity));\n    } else {\n        if (withPool) {\n            spaceFactory.create(adapter, maturity);\n        }\n    }\n    emit SeriesSponsored(adapter, maturity, msg.sender);\n}\n```\n```\nfunction create(address adapter, uint256 maturity) external returns (address pool) {\n    address pt = divider.pt(adapter, maturity);\n    _require(pt!= address(0), Errors.INVALID_SERIES);\n\n    _require(pools[adapter][maturity] == address(0), Errors.POOL_ALREADY_EXISTS);\n\n    pool = address(new Space(\n        vault,\n        adapter,\n        maturity,\n        pt,\n        ts,\n        g1,\n        g2,\n        oracleEnabled\n    ));\n\n    pools[adapter][maturity] = pool;\n}\n```
MEDIUM severity: The vulnerability arises when attempting to deposit or redeem a zero amount against certain external. The vulnerability arises when attempting to deposit or redeem a zero amount against certain external money markets, such as AAVE, within the rebalancing process. This occurs due to the mutually exclusive nature of `redeemAmounts` and `depositAmounts` for a specific holding, as determined by the if-e...

Vulnerable code:
```\nFile: ProportionalRebalancingStrategy.sol\n\nfor (uint256 i; i < holdings.length; ) {\n    address holding = holdings[i];\n    uint256 targetAmount = totalValue * rebalancingTargets[i] / uint256(Constants.PERCENTAGE_DECIMALS);\n    uint256 currentAmount = values[i];\n\n    redeemHoldings[i] = holding;\n    depositHoldings[i] = holding;\n\n    if (targetAmount < currentAmount) {\n        unchecked {\n            redeemAmounts[i] = currentAmount - targetAmount;\n        }\n    } else if (currentAmount < targetAmount) {\n        unchecked {\n            depositAmounts[i] = targetAmount - currentAmount;\n        }\n    }\n\n    unchecked {\n        i++;\n    }\n}\n```\n```\nFile: ProportionalRebalancingStrategy.sol\n\nrebalancingData.redeemData = oracle.getRedemptionCalldataForRebalancing(redeemHoldings, redeemAmounts);\nrebalancingData.depositData = oracle.getDepositCalldataForRebalancing(depositHoldings, depositAmounts);\n```\n```\nfunction deposit(address _reserve, uint256 _amount, uint16 _referralCode)\n    external\n    payable\n    nonReentrant\n    onlyActiveReserve(_reserve)\n    onlyUnfreezedReserve(_reserve)\n    onlyAmountGreaterThanZero(_amount)\n{\n    // Code here\n}\n```\n```\nfunction redeemUnderlying(\n    address _reserve,\n    address payable _user,\n    uint256 _amount,\n    uint256 _aTokenBalanceAfterRedeem\n)\n    external\n    nonReentrant\n    onlyOverlyingAToken(_reserve)\n    onlyActiveReserve(_reserve)\n    onlyAmountGreaterThanZero(_amount)\n{\n```
MEDIUM severity: When a user migrates their ownership due to a lost private key, the rewards previously earned by the. When a user migrates their ownership due to a lost private key, the rewards previously earned by the old owner remain recorded in their account, but cannot be claimed. This is because the `migrateVestingLock()` function, which is called during the migration process, updates the rewards on the old ow...

Vulnerable code:
```\n/**\n * @notice Migrate owner of vesting. Used when user lost his private key\n * @dev Only admin can migrate users vesting\n * @param categoryId Category id\n * @param vestingId Vesting id\n * @param prevUser previous user address\n * @param newUser new user address\n*/\n```\n```\nif (lockupId!= 0):\n    newLockupId = veTRUF.migrateVestingLock(prevUser, newUser, lockupId - 1) + 1\n    lockupIds[categoryId][vestingId][newUser] = newLockupId\n    del lockupIds[categoryId][vestingId][prevUser]\n\n    newVesting.locked = prevVesting.locked\n```\n```\nfunction withdraw(address user, uint256 amount) public updateReward(user) onlyOperator {\n    if (amount == 0) {\n        revert ZeroAmount();\n    }\n    _totalSupply -= amount;\n    _balances[user] -= amount;\n    emit Withdrawn(user, amount);\n}\n```\n```\nuint256 points = oldLockup.points;\nstakingRewards.withdraw(oldUser, points);\n_burn(oldUser, points);\n```
MEDIUM severity: The vulnerability in BLVaultLido's implementation of the oracle update mechanism allows an attacker . The vulnerability in BLVaultLido's implementation of the oracle update mechanism allows an attacker to exploit the vault by sandwiching the oracle update. This is achieved by manipulating the pool's liquidity to match the pre-update oracle price, then selling wstETH to balance the pool to the post-u...

Vulnerable code:
```\nuint256 wstethOhmPrice = manager.getTknOhmPrice();\nuint256 expectedWstethAmountOut = (ohmAmountOut * wstethOhmPrice) / _OHM_DECIMALS;\n\n// Take any arbs relative to the oracle price for the Treasury and return the rest to the owner\nuint256 wstethToReturn = wstethAmountOut > expectedWstethAmountOut\n   ? expectedWstethAmountOut\n    : wstethAmountOut;\n\nif (wstethAmountOut > wstethToReturn) {\n    wsteth.safeTransfer(TRSRY(), wstethAmountOut - wstethToReturn);\n}\n```\n```\nTransaction 1:\n\n    Balances before attack (0.995:1)\n    Liquidity: 79.8 OHM 80.2 wstETH\n    Adversary: 20 wstETH\n\n    Swap OHM so that pool price matches pre-update oracle price:\n    Liquidity: 80 OHM 80 wstETH\n    Adversary: -0.2 OHM 20.2 wstETH\n\n    Balances after adversary has deposited to the pool:\n    Liquidity: 100 OHM 100 wstETH\n    Adversary: -0.2 OHM 0.2 wstETH\n\n    Balances after adversary sells wstETH for OHM (0.5% movement in price):\n    Liquidity: 99.748 OHM 100.252 wstETH\n    Adversary: 0.052 OHM -0.052 wstETH\n\n    Sandwiched Oracle Update:\n\n    Oracle updates price of wstETH to 0.995 OHM. Since the attacker already sold wstETH to balance \n    the pool to the post-update price they will be able to withdraw the full amount of wstETH.\n\nTransaction 2:\n\n    Balances after adversary removes their liquidity:\n    Liquidity: 79.798 OHM 80.202 wstETH\n    Adversary: 0.052 OHM 19.998 wstETH\n\n    Balances after selling profited OHM:\n    Liquidity: 79.849 OHM 80.152 wstETH\n    Adversary: 20.05 wstETH\n```
MEDIUM severity: The `IdleCDO._deposit()` function is vulnerable to re-entrancy attacks due to its design. Specifical. The `IdleCDO._deposit()` function is vulnerable to re-entrancy attacks due to its design. Specifically, the function updates the system's internal accounting and mints shares to the caller, then transfers the deposited funds from the user. This process allows for a potential re-entry point, as some...

Vulnerable code:
```\nfunction _deposit(uint256 _amount, address _tranche) internal returns (uint256 _minted) {\n    // Check that we are not depositing more than the contract available limit\n    _guarded(_amount);\n\n    _updateCallerBlock();\n    _checkDefault();\n\n    // Interest accrued since last depositXX/withdrawXX/harvest is splitted between AA and BB\n    // according to trancheAPRSplitRatio. NAVs of AA and BB are updated and tranche\n    // prices adjusted accordingly\n    _updateAccounting();\n\n    // Mint tranche tokens according to the current tranche price\n    _minted = _mintShares(_amount, msg.sender, _tranche);\n\n    // Get underlyings from sender\n    IERC20Detailed(token).safeTransferFrom(msg.sender, address(this), _amount);\n}\n```
MEDIUM severity: The vulnerability lies in the way custom error statements are defined in the contracts. The error me. The vulnerability lies in the way custom error statements are defined in the contracts. The error messages provided do not provide sufficient information to effectively track updates and monitor the system's behavior. This lack of transparency makes it challenging for off-chain monitoring tools to a...

Vulnerable code:
```\nerror Forbidden();\nerror InvalidFee();\nerror Deactivated();\nerror NoOperators();\nerror InvalidCall();\nerror Unauthorized();\nerror DepositFailure();\nerror DepositsStopped();\nerror InvalidArgument();\nerror UnsortedIndexes();\nerror InvalidPublicKeys();\nerror InvalidSignatures();\nerror InvalidWithdrawer();\nerror InvalidZeroAddress();\nerror AlreadyInitialized();\nerror InvalidDepositValue();\nerror NotEnoughValidators();\nerror InvalidValidatorCount();\nerror DuplicateValidatorKey(bytes);\nerror FundedValidatorDeletionAttempt();\nerror OperatorLimitTooHigh(uint256 limit, uint256 keyCount);\nerror MaximumOperatorCountAlreadyReached();\nerror LastEditAfterSnapshot();\nerror PublicKeyNotInContract();\n```\n```\nmodifier init(uint256 _version) {\n    if (_version!= VERSION_SLOT.getUint256() + 1) {\n        revert AlreadyInitialized();\n    }\n}\n```\n```\nmodifier init(uint256 _version) {\n    if (_version!= VERSION_SLOT.getUint256() + 1) {\n        revert AlreadyInitialized();\n    }\n}\n```\n```\nmodifier init(uint256 _version) {\n    if (_version!= StakingContractStorageLib.getVersion() + 1) {\n        revert AlreadyInitialized();\n    }\n}\n```
MEDIUM severity: The "Equilibrium price" is not used to compute the capacity in the OSDA (Oracle-based Stablecoin DAI. The "Equilibrium price" is not used to compute the capacity in the OSDA (Oracle-based Stablecoin DAI) implementation, leading to a smaller-than-expected maximum payout. This discrepancy arises from the difference in how capacity is calculated in OFDA (Oracle-based Fixed-rate DAI) and OSDA.\n\nIn OFD...

Vulnerable code:
```\nFile: BondBaseOFDA.sol\n\nfunction _createMarket(MarketParams memory params_) internal returns (uint256) {\n    // Calculate the maximum payout amount for this market\n    uint256 capacity = params_.capacityInQuote\n       ? params_.capacity.mulDiv(\n            scale,\n            price.mulDivUp(\n                uint256(ONE_HUNDRED_PERCENT - params_.fixedDiscount),\n                uint256(ONE_HUNDRED_PERCENT)\n            )\n        )\n        : params_.capacity;\n    market.maxPayout = capacity.mulDiv(uint256(params_.depositInterval), uint256(length));\n```\n```\nFile: BondBaseOSDA.sol\n\nfunction _createMarket(MarketParams memory params_) internal returns (uint256) {\n    // Calculate the maximum payout amount for this market, determined by deposit interval\n    uint256 capacity = params_.capacityInQuote\n       ? params_.capacity.mulDiv(scale, price)\n        : params_.capacity;\n    market.maxPayout = capacity.mulDiv(uint256(params_.depositInterval), uint256(length));\n}\n```\n```\nFile: BondBaseOSDA.sol\n\nfunction _validateOracle(\n    uint256 id_,\n    IBondOracle oracle_,\n    ERC20 quoteToken_,\n    ERC20 payoutToken_,\n    uint48 baseDiscount_\n) {\n    // Get the price decimals for the current oracle price\n    // Oracle price is in quote tokens per payout token\n    // E.g. if quote token is $10 and payout token is $2000,\n    // then the oracle price is 200 quote tokens per payout token.\n    // If the oracle has 18 decimals, then it would return 200 * 10^18.\n    // In this case, the price decimals would be 2 since 200 = 2 * 10^2.\n    // We apply the base discount to the oracle price before calculating\n    // since this will be the initial equilibrium price of the market.\n    int8 priceDecimals = _getPriceDecimals(\n        currentPrice.mulDivUp(\n            uint256(ONE_HUNDRED_PERCENT - baseDiscount_),\n            uint256(ONE_HUNDRED_PERCENT)\n        ),\n        oracleDecimals\n    );\n```
MEDIUM severity: The `Multiple contracts cannot be paused` vulnerability refers to a security concern in the Tapioca . The `Multiple contracts cannot be paused` vulnerability refers to a security concern in the Tapioca protocol, where multiple contracts have been designed with `whenNotPaused` restrictions to ensure that certain functions can only be executed when the contract is not paused. However, there is no publ...

Vulnerable code:
```\nfunction executeModule(ITOFT.Module _module, bytes memory _data, bool _forwardRevert)\n    external\n    payable\n    whenNotPaused\n    returns (bytes memory returnData)\n{\n    // rest of code\n}\n\nfunction sendPacket(LZSendParam calldata _lzSendParam, bytes calldata _composeMsg)\n    public\n    payable\n    whenNotPaused\n    returns (MessagingReceipt memory msgReceipt, OFTReceipt memory oftReceipt)\n{\n```
MEDIUM severity: The `GenesisGroup.purchase` API can be optimized by eliminating the redundant `value` parameter, whi. The `GenesisGroup.purchase` API can be optimized by eliminating the redundant `value` parameter, which is currently required to be equivalent to `msg.value`. This check is implemented using the `require` statement, which ensures that the provided `value` matches the `msg.value` before proceeding.\n\...

Vulnerable code:
```\nrequire(msg.value == value, "GenesisGroup: value mismatch");\n```
MEDIUM severity: The `fulfill` function in the TransactionManager smart contract requires user signature validation o. The `fulfill` function in the TransactionManager smart contract requires user signature validation on a `transactionId`. Currently, the user SDK code employs a cryptographically secured pseudo-random function to generate the `transactionId`, which is not a reliable method for ensuring replay-attack...

Vulnerable code:
```\nfunction recoverSignature(\n  bytes32 transactionId,\n  uint256 relayerFee,\n  string memory functionIdentifier,\n  bytes calldata signature\n) internal pure returns (address) {\n    SignedData memory payload = SignedData({\n        transactionId: transactionId,\n        relayerFee: relayerFee,\n        functionIdentifier: functionIdentifier\n    });\n\n    return ECDSA.recover(ECDSA.toEthSignedMessageHash(keccak256(abi.encode(payload))), signature);\n}\n```
MEDIUM severity: The `setSymbolsPrice()` function in the provided code allows for a malicious user to exploit a vulne. The `setSymbolsPrice()` function in the provided code allows for a malicious user to exploit a vulnerability by selecting a `priceSig` from a long time ago. This is possible because the function only restricts the maximum value of `priceSig.timestamp`, but not the minimum value. This allows an attac...

Vulnerable code:
```\nfunction setSymbolsPrice(address partyA, PriceSig memory priceSig) internal {\n    MAStorage.Layout storage maLayout = MAStorage.layout();\n    AccountStorage.Layout storage accountLayout = AccountStorage.layout();\n    LibMuon.verifyPrices(priceSig, partyA);\n    require(\n        priceSig.timestamp <= maLayout.liquidationTimestamp[partyA] + maLayout.liquidationTimeout,\n        "LiquidationFacet: Expired signature"\n    );\n}\n```\n```\nfunction verifyPrices(PriceSig memory priceSig, address partyA) internal view {\n    MuonStorage.Layout storage muonLayout = MuonStorage.layout();\n    require(priceSig.prices.length == priceSig.symbolIds.length, "LibMuon: Invalid length");\n    bytes32 hash = keccak256(\n        abi.encodePacked(\n            muonLayout.muonAppId,\n            priceSig.reqId,\n            address(this),\n            partyA,\n            priceSig.upnl,\n            priceSig.totalUnrealizedLoss,\n            priceSig.symbolIds,\n            priceSig.prices,\n            priceSig.timestamp,\n            getChainId()\n        )\n    );\n    verifyTSSAndGateway(hash, priceSig.sigs, priceSig.gatewaySignature);\n}\n```
MEDIUM severity: The vulnerability arises when a vault account's cash balance becomes non-zero after a liquidation ev. The vulnerability arises when a vault account's cash balance becomes non-zero after a liquidation event, leading to an inability for the account owner to exit the vault. This occurs when a significant portion of the vault account's assets are liquidated, resulting in a substantial amount of cash bei...

Vulnerable code:
```\nFile: VaultConfiguration.sol\n\nif (vaultAccount.tempCashBalance < 0) {\n    int256 x = vaultConfig.primeRate.convertToUnderlying(vaultAccount.tempCashBalance).neg();\n    underlyingExternalToRepay = underlyingToken.convertToUnderlyingExternalWithAdjustment(x).toUint();\n} else {\n    require(vaultAccount.tempCashBalance == 0);\n}\n```
MEDIUM severity: The vulnerability arises from a rounding error in the calculation of the amount per iteration for bo. The vulnerability arises from a rounding error in the calculation of the amount per iteration for both Constant Weight (CoW) strategies. The issue occurs when the `amountIn` variable is divided by the `iterations` variable, which can lead to an additional iteration being performed.\n\nIn the affecte...

Vulnerable code:
```\nTypes.TokenRequest[] memory tokens = new Types.TokenRequest[](1);\ntokens[0] = Types.TokenRequest({token: inputToken, amount: amountIn});\namountIn = amountIn / iterations;\n\nStrategyParams memory params = StrategyParams({\n    tokenIn: inputToken,\n    tokenOut: outputToken,\n    amountToSwap: amountIn,\n    interval: interval,\n    remitToOwner: remitToOwner\n});\n```
MEDIUM severity: The vulnerability allows malicious or rogue owners to potentially steal or lock users' funds by expl. The vulnerability allows malicious or rogue owners to potentially steal or lock users' funds by exploiting loopholes in the protocol's code. Despite the implementation of various control measures to prevent owner theft or locking of funds, the codebase still contains vulnerabilities that can be expl...

Vulnerable code:
```\nFile: LimitOrderRegistry.sol\n\nfunction setFastGasFeed(address feed) external onlyOwner {\n    fastGasFeed = feed;\n}\n```\n```\nfunction performUpkeep(bytes calldata performData) external {\n    (UniswapV3Pool pool, bool walkDirection, uint256 deadline) = abi.decode(\n        performData,\n        (UniswapV3Pool, bool, uint256)\n    );\n\n    if (address(poolToData[pool].token0) == address(0)) {\n        revert LimitOrderRegistry__PoolNotSetup(address(pool));\n    }\n\n    PoolData storage data = poolToData[pool];\n\n    // Estimate gas cost.\n    uint256 estimatedFee = uint256(upkeepGasLimit * getGasPrice());\n```
MEDIUM severity: The vulnerability allows a malicious user to steal an already transferred and bridged reSDL lock due. The vulnerability allows a malicious user to steal an already transferred and bridged reSDL lock due to the lack of approval deletion when the lock is bridged to another chain. When a reSDL token is bridged to another chain, the `handleOutgoingRESDL()` function is executed, which deletes the lock's...

Vulnerable code:
```\nfunction handleOutgoingRESDL(\n    address _sender,\n    uint256 _lockId,\n    address _sdlReceiver\n)\n    external\n    onlyCCIPController\n    onlyLockOwner(_lockId, _sender)\n    updateRewards(_sender)\n    updateRewards(ccipController)\n    returns (Lock memory)\n{\n    Lock memory lock = locks[_lockId];\n\n    delete locks[_lockId].amount;\n    delete lockOwners[_lockId];\n    balances[_sender] -= 1;\n\n    uint256 totalAmount = lock.amount + lock.boostAmount;\n    effectiveBalances[_sender] -= totalAmount;\n    effectiveBalances[ccipController] += totalAmount;\n\n    sdlToken.safeTransfer(_sdlReceiver, lock.amount);\n\n    emit OutgoingRESDL(_sender, _lockId);\n\n    return lock;\n}\n```\n```\nit('PoC steal reSDL', async () => {\n  let lockId = 2;\n\n  let thief = accounts[0];\n  let victim = accounts[1];\n\n  let thiefAccount2 = accounts[2];\n\n  let ts = (await ethers.provider.getBlock(await ethers.provider.getBlockNumber())).timestamp;\n\n  // Thief approves an alt account that he controls to move his lock in the original chain\n  await sdlPool.approve(thiefAccount2, lockId);\n\n  assert.equal(await sdlPool.getApproved(2), thiefAccount2);\n\n  // Thief bridges the lock to an other chain but the approval is not deleted\n  await bridge.transferRESDL(77, victim, lockId, true, toEther(10), { value: toEther(10) });\n  let lastRequestMsg = await onRamp.getLastRequestMessage();\n  assert.deepEqual(\n    ethers.utils.defaultAbiCoder.decode(\n      ['address', 'uint256', 'uint256', 'uint256', 'uint64', 'uint64', 'uint64'],\n      lastRequestMsg[1]\n    ).map((d, i) => {\n      if (i === 0) return d;\n      if (i > 1 && i < 4) return fromEther(d);\n      return d.toNumber();\n    }),\n    [victim, lockId, 1000, 1000, ts, 365 * 86400, 0]\n  );\n  assert.deepEqual(\n    lastRequestMsg[2].map((d) => [d.token, fromEther(d.amount)]),\n    [[sdlToken.address, 1000]]\n  );\n  assert.equal(lastRequestMsg[3], wrappedNative.address);\n  assert.equal(lastRequestMsg[4], '0x11');\n  await expect(sdlPool.ownerOf(lockId)).to.be.revertedWith('InvalidLockId()');\n\n  // The user that received the lock from bridging on the other chain decides to bridge the lock id\n  // back to the original chain\n  await offRamp.connect(signers[6]).executeSingleMessage(\n    ethers.utils.formatBytes32String('messageId'),\n    77,\n    ethers.utils.defaultAbiCoder.encode(\n      ['address', 'uint256', 'uint256', 'uint256', 'uint64', 'uint64', 'uint64'],\n      [victim, lockId, 1000, 1000, ts, 365 * 86400, 0]\n    ),\n    sdl\n```