GMX V2 Perps

Protocol identification

• Name: GMX V2 Perps (perpetual futures segment of the GMX V2 exchange).
• Category: Decentralized perpetual futures (perps) and synthetic derivatives DEX, with isolated GM liquidity pools per market.
• Website / app: app.gmx.io (via Arbitrum ecosystem and GMX profiles; treated as protocol’s own site → *unverified marketing claim*).
• Docs: Public docs are referenced in ecosystem articles and GMX ecosystem overviews, but specific URLs are not independently confirmed here → *unverified marketing claim*. Launch timing
• GMX (v1) launched on Arbitrum in September 2021, then expanded to Avalanche.
• GMX V2 (synthetics / perps architecture) is described as launched in July–August 2023 on Arbitrum. Chains and share of TVL
• Active chains for GMX V2 Perps per current analytics: Arbitrum and Avalanche.
• TVL distribution (aggregator data, *not on‑chain verified*): about 94% on Arbitrum, ~5.5% on Avalanche; remaining share is minor rounding. Native token
• The ecosystem identifies GMX as the native / governance token of the overall GMX protocol; V2 perps use GM pools and synthetic markets but do not introduce a separate native token. Main contracts / addresses Tooling for direct on‑chain queries is unavailable in this turn; therefore specific GMX V2 Perps core contract addresses on Arbitrum and Avalanche are Not verifiable as of 2026‑08‑29 under the required standard.
• Analytics and ecosystem write‑ups reference the gmx-synthetics smart contract system as the core V2 implementation and note that each market uses its own GM pool contract.
• Several yield aggregators list pools such as ETH‑USDC, ETH‑ETH, WBTC.B‑USDC, WBTC.B‑WBTC.B on Arbitrum and AVAX‑USDC on Avalanche, but they do not provide auditable core contract lists.
• Explorer verification status for those core contracts is Not verifiable as of 2026‑08‑29 without direct explorer lookups. Fork lineage / architecture
• GMX V2 is presented as a second‑version architectural overhaul of GMX, not as a direct fork of another perps DEX.
• Key changes vs GMX v1:
• Replace the single GLP multi‑asset pool with isolated GM pools per market (e.g., BTC‑USD, ETH‑USD), isolating liquidity and configurable parameters per market.
• Use gmx-synthetics contracts and Chainlink Data Streams for low‑latency oracle pricing instead of the prior oracle setup.
• No independent evidence in retrieved data of GMX V2 being a fork of a specific upstream protocol (e.g., a known perps DEX) → it appears to be an in‑house evolution. Audits and malicious‑modification history
• Ecosystem governance and integration proposals (e.g., dHEDGE integration) mention that “GMX guards” will complete audit before rollout, implying audited interaction patterns, but this is about the integrator’s contracts, not necessarily full GMX V2 core contracts.
• Independent confirmation of GMX V2 core smart contract audits (auditor names, dates, scope) is Not verifiable as of 2026‑08‑29 from the retrieved data alone.
• No independently sourced reports of malicious modifications or exploited fork variants of GMX V2 Perps surfaced in the available material → absence of evidence, not proof of safety.

GMX V2 Perps looks like a real, mature product rather than a pure landing page: GMX Docs describes active mainnet integrations on Arbitrum and Avalanche, SDK v2 reads market data, positions, orders, wallet balances, and allowances over HTTP, and it also includes order submission and GM account deposit/withdrawal helpers. The docs also expose an OpenAPI reference and GraphQL endpoints, so there is a documented open API surface for integrators. The documentation and UX appear reasonably developed, with separate API, SDK, and getting-started pages rather than marketing-only copy. However, live deposit/withdrawal functionality is only verifiable from the docs as supported workflows; actual success rates, current app uptime, and whether the public web app has broken links or fake metrics are not verifiable as of 2026-08-29 from the available web evidence. The main site/domain references in third-party sources point to gmx.io, and I did not find evidence of a template-clone or fake portal in the material retrieved. Overall: real protocol, real app/docs stack, and a documented API; exact front-end health and live transaction reliability are Not verifiable as of 2026-08-29.

GMX docs list Certora as an auditor of GMX Synthetics (November 2023). The available results did not surface a report with verified severity counts, fix status, or bytecode-match confirmation.

