What is GMX perpetual trading and how it really works

GMX perpetual trading is leveraged long/short trading on GMX where positions don’t expire and are executed at an oracle price, with predictable pre-trade price impact and ongoing fees that accrue over time. It behaves less like an order book and more like an on-chain accounting system where a keeper executes your committed order and the protocol settles funding and borrowing when you touch the position.

Key Takeaways

• GMX perpetual trading is permissionless and non-custodial, so any wallet can trade without KYC, API keys, or exchange custody.
• Orders are executed at an oracle price (Chainlink is cited as an example), and the UI can show predictable price impact tied to open interest imbalance before submission.
• GMX uses a two-phase lifecycle where you create an order on-chain and a keeper executes it later, a design intended to reduce sandwich and frontrun risk.
• The main “quiet” holding costs are funding and borrowing, both tracked through cumulative factors and settled through protocol-defined updates when positions change.

GMX perpetuals and the core idea

Perpetuals are futures-like positions with no expiry, which means the position can stay open indefinitely as long as margin and fees are maintained. On GMX, that “no expiry” feature matters because the trade’s economics are not just entry and exit. The position accumulates time-based costs while it sits open, and those costs are accounted for by the protocol rather than negotiated in an order book.

The clean mental model for what is gmx perpetual trading is a perpetual DEX where the reference price comes from an oracle and the protocol runs a ledger for each position. A trader chooses a market, picks long or short, posts collateral, and sets leverage. The protocol then tracks position size, collateral, and the fee meters that accrue while the position is open.

This is also where “gmx explained” tends to go wrong in other guides. The interesting part is not “up to 100x.” GMX Docs cites up to 100x leverage across major assets on Arbitrum, Avalanche, Botanix, and MegaETH, with Arbitrum called out as having the deepest liquidity and most complete feature set. The interesting part is that execution is designed to be deterministic around an oracle price, while the true holding cost is path-dependent because funding and borrowing accrue over time and get crystallized when the position is modified.

For someone coming from spot, the key difference is simple: spot trading pays the price you trade at and you’re done. Perps add a second layer where the protocol continuously updates what you owe or are owed while the position remains open.

How GMX executes perp orders

Two things happen between clicking “open” and having a live position: an on-chain order is created, then a keeper executes it. GMX Docs describes this two-phase flow as a MEV protection design. The intent is committed on-chain first, and the oracle price is included later at execution, which is meant to reduce frontrunning and sandwich attacks.

Execution itself is not “pool curve pricing.” GMX uses an oracle based perp design where execution happens at oracle prices, with Chainlink cited as an example oracle source. That choice is the product. It makes the reference price legible, and it shifts the question from “what spread am I crossing?” to “what protocol-defined adjustments apply around the oracle price?”

Those adjustments show up as price impact tied to open interest imbalance. GMX Docs says price impact is determined by open interest imbalance and is predictable before submission. That predictability is the point. A trader can see, before committing, whether the market is skewed and whether the trade is paying a fee or receiving a rebate due to that imbalance.

A simple order lifecycle for trading on gmx looks like this:

1. Create the order. The wallet signs and submits the order intent on-chain. 2. Keeper executes the order. A third party keeper triggers execution under protocol rules using the oracle price. 3. Position state updates. The protocol updates position size, collateral, and the cumulative fee accounting that applies at that moment.

A GMX v2 guide that skips this lifecycle usually leaves readers confused about why execution is not instant in the same way a CEX market order is. GMX is explicitly built around an order lifecycle, not continuous matching.

Liquidity pool model behind GMX perps

The counterparty on GMX is not another trader sitting on the other side of a central limit order book. KuCoin’s comparison frames GMX as a multi-asset liquidity pool model where traders trade against a pool rather than a CLOB. That pool design is the second big difference after oracle pricing.

In GMX v1, that pool exposure is commonly discussed through gmx glp. In GMX v2, the liquidity is organized through gm pools. Either way, the economic point is the same: liquidity providers are effectively warehousing risk, and traders are taking risk off that warehouse. When traders win, the pool pays. When traders lose, the pool keeps the loss. KuCoin makes this counterparty relationship explicit in its discussion of LP risk.

This pool-counterparty model changes how “slippage” intuition should work. In an order book perp DEX, the cost of immediacy is usually visible as spread and depth. On GMX, KuCoin describes “zero price impact” behavior for trades executed at the oracle price depending on pool depth, but GMX Docs also emphasizes that price impact is tied to open interest imbalance and is predictable before submission. Put those together and the right framing is not “GMX always has zero slippage.” The right framing is “GMX shows you the imbalance adjustment up front, and that adjustment is a protocol variable, not a market maker quote.”

This is why GMX perps often feel like trading against inventory constraints. The pool has to stay solvent and balanced across markets. The protocol uses price impact and time-based fees to discourage one-way crowding and to compensate the pool for taking the other side.

Funding fees and why they exist

