The activation of GMX V2's multi-asset vault architecture represents a fundamental architectural fork, replacing the single, omnibus GLP liquidity pool with a system of isolated GM pools. Under the V1 model, GLP functioned as a single basket of assets providing shared counterparty liquidity for all trading markets. This created a unified risk surface where a catastrophic loss in one market could impair the entire protocol's solvency. The V2 upgrade decomposes this structure, deploying a distinct GM pool (e.g., GM-BTC, GM-ETH) for each supported asset, each with its own isolated risk parameters, collateral composition, and liability profile.
Protocols
GMX V2 Multi-Asset Vault Architecture
Technical analysis of the deployment and activation of isolated GM pools that replaced the monolithic GLP model in GMX V2. Covers upgrade mechanics, liquidity migration, new risk parameters, and the impact on liquidity providers, yield aggregators, and composability.
introduction
VAULT ARCHITECTURE MIGRATION
The Architectural Fork: From GLP to Isolated GM Pools
How GMX V2 replaced the monolithic GLP model with isolated GM pools, fundamentally altering the protocol's risk, composability, and operational profile.
Operationally, this migration is a breaking change for every composability integration. Protocols that previously accepted GLP as a yield-bearing collateral asset must now re-architect to interact with specific GM tokens, each carrying distinct risk and return characteristics. The upgrade sequence involved deploying new Vault, Market, and Oracle contracts, followed by a state transition where liquidity providers were required to actively migrate from GLP to one or more GM pools. This process introduced a temporary dual-state period where both vault systems operated, creating a complex environment for keepers, arbitrageurs, and data indexers who had to monitor both the legacy and new contract sets simultaneously.
The risk model shift is profound. Where GLP concentrated all market-making risk into a single token, GM pools allow for risk compartmentalization. A volatility event in ETH markets no longer directly threatens the solvency of the BTC liquidity pool. However, this introduces new operational burdens: each pool requires independent monitoring of its collateralization ratio, open interest caps, and oracle health. For integrators like yield aggregators and money markets, the due diligence surface expands from one vault token to many. Chainscore Labs can assess the specific risk parameters and integration architecture for protocols composing with individual GM pools, ensuring that the new isolation model does not introduce unmonitored failure modes in downstream applications.
ISOLATED POOL RISK MODEL
V2 Vault Architecture: Quick Facts
Assess the operational and integration impact of the shift from the monolithic GLP model to isolated GM pools.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Liquidity Model | Monolithic GLP vault replaced by isolated GM pools (e.g., GM: BTC/USD, GM: ETH/USD). | Liquidity Providers, Yield Aggregators | Verify which GM pools your strategy interacts with; re-evaluate diversification assumptions. |
Risk Isolation | A shortfall in one pool does not socialize losses across all LPs; each pool has independent risk parameters. | Risk Managers, LPs | Audit pool-specific parameters (max open interest, borrow rate) instead of relying on a single global risk profile. |
Vault Token | GLP token deprecated; replaced by pool-specific GM tokens with distinct pricing and fee accrual logic. | Wallets, Dashboards, DeFi Protocols | Migrate token balance queries and price feeds from GLP to specific GM token contracts. |
Fee Accrual | Fees accrue directly to the specific GM pool facilitating the trade, not a single shared pool. | Yield Aggregators, Analytics Platforms | Update APR/APY calculations to track per-pool fee performance instead of a single aggregate. |
Composability | Protocols integrating with GLP must migrate to GM tokens; legacy GLP integrations will break. | Money Markets, Leveraged Vaults, Bridges | Review and replace all GLP contract interfaces with the relevant GM pool contracts. |
Oracle Dependencies | Each pool may rely on specific oracle configurations for its underlying assets, diverging from a single feed model. | Arbitrageurs, Oracle Providers | Map oracle feeds to each specific GM pool to validate price source integrity and latency. |
Market Deployment | New markets are deployed as new isolated GM pools with their own bootstrapped liquidity. | Market Makers, Traders | Monitor governance for new pool activations to anticipate new trading and LP opportunities. |
technical-context
VAULT ARCHITECTURE
Technical Mechanism: Isolated Pools and Risk Segmentation
How GMX V2 replaced the monolithic GLP model with isolated GM pools to segment risk, enable independent market parameters, and redefine liquidity provider exposure.
The GMX V2 multi-asset vault architecture fundamentally departs from the V1 GLP model by introducing isolated GM pools. Instead of a single liquidity pool backing all trading markets, V2 allows the creation of multiple, independent GM tokens, each representing a segregated basket of assets. This architectural fork means that a liquidity provider in a GM:BTC-ETH pool is not exposed to the profit-and-loss dynamics of a GM:ALT pool, a critical change for risk management and capital efficiency.
Operationally, each GM pool functions with its own set of risk parameters, including borrowing fees, funding rates, and open interest limits, which are independently configurable by governance. This segmentation directly addresses the V1 risk of a single volatile market destabilizing the entire protocol's liquidity. For integrators, this means that the single GLP token address is replaced by multiple GM token addresses, each requiring its own oracle configuration and risk assessment. Yield aggregators and money markets compositing with GMX vault tokens must now manage multiple pool-specific integrations instead of a single universal one.
The shift to isolated pools also changes the nature of liquidity migration and bootstrapping. New market types, such as synthetic forex or commodities, can be launched with dedicated GM pools without requiring existing LPs to absorb unfamiliar risk. However, this fragmentation can lead to uneven liquidity depth across pools, a factor that arbitrageurs, traders, and protocol risk teams must monitor. Chainscore Labs can assess the risk parameterization of new GM pools and review the integration logic for protocols that must now interact with a multi-token vault architecture instead of a single GLP contract.
GMX V2 MULTI-ASSET VAULT ARCHITECTURE
Impact by Stakeholder
Liquidity Providers
The shift from a monolithic GLP token to isolated GM pools fundamentally alters risk exposure and capital management. LPs can now select specific markets to provide liquidity for, avoiding unwanted asset exposure. However, this requires active position management across multiple GM tokens.
Key Actions:
- Evaluate the risk parameters (target weight, borrowing caps) of each new GM pool before depositing.
- Monitor the migration process from legacy GLP to new GM tokens; understand the timeline and any manual claim steps required.
- Re-assess yield strategies, as fee accrual is now isolated per pool, changing the APR profile compared to the single GLP vault.
- Verify the auto-compounding logic for each GM token to ensure rewards are being reinvested correctly.
implementation-impact
VAULT ARCHITECTURE MIGRATION
Integration and Migration Impact
The shift from the monolithic GLP model to isolated GM pools is a breaking change for every protocol, bot, and interface that composes with GMX vault tokens. The following areas require immediate technical review.
01
Yield Aggregator and Auto-Compounders
Vaults that auto-compound GLP rewards must be completely re-architected for the multi-asset GM model. Each GM pool has an isolated reward stream, requiring new strategies for claiming, swapping, and reinvesting fees. Integrators must update their contract interactions to handle multiple pool tokens instead of a single GLP receipt. Failure to migrate will result in stale positions and lost yield. Chainscore can review your new compounding strategy for correctness against the updated FeeHandler and RewardRouter contracts.
02
Lending Market Collateral Integration
Money markets that listed GLP as collateral must reassess risk parameters for each new GM token. Isolated pools have different volatility profiles, liquidity depths, and oracle dependencies than the single GLP basket. Aave, Compound forks, and isolated lending pairs need new price feed configurations and loan-to-value ratios. Liquidators must update their bots to monitor and seize individual GM tokens. Chainscore can perform a risk parameter audit for listing new GM pool tokens as collateral.
03
Portfolio Tracker and Analytics Migration
Dashboards and tax tools tracking user positions must migrate from the V1 subgraph to the V2 subgraph schema. The data model for vault positions is fundamentally different: a single GLP balance is replaced by multiple GM token balances across isolated pools. Historical PnL, fee accrual, and cost-basis calculations must be rebuilt. Teams should run a parallel indexing period to validate data continuity before deprecating the V1 pipeline. Chainscore can support data pipeline migration and reconciliation validation.
04
Cross-Chain Bridge and L2 Composability
Bridges that wrapped GLP for use on other chains must deploy new wrapped representations for each GM pool token. This introduces a fragmented liquidity model where a single canonical bridged asset no longer exists. Cross-chain yield strategies and omnichain vaults must be redesigned to handle multiple pool-specific tokens. Bridge operators should coordinate with the GMX deployment sequence to ensure token availability at launch. Chainscore can review bridge token implementations and cross-chain message passing for GM pool assets.
05
Arbitrage and Keeper Bot Reconfiguration
Bots that arbitraged the GLP basket or executed liquidations against a single vault must be reconfigured for the multi-pool architecture. Each GM pool has independent pricing, open interest, and rebalancing dynamics. Keeper networks need updated logic to monitor multiple vaults and execute pool-specific order flows. The shift to the low-latency oracle suite also requires bots to consume new price feed interfaces. Chainscore can audit your bot's execution logic against the new OrderHandler and Oracle contracts.
06
Legacy GLP Position Remediation
Protocols still holding or interacting with legacy GLP positions face a critical state transition. The GLP token is deprecated, and continued interaction with V1 contracts carries increasing risk as keeper support and oracle maintenance wind down. Teams must build migration paths for users to exit GLP and enter specific GM pools. This may require governance proposals, UI updates, and user communication campaigns. Chainscore can assess your protocol's exposure to legacy GLP and design a safe migration sequence.
VAULT ARCHITECTURE MIGRATION IMPACT
Risk Matrix: GLP vs. GM Pools
Comparative risk analysis of the monolithic GLP model versus the isolated GM pool architecture, highlighting changes in failure modes, trust assumptions, and operational requirements for integrators.
| Risk Area | GLP Model (V1) | GM Pool Model (V2) | Affected Actors | Recommended Action |
|---|---|---|---|---|
Contagion Risk | Single vault shared all market exposure; a loss in one market impaired all LPs. | Isolated pools contain losses to the specific market; other pools remain unaffected. | Liquidity providers, yield aggregators, money markets using vault tokens as collateral. | Review pool-specific risk parameters and diversify LP positions across multiple isolated pools. |
Oracle Dependency | Relied primarily on Chainlink Data Feeds with medianizer logic. | Uses a low-latency oracle suite combining Chainlink Data Streams and Chronicle; introduces new middleware validation. | Arbitrageurs, liquidation keepers, protocols consuming GMX price feeds. | Perform an oracle manipulation and latency risk assessment for each GM pool's specific feed configuration. |
Liquidity Fragmentation | Deep, unified liquidity for all assets. | Liquidity is siloed per pool, potentially leading to higher slippage and shallower depth for individual markets. | Traders, market makers, aggregators routing orders to GMX. | Monitor on-chain liquidity depth per pool and adjust position sizing and routing logic accordingly. |
Composability Risk | GLP token was a widely integrated, yield-bearing ERC-20 asset. | GM tokens are pool-specific, breaking existing integrations and requiring new adapter logic for each pool. | Yield aggregators, lending protocols, dashboards, and any contract holding GLP. | Migrate all integrations from GLP to specific GM tokens; verify new contract interfaces and token addresses against canonical sources. |
Fee Accrual Model | Fees distributed in ETH/AVAX, requiring manual claiming and re-staking. | Fees auto-compound into the GM token, changing the accounting model for yield tracking. | Analytics platforms, portfolio trackers, LP strategy vaults. | Update yield calculation logic to reflect auto-compounding mechanics; validate against on-chain GM token supply changes. |
Keeper Network Load | Keepers executed liquidations and order fulfillment against a single, unified state. | Keepers must monitor and execute against multiple isolated market states, increasing operational complexity. | Keeper operators, protocol engineers monitoring execution reliability. | Audit keeper infrastructure capacity to handle parallel execution across all active GM pools; monitor for execution delays. |
Market-Specific Parameter Risk | Global parameters applied uniformly, limiting fine-tuning. | Each pool has isolated risk parameters (leverage caps, OI limits, funding rates), creating configuration complexity. | Risk managers, governance delegates, traders. | Continuously monitor governance proposals for parameter changes on each pool and assess the impact on specific trading strategies. |
GM V2 MULTI-ASSET VAULT ARCHITECTURE
Integrator Migration Checklist
A technical checklist for protocols, yield aggregators, and trading interfaces migrating from the monolithic GLP model to the isolated GM pool architecture. Each item identifies a breaking change, its operational impact, and the signal that confirms a successful migration.
What to check: Every contract, keeper bot, and off-chain script that references the legacy GLP token address must be updated to interact with the specific GM token address for the target market (e.g., GM-BTC, GM-ETH).
Why it matters: The V2 architecture isolates liquidity per market. Interacting with the deprecated GLP contract will fail or, worse, interact with a stale pool that no longer represents the protocol's live liquidity. This is a hard breaking change.
Readiness signal: A grep or static analysis of your codebase returns zero references to the V1 GLP contract address on the target network, and all integration tests pass against the new GM token contract.
resource-links
GMX V2 VAULT ARCHITECTURE
Canonical Resources
Primary sources for teams reviewing GMX V2 isolated GM pools, contract interactions, governance-controlled parameters, and integration risk. Use these resources to verify live addresses, ABI changes, pool composition, and upgrade status before deploying production systems.
04
GMX Contract Address and ABI Verification
Before interacting with GMX V2 contracts, verify the current deployed addresses, proxy implementations, ABIs, and chain-specific deployments from official GMX resources and block explorers. The V2 architecture uses multiple contracts rather than a single GLP-style vault surface, so integrations commonly touch routers, readers, market tokens, data stores, handlers, and oracle-related contracts. A safe production workflow should compare official address lists with explorer-verified source code, confirm proxy implementation history, and block deployments if an expected address, ABI, or bytecode hash changes without a corresponding governance or release signal.
06
Chainscore Review Path for V2 Integrators
Teams building on GMX V2 should maintain a review checklist covering contract address verification, pool-specific exposure modeling, oracle dependency analysis, keeper and execution assumptions, governance parameter monitoring, and failure-mode tests for deposits, withdrawals, liquidations, and market pauses. Chainscore Labs can support protocol impact assessment, smart contract integration review, GM token risk modeling, and monitoring design for vaults, money markets, leveraged strategies, dashboards, and bots that depend on the GMX V2 multi-asset vault architecture.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
VAULT ARCHITECTURE FAQ
Frequently Asked Questions
Common questions from operators, integrators, and risk teams about the GMX V2 multi-asset vault architecture and its operational implications.
The V2 architecture isolates risk into individual GM pools, replacing the single GLP pool where all assets shared a common risk profile. Each pool has its own collateral composition, open interest limits, and fee parameters.
Key risk changes:
- A shortfall in one pool (e.g., from a large profitable trader position) does not directly socialize losses across all LPs
- LPs can now choose exposure to specific asset classes rather than accepting a blended risk profile
- Each pool's risk parameters (leverage caps, funding rates, spread configurations) are independently governed
What to verify:
- Confirm which GM pool(s) your vault or strategy interacts with
- Review the specific risk parameters for each pool, as they can diverge significantly
- Monitor pool utilization and open interest separately; a single pool reaching capacity does not mean the entire protocol is constrained
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.