Fees

This page covers all fees on GMX, including trading fees, swap fees, price impact, funding, borrowing, and network fees.

Open / close fees

The position fee is 0.04% or 0.06% of the position size. It applies when opening, closing, increasing, or partially decreasing a position.

The rate depends on whether your trade improves the balance between long and short open interest:

• 0.04% — your trade reduces the absolute difference between long and short open interest
• 0.06% — your trade increases the absolute difference between long and short open interest

For example, if there is more long open interest than short open interest, opening a short position reduces the imbalance and qualifies for the 0.04% fee. Opening another long position increases the imbalance and incurs the 0.06% fee.

All markets currently use these same rates — there are no per-market overrides.

Swap fees

Swap fees on GMX vary by market type — standard or stablecoin — and whether your swap improves or worsens the pool's balance. All fees are calculated on the swap input amount.

Standard swap fees

For a standard swap, the fee is either 0.05% or 0.07% of the swap amount:

• 0.05% — if the swap decreases the USD imbalance between the long and short token pools (balance improved)
• 0.07% — if the swap increases that imbalance (balance not improved)

The pool balance check compares the absolute USD difference between the long and short token pool values before and after your swap. If the post-swap difference is smaller, the lower fee applies.

Stablecoin swap fees

Stablecoin swap markets use significantly lower fees than standard markets. Rates differ by chain:

Chain	Fee (balance improved)	Fee (balance not improved)
Arbitrum (USDC/USDC.e, USDC/USDT, USDC/DAI)	0.005%	0.02%
Avalanche (USDC/USDT.e, USDC/USDC.e, USDT/USDT.e, USDC/DAI.e)	0.01%	0.01%

Atomic swap fees

Atomic swaps use a separate fee of 3.75% on standard markets. An atomic swap executes in a single transaction and uses a separate fee factor.

tip

Single-token pools (where both the long and short token are the same) have no swap fees on any position operation, because collateral, PnL, and pool backing all use the same token — no token conversion is needed. The BTC/USD [WBTC.e-WBTC.e] and ETH/USD [WETH-WETH] pools also have position impact factors set to zero, meaning no price impact of any kind on these markets. For a full comparison, see Single-token vs multi-token pools.

Slippage

Slippage is the difference between the expected execution price when you submit an order and the actual price when the order executes, caused by price movement during the brief window while the order is processing. The default allowed slippage is 1% and can be adjusted in settings or directly in the trade box. Slippage applies to market orders only — limit and trigger orders use a fixed acceptable price you set at order creation.

When you submit a market order, the interface computes an acceptablePrice by applying your slippage setting to the mark price. At execution, the contract checks whether the actual execution price satisfies that acceptablePrice, and reverts if it doesn't.

For example, consider a Market Increase on ETH/USD:

• Expected execution price: $4,000 (long position).
• Actual price at execution: $4,080 (2% higher) due to volatility.
• Since the price moved against you (higher entry for a long), this is unfavorable slippage.
• The order won't execute unless your allowed slippage was set to 2% or higher.

You can set slippage up to a maximum of 5%. The interface shows a warning when slippage exceeds 2%.

Slippage is separate from price impact. Price impact is an additional positive or negative adjustment based on open interest imbalances, applied independently of slippage. See Price impact and price impact rebates for details.

Slippage on GMX vs. other platforms

On most trading venues — AMMs, DEX aggregators, and some centralized exchanges — "slippage" refers to the total difference between the quoted price and the execution price, which includes the effect of your trade on market liquidity (what GMX calls price impact).

On GMX, these are two distinct mechanisms:

• Slippage protects only against oracle price movement between the time you submit an order and when a keeper executes it.
• Price impact is a separate adjustment based on pool imbalance, calculated and applied independently at execution time.

The expected output shown in the interface already accounts for estimated fees and price impact. Your slippage setting adds an additional buffer on top of that estimate to cover oracle price movement during the execution window. This means setting 1% slippage on GMX is not equivalent to setting 1% slippage on a DEX aggregator — on a DEX aggregator, that 1% must cover both price impact and price movement, while on GMX it only needs to cover price movement.

Price impact and price impact rebates

On GMX, opening a position incurs no price impact at entry. The entry price is determined by the oracle price (maxPrice for longs, minPrice for shorts). See Pricing on GMX for details. Price impact is calculated based on the net open interest imbalance caused by both opens and closes, but it is only applied (charged or credited) when you close or decrease a position — hence the name "net price impact."

