Stargatefinance liquidity pools return deposits through local or cross-chain LP redemption

Updated 14 October 2026

Stargatefinance liquidity pools issue liquidity-provider (LP) tokens for deposits of each pool’s asset. V2 local redemption burns those tokens and returns the underlying asset. Same-chain withdrawals require sufficient LP tokens and local unallocated credits. Cross-chain redemption uses a separate pathway with its own credits, fees and delivery requirements. Staked LP tokens must first return from the farm before the wallet can redeem them.

Pool shares, token backing and withdrawal capacity describe different balances. A deposit establishes a liquidity-provider position; cross-chain activity later changes available liquidity. V2 local redemption and cross-chain redemption use different credit checks, even when they draw on the same pool.

The short version: A pool’s total asset balance can exceed its local withdrawal capacity because cross-chain pathways already hold allocated credits.

Local redemption and a credit-limited request

A local withdrawal starts with wallet-held LP tokens and an amount that fits the pool’s current redemption limit. The intended outcome is receipt of the underlying asset on the pool’s own chain. Before submitting that request, establish the relevant conditions:

Match the underlying asset and LP token to the selected pool contract and confirm that its chain remains supported.
Confirm that the redeeming wallet holds the LP tokens outside any farm.
Read redeemable(wallet) and keep the request within that current limit.
Check that the pool is unpaused and the recipient can receive its asset.
Retain the chain’s native coin to pay transaction gas.

The wallet then submits redeem() with the withdrawal amount and recipient. Successful execution burns the processed LP quantity and returns the corresponding underlying asset. Signing the transaction only authorizes it; the transaction must execute successfully before those balance changes occur.

Compare the expected reduction in LP tokens with the recorded burn and the successful transaction receipt. The Redeemed event identifies the payer, recipient and processed amount. The recipient’s underlying-asset balance supplies a separate check of receipt. For native-coin withdrawals, transaction gas also affects the payer’s final balance.

If the local cap covers only part of the intended withdrawal, a smaller request can fit that cap. Waiting requires a later credit reading; elapsed time alone does not establish readiness. The reading reserves no credits, so other activity can lower capacity before execution. A stale limit can therefore make an otherwise valid request exceed available credits and revert on execution.

Pool identity and LP token custody

Each native pool has its own LP token, which represents liquidity deposited into that specific contract. The lpToken() getter identifies it. V2 deposits of the selected pool’s asset increase its pool balance, local credits and recorded total value locked. The contract mints LP tokens 1:1 with the processed deposit amount to the chosen receiver. Pool identity includes the asset, chain and contract version. An LP balance from another deployment does not establish a redeemable position in the selected pool, even when the underlying tokens share a ticker. Farm staking changes where the LP tokens reside. If a farm holds the position, unstaking must return its LP tokens before the wallet redeems the underlying asset.

Unstaking and pool redemption affect different holdings. Staking LP tokens in an incentivized farm can earn that program’s rewards; the LP balance does not establish a fixed annual return or identify the reward token.

Why can a funded pool limit local withdrawals?

A funded pool can limit local withdrawals because some of its credits already support remote cross-chain pathways. Credits track token inflows and outflows. Each pool’s asset balance must cover its local unallocated credits plus the credits allocated to remote pathways. Local redemption uses the unallocated portion of that accounting capacity.

The pool’s poolBalance() reading describes its accounted underlying liquidity. Its tvl() reading tracks the quantity represented by issued LP tokens. These readings describe token quantities, not dollar valuations. Neither assigns the full pooled balance to a particular wallet’s immediate local withdrawal.

For an individual account, redeemable() returns the smaller of its LP balance and the local credit cap, expressed in local token units. That relationship explains why a wallet can hold more LP tokens than it can currently redeem locally. The remaining LP tokens continue to represent the holder’s pool position.

Passing the zero address to redeemable() returns the aggregate local cap without a wallet-balance limit. That result does not establish that any particular account owns enough LP tokens. The account-specific reading also omits other execution checks, including pause status and whether the recipient can accept the asset.

Dynamic credits and withdrawal availability

Credit rebalancing changes withdrawal availability without changing the LP token quantity that a wallet owns. The AI Planning Module reallocates V2 credits among pathways as demand changes. Protocol transfers also affect credit availability. A depleted pathway can remain unavailable while pool backing still exists. Dynamic planning establishes no fixed waiting period for a particular withdrawal. A later request still needs sufficient credits at execution.

Cross-chain redemption through redeemSend

A remote withdrawal can combine redemption with transfer initiation instead of first returning the underlying asset to the source wallet. Stargate V2’s redeemSend() combines LP redemption and transfer initiation in one source-chain call.

Cross-chain redemption checks the selected destination pathway’s credit setting. Native-pool destinations need sufficient finite credits for the output. A path configured for a Hydra OFT destination uses unlimited credits, and delivery mints the backed representation there. The operation also adjusts local credits for any asset fee or reward. A fee can require local credit even when the destination pathway has capacity, so remote redemption remains subject to its own accounting constraints. The caller also sets a minimum output. The source call reverts if fee-adjusted output is zero or below that minimum in shared units.

