Gmx v2.2 + v2.3

Hi all,

We would like to propose a development plan for the coming months for discussion.

This plan has been discussed with GMX contributors, and is prioritized based on our understanding of what would improve the protocol most, while balancing the development time required.

Before going into the plan, a brief recap of the development completed in the current year:

  • GMX V2 improvements:
    • Adaptive funding rate: improve long / short balancing
  • RewardRouter updates:
    • Capping of boost for Multiplier Points
    • Distribution of rewards in GMX tokens
  • GMX V2.1
    • Shifts: allow liquidity to be more easily moved between markets
    • Auto-cancelling orders: auto-cancel orders on position close
    • Atomic withdrawals: to better support lending markets
    • Kink borrowing rate: allow borrowing rates to be lower during regular usage and to scale in times of demand
    • Switched to Chainlink Data Stream time-based oracle for better speed and reliability
  • GLV
    • To automate moving of liquidity between markets, allowing more markets to be supported
  • Integrated Chaos Labs Risk Oracle
    • Allow risk parameters to be updated at a high frequency to safely match market conditions while providing better pricing for traders
  • Ådded support for GMX token buybacks

With the integrated Chaos Labs Risk Oracle, work is currently being completed to reduce the price impact for all markets.

Work to reduce the borrowing and funding rates is also in progress.

For the coming months, we propose to work on:

GMX V2.2

  • Gasless transactions
  • Network Cost Subsidies
    • We have received feedback about high network costs during times of congestion
    • This feature would allow a network fee pool to be accumulated from a portion of open / close fees
    • This network fee pool would be used to subsidize a percentage of the user’s network cost
    • Tiers would be supported so that the percentage subsidized will vary depending on the trade size to prevent gaming or intentional wastage of this subsidy
    • Support of this pool using a percentage of open / close / swap fees would require a Snapshot vote to enable
    • Goal: lower network fees / improve UX for traders
  • Multichain
    • We propose to add support for virtual accounts which would allow users from any supported chain to trade on GMX
    • Flow:
      • The user would send a transaction on the source chain, this transaction would bridge funds to a current GMX deployment, e.g. on Arbitrum or Avalanche
      • The bridge transaction would contain a message of who the sending user is
      • The bridged funds would be stored in a MultichainVault and recorded to be under the sending user’s balance
      • To trade, the user would just need to sign a message on the source chain for each trade, this can be further simplified if the user enables 1ct
    • With this flow, the user will not need to switch networks in their wallet, will not need to bridge any gas token for trading and can have full access to the existing liquidity on Arbitrum and Avalanche
    • In future iterations, a flow can be set up for GM tokens to be mintable from any supported source chain, the GM token will then be bridged back to the source chain to be usable by integrations and other projects on the source chain
    • Goal: allow users from any supported chain to trade on GMX utilizing existing liquidity
  • Cross-collateral
    • This feature would enable using e.g. USDC as collateral to trade in the single token ETH [WETH-WETH] pool
    • Goal: better utilization of liquidity, improve flexibility for traders and liquidity providers
  • Capped price impact
    • Based on the ideas from Q
    • Instead of charging price impact on position open, the open position price impact can be stored in the contract and the net price impact (open + close price impact) can be charged on position close
    • This would allow price impact rebates to be applied to an entire trade
    • For example, if the price impact cap for BTC and ETH is set to zero, this would lead to price impact being virtually zero for these markets
      • While price impact is deducted upfront, the price impact will later be rebated if no price manipulation was detected
      • Current price impact rebates require a manual review process, which leads to the time required for claiming to be between 3-10 days
      • The Chaos Labs Risk Oracle could potentially support automating the flagging of price manipulation to reduce this time needed to 3 days
    • For markets that may not be as liquid as BTC and ETH, some price impact would likely be required but can still be capped depending on the parameters recommended by Chaos Labs
    • Goal: reduce price impact for traders
  • Net OI
    • Based on the same post above from Q
    • We propose to add a configuration to restrict the max difference between the long and short open interest
    • This restriction would apply only on position open and not on position close
    • For example, if there is $100m of liquidity in a GM pool and the max difference is set to $60m, potentially reserve factors for the pool could be increased from 1 to e.g. 1.5, so that $150m of open interest would be supportable by $100m of liquidity, while minimizing the exposure of the pool through the capped net open interest
    • A few cases can be considered in evaluating the practicality of this change:
      • Longs are in profit, shorts are in profit
        • In this case regular ADL would apply if the net PnL increases too much relative to the pool size
      • Longs are in profit, shorts are in loss
        • If longs close, the GM pool would reduce in size to payout the profits, and there would be pending losses from the shorts to cover this payout, in this case the pool is not significantly exposed
        • If longs close and after that price changes such that shorts change from being in loss to being in profit, then ADLs would apply
        • If shorts close, the GM pool would increase in size, which would help to back pending profits from longs, in case the profits of longs increase much more and insufficient shorts are opened to hedge the profits, then ADLs would apply
    • If the supportable open interest can be increased, then the borrowing fee can be reduced even in times of high open interest, while still creating a significant APR to incentivise liquidity into the GM pool
    • Goal: increase liquidity efficiency