Net price impact can be positive or negative, up to a market-specific cap. Unlike orderbook models, GMX caps price impact, so you don't have to worry about orderbook depth. Also unlike orderbooks, a positive price impact means you can be paid rather than penalized.

Price impact formula

Price impact is calculated from the change in pool imbalance caused by a trade:

priceImpact = (initialImbalance ^ exponent × factor) − (finalImbalance ^ exponent × factor)

Where:

• initialImbalance — the absolute difference between long and short values before the trade
• finalImbalance — the absolute difference after the trade
• factor and exponent — per-market configuration parameters (separate values for positive and negative impact paths)

For positions, the imbalance is the difference between long and short open interest. For swaps, the imbalance is the difference between the USD values of the long and short token pools.

When a trade reduces the imbalance (final < initial), the result is positive — the trader receives a better price. When it increases the imbalance, the result is negative — the trader receives a worse price. If a trade crosses the balance point (the larger side becomes the smaller side), the calculation splits: the portion toward balance uses the positive factor and the portion past balance uses the negative factor.

For position operations, price impact adjusts the entry or exit price rather than deducting from collateral, which preserves the intended leverage ratio. The protocol also maintains a virtual inventory that tracks impact across correlated markets to prevent users from reducing their net impact by opening opposing positions in different markets.

For the SDK implementation of this formula, see getPriceImpactUsd and related functions in the price impact module.

The prices shown in the trade history — for both opens and closes — are the mark prices (oracle prices) at which the orders executed. For closing, the net price impact is a separate value not included in the displayed mark price. Instead, price impact adjusts your collateral received independently. For example, if the close price is $1,900 and the net price impact is +$1, the mark price remains $1,900 but you receive an additional $1 in collateral, making your effective value $1,901. Conversely, a -$1 net price impact means $1 is deducted from your collateral received.

You can view net price impact in the net value tooltip on the positions list or close modal. The claimable rebate amount is also included in the net value calculation, so your position's net value reflects any rebate you're owed. For a detailed breakdown, enable "Break down net price impact" in the display settings — this shows the price impact stored when you opened the position, the price impact from closing, and how they combine into the net amount.

Price impact caps by market

Negative and positive price impact have separate caps. The max negative price impact varies per market based on liquidity depth (see table below), while the max positive price impact is 40 bps (0.4%) for most markets. This creates an asymmetry — for example, a market with a 500 bps negative cap still has only a 40 bps positive cap.

Negative price impact caps by market:

• Major markets (BCH, BNB, BTC, ETH, PEPE, SOL): 50 bps (0.5%) cap
• Lower-liquidity markets: 75–1000 bps (0.75%–10%) cap, depending on the market's liquidity depth

For example, if the cap is 50 bps, you never pay more than 50 bps in price impact, regardless of order size. Markets with less liquidity have higher caps to better reflect execution conditions.

Cap	Markets
50 bps	BCH, BNB, BTC, ETH, PEPE, SOL, XAUT
75 bps	BONK, LTC
100 bps	ASTER, AVAX, CRO, CRV, DOGE, ENA, FLOKI, HYPE, LINK, NEAR, SHIB, TRX, XPL, ZEC
150 bps	0G, AAVE, ADA, APE, APT, ARB, ATOM, FARTCOIN, INJ, OP, PENGU, PUMP, TON, TRUMP, UNI, WLD, XLM
200 bps	AR, DASH, DYDX, EIGEN, FIL, ICP, ONDO, SUI, VIRTUAL, XMR, XRP
250 bps	DOT, HBAR, IP, KTA, LDO, MOODENG, ORDI, S, SEI, TAO, TIA
300 bps	AERO, AIXBT, ANIME, AVNT, BERA, BOME, CAKE, FET, JUP, KAS, LINEA, OM, PENDLE, POL, SYRUP, WIF, ZORA
400 bps	WLFI
500 bps	ALGO, BRETT, CHZ, CVX, DOLO, GMX, JTO, LIT, MEME, MEW, MNT, MON, OKB, PI, RENDER, SKY, SPX6900, STX, WELL, ZRO
700 bps	SATS
1000 bps	CC, MELANIA, MET, MORPHO, VVV

You can view the current price impact cap for each market on the Monitor page under the Config column.

For large orders (typically $1,000,000 or more with negative price impact exceeding 0.2%), consider using TWAP to reduce price impact by executing in smaller parts over time. For swaps, positive price impact increases the tokens you receive, while negative price impact decreases them.

note

Capped negative price impact is factored into liquidation price calculations. Positive price impact is excluded. For details, see Price impact in liquidations.

