Maverick V2 burns Boosted Position shares to redeem underlying pool tokens

Minting, Balance Reads and Redemption

BP minting assigns newly added pool liquidity to a share recipient, while balance reads describe existing ownership. Redemption removes liquidity corresponding to shares surrendered. These functions serve different purposes even when an application presents them within one position screen. The liquidity manager offers combined functions for adding liquidity and minting BP shares. A separate lens exposes the underlying assets without performing a withdrawal.

The bare mint function assigns new liquidity the BP already possesses in its pool. It does not supply the deposit itself. Liquidity addition and this assignment belong in the same transaction, using a suitable combined function or multicall. Splitting them leaves an unassigned liquidity addition between transactions. Existing shares remain claims on their particular BP, with its defined liquidity distribution.

Wallet Shares and Reward Stakes

A wallet share balance covers BP tokens held at that address, rather than every related position it controls. An incentive stake holds BP shares in a reward vault and tracks stake ownership through a non-fungible token (NFT). The reward contract exposes stakeBalanceOf for that NFT identifier. This amount describes staked BP shares, not a direct balance of the pool assets.

Withdrawal preparation therefore depends on custody. The liquidity manager needs access to the caller’s BP balance for its wallet-based redemption helper. Shares held in a reward stake need the appropriate unstaking operation before they can fund that withdrawal. Authorized unstaking returns the staking token, which is the BP share token when that reward contract accepts BP shares. An integration can combine authorized unstaking and BP redemption in one transaction.

What Does the BP Lens Actually Measure?

The BP lens reports the position’s underlying assets and the amounts attributable to the specified user’s shares. The boostedPositionUserInformation function returns underlying token A and token B amounts for a specified user. These asset amounts describe ownership at the state the call reads, not a reserved withdrawal payment.

Underlying Position Data

Position Totals

The returned amountA and amountB fields describe the BP’s underlying token amounts. They do not represent all reserves in the wider pool or the full entitlement of each holder.

Bin Detail

The V2 factory permits one bin identifier for movement-mode BPs and at most 24 for static BPs. Bin identifiers, ticks and per-bin token amounts describe where the BP holds liquidity. A bin is a pool accounting unit associated with liquidity placement. A tick identifies a price interval. Adding every pool reserve would attribute other providers’ assets to this BP. The lens also supplies the pool and token identities needed to interpret its amounts.

Individual Ownership

The separate userAmountA and userAmountB outputs describe the specified user’s entitlement. Reward stakes require their own ownership accounting because a wallet-only share reading does not include shares held elsewhere. A later pool state can produce different asset amounts even when the wallet retains the same share balance.

Share Amounts and Token Units

The burn amount uses BP share units, while the returned amounts use the underlying asset units. A displayed share balance therefore cannot substitute directly for a requested amount of token A. ERC-20 balances use integer units. Token decimal metadata tells an application how to translate those integers into readable quantities. The BP token and each underlying token need their own interpretation. Both the holder’s share balance and the BP’s total share supply matter when translating proportional ownership into assets. Portfolio software must distinguish share quantities from asset amounts when displaying a withdrawal.

A partial redemption concerns the selected shares. The unredeemed balance continues to represent ownership of remaining BP liquidity, with token amounts determined by the position state.

Direct Burns and Protected Manager Withdrawals

A direct BP burn specifies a recipient and a share amount, while the manager helper adds output thresholds. The BP contract’s burn function redeems BP shares for underlying pool tokens sent to the specified recipient. Its return values identify token A and token B outputs. The bare function signature does not include minimum amounts for those outputs.

The removeLiquidityFromBoostedPositionToSender helper accepts separate minimum amounts for the underlying tokens and sends proceeds to the caller. It requires approval to access the caller’s BP balance. The helper reverts if its available balance of either underlying token falls below that token’s payout minimum. These thresholds concern withdrawal receipts, not the pool’s trading fee. A custom integration using a direct burn must provide any additional output protection its transaction needs. The chosen route also affects token handling. For WETH proceeds, the manager helper unwraps wrapped ether into ETH. A direct BP burn returns the pool tokens.

Transaction Bounds and Combined Calls

Output minimums concern assets returned, while price bounds concern the pool price at the check. These limits address different changes between transaction preparation and execution.

The checkSqrtPrice function reverts if the pool’s square root price falls outside the supplied bounds. The checkDeadline function reverts if execution occurs after the supplied deadline. These checks only constrain transactions which actually include them; their existence does not impose a universal deadline on BP ownership. A price-bound check describes the pool price, so it does not replace a check on the withdrawal’s token amounts.

A multicall combines supported contract calls within one transaction. The liquidity manager supports checks alongside liquidity functions in this composition. An application may present one confirmation while its transaction invokes several functions. Approval requirements remain specific to the share token, spender and method, even when an interface groups those functions together.

Why Can Redemption Amounts Change?

Redemption amounts change because pool trading and liquidity accounting alter the assets represented by BP shares. Swaps change token composition, while trading fees accumulate in pool bins. A position can therefore hold different amounts of the underlying assets from those originally deposited. Liquidity modes determine placement behavior, and a BP retains its selected distribution rules. A balance read reports the tokens represented at a particular state. Market prices determine their value in a chosen currency. Neither an unchanged share balance nor accrued trading fees establishes a profit over the deposit.

Minimum output settings govern acceptable token receipts. They do not preserve the original deposit composition or its market value when the position changes.

Gas Costs and Additional Contract Work

Withdrawal gas cost reflects executed contract work and network fee conditions. Gas measures computation; fees depend on gas consumed and the applicable fee model. Some networks include additional fee components. BP-share approval, reward unstaking and bin migration can add work when needed. Existing allowance and contract composition affect the required operations. Gas limits cap computation without predicting the actual charge. A transaction which executes and reverts can consume gas while rolling back withdrawal changes. A failed simulation alone does not establish an on-chain fee.

Merged Bin References in Movement Positions

Movement-mode BP liquidity can occupy a bin which the pool later merges into a parent bin. The dynamic BP contract checks bin status when exposing its bin identifiers and ticks. Its migrateBinLiquidityToRoot operation moves the underlying liquidity accounting to the active parent. The liquidity manager also exposes a BP migration helper. This migration repairs merged bin accounting without restoring the original token composition or correcting missing authorization. Calling migrateBinLiquidityToRoot on a static BP performs no operation. A movement-mode BP needs this migration only when its underlying bin has merged.

---

A Withdrawal Read Blocked by a Merged Bin

A merged-bin lookup error can interrupt preparation for redeeming shares held directly in a wallet. Consider a movement-mode BP whose bin query reports BoostedPositionMovementBinNotMigrated. The desired share amount remains the withdrawal input. Migration repairs the affected bin reference; it does not establish a fixed token receipt or gas cost.

• Confirm the queried BP and wallet share balance belong to the selected network and position.
• Use BP migration when the reported condition identifies merged movement-mode liquidity; static BPs do not need this repair.
• After migration completes, refresh underlying amounts against the updated state.
• For the manager withdrawal, confirm sufficient BP-share allowance and acceptable minimum amounts for both pool tokens. Estimate gas for the selected withdrawal route once its inputs and authorization are ready.
• After successful redemption, reconcile the selected share reduction with the recipient’s token receipts, including any wrapped-token handling.

A successful migration permits a fresh position reading, but it does not complete the withdrawal. If the subsequent error concerns allowance or output protection, that condition requires its own correction.

View full-size image