Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability arises when a stable peg fails, causing the oracle to malfunction and subsequently. The vulnerability arises when a stable peg fails, causing the oracle to malfunction and subsequently disable swaps. This occurs when the price of an asset or stable is fetched from OracleX and the `_checkPrice` function detects a deviation beyond the expected range.\n\nThe `_checkPrice` function is...

Vulnerable code:
```\n_require(minPrice <= price && price <= maxPrice, Errors.PRICE_INVALID)\n```
MEDIUM severity: The `_beforeTokenTransfer` function in OpenZeppelin's ERC-20 implementation provides a hook that is . The `_beforeTokenTransfer` function in OpenZeppelin's ERC-20 implementation provides a hook that is called before tokens are transferred, minted, or burned. In the Gluwacoin codebase, this function is used to check whether the unreserved balance (distinct from the regular balance, which is checked b...

Vulnerable code:
```\nfunction _beforeTokenTransfer(\n    address from,\n    address to,\n    uint256 amount\n) internal override(ERC20Upgradeable, ERC20Wrapper, ERC20Reservable) {\n    ERC20Wrapper._beforeTokenTransfer(from, to, amount);\n    ERC20Reservable._beforeTokenTransfer(from, to, amount);\n}\n```\n```\nfunction _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual override {\n    if (from!= address(0)) {\n        require(_unreservedBalance(from) >= amount, "ERC20Reservable: transfer amount exceeds unreserved balance");\n    }\n\n    super._beforeTokenTransfer(from, to, amount);\n}\n```\n```\nfunction _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual override {\n    super._beforeTokenTransfer(from, to, amount);\n}\n```\n```\nERC20WrapperGluwacoin\nERC20Reservable\nERC20ETHless\nERC20Wrapper\nERC20Upgradeable\nIERC20MetadataUpgradeable\nIERC20Upgradeable\nAccessControlEnumerableUpgradeable\nAccessControlUpgradeable\nERC165Upgradeable\nIERC165Upgradeable\nIAccessControlEnumerableUpgradeable\nIAccessControlUpgradeable\nContextUpgradeable\nInitializable\n```
MEDIUM severity: The `Inaccurate Interface` vulnerability is a critical issue in the `ISocketGateway` interface, whic. The `Inaccurate Interface` vulnerability is a critical issue in the `ISocketGateway` interface, which defines a function called `bridge` with parameters `routeId` and `data`. Specifically, the `bridge` function is declared as `bridge(uint32 routeId, bytes memory data)` and is intended to be a bridge...

Vulnerable code:
```\nfunction bridge(\n    uint32 routeId,\n    bytes memory data\n) external payable returns (bytes memory) {\n}\n```
MEDIUM severity: The `TBTCDepositToken` constructor inherits from `DepositFactoryAuthority`, which has a single state. The `TBTCDepositToken` constructor inherits from `DepositFactoryAuthority`, which has a single state variable `_depositFactory`. This variable is intentionally overridden in the `TBTCDepositToken` constructor, which can lead to unexpected behavior and potential security issues.\n\nIn the provided co...

Vulnerable code:
```\nconstructor(address _depositFactory) {\n    ERC721Metadata("tBTC Deposit Token", "TDT");\n    DepositFactoryAuthority(_depositFactory);\n}\n```
MEDIUM severity: The `initialize` function of the pool's committee management system is vulnerable to an issue where . The `initialize` function of the pool's committee management system is vulnerable to an issue where the input array of committee members can contain duplicate entries. This is due to the lack of a check for duplicate values during the processing of the input array.\n\nThe code snippet responsible fo...

Vulnerable code:
```\nfor (uint256 i = 0; i < committeeMembers.length; ++i) {\n    address member = committeeMembers[i];\n    committeeArray.push(member);\n    committeeIndexPlusOne[member] = committeeArray.length;\n}\n```
MEDIUM severity: The PeriodicPrizeStrategy contract contains a vulnerability that allows an attacker to exploit the g. The PeriodicPrizeStrategy contract contains a vulnerability that allows an attacker to exploit the gas consumption of the `completeAward()` function by manipulating the linked list of external token addresses. This vulnerability arises from the fact that the size of the linked list is not limited, a...

Vulnerable code:
```\nfunction addExternalErc20Award(address _externalErc20) external onlyOwnerOrListener {\n    _addExternalErc20Award(_externalErc20);\n}\n\nfunction _addExternalErc20Award(address _externalErc20) internal {\n    require(prizePool.canAwardExternal(_externalErc20), "PeriodicPrizeStrategy/cannot-award-external");\n    externalErc20s.addAddress(_externalErc20);\n    emit ExternalErc20AwardAdded(_externalErc20);\n}\n```\n```\nfunction addAddress(Mapping storage self, address newAddress) internal {\n    require(newAddress!= SENTINEL && newAddress!= address(0), "Invalid address");\n    require(self.addressMap[newAddress] == address(0), "Already added");\n    self.addressMap[newAddress] = self.addressMap[SENTINEL];\n    self.addressMap[SENTINEL] = newAddress;\n    self.count = self.count + 1;\n}\n```\n```\nfunction _awardExternalErc721s(address winner) internal {\n    address currentToken = externalErc721s.start();\n    while (currentToken!= address(0) && currentToken!= externalErc721s.end()) {\n        uint256 balance = IERC721(currentToken).balanceOf(address(prizePool));\n        if (balance > 0) {\n            prizePool.awardExternalERC721(winner, currentToken, externalErc721TokenIds[currentToken]);\n            delete externalErc721TokenIds[currentToken];\n        }\n        currentToken = externalErc721s.next(currentToken);\n    }\n    externalErc721s.clearAll();\n}\n```
MEDIUM severity: The transfer lock for leveraged position orders can be bypassed, allowing an attacker to unlock a to. The transfer lock for leveraged position orders can be bypassed, allowing an attacker to unlock a token while a leverage close announcement is active. This vulnerability occurs when an attacker announces a leverage close order using the `DelayedOrder` contract's `announceLeverageClose` function and...

Vulnerable code:
```\nfunction testExploitTransferOut() public {\n    uint256 collateralPrice = 1000e8;\n\n    vm.startPrank(alice);\n\n    uint256 balance = WETH.balanceOf(alice);\n    console2.log("alice balance", balance);\n\n    (uint256 minFillPrice,) = oracleModProxy.getPrice();\n\n    // Announce order through delayed orders to lock tokenId\n    delayedOrderProxy.announceLeverageClose(\n        tokenId,\n        minFillPrice - 100, // add some slippage\n        mockKeeperFee.getKeeperFee()\n    );\n\n    // Announce limit order to lock tokenId\n    limitOrderProxy.announceLimitOrder({\n        tokenId: tokenId,\n        priceLowerThreshold: 900e18,\n        priceUpperThreshold: 1100e18\n    });\n\n    // Cancel limit order to unlock tokenId\n    limitOrderProxy.cancelLimitOrder(tokenId);\n\n    balance = WETH.balanceOf(alice);\n    console2.log("alice after creating two orders", balance);\n\n    // TokenId is unlocked and can be transferred while the delayed order is active\n    leverageModProxy.transferFrom(alice, address(0x1), tokenId);\n    console2.log("new owner of position NFT", leverageModProxy.ownerOf(tokenId));\n\n    balance = WETH.balanceOf(alice);\n    console2.log("alice after transferring position NFT out e.g. selling", balance);\n\n    skip(uint256(vaultProxy.minExecutabilityAge())); // must reach minimum executability time\n\n    uint256 oraclePrice = collateralPrice;\n\n    bytes[] memory priceUpdateData = getPriceUpdateData(oraclePrice);\n    delayedOrderProxy.executeOrder{value: 1}(alice, priceUpdateData);\n\n    uint256 finalBalance = WETH.balanceOf(alice);\n    console2.log("alice after executing delayed order and cashing out profit", finalBalance);\n    console2.log("profit", finalBalance - balance);\n}\n```\n```\nRunning 1 test for test/unit/Common/LimitOrder.t.sol:LimitOrderTest\n[PASS] testExploitTransferOut() (gas: 743262)\n\nLogs:\n  alice balance 99879997000000000000000\n  alice after creating two orders 99879997000000000000000\n  new owner of position NFT 0x0000000000000000000000000000000000000001\n  alice after transferring position NFT out (e.g., selling) 99879997000000000000000\n  alice after executing delayed order and cashing out profit 99889997000000000000000\n  profit 10000000000000000000\n\nTest result: ok. 1 passed; 0 failed; 0 skipped; finished in 50.06ms\n\nRan 1 test suite: 1 tests passed, 0 failed, 0 skipped (1 total tests)\n```
MEDIUM severity: The current design of the `reinvestReward` function in Balancer Vaults (MetaStable2TokenAuraVault an. The current design of the `reinvestReward` function in Balancer Vaults (MetaStable2TokenAuraVault and Boosted3TokenAuraVault) does not prioritize the interests of vault shareholders. This function, which is permissionless and can be called by anyone, trades reward tokens received by the vault for to...

Vulnerable code:
```\nfunction reinvestReward(\n    MetaStable2TokenAuraStrategyContext calldata context,\n    ReinvestRewardParams calldata params\n) external {\n```\n```\nfunction reinvestReward(\n    Boosted3TokenAuraStrategyContext calldata context,\n    ReinvestRewardParams calldata params\n) external {\n```
MEDIUM severity: The permissioned rebalancing functions in the protocol's smart contracts, accessible only by the adm. The permissioned rebalancing functions in the protocol's smart contracts, accessible only by the admin/owner, can be exploited to cause a loss of assets for users. The admin/owner, who is RESTRICTED, can manipulate the rebalancing process to deplete the ETH buffer and render it inaccessible to users...

Vulnerable code:
```\nFile: BaseLSTAdapter.sol\n\nfunction setRebalancer(address _rebalancer) external onlyOwner {\n    rebalancer = _rebalancer;\n}\n```\n```\nFile: BaseLSTAdapter.sol\n\nfunction setTargetBufferPercentage(uint256 _targetBufferPercentage) external onlyRebalancer {\n    if (_targetBufferPercentage < MIN_BUFFER_PERCENTAGE || _targetBufferPercentage > BUFFER_PERCENTAGE_PRECISION) {\n        revert InvalidBufferPercentage();\n    }\n    targetBufferPercentage = _targetBufferPercentage;\n}\n```
MEDIUM severity: The vulnerability arises from the mishandling of Native ETH and WETH in the Curve V2 pool's `remove_. The vulnerability arises from the mishandling of Native ETH and WETH in the Curve V2 pool's `remove_liquidity_one_coin` and `remove_liquidity` functions. Specifically, when removing liquidity from the pool, the `use_eth` parameter is not explicitly set to `True`, which causes the pool to wrap the ET...

Vulnerable code:
```\n@external\n@nonreentrant('lock')\ndef remove_liquidity_one_coin(\n    token_amount: uint256, \n    i: uint256, \n    min_amount: uint256, \n    use_eth: bool = False, \n    receiver: address = msg.sender\n) -> uint256:\n    A_gamma: uint256[2] = self._A_gamma()\n\n    dy: uint256 = 0\n    D: uint256 = 0\n    p: uint256 = 0\n    xp: uint256[N_COINS] = [0] * N_COINS\n    future_A_gamma_time: uint256 = self.future_A_gamma_time\n    dy, p, D, xp = self._calc_withdraw_one_coin(A_gamma, token_amount, i, future_A_gamma_time > 0, True)\n    assert dy >= min_amount, "Slippage"\n\n    if block.timestamp >= future_A_gamma_time:\n        self.future_A_gamma_time = 1\n\n    self.balances[i] -= dy\n    CurveToken(self.token).burnFrom(msg.sender, token_amount)\n\n    coin: address = self.coins[i]\n    if use_eth and coin == WETH20:\n        raw_call(receiver, b"", value=dy)\n    else:\n        if coin == WETH20:\n            WETH(WETH20).deposit(value=dy)\n        response: Bytes[32] = raw_call(\n            coin, \n            _abi_encode(receiver, dy, method_id("transfer(address,uint256)")), \n            max_outsize=32\n        )\n        if len(response)!= 0:\n            assert convert(response, bool)\n```\n```\nFile: Curve2TokenConvexVault.sol\n\nfunction _unstakeAndExitPool(\n    ICurve2TokenPool pool = ICurve2TokenPool(CURVE_POOL);\n    uint256[2] memory exitBalances;\n    if (isSingleSided) {\n        // Redeem single-sided\n        exitBalances[_PRIMARY_INDEX] = pool.remove_liquidity_one_coin(\n            poolClaim, int8(_PRIMARY_INDEX), _minAmounts[_PRIMARY_INDEX]\n        );\n    } else {\n        // Redeem proportionally, min amounts are rewritten to a fixed length array\n        uint256[2] memory minAmounts;\n        minAmounts[0] = _minAmounts[0];\n        minAmounts[1] = _minAmounts[1];\n\n        uint256[2] memory _exitBalances = pool.remove_liquidity(poolClaim, minAmounts);\n        exitBalances[0] = _exitBalances[0];\n        exitBalances[1] = _exitBalances[1];\n    }\n```
MEDIUM severity: The BalancerLBPSwapper contract contains a vulnerability in its `tokenSpent` and `tokenReceived` var. The BalancerLBPSwapper contract contains a vulnerability in its `tokenSpent` and `tokenReceived` variables, which are intended to be immutable but are not properly declared as such. This oversight allows unauthorized modifications to these variables, potentially compromising the integrity of the con...

Vulnerable code:
```\ntokenSpent = _tokenSpent\ntokenReceived = _tokenReceived\n```\n```\naddress public override tokenSpent;\n\naddress public override tokenReceived;\n```
MEDIUM severity: The `prefundingRefund` calculation within the `claimProceeds` function is flawed, leading to an unde. The `prefundingRefund` calculation within the `claimProceeds` function is flawed, leading to an underflow condition that disallows claiming. This issue arises from the incorrect subtraction of `sold_` from `routing.funding` and the addition of `payoutSent_`, which can result in a negative value for...

Vulnerable code:
```\nfunction claimProceeds(\n    uint96 lotId_,\n    bytes calldata callbackData_\n) external override nonReentrant {\n    (uint96 purchased_, uint96 sold_, uint96 payoutSent_) =\n        _getModuleForId(lotId_).claimProceeds(lotId_);\n\n    (uint96 purchased_, uint96 sold_, uint96 payoutSent_) = \n        _getModuleForId(lotId_).claimProceeds(lotId_);\n\n    // Refund any unused capacity and curator fees to the address dictated by the callbacks address\n    // By this stage, a partial payout (if applicable) and curator fees have been paid, leaving only the payout amount (`totalOut`) remaining.\n    uint96 prefundingRefund = routing.funding + payoutSent_ - sold_;\n    unchecked {\n        routing.funding -= prefundingRefund;\n    }\n```\n```\nfunction claimBids(uint96 lotId_, uint64[] calldata bidIds_) external override nonReentrant {\n    if (bidClaim.payout > 0) {\n        // Reduce funding by the payout amount\n        unchecked {\n            routing.funding -= bidClaim.payout;\n        }\n    }\n}\n```
MEDIUM severity: The protocol's combineShorts function is designed to merge multiple short positions into a single po. The protocol's combineShorts function is designed to merge multiple short positions into a single position, as long as the combined short remains above the primary collateral ratio. This process involves calculating the total debt and ercDebtSocialized for all positions, except for the first one, an...

Vulnerable code:
```\n{\n    uint88 currentShortCollateral = currentShort.collateral;\n    uint88 currentShortErcDebt = currentShort.ercDebt;\n    collateral += currentShortCollateral;\n    ercDebt += currentShortErcDebt;\n    yield += currentShortCollateral.mul(currentShort.zethYieldRate);\n    ercDebtSocialized += currentShortErcDebt.mul(currentShort.ercDebtRate);\n}\n```\n```\nMerge all short records into the short at position id[0]\nfirstShort.merge(ercDebt, ercDebtSocialized, collateral, yield, c.shortUpdatedAt)\n```\n```\nif (c.shortFlagExists) {\n    if (\n        firstShort.getCollateralRatioSpotPrice(\n            LibOracle.getSavedOrSpotOraclePrice(_asset)\n        ) < LibAsset.primaryLiquidationCR(_asset)\n    ) {\n        revert Errors.InsufficientCollateral();\n    }\n    // Resulting combined short has sufficient c-ratio to remove flag\n    firstShort.resetFlag();\n```
MEDIUM severity: The arithmetic calculations in the `addTidal`, `_updateUserTidal`, and `withdrawTidal` functions are. The arithmetic calculations in the `addTidal`, `_updateUserTidal`, and `withdrawTidal` functions are flawed, which can lead to incorrect distribution of Tidal tokens among share owners. Specifically, the functions use the `add` operator instead of `mul` in critical calculations, resulting in incorre...

Vulnerable code:
```\npoolInfo.accTidalPerShare = poolInfo.accTidalPerShare.add(\n    amount * SHARE_UNITS\n).div(poolInfo.totalShare);\n```\n```\npoolInfo.accTidalPerShare = poolInfo.accTidalPerShare.add(\n    amount * SHARE_UNITS).div(poolInfo.totalShare)\n```\n```\npoolInfo.accTidalPerShare += amount * SHARE_UNITS / poolInfo.totalShare;\n```\n```\nuint256 accAmount = poolInfo.accTidalPerShare.add(userInfo.share).div(SHARE_UNITS);\n```\n```\nuint256 accAmount = poolInfo.accTidalPerShare.mul(userInfo.share).div(SHARE_UNITS);\n```\n```\nuint256 accAmount = poolInfo.accTidalPerShare * userInfo.share / SHARE_UNITS;\n```\n```\nuint256 accAmount = poolInfo.accTidalPerShare.add(userInfo.share);\n```\n```\nuint256 accAmount = poolInfo.accTidalPerShare.mul(userInfo.share).div(SHARE_UNITS);\n```\n```\nuint256 accAmount = poolInfo.accTidalPerShare * userInfo.share / SHARE_UNITS;\n```
MEDIUM severity: The LootBox's `plunder` function allows anyone to call the function on behalf of a `tokenId` owner, . The LootBox's `plunder` function allows anyone to call the function on behalf of a `tokenId` owner, which can lead to unintended consequences. Specifically, if a `LootBox` receives an AirDrop but no `NFT` is issued to an owner (yet), a malicious actor can attempt to call `plunder` to burn the ETH an...

Vulnerable code:
```\nfunction plunder(\n    address erc721,\n    uint256 tokenId,\n    IERC20[] calldata erc20s,\n    LootBox.WithdrawERC721[] calldata erc721s,\n    LootBox.WithdrawERC1155[] calldata erc1155s\n) external {\n    address payable owner = payable(IERC721(erc721).ownerOf(tokenId));\n```\n```\n/**\n * @dev See {IERC721-ownerOf}.\n */\nfunction ownerOf(uint256 tokenId) public view override returns (address) {\n    return _tokenOwners[tokenId];\n}\n```\n```\nfunction plunder(\n  IERC20[] memory erc20,\n  WithdrawERC721[] memory erc721,\n  WithdrawERC1155[] memory erc1155,\n  address payable to\n) external {\n    _withdrawERC20(erc20, to);\n    _withdrawERC721(erc721, to);\n    _withdrawERC1155(erc1155, to);\n    transferEther(to, address(this).balance);\n}\n```
MEDIUM severity: The vulnerability allows an attacker to manipulate the withdrawal process in Ninja vaults, causing p. The vulnerability allows an attacker to manipulate the withdrawal process in Ninja vaults, causing partial withdrawals to fail. This occurs when the calculated relative share (r) of the user's tokens in the total balance exceeds the actual amount to be withdrawn. \n\nThe issue arises from the calcul...

Vulnerable code:
```\nuint256 userAmount = balanceOf(msg.sender);\n\nif (userAmount == 0) {\n    user.amount = 0;\n} else {\n    user.amount -= r;\n```\n```\nuint256 r = (balance() * _shares) / totalSupply();\n```\n```\nfunction deposit(uint256 _amount) public nonReentrant {\n   ...\n    user.amount += _amount;\n   ...\n}\n```
MEDIUM severity: The Curve protocol's admin functionality allows for the withdrawal of fees from the pool, which can . The Curve protocol's admin functionality allows for the withdrawal of fees from the pool, which can be exploited by an attacker to drain the pool's funds. Specifically, the `withdraw_admin_fees` function can be used to transfer funds to a malicious smart contract, enabling reentrancy attacks. This v...

Vulnerable code:
```\nCurve Pools\n\nCurve stETH/ETH: 0x06325440D014e39736583c165C2963BA99fAf14E\nCurve stETH/ETH ng: 0x21E27a5E5513D6e65C4f830167390997aA84843a\nCurve stETH/ETH concentrated: 0x828b154032950C8ff7CF8085D841723Db2696056\nCurve stETH/frxETH: 0x4d9f9D15101EEC665F77210cB999639f760F831E\nCurve rETH/ETH: 0x6c38cE8984a890F5e46e6dF6117C26b3F1EcfC9C\nCurve rETH/wstETH: 0x447Ddd4960d9fdBF6af9a790560d0AF76795CB08\nCurve rETH/frxETH: 0xbA6c373992AD8ec1f7520E5878E5540Eb36DeBf1\nCurve cbETH/ETH: 0x5b6C539b224014A09B3388e51CaAA8e354c959C8\nCurve cbETH/frxETH: 0x548E063CE6F3BaC31457E4f5b4e2345286274257\nCurve frxETH/ETH: 0xf43211935C781D5ca1a41d2041F397B8A7366C7A\nCurve swETH/frxETH: 0xe49AdDc2D1A131c6b8145F0EBa1C946B7198e0BA\n```\n```\n@external\ndef withdraw_admin_fees():\n    receiver: address = Factory(self.factory).get_fee_receiver(self)\n\n    amount: uint256 = self.admin_balances[0]\n    if amount!= 0:\n        raw_call(receiver, b"", value=amount)\n\n    amount = self.admin_balances[1]\n    if amount!= 0:\n        assert ERC20(self.coins[1]).transfer(receiver, amount, default_return_value=True)\n\n    self.admin_balances = [0] * N_COINS\n```\n```\nraw_call(receiver, "", value=amount)\n```
MEDIUM severity: The `_zapIn` function in the VaultZapper contract is vulnerable to unexpected reverts due to an inco. The `_zapIn` function in the VaultZapper contract is vulnerable to unexpected reverts due to an incorrect implementation of the `_transferTokenInAndApprove` function. This function is responsible for approving the `router` on behalf of the VaultZapper contract, but it checks the allowance from `msgS...

Vulnerable code:
```\nfunction _transferTokenInAndApprove(\n    address router,\n    IERC20 tokenIn,\n    uint256 amount\n) \n    internal\n{\n    tokenIn.safeTransferFrom(_msgSender(), address(this), amount);\n\n    if (tokenIn.allowance(address(this), router) < amount) {\n        tokenIn.forceApprove(router, amount);\n    }\n}\n```\n```\ndiff --git a/asynchronous-vault/test/Zapper/ZapperDeposit.t.sol b/asynchronous-vault/test/Zapper/ZapperDeposit.t.sol\nindex 9083127..ff11b56 100644\n--- a/asynchronous-vault/test/Zapper/ZapperDeposit.t.sol\n@@ -17,6 +17,25 @@ contract VaultZapperDeposit is OffChainCalls {\n         zapper = new VaultZapper();\n\n    function test_zapIn() public {\n        Swap memory params = \n            Swap(_router, _USDC, _WSTETH, 1500 * 1e6, 1, address(0), 20);\n        _setUpVaultAndZapper(_WSTETH);\n\n        IERC4626 vault = _vault;\n        bytes memory swapData = \n            _getSwapData(address(zapper), address(zapper), params);\n\n        _getTokenIn(params);\n\n        // If the msgSender() happend to approve the SwapRouter before, then the zap will always revert\n        IERC20(params.tokenIn).approve(address(params.router), params.amount);\n        zapper.zapAndDeposit(\n            params.tokenIn, vault, params.router, params.amount, swapData\n        );\n    }\n\n    function test_zapAndDepositUsdcWSTETH() public {\n        Swap memory usdcToWstEth =\n```\n```\nRan 1 test for test/Zapper/ZapperDeposit.t.sol:VaultZapperDeposit\n[FAIL. Reason: SwapFailed("\u{8}y\u{0}\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0(ERC20: transfer amount exceeds allowance\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0)"] test_zapIn() (gas: 4948462)\n\nSuite result: FAILED. 0 passed; 1 failed; 0 skipped; finished in 20.84s (18.74s CPU time)\n\nRan 1 test suite in 22.40s (20.84s CPU time): 0 tests passed, 1 failed, 0 skipped (1 total tests)\n\nFailing tests:\nEncountered 1 failing test in test/Zapper/ZapperDeposit.t.sol:VaultZapperDeposit\n[FAIL. Reason: SwapFailed("\u{8}y\u{0}\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0(ERC20: transfer amount exceeds allowance\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\n```