Gamma
Gamma vault deposits exchange accepted token amounts for shares
Gamma routes Hypervisor vault deposits through UniProxy, which checks deposit conditions before the vault issues shares. Preparing a deposit means matching the required token amounts, confirming spending permissions, and selecting the correct recipient. Completion requires a successful transaction and the corresponding share record; an approval or a displayed estimate does not establish ownership.
The initial amount remains editable before submission. That makes preparation the simplest point to resolve a token shortage, an unexpected allowance, or an incorrect recipient. After execution, checking the receipt and share balance establishes what the transaction actually changed.
A completed vault deposit requires successful execution and shares credited to the intended recipient, while token approval only authorizes spending.
UniProxy, the vault, and the receiving account
For a Hypervisor deposit, UniProxy handles the entry request, while the vault manages the underlying assets and issues liquidity tokens. The deposit specifies the vault and the account that should receive those tokens. Withdrawal uses the Hypervisor contract. These roles explain why the deposit destination, token spender, and share recipient require separate attention.
The selected network and contract addresses identify the position. A familiar token symbol alone cannot establish that a wallet request concerns the intended assets. Keep the vault identity consistent throughout preparation, approval, and confirmation.
Deposit availability before token preparation
A usable token quote does not establish that a vault will accept a deposit when the transaction executes. In the ClearingV2 path, acceptance also involves registration, pause status, price conditions, and applicable limits.
ClearingV2 rejects deposits when the pool price lies outside the vault’s base range. Its ordinary deposit path also checks both token amounts and their permitted relationship. Account exemptions affect some checks, so a privileged integration’s behavior does not establish ordinary deposit eligibility.
A price-condition failure requires a change in the relevant state. Repeatedly increasing approval amounts cannot resolve it.
A starting record for the intended deposit
A useful starting record identifies the selected vault, the funding account, the intended recipient, and the available token balances. Record any existing shares too. Without that baseline, an old position can look like evidence that a new deposit succeeded.
Keep displayed quantities separate from estimated currency values. The transaction commits token amounts, and its receipt records execution. A changing portfolio valuation cannot identify which tokens moved or how many shares a particular deposit created. Retaining the transaction hash also distinguishes separate attempts when a wallet or application presents several similar entries.
Paired amounts and token precision
UniProxy.getDepositAmount returns minimum and maximum companion-token quantities for a supplied token amount. Its inputs identify the vault, the supplied token, and that token’s quantity. The response describes an amount relationship at the queried state. It does not reserve capacity or promise execution at a later block.
The quantity sent to the contract
Token precision determines how a readable amount becomes an integer in a contract call. Apply the precision of each input token separately.
Readable amounts
A wallet usually displays quantities with a decimal point. Preserve enough precision when comparing the proposed companion amount with its permitted bounds.
Integer amounts
Contract amounts use raw token units. For a token with decimal precision d, its displayed amount equals its raw amount divided by 10 to the power d. A conversion using the other token’s precision changes the proposed deposit.
Why can a matching quote still fail?
A matching quote can fail because execution evaluates the deposit against a later state and additional contract conditions. The vault’s composition, applicable limits, or price checks can differ by submission time. Refreshing the quote addresses an outdated amount relationship; it does not remove a pause or a separate price restriction.
Transaction simulation can expose a failure before submission when the integration supports it. A successful simulation describes the state that it evaluated, however, and does not reserve that state. Treat an unexplained revert as an unresolved deposit condition, rather than a reason to weaken unrelated transaction protections.
Allowances before the spending transaction
An ERC-20 allowance authorizes a particular spender to transfer tokens from a particular account. It does not move the approved tokens or create vault shares. Existing allowances determine whether another approval is necessary. The authorized quantity also matters: permission exceeding the intended deposit leaves additional spending authority available.
In the Hypervisor implementation, the vault performs the token transfers even though UniProxy receives the deposit call. Consequently, the spender and entry contract can differ. Match the approval to the deployed transfer path rather than assuming those addresses must be identical.
Changing an existing allowance deserves care. Standard approval replaces its value, and transaction ordering can create exposure while an old allowance remains usable. Token-compatible allowance controls should account for that behavior.
A smaller deposit within the available balance
Consider a hypothetical preparation case with two choices: retain the proposed deposit or reduce it. Every amount, quote bound, balance, and execution outcome in this example is hypothetical. The same requirement governs both choices: available balances must cover the proposed amounts, and the complete deposit must pass the applicable checks.
The initial proposal uses 138 units of token0. Its companion-token quote requires at least 61.8 units of token1, while the account holds 58.1 units. Retaining that proposal leaves a shortage of 3.7 units. Reducing the proposal and obtaining a fresh quote produces a companion amount of 57.6 units, leaving 0.5 units of token1 outside the deposit.
Assume the reduced pair passes both ratio checks and the other deposit conditions. After the required authorization, the funding account submits that pair. The successful receipt records the deposit and its recipient, and the recipient’s share balance increases by the minted amount. If the refreshed proposal instead fails a price check, the account holder stops before submission. The smaller amount resolves the balance shortage only; it cannot resolve a separate restriction.
The deposit call and its commitment boundary
Submitting the deposit authorizes execution of the selected token amounts and recipient, subject to the contract’s checks. Before signing, compare those fields with the prepared request. A transaction hash records a submission; it does not establish that the network executed the transaction successfully.
Contract interfaces differ across deployments and versions. UniProxy v1.2.3 includes a minIn array alongside the token quantities, recipient, and vault address. In Hypervisor v1.3, its entries set minimum token amounts used when adding liquidity to the base and limit positions during direct deposits; they do not set minimum minted shares. Integrations must match the deployed interface and check whether direct deposits are enabled. A companion-token ratio quote is not a minimum-share guarantee.
Receipt status and the credited shares
A successful deposit receipt and the recipient’s share record provide complementary evidence: one identifies the operation, and the other identifies the resulting holding.
The recorded deposit
The Hypervisor Deposit event records the recipient, minted shares, and deposited token amounts. Compare those fields with the intended request. An approval receipt concerns spending permission, so its success cannot substitute for the deposit receipt.
The resulting holding
The share contract’s balanceOf function returns the recipient’s balance. Compare it with the starting balance, allowing for any other share transfers or operations between observations. A mint increases the recipient’s balance and the total supply. A wallet’s rounded display can hide a small change, so raw balances provide a more precise comparison.
Pending transactions and failed attempts
A missing receipt leaves execution unresolved; a failed receipt establishes that the attempted transaction did not complete successfully. Those states call for different responses. Check the submitted transaction before creating another deposit request, since a pending transaction may still execute. Closing the application does not cancel a submitted transaction.
A reverted deposit rolls back its transaction changes, while network execution can still consume gas. Separate approvals that succeeded earlier remain separate transactions. Review any remaining allowance before abandoning the attempt. For programmatic checks, the transaction receipt exposes execution status and logs.
Holding shares or redeeming the position
A share balance represents ownership in the vault, rather than a promise to return the original token quantities. Liquidity management changes the assets that support that holding, and applicable fees affect its outcome. The share count therefore serves a different purpose from a valuation estimate.
Redemption through the Hypervisor burns the submitted shares and returns the corresponding underlying assets. Review the destination and applicable withdrawal constraints before committing that transaction. Leaving shares in the vault maintains the position; redeeming them exchanges that holding for the assets available through withdrawal. Simply closing the interface leaves ownership unchanged.
Useful questions about Gamma
Can a Gamma deposit send shares to a different account?
The UniProxy deposit interface includes a recipient address that can differ from the funding account. Confirm that recipient before signing because share verification must use the receiving account. Control of the funding account does not establish control of another address that receives the shares.
Which token should I use to request the companion amount?
The quote function accepts either token belonging to the selected vault. Supply that token’s address and quantity, then interpret the returned bounds as quantities of the other token. Choosing the token with the tighter available balance can make preparation easier, but the complete pair must still satisfy deposit checks.
Does a zero companion-token quote permit a single-token deposit?
A zero quote does not establish permission to deposit only one token. In ClearingV2, a vault with outstanding shares and a zero total for either underlying token can return zero bounds, while the ordinary deposit path still requires both amounts to be positive. That combination can mean the proposed deposit cannot proceed.
Is sending tokens directly to the vault equivalent to depositing?
A token transfer to the vault does not invoke its share-minting deposit operation. Use the supported deposit entry point rather than a wallet’s ordinary send function. A successful transfer alone does not establish a corresponding ownership claim, and the deposit interface does not promise recovery of an accidental transfer.
What does a share balance reveal about my fraction of the vault?
A share balance divided by the same contract’s totalSupply gives the account’s fraction of outstanding shares when supply is nonzero. Read both values at the same block and in matching units. That fraction describes ownership; calculating a currency value also requires the underlying assets and their valuation.
Why might deposited shares disappear from my wallet after staking?
Staking can move liquidity tokens into a separate contract that records the staked position. Where the selected vault supports such an incentive arrangement, the wallet’s direct share balance alone does not describe the entire holding. Check the staking record and its withdrawal requirements before attempting vault redemption.
Will revoking a deposit allowance withdraw my existing position?
Revoking an underlying-token allowance changes future spending permission; it does not redeem existing vault shares. The shares remain with their holder until a separate operation transfers or redeems them. Treat permission cleanup and position withdrawal as different actions, even when both follow a decision to stop using a vault.
When does a deposit begin earning liquidity fees?
Once minted, shares participate in subsequent fees earned by the vault’s active liquidity, even if newly deposited tokens remain idle. Minting does not mean that every deposited token immediately supplies active pool liquidity. The Hypervisor supports a directDeposit setting that affects deployment during entry, and vault balances can include unused assets. Fee exposure therefore depends on the position’s actual liquidity deployment and range, rather than the wallet confirmation time.