Gamma is a Token-Approval and Share-Verification Workflow

Posted August 2026

Gamma is a concentrated-liquidity vault workflow that calculates the two token amounts before approval, spends those approved ERC-20 balances only when the deposit executes, and mints fungible Hypervisor shares to the recipient address. The approval transaction changes an allowance; it does not deposit assets. A later deposit calls UniProxy, moves token0 and token1 into the selected vault, and creates shares that can be checked through the transaction receipt and the share contract's balanceOf function.

From wallet connection to minted shares

The Gamma deposit workflow moves through five decisions: network, vault, token amounts, allowances, and final confirmation. Each decision changes what the wallet signs next. Start by connecting a compatible EVM wallet, such as MetaMask, Coinbase Wallet, or Trust Wallet. Select the intended chain and vault before entering an amount, because each vault has its own pair, Hypervisor contract, and required ratio.

Entering one token amount prompts the interface to calculate the paired amount. Check that both balances cover the quote. The next signatures approve token0 and token1 when their allowances are insufficient. The final signature submits the deposit through UniProxy. If the pair uses WETH and the wallet holds native ETH, wrapping adds an earlier transaction.

A first dual-token deposit therefore produces two approval transactions and one deposit transaction. Wrapping ETH raises that sequence from three transactions to four. Once the deposit succeeds, the two asset balances fall and one ERC-20 share balance appears. The paired quote deserves a closer read before the first signature.

Let the paired-token quote set both amounts

The paired-token quote identifies how much token1 must accompany a chosen token0 amount. Gamma derives this requirement from the vault's existing asset composition, so a 50/50 value split is not a fixed deposit rule. Concentrated-liquidity ranges leave vault inventory uneven as the pool price moves.

At contract level, getDepositAmount takes the Hypervisor address, a provided token address, and one input quantity. It returns two bounds: a minimum and maximum acceptable quantity for the paired token. The interface converts those raw integers into readable token amounts and selects a deposit value inside the permitted range.

Decimal precision matters here. USDC uses 6 decimals, WBTC uses 8, and WETH uses 18. One displayed USDC therefore represents 1,000,000 base units, while one displayed WETH represents 10 ¹⁸ base units. Compare readable amounts in the interface, yet remember that the signed call carries integer base units. Once both quoted amounts fit the wallet, transaction count becomes the immediate cost question.

Budget the signatures and network gas

A first dual-token vault deposit normally needs three state-changing transactions: two approvals and one deposit. An ETH-to-WETH wrapping step makes four. Existing allowances reduce the count, while a previous approval for another token, chain, or vault does not.

Every included transaction consumes the network's native gas asset. The currency cost is not fixed because it equals the gas used multiplied by the effective gas price. On EIP-1559 networks, that price reflects the block's base fee plus the accepted priority fee, capped by the wallet's maximum fee. The durable figure is the transaction count, not a quoted currency amount.

Approval transactions perform a small token-contract state update. The deposit performs more work: it checks the ratio, pulls two assets, updates vault accounting, and mints shares. It therefore receives a separate gas estimate. Keep enough native gas for all remaining signatures rather than spending the full gas balance on the assets being deposited.

Choose the allowance before approving

The ERC-20 allowance determines how many base units a named spender may transfer from the wallet. Approval changes that allowance without moving the token balance. The later deposit invokes transferFrom, which uses the recorded permission when the Hypervisor pulls each asset.

An ERC-20 approval records a spender address and a 256-bit amount that the token contract exposes through allowance. An exact allowance limits the permission to the quoted deposit amount. A larger allowance supports later deposits until its remaining value falls below the next requested amount. Setting an allowance to 0 removes it through another state-changing transaction.

Review the amount in token units, not just the raw integer. An approval for 25 USDC appears on-chain as 25,000,000 base units because USDC has 6 decimals. Approval for 25 WETH would use 25 × 10 ¹⁸ units. The same displayed number therefore produces very different integers. Address matching is equally important, since allowances belong to one owner, one token contract, and one spender.

Match the chain, vault, and spender

The chain-and-contract check ties the approval to the intended vault. A Gamma vault card identifies the token pair and network, while the wallet request exposes the token contract, spender, amount, and numeric chain ID. All four details should agree with the selected deposit.

EVM addresses contain 20 bytes, displayed as 40 hexadecimal characters after the 0x prefix. Compare the complete address rather than relying on WETH, USDC, or WBTC labels. Tokens with the same symbol on different networks remain separate contracts and balances.

Network IDs remove another ambiguity. Ethereum uses chain ID 1, Optimism uses 10, Polygon PoS uses 137, Base uses 8453, and Arbitrum One uses 42161. Vault availability remains pair-specific, but those identifiers tell the wallet which ledger receives the transaction.