It will take a few months to complete the changes in GMX V2.2 and the changes may be released in separate phases depending on the timeline and what can be completed.

GMX V2.3

After V2.2, we have a few ideas for V2.3:

  • Cross-margin: a frequently requested feature, the support for cross-collateral in V2.2 should help allow this feature to be created
  • Market groups: currently liquidity in similar perp markets are separated by pools, e.g. ETH [WETH-USDC], ETH [WETH-WETH]
    • This can complicate the trading experience as there would be different pools with different funding rates, etc
    • It may be possible to support market groups which would group all similar perp markets under a single group, for example there can be a ETH/USD group which would have the pools:
      • ETH [WETH-USDC]
      • ETH [WETH-WETH]
      • ETH [USDC-USDC]
    • This would combine perp liquidity in all the pools of a group, so that traders would not need to choose between pools
    • Deposits / Swaps / Withdrawals would still be through individual pools as before
    • With this UX simplified, there can be more options for liquidity providers to provide liquidity in the token which they prefer

After discussion with the community, these proposed plans can be compiled into a substack post.

16 Likes

not good,we need deploy on base not only the cross,the wbtc have high risk now.

Yes, big fan of all of these changes, I think this will really excel GMX to a whole other level.

3 Likes

The timing is great. Love that multichain is coming when the community is debating which chain to go next…
turns out:- everywhere (terms and conditions apply :stuck_out_tongue_winking_eye:)

3 Likes

multichain would allow for Base to be supported

for WBTC, cross-collateral and market groups should help, there is a cross-chain version of cbBTC available on Arbitrum

6 Likes

I want to thank X and all the core contributors for their work. I fully support this proposal, and here are my reasons:

1. Gasless Transactions and Cross-Chain Liquidity Reuse

Under the gasless transaction proposal, users can enjoy a completely seamless trading experience on any EVM-compatible chain without needing to pay gas fees themselves. This means that a user on, say, an Arbitrum-based deployment of GMX could access the full liquidity from all chains where GMX is deployed, leveraging the deepest possible liquidity pool and minimizing price impact. Essentially, this solution allows for direct liquidity reuse across multiple chains, ensuring that every user, regardless of which chain they trade on, benefits from GMX’s entire liquidity reserves.

This approach stands in contrast to the traditional model, where each chain hosts its own isolated GMX instance. With isolated deployments, each new chain launch would face a “cold start” problem—having limited initial liquidity and potentially higher trading costs due to smaller pools. Moreover, if the same market exists on multiple chains in isolation, a single market event on one chain can indirectly affect the market on another chain. For example, if the Arbitrum deployment and the Base deployment both offer the same market (e.g., ETH/USD), and Base suddenly gets a liquidity surge that matches Arbitrum’s liquidity depth, then the cost for an attacker to influence prices might plummet. Either the attacker’s cost decreases (making it easier to disrupt the market) or, to maintain security, both Arbitrum and Base would need to simultaneously raise the price impact, thereby harming overall user experience with higher trading costs.

By introducing gasless transactions and unified liquidity, GMX avoids these pitfalls altogether. The result is a genuinely multi-chain integrated liquidity environment, negating the need to scale price impact linearly with the number of chains. This simultaneously improves security, user experience, and capital efficiency. In short, the gasless transaction solution tackles the fundamental challenge of multi-chain deployments at its core, ensuring that adding more chains doesn’t come at the expense of user experience or liquidity depth.

2. Network Cost Subsidies

When the market experiences significant volatility—such as during a major news event or a sudden price spike—network fees (gas costs) can skyrocket due to congestion. During these critical moments, traders are often most eager to adjust their positions quickly to either capitalize on an opportunity or mitigate losses. If traders know they will be confronted with prohibitively high transaction costs at these times (tens or even hundreds of USD in fees), it discourages them from using the platform at all, since they can’t count on stable fees when they need them most.