GMX docs list Dedaub as an auditor of GMX Synthetics, and a secondary source says the Nov 2022 Dedaub review found minor reentrancy and logic issues that were fixed. Specific critical/high/medium counts were not verifiable from the available results.

GMX docs say Guardian is the primary auditor for GMX V2 and conducted 8 engagements between October 2022 and September 2023, totaling 88 person-weeks and 365 findings remediated or acknowledged across severities. The docs also say Guardian continued auditing later protocol updates through 2024–2026.

GMX V2 Perps has an active bug bounty program on Immunefi. The program is listed as live since 20 October 2021 and was last updated on 28 August 2026. Parameters: the public Immunefi resources page states a maximum bounty of $5,000,000. GMX’s security docs also say the bounty covers all repositories under github.com/gmx-io and direct readers to Immunefi for the full scope, reward tiers, and rules. One explicit rule visible on the Immunefi page is that detection of malicious timelock transactions is bounty-eligible if reported within 1 hour after the malicious transaction was sent. Results: the sources provided do not list a complete payout history or count of resolved submissions for the GMX V2 Perps program. It is therefore Not verifiable as of 2026-08-29 how many findings were paid, or the total amount paid, from the supplied sources. A separate secondary article claims the program has already prevented at least one critical bug and that total payouts were roughly $1.05M, but that figure is not confirmed by the primary Immunefi resources provided here, so it should be treated as unverified.

GMX V2 Perps’ main external dependency is Chainlink Data Streams for pricing; orders are keeper-executed against oracle-derived bid/ask values, so oracle staleness, mispricing, or downtime can cause bad fills or incorrect liquidations. The protocol docs also note that some contracts/readers/events may not be audited, so integration surfaces are not uniformly covered. The protocol is not a CLOB and does not rely on order-book counterparties, but it does depend on keepers to submit execution transactions; if keepers fail or are delayed, trading and withdrawals can face denial-of-service risk. On Arbitrum and Avalanche, the primary counterparty exposure is therefore the underlying chain and its infrastructure, not a custodian or RWA issuer. I did not find verified evidence of custodial storage, RWA/SPV exposure, or meaningful CEX/MM dependency in the gathered sources. Not verifiable as of 2026-08-29. The strongest risk concentration is in the oracle + execution path: a prior GMX V1 AVAX/USD manipulation exploit is repeatedly cited in independent coverage as the reason V2’s oracle design matters, showing that oracle-linked markets remain vulnerable in stress or low-liquidity scenarios even after the V2 redesign. A separate cross-chain risk is that GMX operates across multiple networks, so operational exposure is split by chain; one independent risk review said TVL was concentrated on Arbitrum and Avalanche and flagged lacking on-chain failover across oracle/bridge dependencies, but that is an aggregator assessment rather than raw-chain verification.

GMX V2 Perps is organized as a non-custodial protocol: users trade directly from their own wallets, and the protocol does not require a deposit into a centralized account or transfer custody to GMX. For traders, the practical custody model is self-custody throughout the trade lifecycle; positions are opened and settled via smart contracts rather than by handing assets to an operator. For liquidity, custody is split into market-specific smart contracts. On GMX V2, liquidity providers supply assets to GM pools (one pool per market), while GLV vaults allocate liquidity across multiple GM pools; LPs retain on-chain claims on those pool/vault positions rather than ceding assets to a custodial intermediary. This design means custody is organized by contract and market: each GM pool is isolated, so exposure and collateral backing are separated per market instead of being commingled in a single omnibus pool. On Avalanche and Arbitrum, the same model applies at the protocol level, but the exact asset composition can differ by market and chain; from the provided sources, the custody structure is clear, while chain-by-chain balances and TVL splits are Not verifiable as of 2026-08-29 without on-chain queries.

Since launch, the clearly documented major incident in the provided sources is the July 2025 GMX V1 exploit on Arbitrum, not GMX V2. GMX’s own July 2025 incident update is referenced by secondary sources as affecting V1 only, with V2 stated to be unaffected.