Long and short open interest in markets is typically balanced, leading to minimal net price impact. During high volatility, imbalances can cause higher net price impacts. Price impact rebates help mitigate this. If a decrease order has a negative net price impact exceeding the market's cap, the excess becomes claimable as a rebate after a five-day delay.

tip

You can claim rebates in the claims section on the trade page. The delay protects against manipulation, and rebates are reviewed before being granted.

Price impact cap configurations are adjusted per market based on recommendations from Chaos Labs to align with current liquidity conditions.

Funding fees

Funding fees may be a cost or a credit while a position is open. The funding fee rate is visible on the interface when you open or review a trade. The rate changes over time based on the balance of longs and shorts in the market.

If you receive positive funding fees, you can claim them using the "Claim" button in the "Claimable Funding" box of the Trade page.

Adaptive funding

Funding rates gradually adjust over time based on the ratio of long to short open interest. A sudden shift in the OI balance does not immediately reverse the funding direction — the previously larger side may continue to receive funding until the rate adjusts.

Which side pays and at what rate is governed by a signed state variable, savedFundingFactorPerSecond, that the contract updates on every market transaction. A positive value means longs pay shorts; a negative value means shorts pay longs.

The imbalance ratio used for threshold comparisons and rate adjustments is:

longShortImbalance = [abs(longOpenInterest - shortOpenInterest) / totalOpenInterest] ^ fundingExponentFactor

The rate adjusts according to three zones defined by this imbalance relative to two thresholds, thresholdForStableFunding and thresholdForDecreaseFunding:

• Above thresholdForStableFunding: The imbalance is large. The rate increases by longShortImbalance × fundingIncreaseFactorPerSecond per second until the imbalance falls or the rate reaches its maximum cap.
• Between the two thresholds: The rate remains constant.
• Below thresholdForDecreaseFunding: The imbalance is small. The rate decreases by fundingDecreaseFactorPerSecond per second toward zero.

If the imbalance reverses direction (for example, longs were dominant and shorts become dominant), the rate immediately starts increasing in the opposite direction, regardless of which threshold zone it was in.

For example, suppose longs exceed shorts and the rate is increasing with longs paying shorts. If shorts are opened or longs are closed so that shorts now exceed longs, the rate begins increasing in the opposite direction — toward shorts paying longs — until a threshold is reached or the maximum cap is hit.

Accrual and settlement

Funding fees accrue continuously using per-second arithmetic. Each market stores savedFundingFactorPerSecond (the signed adaptive rate) and a fundingUpdatedAt timestamp on-chain. The unsigned fundingFactorPerSecond for the paying side is derived on-demand inside getNextFundingAmountPerSize and is never stored persistently. The total funding accrued for the paying side over a period is:

fundingUsd = sizeOfPayingSide × durationInSeconds × fundingFactorPerSecond

Settlement is event-driven, not scheduled. The on-chain funding state updates whenever a transaction touches the market — executing an order, a deposit, or a withdrawal. Between transactions, funding accrues implicitly via the time elapsed since the last update. When a position is modified or closed, the contract computes the exact funding owed using the elapsed time since that last update.

Per-position settlement uses a checkpoint pattern. Each position stores a fundingFeeAmountPerSize value recorded at the time the position was last updated. When the position is settled, the contract computes:

positionFundingFeeAmount = positionSizeInUsd
    × (latestFundingAmountPerSize − position.fundingFeeAmountPerSize)
    / PRECISION

The result is rounded up for the paying side and rounded down for the receiving side.

note

The fundingFactorPerSecond exposed by the interface and API represents the rate for the paying side. The receiving side's effective rate is scaled proportionally by payingOI / receivingOI, so total funding inflow equals total outflow.

Borrow fees

A borrow fee applies to open positions to prevent traders from reserving all pool liquidity by opening equal long and short positions at minimal cost. If the side with larger open interest fully reserves the pool, the borrow fee also incentivizes liquidity providers to add more capital to the pool.

Only the side with the larger open interest pays the borrow fee. If longs exceed shorts, longs pay; if shorts exceed longs, shorts pay.

The borrow fee accrues continuously per second and is settled when you modify or close a position. The fee is calculated as:

borrowingFeeUsd = positionSizeUsd × (cumulativeBorrowingFactor − positionBorrowingFactor)

where cumulativeBorrowingFactor increases over time at borrowingFactorPerSecond, and positionBorrowingFactor is the snapshot taken when your position was last updated.

The current borrow fee rate is shown on the trade interface as a percentage per hour, applied to your position size. The rate changes over time based on pool utilization.

