Zap In
Construct a Zap In Transaction (yEarn Vaults V1 or V2)

Video Summary

Ensure you have read the Zapper API section for a brief overview of the API types and to acquire an API key. This guide uses the Zapper Transactions API. While this guide shows Zapping In for a Yearn vault, the process for Zapping In for other sources is very similar.
You can learn what a Zap is at the resource here.

Yearn Zap In Overview

The yVault Zap In adds liquidity to V1 and V2 Vaults. The latest currently deployed yVault Zap In can be found here. The Zap accepts ETH or any Arbitrary ERC20 token and converts it into the appropriate input type for the Vault. Any token swaps that are required are done so in a manner such that the output is maximized with as little slippage as possible. This is done via intelligent pathing to ensure that the exchange is routed optimally, leveraging PMMs if necessary. In addition, if the input type for the vault is an LP token (e.g. a Curve LP), the Zap will also acquire the required LPs via an underlying Zap before adding liquidity into the Vault and returning the proceeds to the sender.

Check Zap Allowance

Before Zapping In, check that the Zap contract has approval to spend the tokens you are sending. If ETH is being Zapped in, this step can be skipped as it does not require approval to transfer to the Zap contract.
get
https://api.zapper.fi/
v1/zap-in/yearn/approval-state
Get Approval State

Set Allowance if Needed

If isApprove is false and the sellToken is not ETH, this endpoint can be used to assemble an approval transaction. This transaction will grant the yVault Zap In contract (i.e. the spenderAddress from the previous step) an allowance, enabling it to transfer tokens from the ownerAddress to the Zap contract. This step is required in order for the Zap to proceed if it does not yet have an allowance.
get
https://api.zapper.fi/
v1/zap-in/yearn/approval-transaction
Get Approval Transaction

Zap In

After the approval step has been completed (or if the Zap has already been granted an allowance or ETH is the input). This endpoint can be used to create a transaction for the Zap In. This is the value transaction, which if signed and broadcasted, will transfer funds from the ownerAddress to the Zap contract (the to property in the response). Subsequently, the proceeds from the Zap In will be sent to the ownerAddress (e.g Yearn vault tokens). If the transaction reverts, the sender will pay for the gas consumed, however, the tokens will not be deducted from the ownerAddress.
The slippagePercentage encapsulates the entire atomic transaction and will cause the transaction to revert if it is exceeded. For example, if the slippagePercentage is 3% (0.03) and the Zap requires multiple swaps (exchanges), the transaction will revert if cumulative slippage exceeds 3%. This represents the maximum acceptable slippage and does not imply that the Zap will actually experience this much slippage upon execution.
The poolAddress represents the yVault to enter. This address can be obtained from Zapper's Data API as shown here
The gasPrice recommended by Zapper is returned from Zapper's Gas Price API. Alternatively, you can choose to use any gas price you'd like. The gasPrice should be in WEI
get
https://api.zapper.fi/
v1/zap-in/yearn/transaction
Get Zap In Transaction

Send It!

With Web3/Ethers

The transaction objects returned from the Get Zap In Transaction and Get Approval Transaction endpoints are ready to be consumed by web3 or ethers. After initializing these libraries with a provider capable of signing the transaction (e.g. Metamask), a user can sign and broadcast the transaction in the same familiar way that they interact with any other DeFi protocol. For more details see the web3 documentation on sending transactions.

With smart contracts

To consume the transaction object in your smart contract, it must have a balance of the sellTokenAddress representing the sellAmount. Therefore, because your smart contract holds this balance, it is also the ownerAddress. When assembling the transaction in the Get Zap In Transaction request, care should be taken to assemble it with these parameters in mind.
A function in a smart contract that consumes a Zap In transaction might resemble this:
1
// Zaps into a Yearn yVault with ETH or ERC20 Tokens using a Zapper Transaction Object
2
function ZapIn(
3
// The `sellTokenAddress` field from the API response.
4
address sellToken,
5
// The `buyTokenAddress` field from the API response.
6
address buyToken,
7
// The `to` field from the API response.
8
address payable ZapContract,
9
// The `data` field from the API response.
10
bytes calldata zapCallData
11
)
12
external
13
onlyOwner
14
payable // Must attach ETH equal to the `value` field from the API response.
15
returns (uint256 yVaultTokensRec)
16
{
17
// ...
18
19
// Give the Zap an infinite allowance to spend this contract's `sellToken`.
20
// Note that for some tokens (e.g., USDT, KNC), you must first reset any existing
21
// allowance to 0 before being able to update it.
22
require(sellToken.approve(ZapContract, uint256(-1)));
23
// Check this contract's initial balance
24
uint256 initialBalance = IERC20(buyToken).balanceOf(address(this));
25
// Call the encoded Zap function call on the contract at `ZapContract`,
26
// passing along any ETH attached to this function call for the Zap.
27
// NOTE: You should restrict calls to trusted ZapContracts and never tokens!
28
(bool success,) = ZapContract.call{value: msg.value}(zapCallData);
29
require(success, 'Zap In Failed');
30
yVaultTokensRec = IERC20(buyToken).balanceOf(address(this)).sub(initialBalance);
31
// ...
32
}
Copied!
Last modified 3mo ago