GMX V2 Perps uses a hybrid key-management model rather than a single admin key. For users, *classic trading* is fully self-custodial: each trade is signed in the wallet, so the user keeps control of the private key and funds. For lower-friction trading, *express trading* uses off-chain message signing and a relay-managed submission flow, and *express + one-click* adds a locally stored sub-account key that can auto-sign without manual confirmation. Operationally, GMX also relies on several non-user service roles: oracle keepers sign reference prices, archive nodes store/query those signed prices, and order keepers bundle prices with user requests and execute them on-chain. Protocol permissions are governed in contracts via a RoleStore, where a RoleAdmin can grant and revoke roles; the deployer initially holds RoleAdmin and is expected to remove it after setup. On the source material available here, the exact current custody and rotation practices for any admin or multisig keys are Not verifiable as of 2026-08-29.

GMX V2 Perps uses a modular, upgradeable smart‑contract architecture on Arbitrum and Avalanche with multiple admin / guardian roles, but remains non‑custodial in the sense that users can close positions and withdraw liquidity through protocol functions even if admins are active. ### Core contracts & architecture GMX V2 separates responsibilities into bank, data storage, logic, and event contracts to allow upgrades without migrating user funds. Key components mentioned in docs include:

• DataStore – centralized storage for configuration, risk parameters, fees, and market state.
• Reader / GlvReader – view contracts exposing positions, markets, prices.
• Bank‑style contracts for collateral, GM / GLV liquidity, and settlement (names vary by chain/market). Contracts are explicitly designed to be upgradeable, with logic separated from storage so new implementations can be wired in while preserving state. The protocol runs the same architecture on Arbitrum and Avalanche, with chain‑specific address lists published in docs. > On‑chain verification of exact addresses, proxy patterns and decoded admin events: Not verifiable as of 2026‑08‑29. ### Admin, owner, and emergency roles GMX security documentation describes a multi‑layered admin structure:
• Guardian auditor is engaged on every major upgrade and has done many V2 reviews, indicating frequent contract changes and active governance over parameters.
• Protocol‑level roles control: fee configuration, listing / delisting markets, collateral parameters, maximum leverage, and risk caps.
• There are *emergency / pause* capabilities for V2 synthetics, referenced in audit scopes (e.g., fee automations, gasless calls, cross‑chain V2.2), implying some contracts can be paused or have trading restricted in adverse conditions. Timelock delays, exact admin addresses, and whether ownership is renounced or controlled by a multisig cannot be confirmed from current off‑chain sources alone. > Timelock duration, role renunciation, and specific admin/wallet identities: Not verifiable as of 2026‑08‑29. ### Upgradeability and user exit Docs emphasize upgrades "without fund migration", meaning user balances remain in the same storage while logic contracts change. Users interact via:
• Closing perp positions and withdrawing collateral through the standard trading interface.
• Exiting GM / GLV liquidity by redeeming tokens through bank contracts. There is no indication of an admin ability to seize user funds; risk is mainly around changing parameters (fees, caps, listings), pausing trading, or modifying oracle / risk logic. ### Worst case if keys are compromised If admin or guardian keys controlling upgrade/parameter roles are compromised, credible scenarios include:
• Malicious upgrade of logic contracts to miscalculate PnL, fees, or liquidations, draining GM / GLV pools.
• Changing oracle configuration to push bad prices, forcing mass liquidations or siphoning protocol funds.
• Pausing markets, preventing new positions or orderly exit, though pure fund theft would still require hostile logic changes. Because GMX V2 is upgradeable and actively managed, smart‑contract governance risk is material: a key compromise could turn into protocol‑level theft or freeze, even though user balances are not directly custodied by a single EOA.

GMX’s core team is generally described as pseudonymous/anonymous, not a fully public founding team. Multiple sources say the protocol does not publish a clear list of real-name founders; the visible technical lead is often identified by the handle xdev10 / xdev_10, while community governance materials name operational contributors rather than a formal incorporated executive team. For credibility, the clearest public background is that GMX traces its origins to earlier DeFi efforts, especially Gambit Financial on BNB Chain, and older community writeups also connect the team to prior projects such as XVIX and GMT/xGMT. Those references are consistent across independent summaries, but they are still secondary-source reconstructions rather than a fully disclosed founder history. A reality-check point is that the protocol has had a major exploit: a July 2025 report states a hacker stole about $40 million, and that the breach did not affect GMX V2 or the native token. That means the protocol is not “hack-free,” even if V2 itself was not the impacted component. On operational transparency, GMX governance materials indicate a 2-of-3 multisig with two publicly named signers: Krunal Amin and Benjamin Simon; a third signer is pseudonymous. This suggests a real operational structure, but not a fully open founder/corporate identity model. A real-office / onshore-offshore determination is Not verifiable as of 2026-08-29 from the gathered sources. Likewise, a formal legal-entity footprint beyond governance and contributor roles is not clearly established in these sources, so the safest conclusion is that GMX looks like a real, functioning DeFi protocol with public governance touchpoints, but with a web-front over a largely pseudonymous core team.

