GMX Smart Contracts (V1 & V2): Architecture and Addresses
GMX is a pioneer of the decentralized perpetual futures segment (Perp DEX), having popularized the "liquidity pool as counterparty" model. Originally launched on Arbitrum and Avalanche, the protocol has undergone significant evolution. The GMX V2 architecture is a sophisticated synthetic layer that minimizes systemic risk through isolated markets, the modular DataStore and ultra-fast oracles.
Below is the verified technical registry of smart contract addresses across the GMX ecosystem. This reference is mission-critical for dApp developers, vault operators and arbitrageurs interacting with the contracts directly through the Ethers.js, web3.py or viem libraries. A practical API integration guide lives on a separate page.
1. Core ecosystem tokens ($GMX and $GLP)
The $GMX token is the protocol's utility and governance asset. Version V1 relied on $GLP — a single index token for liquidity providers. An important clarification for developers: there are two GLP smart contracts. The base token is used by the protocol for internal accounting, while users hold the staked version in their wallets (Staked GLP, or fsGLP), which is what generates yield.
0xfc5A1A6EB076a2C7aD06eD22C90d7E710E35ad0a
Arbiscan ↗
0x4277f8F2c384827B5273592FF7CeBd9f2C1ac258
Arbiscan ↗
0x1aDDD80E6039594eE970E5872D247bf0414C8903
Arbiscan ↗
0x62edc0692BD897D2295872a9FFCac5425011c661
Snowtrace ↗
2. GMX V2 Architecture: Isolated Pools and DataStore
The key paradigm shift in GMX V2 is abandoning the global pool (GLP) in favor of isolated markets (GM Pools). Each market (e.g., ETH/USDC or BTC/USDT) has its own liquidity token (gmToken). This allows the platform to list more volatile assets (long-tail assets) without putting the protocol's entire capital at risk. The full GMX ecosystem overview includes an analysis of tokenomics and fee distribution.
0x7C68C7866A64FA2160F78EEaE12217FFbf871fa8
Arbiscan ↗
Function: The main gateway for creating deposit requests, withdrawals, swaps and opening margined positions in the V2 architecture.
0xFD70de6b91282D8017aA4E741e9Ae325CAb992d8
Arbiscan ↗
Function: In V2, pool balances, market parameters and open user positions are not scattered across many small contracts. They are all stored centrally in the DataStore. This radically simplifies protocol upgrades, since the storage layer is fully decoupled from the logic layer.
GMX V2 smart contracts do not execute a trade within the same transaction (unlike AMMs such as Uniswap).
- Step 1 (User): The user sends assets and creates an
Order(request) through theExchangeRoutercontract. - Step 2 (Keeper): An automated off-chain bot (Keeper) pulls a cryptographically signed price from the oracle and invokes the execution function on the handler contract.
*This architecture makes front-running and sandwich attacks mathematically impossible, because the execution price becomes known only after the request has been committed to the blockchain.
3. Oracle Infrastructure and Risk Management (ADL)
To support leveraged trading of up to 50x-200x (depending on the asset), the protocol requires zero-latency quotes. Traditional push oracles proved far too slow.
Chainlink Data Streams (Pull Model)
GMX V2 features tight integration with Chainlink Data Streams. Instead of waiting for periodic price "writes" to the blockchain by oracles, the V2 infrastructure uses a pull model. Keeper bots pull the freshest quotes from the Chainlink decentralized oracle network (DON) themselves and attach them directly to the execution transaction.
Advantages:
- Sub-second price updates (protection against latency arbitrage).
- Precise position liquidation without slippage.
Auto-Deleveraging (ADL) & Impact Fees
Because liquidity in V2 is split across GM pools, a new bankruptcy-protection mechanism became necessary — Auto-Deleveraging (ADL). If open interest on a market becomes critically skewed and traders' unrealized profits exceed the stablecoin reserves in a given pool, the smart contract will automatically close the most profitable positions. Current liquidity and TVL metrics help gauge pool health.
Additionally, Impact Fees are in play: the contracts dynamically penalize traders who amplify imbalance and reward those who trade toward restoring the pool's equilibrium.
Security and Audits
All GMX smart contracts (the gmx-synthetics and gmx-contracts repositories) have passed multiple security reviews by Quantstamp, ABDK and Sherlock. Detailed audit reports with vulnerability breakdowns are available in the archive. Changes to the protocol's risk parameters are made through on-chain voting by the GMX DAO and Risk Committee.
Frequently Asked Questions (FAQ)
The base GLP token (0x4277...c258) is used by the smart contract itself for internal pool-share accounting. Users who add liquidity, however, receive the wrapped version in their wallets — Staked GLP (fsGLP) at 0x1aDD...8903. It is this version (Fee + Staked GLP) that automatically accrues fee revenue in ETH or AVAX.
In GMX V1, a single multi-asset pool (GLP) operated, where a basket of BTC, ETH, USDC and other tokens served as common collateral. In GMX V2, the architecture moved to isolated markets (GM Pools). This prevents systemic contagion: if one asset suffers an exploit or abnormal volatility, it cannot bring down the platform's other pools.
Beyond high adaptive funding rates, V2 implements the Auto-Deleveraging (ADL) mechanism. If a pool cannot pay out profits due to severe imbalance (for example, when 90% of traders have earned huge multiples on longs and the pool's liquidity cannot cover their gains), the system forcibly realizes profits (closes positions) for the most successful traders at the current market price.