On the other hand, consider why GMX has attracted a loyal user base so far: GMX does not have “scam wicks” or artificial price spikes that can unfairly liquidate traders. Traders trust GMX because even in extreme market conditions, they can get a fair price execution. This trust in fair pricing and no scam wicks is a major reason traders choose GMX.

By extending this principle to network costs via subsidies—essentially smoothing out or offsetting these transaction fees—GMX can ensure that even under extreme conditions, traders do not have to contend with sudden and excessive costs. This maintains a level of predictability and fairness that can profoundly influence a trader’s decision to stick with GMX over the long term.

3. Multichain Expansion

GMX’s DeFi scalability potential truly emerges when considering multi-chain expansion across various EVM-compatible environments, while GMX-Solana represents a parallel trajectory into non-EVM ecosystems. GMX, initially rooted on Arbitrum, can seamlessly branch out to any EVM-compatible chain—like Base or other emerging L2s—providing the same deep liquidity and unified trading experience that users enjoy on its original deployment. This approach ensures that traders can access consistently robust liquidity and market conditions without the inefficiencies of isolated, chain-specific markets.

In parallel, GMX-Solana would concentrate on entirely different execution environments, such as Solana’s high-throughput, low-latency network. By operating independently from GMX’s EVM focus, GMX-Solana can tap into Solana’s unique technical advantages and user base, all while linking into the broader liquidity network that both GMX and GMX-Solana help cultivate. The result is a wider DeFi trading ecosystem where GMX covers the EVM side of the spectrum and GMX-Solana opens the door to the non-EVM world, together pushing toward the future.

Eventually, GMX could become the universal layer for derivatives trading: no matter what chain a trader is on, or what environment they prefer, GMX would be there, offering any market with significant liquidity. It represents the next step toward making DeFi liquidity and trading conditions universal, borderless, and omnipresent.

4. Cross-Collateral Functionality

Within GMX, there are currently synthetic pools that, for example, track BCH/USD using BTC and USDC (denoted as BCH/USD[BTC-USDC]). Under the current system, if you wanted to maintain a delta-neutral position or conduct funding rate arbitrage internally (i.e., all within GMX), it’s complex and often impossible. You might want to short BCH/USD using BTC as collateral to offset your BCH exposure, but the platform currently does not allow for that kind of direct matching. Instead, you must rely on external exchanges and additional steps, which increases complexity, cost, and risk.

By introducing cross-collateral capabilities, a trader could directly use BCH as collateral when taking a position in the BCH/USD[BTC-USDC] market. For example, you could open a 1x Short BCH/USD position using BCH itself as collateral. This dramatically simplifies constructing delta-neutral or risk-managed positions and makes it easier for traders to engage in funding rate arbitrage strategies. This leads to improved stability in OI balances, since maintaining a balanced OI distribution becomes more straightforward and less costly. Essentially, cross-collateral functionality removes a key barrier that prevents the internal ecosystem from self-correcting, thereby stabilizing the markets.

5. Capped (Post-Position) Price Impact

This concept focuses on shifting how traders perceive price impact costs. Currently, GMX applies “pre-position” price impact, meaning traders see an immediate negative price impact when they open a position. For example, imagine that opening a position comes with a -5 bps negative price impact. Traders often mentally double this cost, assuming that when they close the position, they’ll experience a similar penalty, effectively treating the total cost as -10bps. This is not actually correct, but it’s how the cost structure is commonly perceived.

In reality, when the trader closes the position, the impact might be reversed, partially offsetting the initial cost. Suppose the closing price impact is +4bps. The net price impact over the entire trade (open and close) is actually just -1bps, not -10bps. On an order book exchange, a -1bps total cost is like a combined opening/closing spread of -1bps, which is very competitive. But because GMX currently shows that initial -5bps cost up front, many traders get the wrong impression and believe GMX’s cost is significantly higher than it really is.

Switching to “post-position” price impact means that traders would see near-zero price impact at opening and only realize the net cost when closing. Here’s a simplified scenario:

• With pre-position price impact: You open a position and see -5bps immediately, so you think you’ll pay another -5bps when closing, totaling -10bps in your mind.

• With post-position price impact: When you open a position, you see 0bps. Only upon closing do you see a final calculation of (for instance) -1bps overall. Traders pay attention mostly when they open positions. By the time they close, they are more focused on whether they made a profit or loss. Thus, a one-time -1bps adjustment at the end feels more natural and far less intimidating than a perceived -10bps at the start.