GMX V2 perps currently has a mixed but overall serious, security‑focused reputation: the protocol is seen as a leading perp DEX with strong audit and bug‑bounty practices, but its brand is materially affected by severe incidents and critical bugs in GMX V1. Security / audits / bug bounties

• GMX V2 (synthetics) has been audited by multiple reputable firms, including Guardian (primary auditor, multiple engagements), ABDK, Certora, Dedaub and Sherlock, with hundreds of findings remediated or acknowledged.
• The project maintains an active bug bounty program via Immunefi with rewards reportedly up to $5m, one of the largest in DeFi, covering all GMX contracts.
• GMX has paid large bounties historically (e.g., ~$1m to Collider Research in 2022 for a critical flaw, plus several GMX V1 bounty findings disclosed publicly), reinforcing a reputation for incentivizing white‑hat reporting. Major incidents and criticisms (largely V1, reputational spillover to V2)
• GMX V1 has suffered multiple serious issues, including:
• A price‑manipulation exploit against AVAX/USD in 2022 (~$565k).
• A re‑entrancy vulnerability that enabled a July 2025 exploit draining ~$42m from the GLP pool on Arbitrum V1; V2 and Avalanche were reportedly unaffected.
• The 2025 exploit triggered extensive criticism of the limits of audits and GMX’s security practices, with commentators highlighting that the exploited code had been audited and that a subsequent fix introducing the bug had gone unaudited.
• GMX’s response—on‑chain negotiation of a white‑hat bounty (~$5m), recovery of most funds, and a ~$44m compensation plan for affected users—is generally viewed positively and often cited as an example of good incident handling and user remediation. Operational / design concerns (V2)
• Analysis of GMX V2 has flagged keeper centralization risk: order execution relies on keepers, creating potential denial‑of‑service and transaction‑reordering concerns if keepers fail or misbehave.
• Oracle and market‑structure risks remain a theme, given prior price‑manipulation episodes and the systemic nature of oracle dependence, though V2’s Chainlink integration is seen as an improvement. Legal / regulatory / fraud / sanctions
• There are no credible public allegations of fraud, rug pull, or insolvency against GMX itself in the reviewed material.
• Reported hacks involving GMX‑related positions (e.g., Abracadabra’s GMXCauldronV2 exploit) targeted other protocols’ contracts; GMX clarified its own contracts were unaffected, which independent security write‑ups support.
• No direct references to sanctions, formal regulatory actions, or court cases against GMX, its founders or investors were found. Not verifiable as of 2026‑08‑29. Sentiment / overall reputation
• Among DeFi practitioners, GMX is widely regarded as a top‑tier perp DEX with proactive security culture, but the GMX V1 2025 exploit and multiple critical post‑launch bugs are persistent reputational scars that drive ongoing scrutiny of GMX V2’s security, keeper design, and audit/bounty processes.