UniProxy is the deposit entry point in the Hypervisor architecture. The selected Hypervisor executes the two token transfers and mints the shares. Consequently, the approval request and deposit call need not display the same destination address. Read each field by its role, then use the receipt to confirm the exact state changes.

Read the deposit receipt as state changes

The deposit receipt proves whether the transaction changed on-chain state. A successful EVM receipt carries status 1; status 0 means execution reverted and its attempted token transfers and share mint did not persist. Earlier approval transactions remain separate state changes.

A successful Gamma deposit produces several useful logs. Each deposited ERC-20 emits a Transfer event from the wallet to the Hypervisor. The share contract emits another Transfer from the zero address to the recipient, representing newly minted shares. Its Deposit event contains five arguments: sender, recipient, shares, amount0, and amount1. Two address fields are indexed for efficient lookup.

The transaction hash provides a stable lookup key. It is 32 bytes, normally displayed as 64 hexadecimal characters after 0x. Open it in the explorer for the actual chain: Etherscan for Ethereum, BaseScan for Base, or Arbiscan for Arbitrum One. Compare the receipt's token amounts with the final interface quote. Then move from event evidence to the persistent share balance.

Verify the ERC-20 share balance

The Hypervisor share contract records the durable ownership result of the deposit. Gamma uses that ERC-20 balance as the holder's proportional claim on the vault, so verification centers on the share contract rather than a screenshot or estimated currency value.

Call balanceOf with the recipient address. The function returns one uint256 value. Hypervisor shares use 18 decimals, meaning 10 ¹⁸ raw units represent one displayed share. A block explorer's token-holdings view performs the same conversion. If the wallet omits the asset, importing the correct share contract changes only its display; it does not mint or move anything.

totalSupply returns the aggregate number of outstanding shares. Dividing the wallet's raw balanceOf value by raw totalSupply gives its fraction of the vault. Multiplying that fraction by 100 expresses a percentage. The share count does not equal the deposit's currency value. It represents proportional accounting, and later deposits, withdrawals, and vault activity change the relationship between shares and underlying token amounts.

Repair an insufficient paired-token setup

An insufficient paired-token error means the quoted second amount exceeds the wallet's available balance. Approval cannot correct this setup error because an allowance grants transfer permission without creating token units. The entry amount must shrink, or the missing paired asset must reach the same wallet on the selected chain.

Suppose the form starts from WBTC in a WBTC/WETH-style vault. Pressing Max for WBTC instructs the form to calculate the full matching WETH requirement. If the wallet lacks that much WETH, reduce the WBTC input until both quoted amounts sit below their respective balances. The same logic applies when USDC is the constrained side.

Native ETH and WETH also count as different balances. Wrap enough ETH when the vault requests WETH, while retaining native ETH for gas. After the wrap confirms, refresh the quote because the vault ratio might have changed between blocks. Reapprove only when the existing allowance is below the revised token amount. The final quote should fit both balances before the deposit button becomes actionable.

Resolve dashboard lag with on-chain data

On-chain share state settles the question when a dashboard updates slowly. A status-1 deposit receipt, a mint event to the intended recipient, and a nonzero balanceOf value establish that the deposit completed even when the interface has not rendered the position.

First confirm the wallet address, chain ID, and recipient in the receipt. Then query the Hypervisor share contract on that chain. If the balance exists, reconnecting the wallet, switching away from and back to the correct network, or refreshing the application lets its cached account data catch up. None of those display actions changes ownership.

A status-0 receipt describes a different outcome. EVM execution is atomic, so the deposit's two transfers and share mint all revert together. Do not infer success from a prior approval; approval and deposit have separate hashes. Return to the form, obtain a fresh paired quote, confirm both balances and allowances, and submit a new deposit transaction.

A five-condition confirmation checklist

The pre-deposit checklist should end with five concrete conditions. Each condition maps to a contract requirement or an observable state change, making the final wallet request easier to interpret.

• The wallet is on the chain shown by the vault, and both token contract addresses match the selected pair.
• Both quoted token amounts fit the available balances, with native gas reserved for every remaining transaction.
• Each allowance names the requested spender and covers at least the corresponding token amount.
• The deposit request sends token0 and token1 to the intended Hypervisor recipient workflow through UniProxy.
• The successful receipt shows status 1, the expected asset transfers, and an ERC-20 share mint to the chosen address.

These checks separate permission from execution. Approval changes what a contract is allowed to transfer; deposit consumes the quoted assets and creates the ownership record. The final Gamma confirmation is complete only when the receipt and share contract agree with the interface.

Questions and answers about Gamma