This subtle shift changes trader psychology dramatically. It reduces cognitive friction and confusion around GMX’s fee mechanism without actually altering the underlying economics of price impact. This encourages more trading since traders won’t be scared off by what appears (but isn’t) a hefty upfront cost.

6. Net OI

The current system caps OI at a level roughly equal to the total pool value, assuming a reserve factor of 1. This is an underutilization of capital. In fact, GMX’s liquidity is already substantial enough to rival the order book depth on major centralized exchanges like Binance in some markets. For large, liquid markets, GMX even surpasses the depth of some Binance perpetual pairs. As the GMX virtual order book goes live, this advantage will become even more apparent.

However, limiting the OI to the pool’s total value is far too conservative and doesn’t reflect the true risk exposure. The actual net risk to liquidity providers (LPs) is much smaller than the raw OI number might suggest. For example, consider a pair like OP/USD. Even though the OI might appear large, the net utilization—i.e., the actual risk after offsetting longs and shorts—is often extremely low (e.g., 0.01%).

By focusing on net OI—considering long and short positions together rather than simply adding them up—GMX can safely support an OI that’s multiple times (or even tens of times) greater than the pool value. This would massively increase capital efficiency and trading volume without significantly increasing LPs’ actual risk.

This approach matches how traditional order books function. On Binance, you might only see a few hundred thousand dollars of liquidity within ±2% of the mid-price, and yet the market supports huge trading volumes without collapsing. GMX can mirror and even outperform that model, providing deep, stable liquidity without “using up” all the capacity just because one side of the market took a big position.

Ultimately, this change would transform GMX from a simple DeFi perpetuals platform into something that truly competes with traditional order book exchanges—offering deep, stable liquidity, minimal price impact, and massive scalability. It redefines market-making by decentralizing it, making it DeFi-native, and allowing it to scale globally across chains and environments.

Conclusion:

These six proposals—ranging from gasless transactions that unify liquidity across chains, through network cost subsidies that smooth out extreme fees during volatile periods, to multichain expansions and cross-collateral features that simplify delta-neutral strategies—are not merely incremental improvements. They collectively represent a foundational shift in how GMX can scale, improve trader experience, maintain OI balance, and handle price impact perception. The use of detailed examples, such as the difference between pre-position and post-position price impact, the complexity of delta-neutral setups without cross-collateral, and the capital inefficiencies of focusing on absolute OI rather than net OI, underscores how these changes directly address key pain points in the current model.

Glory to GMX!

Q

12 Likes

Excellent list of priorities !

On the multichain implementation, if i understand correctly this is an extremely elegant way to go multichain rather effortlessly, without having to deploy on each chain, but has a few caveats. Can you confirm the following ?

  • It would require integration of a 3rd party bridge - if so any partners in mind ?
  • A wrapper contract on other chains would need to handle the bridging in and out + messaging
  • UI will abstract it so from a user point of view it is more or less seamless.
  • Experience on other chains would be close to native but not as fast as being directly trading on Arb or Avax

Thanks !

4 Likes

Your write-up looks fantastic, @xdev_10 and really speaks well to the future of the platform.

Two points:

  • In addition to the technical aspects associated with implementing this multi-chain, I very much hope that the devs dedicate a lot of effort to the ui/ux. I really think the user interface can end up being the “bottleneck” regarding adoption as we’re entering a phase of crypto where more and more non-technical people enter the space. I’ll be frank: there are aspects of the gmx website that still aren’t intuitive, or would be considered intimidating. They work great for people that have already been in defi for years, but “Johnny who just bought his first crypto on coinbase and wants to make a long/short” would still struggle getting his bearings on the gmx website. If this is the method by which we’re expanding to base and other EVMs, then this is our opportunity to capture the marketshare of Johnny Come Lately’s that are new to the space.

  • I couldn’t help but notice there isn’t mention of any updates or new use cases for the GMX token in any of those bulletpoints. Should this be tabled for v2.4 or are there any opportunities being unspoken in Xdev’s post that could benefit the token (aside from more fees feeding into the APR %) ?

2 Likes

Thanks for your proposals. I would like to ask: which bridge should be considered for GMX—Wormholes, LayerZero, or something else?

1 Like

Awesome roadmap! Can’t wait to have this implemented.

Regarding the bridge, Across may have lower fees and seems reputable too. I think it is what Uniswap is using for their new “Unichain” feature.