GMX V2 Perps is a market-making / liquidity-provision protocol for perpetuals, not a passive staking product: users deposit collateral into isolated GM liquidity pools, and traders use those pools for spot/perp execution. The yield comes primarily from real trading activity—position open/close fees, swap fees, liquidation fees, and borrowing fees—so the return is broadly organic, though it is highly dependent on trading volume and volatility rather than guaranteed emissions. Economically, it is not a directional strategy for LPs; LPs are effectively on the other side of trader flow and can experience PnL from market-making / inventory exposure. The protocol’s design uses multi-asset pools and isolated markets, with fees that can vary by trade impact; third-party coverage reports 0.04%–0.06% position fees and up to 100x leverage for traders. There are no protocol-native lockups highlighted in the gathered sources; withdrawal mechanics and gate/limit details are Not verifiable as of 2026-08-29. Likewise, the extent of leverage/looping/restaking/external yield exposure for liquidity providers is Not verifiable as of 2026-08-29. Fee/revenue split reported by DeFiLlama is 37% of collected fees to revenue, split into 10% treasury and 27% GMX token holders; the remaining share accrues to liquidity providers. This implies protocol revenue exists, but the dominant LP yield source is trading activity rather than subsidies. On TVL, the gathered sources are inconsistent and not on-chain verified in this run: DeFiLlama shows GMX V2 Perps with Average APY 6.9% on the main page and 21.82% on an ARB-denominated view, while a third-party dashboard reported roughly $177.5M TVL and ~94% Arbitrum / ~5.5% Avalanche exposure. Because the sources disagree and Dune/on-chain checks were unavailable, TVL total/by product/by chain/trend is Not verifiable as of 2026-08-29. APY appears volatile and highly volume-dependent: the available snapshots range from 6.9% to 21.82%, and external commentary suggests GM pool APYs can move materially with trading activity and volatility. That makes sustainability conditioned on persistent flow, not fixed emissions.

GMX V2 Perps has no on-chain reserve/treasury balance that is verifiable from the provided sources alone; Not verifiable as of 2026-08-29 for exact treasury size, reserve addresses, composition, custody, control, reserve policy, or attestations. The only directly relevant protocol-level data in the search results is TVL by chain from aggregators, which is not the same as treasury or reserves: DefiLlama shows TVL of $171.94m, with $162.16m on Arbitrum and $9.03m on Avalanche, while other aggregators report materially different TVL figures, indicating that even protocol asset depth is inconsistently measured across sources.

GMX v2 perps use the GMX and GLP tokens from GMX v1; there is no separate v2-native token. All tokenomics refer to these. > On-chain data: Not verifiable as of 2026-08-29. ### Native token & contracts

• GMX (ERC‑20, Arbitrum/Avalanche) – governance and value-accrual token.
• GLP – index-style liquidity provider token, different per chain. Exact contract addresses must be taken from explorers; not verifiable as of 2026-08-29 under current tool limits. ### Supply, market cap, FDV
• GMX has a max supply cap of 13.25m GMX across chains.
• Supply is split between mainnet and esGMX (escrowed) forms; detailed circulating vs total supply figures vary by chain and are reported by aggregators like Coingecko/DefiLlama.
• Market cap and FDV are aggregator-derived and change continuously; up-to-date values are available on market data sites. ### Utility & governance
• GMX utility:
• Protocol governance via Snapshot and on-chain voting.
• Revenue share: 30% of protocol fees to GMX stakers; the rest to GLP and other sinks.
• Staking rewards in ETH/AVAX plus esGMX; stakers receive multiplier points.
• GLP utility:
• Represents LP share of the trading pool; earns trading fees and funding. ### Revenue share, buybacks, burns
• Fees from swaps, leverage trading and liquidations are split between GMX stakers, GLP holders and the protocol reserve.
• GMX implements buyback and burn mechanisms funded from fees, reducing GMX supply over time. ### Emissions & unlocks
• GMX emissions mainly via esGMX vesting for stakers, contributors and liquidity incentives.
• Team/investor/treasury allocations and detailed unlock schedule are described in the GMX tokenomics docs and governance, but specific on-chain execution of announced unlocks is Not verifiable as of 2026-08-29. ### Allocations & concentration
• Public materials describe allocations to community incentives, contributors, team/treasury; granular top-holder concentration and insider wallet behavior require on-chain holder analysis, Not verifiable as of 2026-08-29. ### Control functions
• GMX contracts are upgradeable via governance; exact presence of mint/blacklist/fee-switch functions and their controllers must be confirmed per contract on explorers, Not verifiable as of 2026-08-29. ### DEX liquidity & listings
• GMX is primarily listed on centralized exchanges and major DEXs (Uniswap, Sushi, Trader Joe) on Arbitrum and Avalanche, with deep liquidity around GMX–ETH and GMX–USDC pairs.
• GLP is non-transferable in the usual sense and mainly exists within the GMX protocol.

