Beefy vaults can depend on strategy liquidity to complete withdrawals

Beefy vaults redeem your shares using assets held by the vault and its strategy. When the vault’s idle assets fall short, withdrawals also depend on the strategy releasing funds. A lending position may need available borrowing-market liquidity, while an LP withdrawal can return pool tokens that require another operation to reach your preferred asset.

A vault balance represents your share of its assets, while withdrawal execution depends on available vault assets and, when needed, the strategy’s ability to release more.

Direct redemption and a blocked conversion

A standard Beefy vault accepts a deposit asset, directs it into an automated yield strategy, and issues receipt tokens called mooTokens representing your shares. Redeeming those shares returns the deposit asset, subject to execution conditions and applicable fees. Choosing a different output adds conversion requirements. These operations can fail for different reasons, so identifying the requested output helps locate the restriction.

Redemption into the vault asset

The vault uses assets already in its contract and requests additional assets from its strategy when needed. For a farm strategy, this can involve unstaking deposited liquidity pool tokens. The withdrawal depends on that external operation succeeding. Holding a receipt token establishes a share of the position; it doesn’t establish that every underlying asset is immediately available.

Conversion into another token

Where supported, Zap combines redemption with operations that produce a selected output token. A missing conversion route can leave direct redemption available. That fallback returns the vault asset, which may still be an LP token. It doesn’t bypass a strategy that cannot release its position.

Why can lending liquidity prevent a withdrawal?

A lending strategy can struggle to release deposits when borrowers have drawn down the underlying market’s available assets. This becomes especially relevant when the strategy repeatedly supplies and borrows the same asset. Closing that position requires reducing debt while releasing collateral, with each operation constrained by the lending protocol.

Insufficient liquidity in the underlying lending market can prevent a folding strategy from unwinding for a withdrawal. Repayments or new supply can restore liquidity, but the withdrawal has no reliable completion deadline while that constraint remains. A recorded balance alone doesn’t show whether enough assets are available for the requested exit.

View full-size image

LP redemption and liquidity removal

An LP vault can complete its withdrawal by returning liquidity pool tokens, leaving the underlying pool position intact. Removing liquidity is a further operation that exchanges those tokens for their underlying assets. Swapping those assets into one preferred token introduces another liquidity dependency. Poor swap execution doesn’t necessarily mean the vault itself cannot redeem shares. Conversely, a functioning swap route cannot recover LP tokens from a farm that refuses to release them. The distinction matters because the available recovery action follows the operation that failed.

Compounding changes holdings without reserving an exit balance

A farming strategy harvests rewards, converts them into the relevant deposit assets, and reinvests the proceeds. It doesn’t create a dedicated withdrawal reserve for each depositor. Reward-token liquidity also affects the conversion that compounding requires. A harvest problem and a withdrawal problem therefore need separate assessment: a failed reward swap doesn’t, by itself, establish that the deposited position is inaccessible. The strategy’s withdrawal logic determines whether an exit requires the failing operation.

Does a paused strategy always block withdrawals?

A paused strategy doesn’t always block withdrawals; the affected functions and location of the assets determine whether redemption remains possible.

Beefy’s emergency controls include a manager-authorized operation that pauses a strategy and attempts to retrieve its farm position. A successful retrieval can leave the deposit assets in the strategy for user withdrawals. That operation still relies on the underlying protocol releasing funds. A pause label alone therefore establishes neither successful recovery nor permanent loss. The relevant distinction is whether the assets have returned and whether the withdrawal function remains executable for that implementation.

The accounting behind the withdrawal amount

The standard mooToken vault model calculates a proportional asset claim from the shares being redeemed and the vault’s accounted holdings. Conceptually, the gross claim equals redeemed shares divided by total shares, multiplied by accounted assets. This relationship explains the calculation before applicable deductions and execution effects; it isn’t a promise of a fixed token amount.

The contract term want identifies the deposit asset. The vault’s balance() includes assets reported by the strategy, while available() measures assets held directly in the vault contract. Those figures answer different questions. A low idle balance can be normal when assets are deployed, and a high total balance doesn’t prove immediate withdrawability.

View full-size image

In the standard BeefyVaultV7 implementation, withdrawal uses idle vault assets first and calls the strategy only for any shortfall. If that call returns less than requested without reverting, the vault adjusts the payout downward. It doesn’t automatically preserve the difference as unredeemed shares. That behavior makes the actual asset transfer important when assessing a completed withdrawal.

Failed execution and successful redemption

A withdrawal’s transaction status distinguishes an unsuccessful call from a completed transfer, but it doesn’t explain every difference in the received amount. The error and token movements provide the next level of detail.

A reverted withdrawal

A transaction that reverts rolls back its state changes, including any share burn within that transaction. Network execution fees can still apply. Repeating the same call doesn’t restore lending liquidity or repair an external contract failure. A pending transaction is different: it hasn’t yet established either success or failure. A wallet’s confirmation prompt also doesn’t prove that the blockchain accepted a withdrawal.

A completed withdrawal

A successful receipt establishes that the transaction executed. The redeemed share amount and transferred asset amount establish what it delivered. Compare quantities in matching units: mooTokens, LP tokens, and the pool’s underlying tokens represent different things. A direct LP withdrawal can be complete even though the wallet still holds a pool position. A displayed value estimate isn’t a substitute for identifying the token actually received.

Exit costs and the limit of recovery controls

The cost of leaving depends on the operations required to release and convert the position. A simple redemption and an exit that unwinds borrowing or removes liquidity can require different amounts of gas. Withdrawal fees, where applicable, also affect the received amount. These costs deserve attention before adding a conversion, but paying more gas cannot supply missing assets to a lending market. Emergency retrieval and strategy replacement likewise depend on executable underlying contracts. Contract failures or asset losses can prevent full recovery even when the vault still records a position.

View full-size image