Funding exists because perpetuals have no expiry. Without an expiry-based convergence, the market needs a mechanism to keep the perpetual price anchored to a reference price. Cyfrin’s GMX perpetuals trading material describes funding fees as payments between long and short positions intended to maintain market equilibrium.

The implementation detail that matters on GMX is that funding is not just a vague periodic rate. Cyfrin describes GMX’s approach as tracking long and short payments separately and computing funding via cumulative fee factors per unit size. That is an on-chain accounting trick: instead of updating every position every time funding changes, the protocol maintains global cumulative factors and uses them to compute what any specific position owes when it is updated.

Cyfrin’s “How Funding Fee Is Updated” lesson summary describes what happens when a trader modifies a position: funding fee settlement involves a defined sequence of function calls and state updates where global cumulative rates and position-specific data interact to calculate and apply funding fees. The packet does not provide the deeper implementation details, but the high-level implication is enough for a trader. Funding is continuously accruing in the background, and it becomes real when the position is changed, such as increasing, decreasing, or closing.

That settlement timing is why funding can feel “invisible” until it is not. A position can be directionally right and still underperform because the cumulative funding ledger moved against it during the holding period.

Leverage, costs, and practical risks

GMX Docs cites up to 100x leverage on major assets across Arbitrum, Avalanche, Botanix, and MegaETH, while KuCoin characterizes typical leverage on major pairs as often 50x–100x. The exact cap varies by market and chain, but the practical point is stable: high leverage makes small recurring costs matter.

GMX’s cost stack is easiest to read like a pre-trade cost sheet rather than a single “fee.” The sources support three buckets that dominate the experience:

1. Predictable price impact from open interest imbalance. GMX Docs says this is determined by open interest imbalance and is predictable before submission. 2. Funding fees between longs and shorts. Cyfrin describes these as equilibrium payments tracked via cumulative fee factors per unit size with separate long and short tracking. 3. Borrowing fee tied to pool liquidity usage. KuCoin summarizes GMX as charging a borrowing fee based on how much liquidity a trader uses from the pool.

The risk profile follows the same plumbing. Non-custodial and permissionless does remove exchange custody and account-freeze risk, and GMX Docs explicitly markets that property. It does not remove counterparty dynamics. The counterparty is the pool, and the pool’s incentives are enforced through price impact, funding, and borrowing mechanics.

The most common user mistake is benchmarking GMX fills to a CEX or CLOB perp DEX. Queue position and maker-taker games are not the edge here. The edge is understanding when the pool is skewed, what imbalance you are paying to take, and how the two ongoing meters, funding and borrowing, will compound while the position sits open.

Near the end of any serious comparison, the broader category matters: a perpetual DEX can be order-book driven or pool-driven, and GMX sits firmly in the pool-and-oracle camp.

Common misconceptions that cost users money

“GMX is just an AMM perp.” That framing imports constant-product intuition that does not match GMX’s execution model. GMX Docs specifies that execution happens at oracle prices rather than against an internal pool curve, and that price impact is tied to open interest imbalance and shown before submission. The mechanism is closer to oracle reference pricing plus deterministic adjustments than it is to a pure AMM curve.

“Funding is just a simple APR you pay every 8 hours.” Cyfrin’s material describes funding on GMX as a ledger approach using cumulative fee factors per unit size with separate tracking for longs and shorts. The update process is triggered through protocol-defined state updates when a trader modifies a position, which is why the timing of when you increase, decrease, or close matters to what gets settled.

“Non-custodial means no counterparty risk.” GMX being non-custodial means the exchange does not hold user keys and does not run an account system with KYC or API keys, as GMX Docs emphasizes. The trade still has a counterparty structure because traders are trading against pooled liquidity, described by KuCoin as GLP/GM. Risk shifts from exchange custody to protocol and pool dynamics, including borrowing fees based on liquidity usage.

“Two-step execution means worse fills by default.” The two-phase create-then-execute flow is described by GMX Docs as MEV protection, committing intent before oracle prices are included to reduce sandwich and frontrun risk. It is a structural tradeoff, not a free lunch, but it is not the same thing as “the protocol is trying to slip you.”

The Take

I’ve watched traders treat GMX like a CEX with a nicer UI and then act surprised when the PnL doesn’t match their mental model of spread and slippage. The expensive misunderstanding is thinking the only cost is what you see at entry. On GMX, the deterministic part is execution around an oracle price plus a known imbalance adjustment. The part that quietly eats you is the path-dependent ledger, funding and borrowing, that accrues while you wait.

If a position is meant to be held, the job is monitoring the two meters, not admiring the entry. GMX’s design makes it possible to know the reference price source and see the open-interest imbalance cost before submitting. That is a better deal than guessing at order book depth. It also means the protocol is telling you, up front, what you’re paying to take the other side of the pool’s inventory.

Sources

• GMX Docs
• KuCoin Learn
• Cyfrin Updraft
• Cyfrin Updraft