GMX V2 Perps would be expected to experience severe stress if BTC fell below $10,000, because BTC is a core reference asset for perp markets and a sharp downside move would likely increase liquidations, funding dislocations, and liquidity-provider losses in BTC-linked markets. GMX V2’s architecture is designed to isolate risk by market rather than pool all assets together, so stress in BTC markets should primarily transmit within the BTC market and not automatically become a protocol-wide bad-debt event. For GMX V2, the key mechanism is market isolation: each market has its own synthetic pool and backing assets, which the V2 design explicitly uses to contain losses to the affected market. That means a BTC crash below $10,000 is more likely to create localized pressure on BTC perpetual liquidity and traders than to mechanically destabilize unrelated markets such as ETH or AVAX. The main stress channels are:

• Liquidation pressure on leveraged longs, which would likely rise sharply in a fast BTC drawdown.
• Funding-rate distortion, because GMX V2 funding adjusts with market imbalance and can spike when one side becomes heavily crowded.
• LP mark-to-market losses in BTC-backed exposure, depending on the market’s composition and skew.
• Higher price impact / execution slippage in stressed conditions, as the protocol’s risk framework explicitly relies on price impact and OI controls to limit abusive or destabilizing flow. What cannot be verified from the available sources is the exact loss size, insolvency threshold, or chain-by-chain TVL impact for Arbitrum versus Avalanche under a BTC sub-$10,000 scenario. Not verifiable as of 2026-08-29. The most defensible conclusion is that BTC below $10,000 would be a high-stress, high-liquidation scenario for GMX V2 Perps, but the V2 design should limit the damage mainly to BTC markets rather than create immediate whole-protocol contagion.

GMX V2’s market design materially limits *cross-market* contagion: each market is isolated, and bad debt in one market does not automatically impair other markets’ LP positions. For a 20% depeg of the largest collateral in a given market, the immediate loss to that market’s collateral value is proportional to that token’s weight in the market basket; if the depegged token is worth 20% of the basket, NAV falls by about 4% ( 20% d7 a20%), and if it is worth 50% of the basket, NAV falls by about 10%. What I can verify from the available sources is the *mechanism*, not the live exposure mix: GMX V2 uses linear PnL math, per-market synthetic pools, and configurable collateral composition, but the exact Arbitrum/Avalanche market collateral weights are not provided in the retrieved sources. Because of that, the portfolio-level impact on GMX V2 Perps is Not verifiable as of 2026-08-29. Risk interpretation for this scenario:

• If the depegged collateral is a small slice of the market basket, the loss is limited and mostly absorbed by that market’s LPs.
• If the depegged collateral is the dominant asset, the market can face a sharp NAV shock, accelerated liquidations, and socialized losses inside that market pool.
• Arbitrum and Avalanche exposures are separate at the market level, so the stress should be analyzed chain-by-chain rather than as one combined pool. The protocol docs also note that collateral can be held in ETH or stables and that margin/collateral mechanics are configurable, so the actual stress outcome depends on the specific market’s parameters and current composition.

For a fraud committed by the DAO or owners, the main risk is governance/privileged-role abuse, not an operating-chain exploit. Public risk analyses flag that a compromised or malicious admin/config role could change key parameters, redirect fees, or grant bridge/control permissions in ways that could extract value from traders and LPs across GMX deployments; however, the exact degree of centralized control, multisig composition, and abuse resistance for GMX V2 on Arbitrum and Avalanche is Not verifiable as of 2026-08-29. I did not find evidence in the supplied sources of an actual DAO fraud incident for GMX V2 Perps. The strongest concrete historical event in the result set is the July 2025 GMX V1 Arbitrum exploit, which GMX and media sources describe as a smart-contract vulnerability and not DAO fraud; GMX V2 was reported as unaffected. For a stress case, the realistic loss channel would be: privileged governance actions could misroute protocol revenue, alter reward logic, or change risk parameters to advantage insiders at the expense of users. That is a governance integrity scenario rather than a technical hack, and the web results do not provide enough verifiable on-chain evidence to quantify it for GMX V2. Assessment: low evidence of past DAO fraud, but non-zero governance abuse risk remains because the protocol depends on privileged roles and cross-chain operational controls.