The redeemSend() function accepts Taxi mode and rejects Bus mode. Taxi supports individual transfers and destination composability. Stargate set October 1, 2026 for its switch to Taxi-only delivery. Historical descriptions of Bus batching do not provide a Bus option for this redemption function.

Source-chain execution burns the LP tokens and initiates the message; destination delivery follows through LayerZero V2. A successful source transaction receipt establishes initiation, not possession of the destination asset. Chain finality, message verification and execution services affect delivery time. A receiving native pool must also remain on a supported pathway.

What costs affect a cross-chain pool withdrawal?

A cross-chain pool withdrawal combines route pricing with a LayerZero messaging fee and the source transaction’s gas cost. The quoteRedeemSend() function quotes the messaging component. Asset fee or reward calculations describe a separate component, so a messaging quote alone does not explain the difference between redeemed LP quantity and destination output.

A same-chain redemption does not initiate a LayerZero message. Its gas cost still affects the payer’s native-coin balance. App-specific OFT transfer pricing applies to its stated interface and transfer category; it does not establish a universal percentage for local LP redemption. Keep an asset deduction separate from a gas payment when comparing withdrawal proceeds.

Native pool assets and Hydra backing

Native pool assets include supported USDC, USDT and ETH deployments. Here, a native asset can be an ERC20 token or a chain’s coin. The selected pool determines which asset local redemption returns.

Hydra extends pool liquidity through backed Omnichain Fungible Tokens (OFTs). Those representations and LP tokens have different claims: a Hydra token redeems its backing, while an LP token represents deposited pool liquidity. Outstanding representations help explain why pool assets support obligations beyond immediate LP withdrawals. Their existence alone does not establish the local withdrawal cap. Stargate’s native liquidity contracts operate on EVM chains; a broader frontend route does not establish a native pool on every destination.

Pool support deadlines in 2026

October 23, 2026 is the scheduled Stargate V2 support cutoff for Metis, including its USDT, ETH and Metis pools. The associated offchain-service deadline is October 30, 2026. Affected LPs should withdraw before the October 23 product cutoff; waiting for the later service deadline risks losing access to funds. These announced dates remain subject to change.

The scheduled V2 support cutoff for Aurora, LightLink and Gnosis was September 23, 2026, preceding their September 30 offchain-service deadline. Affected LP positions included Aurora’s USDC pool, LightLink’s ETH pool and Gnosis’s USDC and ETH pools. A remaining LP balance does not establish that a supported exit remains available after a chain’s retirement.

Gravity, Camp and GOAT also have a scheduled V2 cutoff of October 23, 2026. Affected Hydra assets include USDC.e and WETH on all three chains, plus Hydra USDT on Gravity and GOAT. Those Hydra holdings need redemption to pools on chains with continuing support before the cutoff to avoid losing access. A pool-backed token’s accounting support and a functioning redemption pathway remain separate requirements.

Redemption precision and residual LP units

V2 redemption converts requested amounts from local token precision into the protocol’s shared precision before processing the withdrawal. That conversion truncates units that shared precision cannot represent. Local redemption burns the processed LP amount and returns the corresponding quantity of the underlying asset. The submitted amount and processed amount can therefore differ by a small remainder.

Open full-size image

The deployment’s token decimals and sharedDecimals determine that conversion. Compare the processed quantity with the actual burn and redemption event, using the asset’s correct units. Any LP units that the redemption does not burn remain in the holder’s balance; rounding does not convert them into an additional underlying-asset payment.

Before you start with Stargatefinance liquidity pools

Can a local pool withdrawal pay a different recipient address?

Direct V2 local redemption can return the underlying asset to a recipient other than the LP holder. The caller supplies the recipient address to redeem(), while the pool burns LP tokens from the caller’s account. Naming a recipient does not give that address authority over another account’s LP tokens. The recipient must be able to receive the selected asset.

Does direct V2 redemption require approval to burn LP tokens?

The V2 pool can burn the caller’s LP tokens during direct redemption without a separate LP allowance. Its LP token contract restricts that burn authority to the associated pool. This differs from approving an underlying ERC20 token for a deposit. A farm or another integration can have additional authorization requirements for its own token movements.

Why might a native-coin withdrawal fail for a smart contract recipient?

A native-coin pool withdrawal can revert when the recipient contract rejects the coin transfer. The native pool’s local redemption uses a checked native transfer and raises Stargate_OutflowFailed if delivery fails. Receiving an ERC20 token does not establish that the same contract accepts native coin.

Is withdrawing a V1 position the same operation as redeeming V2 LP tokens?

V1 and V2 pool withdrawals use different contract operations. V1’s redeemLocal design uses cross-chain messages, while V2’s local redeem operation uses the local pool’s credits. The manual migration path removes V1 liquidity before adding it to a V2 pool. A V1 LP token does not become a V2 LP token when an interface changes its version filter.

What happens to the LP tokens if a local redemption reverts?

A reverted local redemption leaves its LP burn and underlying-asset transfer unapplied. The attempted transaction does not become a completed withdrawal merely because the wallet signed it or the network assigned a transaction hash. An insufficient-credit failure concerns capacity; a recipient-transfer failure concerns delivery compatibility. A later credit increase can allow the same request to succeed; retrying alone does not make an incompatible recipient accept the asset.