Rate models

Most markets use a kink model (two-segment curve). The rate increases linearly up to an optimal utilization threshold, then rises more steeply above it:

borrowingFactorPerSecond = baseBorrowingFactor × usageFactor

if usageFactor > optimalUsageFactor:
    diff = usageFactor − optimalUsageFactor
    additional = (aboveOptimalUsageBorrowingFactor − baseBorrowingFactor) × diff / (1 − optimalUsageFactor)
    borrowingFactorPerSecond += additional

A typical configuration is:

• Optimal utilization: 75%
• Rate at or below 75% utilization: 45–55% per year
• Rate at 100% utilization: 100–130% per year

Some markets use a power (curve) model instead:

borrowingFactorPerSecond = borrowingFactor × reservedUsd ^ borrowingExponentFactor / poolUsd

The default base configuration uses a linear exponent of 1, which targets approximately 15.77% per year at 100% utilization.

Of the borrow fee collected, 63% goes to the pool (accruing to liquidity providers) and 37% goes to the protocol fee receiver.

Network fee

Every trade on GMX involves two transactions: your request and the keeper's execution. The network fee covers the gas cost of the second transaction.

1. You send a transaction to request an action — open, close, deposit collateral, or withdraw collateral.
2. A keeper observes the request on-chain and executes it in a separate transaction.

The gas cost of the keeper's execution transaction is what the interface calls the network fee. Because gas prices can spike between your request and the keeper's execution, the interface charges a max network fee that overestimates the likely cost. When the keeper executes your order, only the gas actually consumed is paid to the keeper — the remainder is refunded to your account automatically.

The interface displays the network fee row after subtracting an estimated refund. The full max network fee amount, along with an estimated refund breakdown, is visible in the tooltip next to the fee row.

note

The estimated refund shown in the tooltip is an approximation based on recent data, not a guaranteed amount. The actual refund depends on gas prices at the time of execution.

Max network fee buffer

The max network fee includes a configurable buffer to guard against gas price spikes. You can adjust this buffer in the Max network fee buffer setting, found in the settings panel.

When Express Trading is enabled, an additional 10% buffer is applied on top of your configured buffer to account for the higher gas reliability requirements of Express order execution.

TP/SL and additional orders

When you place a position with Take-Profit or Stop-Loss orders, the max network fee includes fees for those additional orders. If those orders don't trigger and are canceled, their network fees are refunded in full.

Arbitraging

GMX's fee and price impact mechanics reward trades that rebalance pools, which creates arbitrage opportunities for both perpetuals and swaps. When a pool is imbalanced, you can profit while helping restore balance.

Perps

You can arbitrage positive price impact and funding fees on perpetual markets.

For example, if ETH long open interest exceeds short open interest, opening a short position reduces the imbalance. The contract calculates price impact based on the change in the absolute difference between long and short open interest before and after your trade. Because the imbalance decreases, you receive a positive price impact — a better entry price than the current mark price. While the position is open, you also earn funding fees, because the dominant (long) side pays the minority (short) side.

If ETH long positions subsequently close such that short open interest exceeds long open interest, closing your short position also reduces the (now reversed) imbalance, and you receive a positive price impact on exit — a better exit price than the mark price.

For markets where the index token is the same as the collateral token (for example, using ETH as collateral in the ETH/USD market), you can open a delta-neutral short position by posting the index token as collateral. This exposes you to funding income without directional ETH price risk. When arbitraging with a long position, opening a 1x long with a stablecoin as collateral gives you 1x exposure to the index token without additional leverage.

note

With adaptive funding, the rate decreases toward the market's minFundingFactorPerSecond floor as open interest becomes balanced — not necessarily to zero. Factor this in when sizing an arbitrage position, as the funding income may be lower by the time open interest equalizes.

Pool balances and funding rates per hour can be viewed on the Stats page. For programmatic access, the /markets/info endpoint provides near-live funding rates (refreshed every 5 seconds), while the /rates endpoint provides hourly historical snapshots.

Swaps

You can arbitrage positive price impact on swap markets.

Swap price impact is calculated based on the change in the absolute USD difference between the long token pool value and the short token pool value. If your swap reduces that difference, you receive a positive price impact — additional output tokens beyond the baseline swap amount.

For example, in the ETH/USDC pool, if the USD value of ETH in the pool exceeds the USD value of USDC, swapping USDC for ETH reduces the imbalance and earns a positive price impact. You receive more ETH than the unadjusted swap would provide.

Pool balances can be viewed on the Stats page.