For a stress scenario on GMX V2 Perps, the key point is that the primary yield source can turn negative over a 30-day window if trading activity, borrowing demand, liquidation flow, and favorable price-impact capture are weak. GMX’s own materials state that LP economics come from trading fees, borrowing fees, funding fees, price impact, and liquidations; if these inflows fall, yield falls with them. For a concrete 30-day reference, YieldScope shows the Arbitrum ETH-USDC GMX V2 Perps pool with 19.4% APY and 10.3% 30d avg. That is not a negative 30-day yield, but it does show that the realized yield has already been materially below the current APY, which is consistent with a stress regime where fee generation weakens. If you are asking whether the protocol’s primary yield source can become negative under stress, the answer is yes in principle, because GMX V2 LP returns are not fixed coupons; they are the net result of variable fee income and adverse position effects. GMX V2 documentation and community analysis describe the design as risk-isolated, with per-market funding and price-impact mechanics that can reduce or offset LP earnings when market conditions are poor. What cannot be verified from the provided sources is the exact 30-day negative yield threshold for the selected pools on Arbitrum and Avalanche. Not verifiable as of 2026-08-29 whether either chain’s current 30-day primary yield is below zero, because the available sources do not provide a chain-by-chain negative 30-day LP return series for the specific GMX V2 markets in scope.

GMX v2 perps are governed through a mix of on-chain DAO, multisigs and off-chain entities; however, detailed on-chain control structures for v2-specific contracts are Not verifiable as of [2026-08-29]. 1. Governance structure & who controls what

• Core protocol & parameters: GMX uses GMX Governance and esGMX (escrowed GMX) for voting; token holders vote on proposals that affect protocol parameters and treasury usage.
• Contracts & upgrades: Control over deployment and upgrades of GMX v2 perps contracts is described as being under multisigs and governance, but exact admin addresses/roles per chain for v2 are Not verifiable as of [2026-08-29].
• Frontend: The main app is hosted and operated by the GMX contributors team; no independent frontends appear dominant, indicating de facto control by the core team.
• Funds/treasury: GMX DAO governs the protocol treasury, with spending and incentives typically ratified via governance proposals; detailed treasury wallet list and controls for v2 are Not verifiable as of [2026-08-29]. 2. DAO: real vs symbolic; proposals & voting concentration
• Governance is performed via on-chain votes using GMX and esGMX, with staking weight determining influence, which points to a real but token-weighted DAO, not purely symbolic.
• Proposal process generally: community or contributors draft proposals, discussed in forums/Discord, then put to on-chain vote via Snapshot or similar platforms; specific formal process steps for v2-only changes are Not verifiable as of [2026-08-29].
• Voting concentration, top holders (GMX/esGMX), and their shares of total voting power on Arbitrum and Avalanche via Dune are Not verifiable as of [2026-08-29]. 3. Multisigs, timelocks, signers
• GMX uses operational multisigs (e.g., on Arbitrum and Avalanche) for upgrades and parameter changes, but for v2 perps exact signer lists, thresholds, and the presence/length of timelocks are Not verifiable as of [2026-08-29].
• Independence of signers (e.g., external community vs core team) for these multisigs is Not verifiable as of [2026-08-29]. 4. Off-chain entity & ToS
• GMX presents itself primarily as a decentralized protocol; any company entity, jurisdiction, registration number, and board of directors associated with GMX operations are Not verifiable as of [2026-08-29].
• Terms of Service for the GMX app (user-facing legal agreement and responsible entity) are Not verifiable as of [2026-08-29]. Key risk takeaway: governance is token-weighted and multisig-administered, with meaningful community input but material practical control by core contributors; however, many specifics for GMX v2 perps (admin roles, treasury routing, signer independence) cannot be confirmed from available independent sources as of [2026-08-29].

GMX V2 Perps is a non‑custodial, smart‑contract perpetuals protocol with core deployments on Arbitrum and Avalanche, operated by a DAO rather than a traditional corporate entity. ### 1. Legal / entity structure

