Velodrome V2 zaps for liquidity from one token
Last updated ·
Velodrome V2 zaps can fund an existing liquidity pool from one compatible token through a combined swap and deposit transaction. The router obtains the pool assets, adds them in the required proportions and mints liquidity provider tokens. A viable route for each required conversion and sufficient destination liquidity determine whether this works. Standard ERC-20 inputs must behave as expected during transfers. Token approval may require an earlier transaction, while optional staking can belong to the zap itself. Starting with one token still creates exposure to both pool assets. The deposited share tracks the pool’s changing balances after the conversion.
Should I use a V2 zap or deposit both pool tokens?
A paired deposit suits a wallet already holding both destination assets in suitable amounts. Missing either asset makes that direct deposit incomplete, while a zap can obtain the missing token through conversion. The zap also supports a different compatible starting token with routes into both pool assets.
| Deposit option | Starting assets | Conversion inside deposit | Where execution can fail |
|---|---|---|---|
| Zap from a pool token | One destination token | Swaps part for the other pool token | Required route fails or output misses its minimum |
| Zap from another token | One compatible ERC-20 outside the pair | Separate allocations acquire both pool tokens | Either conversion can miss its minimum |
| Paired V2 deposit | Both pool tokens | No swap within addLiquidity | Insufficient balance, allowance or deposit amounts |
Keeping already balanced assets avoids conversion swaps. Funding from a different token introduces both swap legs and their execution constraints. A successful unstaked deposit increases the recipient’s LP-token balance. A zap with staking credits the recipient at the pool’s gauge.
Input amounts and pool shares
The starting token and the resulting LP token represent different assets, even when the starting token belongs to the destination pool.
The input allocation
The router accepts one input-token address. Its amountInA and amountInB parameters allocate that same token toward the pool’s respective assets. They are not amounts of two different wallet tokens. Both allocations together determine how much input the ERC-20 branch transfers from the caller. Treating a destination-token quote as another input balance would misinterpret these parameters.
LP tokens
LP means liquidity provider. A V2 LP token represents a proportional share of a specific pool. Its balance measures pool ownership using LP-token units, not units of the deposit token. The quantity minted depends on deposited amounts relative to existing reserves and LP supply. Adding liquidity also changes those reserves, so an LP-token count alone does not identify the original input quantity.
Compatible tokens and funded V2 pools
The V2 zap accepts standard ERC-20 inputs for funded stable or volatile destination pools, with routes for required conversions.
Transfer behavior
A fee-on-transfer token deducts value during a transfer. The zap expects ordinary transfers, so that behavior falls outside its documented token support. A router’s separate swap method can have different compatibility rules. Support in one swap method does not establish support in the zap.
Destination reserves
The V2 zap requires an existing pool with both reserves above 1 000 base units of their respective tokens; otherwise, it reverts. Pool creation alone does not satisfy this condition if usable reserves remain absent. The destination’s token addresses, stable-or-volatile flag and factory identify the actual pool. The factory must also pass the router’s registry check. Slipstream concentrated-liquidity positions use a separate position-manager system. The V2 zap mints fungible LP tokens; other deposit methods have their own prerequisites.
How the router balances the deposit
Swap routes specify how the input reaches each required pool asset. The V2 call receives those routes as parameters, without discovering an optimal path or calculating the input split automatically. Each conversion can traverse intermediate pools, so the full path affects the assets available for the deposit.
When the input already matches one destination asset, the router skips that asset’s conversion. The remaining allocation funds the other asset’s route. With an input outside the pair, it executes the route to the first asset before the second. An earlier swap can change reserves used by a later calculation.
After conversion, the router calculates deposit amounts against the destination’s reserve ratio. It uses the available asset balances while respecting deposit minimums, and this matching step can leave an excess of one asset. The limiting balance is the one supporting less liquidity at the destination’s reserve ratio.
The pool then mints LP tokens from the amounts it actually receives. Conversion quantities and minted liquidity therefore describe different parts of the operation. A quoted token amount cannot be read as a quoted LP-token balance. Small deposits can revert when integer rounding leaves the LP-token quantity below the pool’s minimum mint amount.
Residual balances of the input token and destination assets return to the caller after a successful zap. These refunds can contain more than the starting token. They are balances unused by the deposit, so a refund is compatible with successful liquidity creation.
Minimum amounts across swaps and deposits
Separate minimums govern conversion output and liquidity addition, because a satisfactory swap does not by itself guarantee acceptable deposited amounts. The amountOutMinA and amountOutMinB fields constrain conversion outputs in their destination-token units. The amountAMin and amountBMin fields constrain the respective token amounts entering the pool. Those fields are token quantities, not a minimum LP-token count.
The generateZapInParams helper derives quote values from the supplied routes, allocations and pool state. Its return values do not automatically include a chosen slippage allowance. Integrations must translate an acceptable tolerance into the minimums used by the transaction. A lower minimum permits execution over a wider range of prices. Setting it carelessly can admit an unfavorable conversion; an overly restrictive bound can cause a revert when reserves move.
A reverted zap rolls back its swaps and deposit together. The sender still pays for execution already consumed.
Does a one-transaction zap include token approval?
An ERC-20 zap needs sufficient allowance beforehand; the basic V2 zapIn call does not approve the input token for the wallet. Approval authorizes the router to transfer the chosen token. The zap performs the subsequent conversions and liquidity addition within its own transaction. If an adequate allowance already exists, another approval may be unnecessary. The token contract, spender and authorized amount determine that permission. A successful approval has not created a pool position.
Swap fees and execution costs
Conversion swaps incur the fees of pools along their routes, while blockchain execution consumes gas. Route length, input size and available reserves affect execution costs or conversion losses. Price impact is the effect a swap has on its execution price; slippage tolerance sets the acceptable minimum outcome. A combined transaction does not establish that the overall cost is lower than a paired deposit from assets already held.
Wallet LP tokens and gauge deposits
Optional staking changes where the new LP tokens reside. Without staking, the pool mints tokens directly to the designated recipient. With staking, the router mints them to itself and deposits them into the corresponding gauge for that recipient. A gauge holds LP tokens and records the account’s staked balance, which explains why a staked deposit need not increase the wallet’s transferable LP-token balance.
Auto-staking requires a working gauge that accepts deposits. The gauge rejects deposits when the protocol marks it as inactive. Failure in this branch reverts the combined zap; it does not silently fall back to leaving LP tokens in the wallet. Pool availability and gauge eligibility therefore remain separate conditions. A funded pool can support liquidity addition even when staking is unavailable.
Staked liquidity can earn VELO emissions when rewards accrue to that gauge. Reward amounts depend on the gauge’s funding and the recipient’s share over time. Stakers give up trading fees accruing on those LP tokens; the gauge forwards those fees to pool voters.
What to know about Velodrome
Can native ETH fund a V2 zap?
The V2 router has a native ETH input branch that wraps ETH for its internal operations. The transaction must identify the native input and send value equal to the combined input allocations. That branch differs from transferring an approved ERC-20 token. Sending native value alongside an ordinary ERC-20 input causes the basic zap call to revert.
Do I need a VELO voting lock to use a V2 zap?
A V2 zap does not require a VELO voting lock. Its liquidity-deposit operation uses the input asset, destination pool and conversion routes. Optional staking deposits the minted LP tokens into the pool’s gauge. A voting lock is a separate position used for governance and reward allocation; the zap does not create one or require one as payment.
Which units do zap input amounts and minimums use?
Zap amounts use the base units of the token each field describes. Both input allocations use input-token units. Swap-output minimums and deposit minimums use their respective destination-token units. Decimal precision can differ between tokens, so equal raw integers need not represent equal displayed quantities. An integration must preserve each field’s token identity when converting amounts for display.
Can a zap send its LP position to another address?
The V2 zap’s to parameter selects the recipient of newly minted liquidity or its gauge credit. The caller funds the zap and, for an ERC-20 input, authorizes the router to transfer that token. Residual input and destination-token balances return to that caller, even when the position recipient differs. Choosing a recipient therefore does not redirect all assets the operation may return.
Does the basic V2 zap include an expiry parameter?
The basic V2 zapIn method has no deadline argument. Its swap and deposit minimums govern acceptable amounts when execution occurs. A deadline accepted by another router method does not automatically apply to this call. A quote describes the pool state used for that calculation; it does not reserve those prices while a transaction waits for inclusion.
Can a V2 liquidity position later be converted into one token?
The V2 router’s zapOut method can remove liquidity and convert the pool assets into a selected output token through valid routes. It requires caller-held LP tokens and sufficient LP-token allowance to the router, so staked tokens must first become available outside the gauge. Withdrawal and conversion minimums still apply. The output amount follows the pool balances and conversion prices at exit. It can differ from the original deposit.