Edit: yes, cf. Permissionless Bridging is Now Live

2 Likes

would love to see more focus on the multi-chain approach - solana (and Sui). Plus explore other oracles like Pyth that can support those chains. Great job anyway

2 Likes

Regarding 1: I can confirm that significant work is already being done on improving the UI and UX of gmx.io and the GMX dApp.

Regarding 2: additional use cases for the GMX token are indeed not part of this dev outline, but there are ongoing discussions about how to potentially optimise that. In terms of benefits to the token, the impending GMX-Solana deployment and its approach of Buyback & Distribute will be a key driver imho.

4 Likes

Thank you for this question

  • It would require integration of a 3rd party bridge - if so any partners in mind ?

Yes, any bridge that allows a fund transfer and message to be sent cross-chain in a single transaction would be supportable, at the moment based on our evaluation, LayerZero and Across seem most suitable

LayerZero: 10-30 seconds to bridge
Across: a few seconds to bridge

The cost would vary depending on the size of the transfer, so the interface can select the most appropriate bridge based on speed + cost

  • A wrapper contract on other chains would need to handle the bridging in and out + messaging

With LayerZero and Across, our current understanding is that a new contract does not need to be deployed on the source chain, the existing contracts already deployed by these protocols can relay the message, simplifying the deployment process

  • UI will abstract it so from a user point of view it is more or less seamless.

yes

  • Experience on other chains would be close to native but not as fast as being directly trading on Arb or Avax

Trading actions like increase position / decrease position / swaps should be as fast as native if no funds need to be moved between chains

For actions that would require funds to be moved between chains, there will be estimated 1-30 seconds bridging time needed

3 Likes

thank you for this feedback, we agree that while improvements have been made to the stability / speed of the interface, further improvements are needed

these will continue in parallel while the v2.2 + v2.3 contract changes are being developed

for tokenomics, at the moment, we feel that improving the protocol should be the focus for the next few months, and during this time we can continue to discuss new token utilities

3 Likes

Thanks for your proposals. I would like to ask: which bridge should be considered for GMX—Wormholes, LayerZero, or something else?

Awesome roadmap! Can’t wait to have this implemented.

Regarding the bridge, Across may have lower fees and seems reputable too. I think it is what Uniswap is using for their new “Unichain” feature.

@dustinD @yellow thank you for these questions, i believe the following reply would help provide more information on the bridging solution

2 Likes

Hello X,

Happy to see you ship and the plan ahead for the following months. Here are a few comments for discussion. Although I am really excited for cross-margin and the other features in V2.3, I’ll focus on v2.2 for now.

I agree that P1 priority task should be chain-agnostic trading, gasless transactions and optimizing the max OI/total liquidity ratio.

P2 would be network cost subsidies; other tweaks to position fees; and chain-agnostic liquidity provision.

One thing that is missing from this discussion is the integration of RWA and Forex. There has been some talk on this forum about integrating them. There’s also been some X posts (1, 2) highlighting the importance of non-crypto assets on platforms like GMX. Even for synthetic “mirror” assets; not crypto-assets backed by the actual underlying.

Judging by generated volumes on Gains Network, Forex integration would be the first logical step and possible amount to a significant percentage of total volume.

I’m assuming this is a conversation that’s been had between the core contributors. Can you give us a quick summary of the conclusions?

The design of GLV lends itself well to Forex trading (GLF?). A pool backed by USDC could potentially allow synthetic positions of most major FOREX pairs with reasonable leverage. Liquidity provider losses due to off-hour gaps resulting in liquidations could be mitigated by an insurance fund structured in the same way as the network subsidies proposed in GMX2.2.

Further risk analysis can be outsourced to Chaos Labs. However, I assume this risk would be minimal due to the usually more muted volatility of Forex pairs and their difficulty to manipulate without significant capital. Also, they could provide good preliminary data for Chainlink’s ‘8/5’ oracles as GMX moves into RWA.

1 Like

hi @EruditePepe, thank you for the thoughts on this and the questions, for RWA and Forex, I believe @coinflipcanda would be best to provide details on this

Love the direction the roadmap is taking, significant step forward for GMX. Excited by the possibilities that come with cross-chain expansion :blueberries:

2 Likes

I’ve been reflecting on all these different elements of the dev plans, plus what’s been realised this last year. It’s remarkable how much further the protocol has come, and what the coming months will bring in terms of further enhancing accessibility, stability, liquidity efficiency and trader UX.

1 Like