• GMX is generally described as a decentralized derivatives exchange governed by GMX DAO, with no clearly disclosed operating company for the protocol itself.
• A related entity, GMX Labs, appears as a development contributor, but its exact corporate form and jurisdiction are not clearly detailed in public-facing materials (marketing claim).
• Because governance is token‑based and global, effective control is dispersed, which complicates traditional regulatory characterization (inference). ### 2. Jurisdictions, access restrictions & ToS
• Front‑end interfaces (e.g., gmx.io) implement geo‑blocking for certain jurisdictions, typically including the U.S. and other high‑risk regions, plus sanctions‑listed countries, via IP checks.
• GMX documentation indicates no KYC/AML on‑chain, consistent with permissionless DeFi; any KYC would be at the level of third‑party front‑ends or aggregators, not the protocol contracts.
• As with many DeFi apps, users interact via self‑custodied wallets, and the protocol itself does not maintain user accounts or profiles (AML obligations shifted to access points, not contracts). ### 3. Regulatory classification & risk
• GMX V2 Perps provides leveraged crypto‑settled perpetual futures. Regulators in the U.S., EU and other major jurisdictions often classify such products as derivatives / futures, potentially requiring licensing if offered to local retail clients.
• The DAO and core contributors could face regulatory scrutiny similar to other derivatives DeFi protocols (e.g., unregistered swaps venues, off‑exchange futures), but no specific GMX enforcement action is currently public.
• There is no evidence of formal approval or licensing for GMX as an exchange or broker‑dealer in any major jurisdiction as of 2026‑08‑29 ("Not verifiable as of 2026‑08‑29"). ### 4. Enforcement, sanctions, warnings
• No public enforcement actions, court cases or sanctions lists directly naming GMX, GMX DAO, or GMX V2 Perps were identified ("Not verifiable as of 2026‑08‑29").
• Given global regulatory trends around crypto derivatives, GMX users face regulatory change risk: rules could render access from certain jurisdictions unlawful, or target DAO participants (inference based on broader derivatives cases). ### 5. Data protection
• The smart contracts do not hold personally identifiable information; interaction is via pseudonymous addresses.
• Front‑end operators may collect usage analytics and IP data under their own privacy policies; those are separate from protocol‑level risk. Overall, GMX V2 Perps functions as a permissionless derivatives venue without KYC, with DAO governance and geo‑blocked front‑ends, and sits in a high‑regulatory‑risk segment (crypto perps) despite no currently known direct enforcement actions.

Yes. In GMX V2 Perps, the stablecoin used is USDC on the Arbitrum and Avalanche deployments (the protocol’s market/pool pages and docs identify USDC as the quoted stable asset for these perp markets), and USDC itself has experienced at least one major depeg event in March 2023 when it traded materially below $1 after Silicon Valley Bank exposure was disclosed. I could not verify, from the provided web results alone, whether GMX’s specific USDC balance or pricing feed on Arbitrum/Avalanche ever suffered a protocol-level depeg incident separate from the wider USDC market event; that part is Not verifiable as of 2026-08-29. For the March 2023 USDC depeg, the stablecoin fell to roughly $0.87–$0.88, which is about a 12%–13% depeg from the $1 peg. If you mean only GMX V2’s own collateral/stable-asset incidents rather than the underlying USDC asset’s market depeg, that requires on-chain verification that is unavailable in this run.

Top 5 risks for GMX V2 Perps are: smart-contract risk (audited code can still contain undiscovered bugs or design flaws); oracle risk (pricing depends on Chainlink/Data Streams, so feed errors, delays, or misconfiguration can affect executions and liquidations); LP/counterparty risk (liquidity providers absorb trader P&L and can lose value in trending or imbalanced markets); leverage/liquidation risk (highly leveraged users can be liquidated quickly in volatile conditions); and chain/infrastructure risk (GMX runs on Arbitrum and Avalanche, so congestion or outages in the underlying networks can impair trading). A useful nuance is that V2 reduces some V1 risks, but it does not eliminate the structural exposure of an oracle-priced perp venue, especially for liquidity providers.

GMX V2 Perps’ top strengths are: 1) isolated GM pools, which let liquidity providers and traders choose specific markets and limit contagion across markets; 2) oracle-based execution, which supports predictable pricing and reduces dependence on an order book; 3) multi-chain deployment on Arbitrum and Avalanche, giving users flexibility across two major EVM ecosystems; 4) support for both spot swaps and perpetuals, making it a more versatile venue than a perps-only DEX; and 5) mature, battle-tested design, since GMX v2 is an evolution of a widely used protocol with an established developer codebase and long-running market support.