Gamma fees vary with the product, fee calculation, and transaction work

Approvals, Deposits, and Settlement Create Different Costs

A cost comparison starts with the operation being priced: authorizing token spending, depositing assets, managing an order, or collecting proceeds. An approval changes spending permission. A deposit moves assets into a position. Each separately submitted transaction can carry its own network charge, so a deposit estimate alone does not describe every transaction associated with entry.

Gamma's Hypervisor deposit integration uses UniProxy, while withdrawals interact with the Hypervisor. Those calls perform different work, making their gas costs unsuitable as direct substitutes. Compare transactions that use the same deployment and operation before attributing a difference to network pricing.

Costs inside a position require separate accounting. A deduction from collected trading fees can affect vault assets without appearing as a distinct charge against the depositor's wallet.

LP Charges Reduce Collected Trading Fees

Pool Income and the Manager's Share

A liquidity provider earns fees when trades use its active liquidity, subject to the underlying pool's fee distribution. The pool's swap charge and Gamma's management deduction have different calculation bases. Applying both percentages directly to deposited capital would misstate the cost. A pool fee describes trading charges; a management share describes the portion of applicable earnings retained by the manager.

Configuration Determines the Deduction

Gamma's Hypervisor v1.3 implementation deducts its configured management share from collected pool fees. Its fee calculation uses a divisor, so a raw contract value must be interpreted through that implementation's arithmetic. The owner can change the setting. A value copied from another vault, or read today for an older transaction, does not establish the applicable historical deduction.

The calculation also distinguishes earned fees from returned principal. A collection during withdrawal does not, by itself, establish a percentage charge on the entire withdrawal.

Why Can Similar Gamma Transactions Have Different Gas Costs?

Similar Gamma transactions can have different costs because the price of execution changes and the contracts may perform different amounts of work.

Gas Price Changes the Cost of Execution

For ordinary Ethereum execution, the paid gas component equals gas used multiplied by the effective gas price. A wallet's maximum fee per gas caps the price per gas unit, rather than specifying the final transaction charge. When execution uses less gas than the allowed limit, unused gas does not become an additional protocol fee.

Contract State Changes the Work Required

Equal deposit amounts do not guarantee equal execution paths. Gamma's Hypervisor includes conditional token transfers, liquidity operations, and fee collection. Order creation can likewise update existing position records or initialize new ones. These state differences can change gas use even when an interface gives both actions the same label. Compare the function, inputs, and gas consumed before concluding that the network became more expensive.

Some rollups also charge for publishing transaction data or operating the network. Their execution-gas subtotal may therefore be smaller than the complete transaction fee.

Transaction Choices Carry Different Cost Inputs

Gamma operations differ in the work they request and the prerequisites they require. The comparison below identifies relevant cost inputs without treating different outcomes as interchangeable.

Scale orders distribute an intended conversion across prices. Their additional position processing changes the work being priced, so comparison with a single order must account for that difference.

Limit-Order Deductions Apply to Accrued Fees

Gamma's limit-order settlement tracks principal separately from fees earned by the order's liquidity position. The claim calculation applies the configured hook share to accrued fees, then combines the remaining fees with principal for payment. Treating that share as a deduction from the entire order amount would use the wrong base.

The settlement relationship is straightforward: intended user proceeds equal principal plus accrued fees minus the treasury's share of those fees. Token amounts must remain separate until any valuation converts them into a common unit. Adding unlike token quantities would produce a meaningless total.

The hook percentage is configurable. For a settled claim, the OrderClaimed event records principal amounts, fee amounts, and the hook parameter. Those fields help explain the deduction, while actual transfers establish receipt. A creation transaction's gas charge does not include every later transaction that an order owner might submit.

Perpetual Strategies Add Trading Charges and Funding

For Gamma's perpetual strategies, trading charges and funding affect the position's result separately from any transaction used to move funds. Gamma describes strategies that trade perpetual positions on Hyperliquid. Their costs require the relevant vault's trading history, rather than the receipt for an LP deposit.

Hyperliquid distinguishes maker and taker execution and treats vault trading volume separately from the master account. A personal account's fee tier therefore does not establish the tier used by a vault. The applicable trading record must identify the account and execution concerned.

Hyperliquid funding payments transfer value between the long and short sides of a perpetual market. Funding can add to or subtract from a position's balance. Its effect depends on the position and applicable rate, so a funding debit should not be labeled a Gamma management fee.

Execution Losses Require Separate Accounting

A lower position value does not identify a fee by itself. Gamma's perpetual strategies face execution slippage, and their trading positions can gain or lose value. LP positions also change their asset composition as trading occurs. Separating explicit deductions from execution prices and market valuation prevents every shortfall from becoming an alleged fee. A transaction's fee fields answer what execution cost; they cannot explain the complete investment result.

Which Costs Can You Control Before Signing?

You can control submission timing and available transaction settings, while deployed fee rules and market conditions constrain the final cost.

A lower fee cap can limit the execution price you accept, but inclusion still requires a compatible network price. Waiting can change the gas quote. It can also change a deposit's acceptable asset ratio or an order's validity relative to the pool price. A cheaper quote is useful only while the requested operation remains valid.

Reducing the gas limit does not make the same contract work cheaper. An insufficient limit can cause execution to run out of gas.

Existing token authorization can remove the need for a new approval transaction when it covers the correct spender and amount. Authorization for another contract does not provide that permission. Likewise, changing an order's structure changes its execution objective, so gas savings alone do not establish that the revised order is equivalent.

Failed Calls Can Still Consume Gas

A transaction that executes and reverts can incur gas costs even though its requested state changes do not persist. That creates a real difference between a successful operation's cost and the total spending across unsuccessful attempts.

Wallet rejection before broadcast and execution failure after inclusion are different events. A request that never executes on the network has no executed-transaction gas charge. A confirmed failure can have one. The receipt's status establishes success or failure; gas consumption alone does not establish the outcome.

A failed deposit caused by unacceptable inputs requires corrected inputs. Raising the transaction fee cannot make an invalid asset ratio valid. A pending transaction with insufficient pricing presents a different problem: it has not yet established a final execution charge.

Confirmed Records Establish the Final Amount

A settled cost comparison combines the network charge with the product-specific deduction, keeping the amounts and their calculation bases separate.

View full-size image

For network spending, retain the transaction hash, network, receipt status, gas used, and effective gas price. Include additional network fee components where applicable. The gas limit describes permitted consumption; cumulativeGasUsed includes this transaction and any earlier transactions in the same block. Neither should replace the transaction's actual gas use.

For vault or order deductions, connect the event amounts to the fee rule that applied at execution. Keep gross earnings, retained earnings, returned principal, and wallet-paid gas distinct. A charge already reflected in a net proceeds figure must not be subtracted again.

Preserve the original token units alongside any converted currency value. A different valuation timestamp can change the displayed currency cost without changing the recorded token charge. Once the records reconcile, the difference between two actions can be assigned to actual execution work, network pricing, or a product deduction. An unexplained balance difference remains unresolved rather than becoming a fee estimate.