Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability arises from the incorrect use of `baseTokenId = reservedUntilTokenId` in the `_add. The vulnerability arises from the incorrect use of `baseTokenId = reservedUntilTokenId` in the `_addFounders` function. This can lead to the first `tokenRecipient` being invalid, resulting in the founder losing a portion of the NFT. The issue occurs when `reservedUntilTokenId` is greater than 100, c...

Vulnerable code:
```\nfunction _addFounders(IManager.FounderParams[] calldata _founders, uint256 reservedUntilTokenId) internal {\n    // Used to store the base token id the founder will recieve\n    uint256 baseTokenId = reservedUntilTokenId;\n\n    // For each token to vest:\n    for (uint256 j; j < founderPct; ++j) {\n        // Get the available token id\n        baseTokenId = _getNextTokenId(baseTokenId);\n\n        // Store the founder as the recipient\n        tokenRecipient[baseTokenId] = newFounder;\n\n        emit MintScheduled(baseTokenId, founderId, newFounder);\n\n        // Update the base token id\n        baseTokenId = (baseTokenId + schedule) % 100;\n    }\n}\n\nfunction _getNextTokenId(uint256 _tokenId) internal view returns (uint256) {\n    unchecked {\n        while (tokenRecipient[_tokenId].wallet!= address(0)) {\n            _tokenId = (_tokenId + 1) % 100;\n        }\n\n        return _tokenId;\n    }\n}\n```\n```\nfunction _isForFounder(uint256 _tokenId) private returns (bool) {\n    uint256 baseTokenId = _tokenId % 100;\n\n    if (tokenRecipient[baseTokenId].wallet == address(0)) {\n        return false;\n    } else if (block.timestamp < tokenRecipient[baseTokenId].vestExpiry) {\n        _mint(tokenRecipient[baseTokenId].wallet, _tokenId);\n        return true;\n    } else {\n        delete tokenRecipient[baseTokenId];\n        return false;\n    }\n}\n```\n```\ncontract TokenStorageV1 is TokenTypesV1 {\n    /// @notice The token settings\n    internal Settings settings;\n\n    /// @notice The vesting details of a founder\n    /// @dev Founder id => Founder\n    mapping(uint256 => Founder) internal founder;\n\n    /// @notice The recipient of a token\n    /// @dev\n    mapping(uint256 => Founder) public tokenRecipient;\n}\n```\n```\nfunction test_lossFirst(address _minter, uint256 _reservedUntilTokenId, uint256 _tokenId) public {\n    deployAltMock(200);\n    (address wallet,,) = token.tokenRecipient(200);\n    assertEq(wallet, founder);\n}\n```\n```\n$ forge test -vvv --match-test test_lossFirst\n\nRunning 1 test for test/Token.t.sol:TokenTest\n[PASS] test_lossFirst(address,uint256,uint256) (runs: 256, μ: 3221578, ~: 3221578)\nTest result: ok. 1 passed; 0 failed; 0 skipped; finished in 355.45ms\nRan 1 test suite: 1 test passed, 0 failed, 0 skipped (1 total tests)\n```
MEDIUM severity: The vulnerability arises from the inconsistent spot prices used during the comparison, which can lea. The vulnerability arises from the inconsistent spot prices used during the comparison, which can lead to incorrect conclusions about the pool's integrity. The `SPOT_PRICE.getComposableSpotPrices` function returns spot prices in native decimals, which are then converted to `POOL_PRECISION` for use in...

Vulnerable code:
```\nFile: BalancerComposableAuraVault.sol\n\nfunction _checkPriceAndCalculateValue() internal view override returns (uint256) {\n    (uint256[] memory balances, uint256[] memory spotPrices) = \n        SPOT_PRICE.getComposableSpotPrices(\n            BALANCER_POOL_ID,\n            address(BALANCER_POOL_TOKEN),\n            PRIMARY_INDEX()\n        );\n\n    (/* */, uint8[] memory decimals) = TOKENS();\n    for (uint256 i = 0; i < spotPrices.length; i++) {\n        spotPrices[i] = spotPrices[i] * POOL_PRECISION() / 10 ** decimals[i];\n    }\n\n    return _calculateLPTokenValue(balances, spotPrices);\n}\n```\n```\nFile: StableMath.sol\n\n/**\n * @dev Calculates the spot price of token Y in token X.\n */\nfunction _calcSpotPrice(\n    uint256 amplificationParameter,\n    uint256 invariant,\n    uint256 balanceX,\n    uint256 balanceY\n) internal pure returns (uint256) {\n    uint256 a = (amplificationParameter * 2) / _AMP_PRECISION;\n    uint256 b = invariant + a * (invariant - invariant);\n    uint256 numerator = 2 * a * balanceX * balanceY + a * balanceY * balanceY + b * balanceY;\n    uint256 denominator = 2 * a * balanceX * balanceX + a * balanceX * balanceX + b * balanceX;\n    return numerator / denominator;\n}\n```\n```\nFile: SingleSidedLPVaultBase.sol\n\nfunction _calculateLPTokenValue(\n    uint256 price = _getOraclePairPrice(primaryToken, address(tokens[i]));\n\n    uint256 lowerLimit = price * (Constants.VAULT_PERCENT_BASIS - limit) / Constants.VAULT_PERCENT_BASIS;\n    uint256 upperLimit = price * (Constants.VAULT_PERCENT_BASIS + limit) / Constants.VAULT_PERCENT_BASIS;\n    if (spotPrices[i] < lowerLimit || upperLimit < spotPrices[i]) {\n        revert Errors.InvalidPrice(price, spotPrices[i]);\n    }\n```
MEDIUM severity: The `Market::_allowedBorrow` function, responsible for verifying the authorization of spenders to pe. The `Market::_allowedBorrow` function, responsible for verifying the authorization of spenders to perform borrowing actions, contains a critical oversight in its handling of Pearlmit allowances. Specifically, when a spender utilizes a Pearlmit allowance to borrow, the function attempts to decrement...

Vulnerable code:
```\nfunction _allowedBorrow(address from, uint256 share) internal virtual override {\n    if (from!= msg.sender) {\n        (uint256 pearlmitAllowed,) = penrose.pearlmit().allowance(from, msg.sender, address(yieldBox), collateralId);\n        require(allowanceBorrow[from][msg.sender] >= share || pearlmitAllowed >= share, "Market: not approved");\n        if (allowanceBorrow[from][msg.sender]!= type(uint256).max) {\n            allowanceBorrow[from][msg.sender] -= share;\n        }\n    }\n}\n```\n```\nrequire(\n    allowanceBorrow[from][msg.sender] >= share || permitAllowed >= share,\n    "Market: not approved"\n);\n```\n```\nif (allowanceBorrow[from][msg.sender]!= type(uint256).max) {\n    allowanceBorrow[from][msg.sender] -= share;\n```
MEDIUM severity: The `_accumulateInternalRewards` function in the SingleSidedLiquidityVault contract is vulnerable to. The `_accumulateInternalRewards` function in the SingleSidedLiquidityVault contract is vulnerable to an underflow error when processing internal reward tokens. This occurs when the `rewardToken.lastRewardTime` is set to a value greater than the current block timestamp (`block.timestamp`). This can h...

Vulnerable code:
```\nfunction _accumulateInternalRewards() internal view returns (uint256[] memory) {\n    uint256 numInternalRewardTokens = internalRewardTokens.length;\n    uint256[] memory accumulatedInternalRewards = new uint256[](numInternalRewardTokens);\n\n    for (uint256 i = 0; i < numInternalRewardTokens; ) {\n        InternalRewardToken memory rewardToken = internalRewardTokens[i];\n\n        uint256 totalRewards;\n        if (totalLP > 0) {\n            uint256 timeDiff = block.timestamp - rewardToken.lastRewardTime;\n            totalRewards = (timeDiff * rewardToken.rewardsPerSecond);\n        }\n\n        accumulatedInternalRewards[i] = totalRewards;\n\n        unchecked {\n            i++;\n        }\n    }\n\n    return accumulatedInternalRewards;\n}\n```\n```\nfunction addInternalRewardToken(\n    address token_,\n    uint256 rewardsPerSecond_,\n    uint256 startTimestamp_\n) external onlyRole("liquidityvault_admin") {\n    InternalRewardToken memory newInternalRewardToken = InternalRewardToken(\n        token,\n        decimalsAdjustment: 10**ERC20(token_).decimals(),\n        rewardsPerSecond: rewardsPerSecond_,\n        lastRewardTime: block.timestamp > startTimestamp_? block.timestamp : startTimestamp_,\n        accumulatedRewardsPerShare: 0\n    );\n\n    internalRewardTokens.push(newInternalRewardToken);\n}\n```
MEDIUM severity: A malicious admin can exploit the `updateWrapper` function in the `PriceOracleManager` contract to u. A malicious admin can exploit the `updateWrapper` function in the `PriceOracleManager` contract to update the price oracle for any underlying collateral without any restrictions, allowing them to set a malicious price oracle that can be used to liquidate users' collateral with negligible $TAU cost....

Vulnerable code:
```\n2. Multisig. \n    Trusted with essentially everything but user collateral.\n```\n```\nFile: taurus-contracts/contracts/Oracle/PriceOracleManager.sol\n\nfunction updateWrapper(address _underlying, address _wrapperAddress) external override onlyOwner {\n    if (!_wrapperAddress.isContract()) {\n        revert notContract();\n    }\n    if (wrapperAddressMap[_underlying] == address(0)) {\n        revert wrapperNotRegistered(_wrapperAddress);\n    }\n\n    wrapperAddressMap[_underlying] = _wrapperAddress;\n\n    emit WrapperUpdated(_underlying, _wrapperAddress);\n}\n```\n```\ncontract AttackOracleWrapper is IOracleWrapper, Ownable {\n    address public attacker;\n    IGLPManager public glpManager;\n\n    constructor(address _attacker, address glp) {\n        attacker = _attacker;\n        glpManager = IGLPManager(glp);\n    }\n\n    function getExternalPrice(\n        address _underlying,\n        bytes calldata _flags\n    ) external view returns (uint256 price, uint8 decimals, bool success) {\n        if (tx.origin == attacker) {\n            return (1, 18, true);\n        } else {\n            uint256 price = glpManager.getPrice();\n            return (price, 18, true);\n        }\n    }\n}\n```\n```\nFile: taurus-contracts/contracts/Vault/BaseVault.sol\n\nfunction liquidate(\n    address _account,\n    uint256 _debtAmount,\n    uint256 _minExchangeRate\n) external onlyLiquidator whenNotPaused updateReward(_account) returns (bool) {\n    if (_debtAmount == 0) {\n        revert wrongLiquidationAmount();\n    }\n\n    UserDetails memory accDetails = userDetails[_account];\n\n    if (_debtAmount > accDetails.debt) {\n        _debtAmount = accDetails.debt;\n    }\n\n    (uint256 collateralToLiquidate, uint256 liquidationSurcharge) = _calcLiquidation(\n        accDetails.collateral,\n        accDetails.debt,\n        _debtAmount\n    );\n\n    uint256 collateralToLiquidator = collateralToLiquidate - liquidationSurcharge;\n    if (collateralToLiquidator < (_debtAmount * _minExchangeRate) / Constants.PRECISION) {\n        revert insufficientCollateralLiquidated(_debtAmount, collateralToLiquidator);\n    }\n\n    userDetails[_account].collateral = accDetails.collateral - collateralToLiquidate;\n    userDetails[_account].debt = accDetails.debt - _debtAmount;\n\n    TAU(tau).burnFrom(msg.sender, _debtAmount);\n\n    IERC20(collateralToken).safeTransfer(msg.sender, collateralToLiquidator);\n    IERC20(collateralToken).safeTransfer(\n        Controller(controller).addressMapper(Constants.FEE_SPLITTER),\n        liquidationSurcharge\n    );\n\n    emit AccountLiquidated(msg.sender, _account, collateralToLiquidate, liquidationSurcharge);\n\n    return true;\n}\n```
MEDIUM severity: The ERC20 standard specifies that a successful transfer should return a boolean value indicating suc. The ERC20 standard specifies that a successful transfer should return a boolean value indicating success, typically `true`. However, many tokens deviate from this convention, omitting the return value altogether. This non-compliance can lead to unexpected behavior when attempting to transfer tokens...

Vulnerable code:
```\nif (!instance.transfer(getSendAddress(), forwarderBalance)) {\n    revert('Could not gather ERC20');\n}\n```
MEDIUM severity: The RocketNetworkWithdrawal vulnerability is a potential issue that arises when processing a withdra. The RocketNetworkWithdrawal vulnerability is a potential issue that arises when processing a withdrawal due to rounding errors in the division operation. This occurs when calculating the withdrawal amounts for a user and a node based on their respective shares of the total withdrawal balance.\n\nThe...

Vulnerable code:
```\nuint256 totalShare = rocketMinipoolManager.getMinipoolWithdrawalTotalBalance(msg.sender);\nuint256 nodeShare = rocketMinipoolManager.getMinipoolWithdrawalNodeBalance(msg.sender);\nuint256 userShare = totalShare.sub(nodeShare);\n\nuint256 nodeAmount = 0;\nuint256 userAmount = 0;\n\nif (totalShare > 0) {\n    nodeAmount = msg.value.mul(nodeShare).div(totalShare);\n    userAmount = msg.value.mul(userShare).div(totalShare);\n}\n```
MEDIUM severity: The Napier AMM pool's LP tokens are always valued at a fixed ratio of 3 PTs, which can lead to an un. The Napier AMM pool's LP tokens are always valued at a fixed ratio of 3 PTs, which can lead to an unfair distribution of assets or PTs to users. This discrepancy arises from the pool's assumption that the Base LP Token is equivalent to 3 times the amount of PTs, as initially deposited in the Curve p...

Vulnerable code:
```\nFile: PoolMath.sol\n\nint256 internal constant N_COINS = 3;\n\nfunction swapExactBaseLpTokenForUnderlying(PoolState memory pool, uint256 exactBaseLptIn)\n    internal\n{\n    // Note: Here we are multiplying by N_COINS because the swap formula is defined in terms of the amount of PT being swapped.\n    // BaseLpt is equivalent to 3 times the amount of PT due to the initial deposit of 1:1:1:1=pt1:pt2:pt3:Lp share in Curve pool.\n    exactBaseLptIn * N_COINS\n\n    function swapUnderlyingForExactBaseLpToken(PoolState memory pool, uint256 exactBaseLptOut)\n    {\n        (int256 _netUnderlyingToAccount18, int256 _netUnderlyingFee18, int256 _netUnderlyingToProtocol18) = executeSwap(\n            pool,\n            // Note: sign is defined from the perspective of the swapper.\n            // positive because the swapper is buying pt\n            exactBaseLptOut * N_COINS\n        )\n```\n```\n/// @dev Number of coins in the BasePool\nuint256 internal constant N_COINS = 3;\n\n...SNIP...\n\ntotalBaseLptTimesN: baseLptUsed * N_COINS,\n...SNIP...\n\ntotalBaseLptTimesN: totalBaseLpt * N_COINS,\n```
MEDIUM severity: The vulnerability allows malicious users to bypass the slashing mechanism by exploiting the `checkpo. The vulnerability allows malicious users to bypass the slashing mechanism by exploiting the `checkpointProtection` modifier in the StakingModule. This modifier is designed to prevent actions like claims from being processed if the account's stake has been modified in the same block. However, a malic...

Vulnerable code:
```\nmodifier checkpointProtection(address account) {\n    uint256 numCheckpoints = _stakes[account]._checkpoints.length;\n    require(numCheckpoints == 0 || _stakes[account]._checkpoints[numCheckpoints - 1]._blockNumber!= block.number, "StakingModule: Cannot exit in the same block as another stake or exit");\n}\n```
MEDIUM severity: The `_updateL2L1MessageStatusToClaimed` and `_updateL1L2MessageStatusToClaimed` functions are respon. The `_updateL2L1MessageStatusToClaimed` and `_updateL1L2MessageStatusToClaimed` functions are responsible for updating the message status when claiming messages on L1 and L2, respectively. However, the message state check in these functions is incomplete, as it only verifies the status as `INBOX_STA...

Vulnerable code:
```\nfunction _updateL2L1MessageStatusToClaimed(bytes32 _messageHash) internal {\n    if (inboxL2L1MessageStatus[_messageHash]!= INBOX_STATUS_RECEIVED) {\n        revert MessageAlreadyClaimed();\n    }\n\n    delete inboxL2L1MessageStatus[_messageHash];\n\n    emit L2L1MessageClaimed(_messageHash);\n}\n```\n```\nfunction _updateL1L2MessageStatusToClaimed(bytes32 _messageHash) internal {\n    if (inboxL1L2MessageStatus[_messageHash]!= INBOX_STATUS_RECEIVED) {\n        revert MessageAlreadyClaimed();\n    }\n\n    inboxL1L2MessageStatus[_messageHash] = INBOX_STATUS_CLAIMED;\n\n    emit L1L2MessageClaimed(_messageHash);\n}\n```
MEDIUM severity: The `setVerifierAddress` function, responsible for updating the verifier address for a specific proo. The `setVerifierAddress` function, responsible for updating the verifier address for a specific proof type, fails to emit an event upon successful execution. This oversight allows for a critical security vulnerability to arise. When the operator (security council) changes the verifier address, no no...

Vulnerable code:
```\nfunction setVerifierAddress(address _newVerifierAddress, uint256 _proofType) external onlyRole(DEFAULT_ADMIN_ROLE) {\n    if (_newVerifierAddress == address(0)) {\n        revert ZeroAddressNotAllowed();\n    }\n    verifiers[_proofType] = _newVerifierAddress;\n}\n```
MEDIUM severity: The vulnerability arises when a deposit fails due to improper handling of debt repayment by swapping. The vulnerability arises when a deposit fails due to improper handling of debt repayment by swapping through the `swapTokensForExactTokens()` function. This can occur when the `processDeposit()` function fails in the `try` block, resulting in the status being set to `deposit_failed`. \n\nIn this sce...

Vulnerable code:
```\nfunction processDeposit(GMXTypes.Store storage self) external {\n    try GMXProcessDeposit.processDeposit(self) {\n        //..more code\n    } catch (bytes memory reason) {\n        self.status = GMXTypes.Status.Deposit_Failed;\n        emit DepositFailed(reason);\n    }\n}\n```\n```\n(bool _swapNeeded, address _tokenFrom, address _tokenTo, uint256 _tokenToAmt) = \n    GMXManager.calcSwapForRepay(self, _rp);\n\nif (_swapNeeded) {\n    ISwap.SwapParams memory _sp;\n\n    _sp.tokenIn = _tokenFrom;\n    _sp.tokenOut = _tokenTo;\n    _sp.amountIn = IERC20(_tokenFrom).balanceOf(address(this));\n    _sp.amountOut = _tokenToAmt;\n    _sp.slippage = self.minSlippage;\n    _sp.deadline = block.timestamp;\n    GMXManager.swapTokensForExactTokens(self, _sp);\n}\n```\n```\nfunction processDepositFailure(GMXTypes.Store storage self, uint256 slippage, uint256 executionFee) external {\n    GMXChecks.beforeProcessAfterDepositFailureChecks(self);\n\n    GMXTypes.RemoveLiquidityParams memory _rlp;\n\n    if (GMXReader.lpAmt(self) <= self.depositCache.healthParams.lpAmtBefore) {\n        processDepositFailureLiquidityWithdrawal(self);\n    }\n}\n```
MEDIUM severity: The UNI token contract's transfer limit, set at 2^96 UNI tokens, poses a significant risk of token l. The UNI token contract's transfer limit, set at 2^96 UNI tokens, poses a significant risk of token loss and denial-of-service (DoS) attacks. This limitation is enforced by the `balanceOf` function, which checks the sender's token balance before processing a transfer. However, when a user attempts to...

Vulnerable code:
```\nself.tokenA.safeTransfer(self.withdrawCache.user, self.tokenA.balanceOf(address(this)))\n```
MEDIUM severity: The `zAuction` contract contains a vulnerability in its withdrawal, deposit, and exchange functions,. The `zAuction` contract contains a vulnerability in its withdrawal, deposit, and exchange functions, which allows for zero-value transactions to be processed without any actual effect. This is achieved by allowing transfers where the `from` and `to` addresses are the same, or where the transfer amou...

Vulnerable code:
```\nfunction Withdraw(uint256 amount) external {\n    ethbalance[msg.sender] = SafeMath.sub(ethbalance[msg.sender], amount);\n    payable(msg.sender).transfer(amount);\n    emit Withdrew(msg.sender, amount);\n}\n```\n```\nfunction Deposit() external payable {\n    ethbalance[msg.sender] = SafeMath.add(ethbalance[msg.sender], msg.value);\n    emit Deposited(msg.sender, msg.value);\n}\n```\n```\nfunction zDeposit(address to) external payable onlyZauction {\n    ethbalance[to] = SafeMath.add(ethbalance[to], msg.value);\n    emit zDeposited(to, msg.value);\n}\n\nfunction zWithdraw(address from, uint256 amount) external onlyZauction {\n    ethbalance[from] = SafeMath.sub(ethbalance[from], amount);\n    emit zWithdrew(from, amount);\n}\n\nfunction Exchange(address from, address to, uint256 amount) external onlyZauction {\n    ethbalance[from] = SafeMath.sub(ethbalance[from], amount);\n    ethbalance[to] = SafeMath.add(ethbalance[to], amount);\n    emit zExchanged(from, to, amount);\n}\n```
MEDIUM severity: The liquidity withdrawal process is vulnerable to being blocked, allowing malicious actors to manipu. The liquidity withdrawal process is vulnerable to being blocked, allowing malicious actors to manipulate the system and prevent legitimate users from accessing their funds. This issue arises from the design of the withdrawal queue, which allows for partial withdrawals when a request is not in the qu...

Vulnerable code:
```\naddress _currentAddr = withdrawalQueue.head();\nuint256 _tokensToWithdraw = withdrawalsInfo[_currentAddr].withdrawalAmount;\n\nuint256 _amountInDAI = convertDAIXtoDAI(_tokensToWithdraw);\n\nif (_availableLiquidity < _amountInDAI) {\n    break;\n}\n```\n```\n} else if (_availableLiquidity < convertDAIXtoDAI(_tokensToWithdraw)) {\n    uint256 _availableDAIxTokens = convertDAIToDAIx(_availableLiquidity);\n    uint256 _currentWithdrawalAmount = _tokensToWithdraw.sub(_availableDAIxTokens);\n    withdrawalsInfo[_msgSender()].withdrawalAmount = _currentWithdrawalAmount;\n\n    aggregatedQueueAmount = aggregatedQueueAmount.add(_currentWithdrawalAmount);\n    withdrawalQueue.push(_msgSender());\n\n    _withdrawLiquidity(_msgSender(), _availableDAIxTokens);\n} else {\n```
MEDIUM severity: This vulnerability allows for the creation of a withdrawal request with a zero amount, which can be . This vulnerability allows for the creation of a withdrawal request with a zero amount, which can be successfully executed and added to the queue. This can lead to a denial-of-service (DoS) attack, where malicious actors can spam the system with requests for zero-value withdrawals, potentially overwh...

Vulnerable code:
```\nfunction requestWithdrawal(uint256 _tokensToWithdraw) external override {\n    // Check if the user has requested withdrawal before\n    if (withdrawalRequests[_msgSender].tokensToWithdraw > 0) {\n        // Check if the requested withdrawal amount is greater than the available balance\n        if (_tokensToWithdraw > balanceOf[_msgSender]) {\n            revert("Insufficient balance");\n        } else {\n            // Update the withdrawal request\n            withdrawalRequests[_msgSender].tokensToWithdraw = _tokensToWithdraw;\n        }\n    } else {\n        // Create a new withdrawal request\n        withdrawalRequests[_msgSender] = WithdrawalRequest(_tokensToWithdraw, block.timestamp);\n    }\n}\n```
MEDIUM severity: The CREATE3 library, which is used to deploy contracts on zkSync Era, is not available in the zkSync. The CREATE3 library, which is used to deploy contracts on zkSync Era, is not available in the zkSync Era environment. This is because the logic to compute the address of Create2 is different from Ethereum, and the zkSync Era implementation does not support the same approach.\n\nIn the provided code,...

Vulnerable code:
```\npragma solidity ^0.8.0;\n\nimport "./MiniContract.sol";\nimport "./CREATE3.sol";\n\ncontract DeployTest {\n    address public deployedAddress;\n    event Deployed(address);\n\n    function generateContract() public returns (address, address) {\n        bytes32 salt = keccak256("SALT");\n\n        address preCalculatedAddress = CREATE3.getDeployed(salt);\n\n        bytes memory creationCode = abi.encodePacked(type(MiniContract).creationCode, abi.encode(777));\n\n        address deployed = CREATE3.deploy(salt, creationCode, 0);\n        return (preCalculatedAddress, deployed);\n    }\n}\n```\n```\naddress => keccak256(\n    keccak256("zksyncCreate2") => 0x2020dba91b30cc0006188af794c2fb30dd8520db7e2c088b7fc7c103c00ca494,\n    sender,\n    salt,\n    keccak256(bytecode),\n    keccak256(constructorInput)\n)\n```