Gamma vault withdrawals redeem shares while limit orders settle through cancellation or claims

Gamma deposits and orders create different positions, so their completion checks differ. A liquidity vault deposit produces shares that represent participation in its assets. A limit order creates a position awaiting execution or cancellation. Leaving a vault means redeeming shares; collecting an executed order means claiming its proceeds. Track the transaction, the position balance, and the recipient's assets together to distinguish a completed operation from an approval, an open position, or an uncollected balance.

Vault Shares and Order Positions

Vault deposits establish continuing liquidity exposure, while limit orders commit assets to a price-dependent conversion. Their exit instructions belong to different contracts. Hypervisor vaults use share redemption; the LimitOrderHook system tracks orders by pool and position key. An order key identifies a position within a pool; each user's liquidity and entitlement are tracked separately. These records provide the starting point for reconciliation, because a transaction involving one product does not close a position in the other.

Deposit Ratios and Token Authorization

The Hypervisor deposit workflow uses UniProxy to determine acceptable asset amounts and submit the deposit through UniProxy.

Asset Amounts Before Submission

UniProxy's deposit calculation takes the vault, the supplied token, and its quantity. It returns a permitted interval for the other token. That interval describes acceptable inputs for the selected vault. An amount outside it requires a fresh calculation or adjusted inputs before another submission.

Approval Before Asset Transfer

An ERC-20 approval establishes how much a particular spender may transfer. It does not itself deposit assets or create vault shares. The allowance belongs to a specific token, owner, and spender, so permission granted to another contract does not satisfy the intended deposit.

Deposit confirmation therefore requires evidence of the deposit operation itself. Match its recipient and minted shares with the intended vault. A successful approval confirms authorization; use the deposit receipt and the recipient's share records to establish whether the deposit also completed.

Parameters That Determine Acceptance

Deposit, withdrawal, order creation, and claim requests have different acceptance conditions, as shown below.

The named implementations define these conditions; another contract version requires its own matching interface. A rejected pool or incompatible hook cannot become eligible through a larger transaction fee. The compatible deployment and its accepted pool configuration must match before another attempt.

Execution States Behind the Price Chart

The limit-order system processes eligible positions through swap callbacks, with keeper handling for positions beyond the configured execution limit.

A displayed price therefore does not establish that a particular order has completed. The relevant records include the pool, position key, active state, and keeper-waiting state. The execution event identifies the position that completed execution. A keeper-waiting position still has an outstanding processing step; that state alone does not prove that proceeds reached the wallet.

Scale orders create multiple positions across a price range. Reconciliation must account for their individual states, since one executed position does not establish completion of the entire set. The number of positions that execute during one callback is configurable, so it should not become a fixed waiting-time promise.

Why Does a Confirmed Transaction Leave the Position Open?

A confirmed transaction can complete an intermediate operation, such as approval or order creation, while the underlying position remains open.

The transaction's called function determines what it attempted. Its receipt and resulting contract state establish what happened. For an order, creation, execution, and collection have different meanings. The manager exposes separate events for these operations, including a claim event with principal and fee fields. Match the event to the same pool and position key; for creation, cancellation, and claims, also match the user address.

A transaction hash alone only identifies a submitted transaction. Network inclusion and execution still matter. When an application display disagrees with the transaction record, reconcile the recorded operation before submitting another one. Repeating a successful operation can create additional activity instead of resolving the display discrepancy.

Vault Redemption and Asset Reconciliation

The Hypervisor withdrawal path exchanges the submitted shares for underlying pool assets and sends those assets to the designated recipient.

Share Removal

Hypervisor v1.3 burns the shares submitted in a successful withdrawal. Its withdrawal event records the recipient, share quantity, and underlying token amounts. A remaining share balance can represent a partial exit.

Underlying Assets

The redemption includes the withdrawing share of deployed liquidity and unused vault balances. Its asset quantities reflect the position at withdrawal. They need not reproduce the original deposit quantities.

Reconciliation should use the actual recipient, rather than assuming every asset returns to the submitting address. Compare each underlying token separately. A combined value display can obscure whether the expected assets arrived, particularly when the wallet presents a different valuation or token display precision.

Order Cancellation and Proceeds Claims

The LimitOrderManager cancellation path removes the user's liquidity from an active position and settles the resulting entitlement through its claim logic.

Execution proceeds become collectible after execution establishes the relevant claim state. Cancellation provides a separate exit for an active position. The implementation can also direct a cancellation request into claim handling when the position is already claimable. The position's state when the cancellation transaction runs determines whether it removes liquidity or claims an existing entitlement, even if the application displayed an earlier status.

View full-size image

The claim operation clears the user's position record and settles its principal and fees. Collection evidence therefore combines the claim record with received assets. An order marked executed with an outstanding user entitlement has reached execution, but collection remains unfinished.

Outstanding Rewards and the Next Transaction

Liquidity incentives can add a separate balance to reconcile alongside the vault position. Gammachef accepts staked LP tokens and supports reward claims, while Merkl can distribute incentives without LP-token staking. The applicable reward arrangement determines which balances belong in the exit record.

The next action follows the remaining position: unredeemed shares require a vault exit, an active order requires continued exposure or cancellation, and a collectible entitlement requires settlement. If those records are already cleared and the recipient holds the expected assets, a stale application display does not justify repeating the exit.

Updated: Tue, Sep 15, 2026