GMX V2 Perps

GMX V2 Perps is the perpetuals product of GMX, a decentralized spot and perpetual exchange. Its official website is gmx.io and its docs are at docs.gmx.io; the protocol categorizes itself as a decentralized exchange/perpetuals venue. Public sources place the V2 beta launch in August 2023 and indicate it was live on Arbitrum first, then also on Avalanche.

The native token is GMX. Main on-chain contract-address verification and Dune-backed cross-checks are Not verifiable as of 2026-09-04 in this run because on-chain tooling was unavailable; therefore I cannot responsibly list main contract addresses or claim explorer verification status here. For fork lineage, GMX V2 is best understood as a major architectural evolution of GMX rather than an obvious upstream fork of another perp DEX: it replaced the original shared GLP model with isolated GM pools and added Chainlink Data Streams/oracle integration.

Public security pages say the V2 contracts were audited by Guardian, ABDK, Certora, Dedaub, and Sherlock, and the V2 beta announcement plus security/docs pages indicate the change set was intentionally designed and reviewed. I found no reliable evidence in the gathered material of a malicious-modification history specific to GMX V2 itself; however, “similar forks” in DeFi often fail through unreviewed parameter changes, oracle changes, or admin-key misuse, so that risk remains a general fork-pattern warning rather than a documented GMX V2 incident.

GMX V2 Perps appears to be a real, functioning product rather than a pure landing page: the docs describe active trading, deposit, and withdrawal flows, and the SDK/API pages explicitly support integrations for Arbitrum and Avalanche. The documentation also shows a dedicated API surface, with HTTP APIs and GraphQL endpoints for indexed on-chain data, so an open API does exist. Product maturity looks moderate to high from the documentation alone: there are separate trading docs, SDK docs, and protocol GitHub references for deposits/withdrawals and API-relayed workflows, which is more substantial than a marketing-only site.

However, live UX quality, broken-link rate, fake-metric checks, and real deposit/withdrawal completion cannot be verified from the available web evidence alone, so those specifics are Not verifiable as of 2026-09-04. No credible sign from the gathered sources suggests a template-only or fake portal, but that conclusion is limited to the documented surfaces and remains unverified without direct app inspection.

GMX has an active bug bounty program on Immunefi. It is listed as live since 20 October 2021, with a maximum bounty of $5,000,000. The published reward structure says critical smart contract issues can be rewarded up to 10% of funds directly affected, capped at $5,000,000, with a minimum critical reward of $50,000; web/app findings have separate flat tiers, and reports need a runnable PoC for in-scope web applications.

GMX’s security docs also state the program covers all repositories under github.com/gmx-io. Publicly visible summaries indicate the program is ongoing, but specific payout totals/results are not fully disclosed in the sources reviewed, so detailed results are not verifiable as of 2026-09-04.

As of September 6, 2026. Dune/on-chain verification was unavailable; therefore exposure percentages and current balances are Not verifiable as of September 6, 2026. Dependencies and scenarios

• Oracles/manipulation — high criticality. GMX V2 uses Chainlink Data Streams as its primary oracle path, with additional provider/reference-feed and static-price mechanisms. Execution uses bid/ask bounds (minPrice/maxPrice), so stale, delayed, unavailable, corrupted, or improperly configured oracle data could cause mispricing, bad liquidations, or toxic order flow. Reference checks are not universal, and static-price providers can bypass them.
• CEX/MM exposure. GMX is oracle-priced and has no order book or required external market maker. However, Chainlink’s upstream market-data ecosystem and liquidity conditions can transmit CEX outages, wicks, or fragmentation into the oracle. Direct GMX dependence on named CEXs/MMs was Not verifiable as of September 6, 2026.
• Liquidity/collateral. GM/GLV pools bear trader PnL and are funded by assets such as ETH/BTC and stablecoins including USDC/USDT. A rapid asset move, stablecoin depeg, pool imbalance, or profitable trader concentration can impair LP solvency or withdrawals; GMX documentation explicitly notes pools may be unable to cover extreme pending profits.
• Bridges/cross-chain. Arbitrum and Avalanche are separate active deployments. GMX Account cross-chain deposits/withdrawals use Stargate for token transfers and LayerZero for messaging, creating bridge, messaging, liquidity-cap, and pause risks. Direct chain-level V2 exposure is distinct from this account bridge path.
• Custody/RWA/LST/restaking. Core dependency on custodians, RWA issuers/SPVs, LSTs, or restaking protocols was Not verifiable as of September 6, 2026; supported collateral exposure should be monitored per-chain and per-market. > Contradiction/update: The prior note described GMX as directly relying on Binance/Coinbase-style feeds. Current GMX documentation identifies Chainlink Data Streams/provider infrastructure as the protocol oracle path; direct named-CEX dependency is not established by the reviewed evidence. Failure scenarios: oracle outage/manipulation; Chainlink/provider configuration failure; bridge/message compromise or liquidity exhaustion; USDC/USDT or volatile-collateral depeg; pool insolvency from asymmetric PnL; Arbitrum/Avalanche halt; keeper/relay/API outage. Structured fields: dependency_failure_active: null; max_exposure_pct: null. On-chain exposure, chain split, and maximum dependency concentration: Not verifiable as of September 6, 2026.

GMX V2 Perps is organized as a non-custodial protocol for traders: users keep control of their own wallet and interact with the markets on-chain rather than depositing into a centralized custodian. Liquidity custody is segregated by market, not pooled globally: each GM market has its own isolated collateral pool, so exposure is ring-fenced per market and LPs choose which market to fund. The market design can be fully synthetic in some cases, meaning a given market may be backed only by stablecoins and not require custody of the spot asset at all.

I could not verify any protocol-wide withdrawal pause from the available web evidence, so that field remains not verifiable as of 2026-09-06.

Scope correction: this was a GMX V1 Arbitrum GLP incident, not a GMX V2 Perps incident. GMX governance states GMX V2 on Arbitrum and Avalanche was unaffected; V2 trading and liquidity continued normally. On July 9, 2025, a cross-contract reentrancy vulnerability enabled manipulation of GLP valuation and withdrawals.

Affected parties were Arbitrum V1 GLP liquidity providers and some integrated third-party protocols; no V2 Perps user or pool loss was reported. GMX paused V1 activity, formed an incident-response war room, negotiated fund recovery, and later burned the whitehat-held GLP. Approximately $40.1M was recovered, with about $3M residual GLP and $0.9M segregated fees.

The DAO added $2M from treasury, and approximately $44M was made available through the GLV distribution plan. The attacker/whitehat received a $5M bug bounty. Distribution to affected GLP holders was completed on August 13, 2025; GMX stated impacted holders were made whole.

No additional in-scope GMX V2 Perps incident was identified through September 6, 2026.

GMX V2 Perps is organized as a self-custodial protocol: traders and LPs keep their own wallet keys, while the protocol coordinates execution through smart contracts rather than holding user assets centrally. For user actions, GMX documents an on-chain signing flow for classic trading, where the user signs each trade with their wallet. The execution side is split between keepers and oracle infrastructure: keepers listen for user requests and submit executions, while an off-chain oracle system signs and publishes prices used by the protocol.

The codebase also describes role-based administration in a RoleStore, where a RoleAdmin can grant and revoke roles, with the deployer initially holding that authority until setup is complete. Independent commentary also describes GMX governance as DAO-driven and controlled through a multisig for critical protocol changes, but that specific multisig setup is Not verifiable as of 2026-09-04 from the provided sources. For a risk view, the key-management model is therefore distributed, not custodial: end-users manage their own keys; operational control is concentrated in keeper/oracle operators and protocol admin roles; and protocol upgrade/governance authority is likely mediated through DAO/multisig processes, though the exact current signer set is not verifiable here.

Assessment date: September 6, 2026. Dune MCP was unavailable; on-chain verification, block heights, execution IDs, and decoded-event checks were skipped. Therefore: Not verifiable as of September 6, 2026 for proxy-admin type, current role holders, role renunciation, emergency permissions, and timelock delay. Verified deployment references (official registry):

• Arbitrum: DataStore 0xFD70de6b91282D8017aA4E741e9Ae325CAb992d8; RoleStore 0x3c3d99FD298f679DBC2CEcd132b4eC4d0F5e6e72; ExchangeRouter 0x7dE39FF2e232A2203196788d37e234cF8F1b83f1; Oracle 0x26C02F221e8dB5A821e12347C7eA8a6b6E10842f; ConfigTimelock 0x2Dd99f39f58445CDDC57AA5E0DB2C367335BBD44; GovTimelock 0xFBEff82f2DD5E51B8AF34b57cf788b4b09d466F9; Timelock 0x7A967D114B8676874FA2cFC1C14F3095C88418Eb.
• Avalanche: DataStore 0x2F0b22339414ADeD7D5F06f9D604c7fF5b2fe3f6; RoleStore 0xA44F830B6a2B6fa76657a3B92C1fe74fcB7C6AfD; ExchangeRouter 0xc002Db96E682FFF6675966F959677285a0C45Efa; Oracle 0x29220fA3b24279279C211701DE4a7b035122B911; ConfigTimelock 0x854a176289958DD875b0a256FF0dd47f747e39B0; GovTimelock 0xA2aAaa1CbBd4B4f1Fd548f0a3f58B924EE36f266; Timelock 0xdF23692341538340db0ff04C65017F51b69a29f6. Architecture / admin risk: GMX uses permanent DataStore and RoleStore, separate custody vaults, and replaceable stateless logic contracts; this is upgradeable at the logic/deployment layer, not established here as a transparent/UUPS proxy system. Privileged actions are RoleStore-gated; documented control paths include ConfigTimelock, GovTimelock, and Timelock. ``text Users → ExchangeRouter → request storage ↓ keeper-gated handlers → Bank/Vaults ↓ DataStore/RoleStore Oracle providers → Oracle → execution validation Governance → Timelocks → roles/config/new handlers `` A compromised privileged key could potentially grant roles, disable features, change risk/configuration parameters, whitelist malicious tokens, manipulate oracle configuration, or deploy authorized replacement logic. Direct arbitrary fund drainage is not established; withdrawal availability during a malicious pause/configuration event is also Not verifiable as of September 6, 2026. Audits are documented for GMX V2, but deployment-to-audited-commit matching and unresolved severity counts are Not verifiable as of September 6, 2026.

abdk audit report — ABDK GMX Synthetics Audit; file audits/abdk/ABDK_GMX_Synthetics_Audit.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

dedaub audit report — GMX Synthetics DeDaub Audit; file audits/dedaub/GMX_Synthetics_DeDaub_Audit.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

sherlock audit report — Sherlock GMX Update Audit Report; file audits/sherlock/Sherlock_GMX_Update_Audit_Report.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX docs list ABDK as having audited GMX Synthetics at a specific commit. The search results did not expose the report body or findings in this run.

Formal‑verification and audit firm that reviewed GMX Synthetics (including V2) in November 2023.

GMX docs state Certora audited GMX Synthetics in November 2023. The search results confirm the report exists in the gmx-synthetics repository, but the detailed findings were not extracted in this run.

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. The search results also surfaced a Guardian/GMX oracle update report, but that is not sufficient to attribute a full GMX V2 code audit scope or findings to Dedaub here.

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.

Separate published report; must not be merged with Gasless Sponsored Calls 1.

Separate published report in a seven-report Crosschain V2.2 series.

Newly confirmed published report in the official GMX audit repository.

Separate published report; must not be merged with JIT Review.

GMX audit report — Synthetics; file audits/guardian/2022-10-24_GMX_Synthetics.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Synthetics; file audits/guardian/2023-01-08_GMX_Synthetics.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Synthetics; file audits/guardian/2023-03-15_GMX_Synthetics.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Synthetics; file audits/guardian/2023-05-15_GMX_Synthetics.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Synthetics; file audits/guardian/2023-06-02_GMX_Synthetics.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Synthetics; file audits/guardian/2023-07-11_GMX_Synthetics.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Synthetics; file audits/guardian/2023-07-28_GMX_Synthetics.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Oracle Updates; file audits/guardian/2023-09-01_GMX_Oracle_Updates.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Synthetics Updates; file audits/guardian/2023-09-26_GMX_Synthetics_Updates.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Migrator; file audits/guardian/2023-10-25_GMX_Migrator.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Report by Certora; file audits/certora/2023-11-13_GMX_Report_by_Certora.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Subaccount; file audits/guardian/2023-11-26_GMX_Subaccount.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Governance Updates; file audits/guardian/2023-12-17_GMX_Governance_Updates.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Config; file audits/guardian/2024-01-16_GMX_Config.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Updates 1; file audits/guardian/2024-06-14_GMX_Updates_1.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — GLV; file audits/guardian/2024-09-03_GMX_GLV.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Config Syncer; file audits/guardian/2024-09-04_GMX_Config_Syncer.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Buybacks Report; file audits/guardian/2024-11-18_GMX_Buybacks_Report.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Gasless Sponsored Calls 1; file audits/guardian/2025-04-11_GMX_Gasless_Sponsored_Calls_1.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Crosschain V2.2 1 report; file audits/guardian/2025-07-29_GMX_Crosschain_V2.2_1_report.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — JIT Review report; file audits/guardian/2025-09-24_GMX_JIT_Review_report.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — Fee Automations report; file audits/guardian/2025-11-04_GMX_Fee_Automations_report.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX audit report — V2 Review Report; file audits/guardian/2026-06-16_GMX_V2_Review_Report.pdf in gmx-io/gmx-synthetics (protocol audit catalog).

GMX V2 Synthetics / perps security reviews for the GMX V2 codebase used on Arbitrum and Avalanche. GMX docs state Guardian conducted 8 engagements between Oct 2022 and Sep 2023, and the Guardian case study says GMX V2 was reviewed 7 times in a 10-month pre-launch period.

GMX Synthetics audit

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 Synthetics audit

GMX Synthetics audit

GMX Synthetics audit

Primary auditor for GMX V2 synthetics perpetuals exchange (perps) across Arbitrum and Avalanche. Engagements spanned October 2022–July 2023 with multiple reports; later case study summarises 7 pre‑launch V2 reviews plus ecosystem integrations.

GMX Synthetics audit

GMX Synthetics audit

GMX Synthetics remediation review

GMX oracle updates audit

Sherlock published an audit for GMX Synthetics V2; search results indicate the archived Sherlock repo contains the report and scope at commit 8028cb8... The result set confirms Sherlock audited GMX Synthetics updates, but the exact severity breakdown was not fully recoverable here.

Audit contest platform that ran at least one GMX Synthetics / GMX V2 audit with published findings via GitHub issues and a full report.

GMX V2 perps is built and governed by a pseudonymous / largely anonymous team, with no publicly disclosed legal “founder” in the usual startup sense. ### Founders & Core Contributors

• Multiple independent sources state that GMX was founded by anons, emerging from a merger/migration of XVIX and Gambit communities.
• The lead developer/architect is consistently identified as “X” / xdev_10, previously active on XVIX and Gambit.
• Other recurring pseudonymous core developers: gkrasulya, 0xBrooks.
• A GMX DAO human-capital brief describes ~30 individual contributors operating under pseudonyms in an “unincorporated startup partnership”, with roles across architecture, BD, ops and infra (e.g. xdev_10, coinflipcanada, Saulius, Tano, Jonezee, Saurabh, Atomist, Shogun, Jrogon, Fredegar). ### Multisig Signers & Public Individuals
• Protocol upgrades/treasury are controlled via a 2-of-3 multisig.
• Two public signers repeatedly identified:
• Krunal Amin – founder of UniDex, Arbitrum DAO delegate.
• Benjamin (Ben) Simon – co-founder of Stealth Crypto, with roles in Lido, Aave, MakerDAO.
• A third signer is pseudonymous (Hanzo). ### Prior Projects & Track Record
• GMX’s technical lineage and some contributors trace back to Gambit Financial on BSC and XVIX (derivatives/DeFi experiments), which were migrated into GMX.
• UniDex and Stealth Crypto give Amin and Simon a prior public track record, but both are advisory/multisig roles, not clearly disclosed as “founders” of GMX. ### Public vs. Anonymous; Jurisdiction & Offices
• Multiple sources and GMX-aligned reports state the team is fully anon/pseudonymous, with no conventional founding company and no confirmed external investors.
• Governance documents describe contributors as an unincorporated partnership, not a registered operating company, and do not identify a specific jurisdiction or office.
• A reference to a “GMX contributor DAO” and foundation-style language appears in secondary sources, but concrete incorporation details are Not verifiable as of 2026-09-04. ### Reality Check
• Founders: unknown / pseudonymous. Lead dev likely X (xdev_10); project evolved from Gambit/XVIX. This is consistently reported but not formally attested by a legal entity.
• Team structure: DAO-style, pseudonymous contributors, 2-of-3 multisig with two known DeFi figures.
• Real-world entity/office: not evidenced. Any corporate “GMX company” listings from generic business databases (e.g., CB Insights naming a different founder) conflict with the DeFi-native narrative and appear to reference a name collision rather than this protocol, so they are disregarded. For institutional risk framing: GMX V2 perps should be treated as a DAO-run, pseudonymous protocol with limited recourse to an identifiable operating company, high dependence on multisig keyholders and social governance for accountability.

GMX V2 perps generally have a strong technical reputation and are seen as a battle‑tested perp DEX on Arbitrum and Avalanche, but that reputation is clouded by the high‑profile GMX V1 exploit and ongoing concerns about oracle dependence and complexity. General sentiment & market reputation

• Independent reviews in 2026 rate GMX around 3.6–4.2/5, citing it as a legitimate, still‑relevant perp DEX with solid security practices, deep Arbitrum ecosystem integration, and real‑yield exposure for LPs.
• GMX V2 is described as “battle‑tested” with isolated liquidity pools that reduce risk compared with the v1 single GLP pool, but with higher fees than order‑book DEXs and complex LP mechanics. Security posture, audits, and bug bounties
• GMX V2 contracts are extensively audited, with Guardian as primary auditor. Guardian reports multiple engagements across 2022–2026, hundreds of findings, and continuous coverage of new features (GLV, cross‑chain V2.2, fee automations). GMX maintains an active bug bounty across all repos.
• Third‑party commentary cites 7 audits pre‑V2 and 10 after launch, praising GMX for remediating all high‑severity issues and integrating auditor test cases into their own suite.
• GMX runs a high‑cap bug bounty (claims of up to $5m rewards) and has paid out for several serious issues, including the Collider VC bug and other high‑severity findings. Claims that “no user funds stolen” in its existence are marketing statements and conflict with later exploit reporting; they are unverified marketing claims. Major criticisms and incident history
• A critical cross‑contract reentrancy exploit in GMX V1 reportedly led to about $42m in losses and is widely discussed as a case study in post‑audit vulnerabilities and unaudited hotfixes. This materially impacts the protocol’s security reputation, even though it targeted v1 rather than v2.
• Critics highlight that the vulnerability was introduced while fixing a previous bug and went unaudited, reinforcing concerns that “audit badges” can create false security.
• Structural criticisms of GMX V2 include: oracle dependency (price feed risk), relatively higher fees vs. order‑book DEXs, limited asset selection, smart‑contract/keeper risks, complex LP exposure, and suitability mainly for experienced traders. Legal, regulatory, sanctions, fraud/rug allegations
• No evidence in retrieved sources of fraud, rug‑pull, insolvency, sanctions, or specific regulatory enforcement actions against GMX or its core team as of the latest articles. Not verifiable as of 2026‑09‑04. Unresolved concerns for institutional risk
• Legacy perception risk from the $42m v1 exploit and questions about change‑management discipline.
• Ongoing reliance on oracle infrastructure and complex cross‑chain mechanisms in V2.
• Pseudonymous governance and lack of clear, public information on founder identities, investors, or regulatory posture in mainstream sources. Not verifiable as of 2026‑09‑04.

Economic model — verified through September 6, 2026. GMX V2 is an on-chain spot/perpetuals venue. LPs deposit long/short assets into individual GM markets or diversified GLV vaults; GLV allocations can shift among approved markets. Example: WETH-USDC uses WETH for long backing and USDC for short backing.

LP compensation comes from trading, swap, borrowing and liquidation fees; GMX states 63% goes to pools and 37% to the protocol on Arbitrum/Avalanche. This is not market-neutral: pools target balanced long/short inventory, but remain exposed to token-price moves, trader PnL, open-interest imbalance, utilization, adverse selection and potential inventory impairment. GLV is diversified but not hedged.

LP capital is not restaked or externally deployed; leverage exists at the trader/market layer, with market-specific caps that can reach 100x but decline as open interest rises. Deposits/withdrawals are keeper-executed requests requiring an execution fee; requests can be cancelled before execution. Redemptions are constrained by reserve factors, open-interest caps, pool caps and available liquidity; if availability is zero, withdrawal may wait for positions to close or new liquidity.

There is no fixed lock-up identified. Current DeFiLlama snapshot: TVL $204.62m, comprising Arbitrum $193.83m (~95.0%) and Avalanche $10.17m (~5.0%); the page also reports small TVL on other chains. 30-day fees were $1.84m and annualized fees $30.59m; annualized revenue was $11.32m. Reported 30-day incentives were only $4.5k versus $1.84m fees (~0.25%), indicating predominantly fee-funded economics, but net LP yield also includes PnL/inventory effects. Contradiction/data gap: protocol/API documentation exposes APY and performance periods, but a reproducible current APY history, chain-by-chain product TVL trend, or Dune-vs-DeFiLlama reconciliation is Not verifiable as of September 6, 2026.

Dune on-chain verification is unavailable in this run. APY sustainability is therefore uncertain and volume/fee-sensitive. Structured fields: organic_yield_pct: null; leverage_ratio: null.

As of September 6, 2026, GMX V2 Perps reserves are not fully verifiable. Dune on-chain balance queries are unavailable in this run; therefore liquid reserves, liabilities, chain-level exposure, token composition, and custody balances are Not verifiable as of September 6, 2026. No reserve attestation or consolidated liabilities statement was identified. Known treasury/control information: GMX’s official documentation lists DAO Treasury 0x4bd1cdAab4254fC43ef6424653cA2375b4C94C0E, POL Multisig 0xc6378ddf536410c14666dc59bc92b5ebc0f2f79e, Governance Committee 0x0263ad94023a5Df6d64f54BFEF089F1FBF8A4CA0, Bond Protocol 0xea8a734db4c7EA50C32B5db8a0Cb811707e8ACE3, GM Holdings 0xe1f7c5209938780625e354dc546e28397f6ce174, plus additional treasury-related addresses.

The page specifically identifies 0x68863dDE14303BcED249cA8ec6AF85d4694dea6A as Treasury (Arbitrum). Custody is therefore distributed across DAO-controlled contracts/multisigs and related protocol contracts, but current balances and signer/control thresholds are not verified here. Reserve policy: V2 markets use a configurable reserve factor that caps the ratio of position-reserved value to pool value; reservedUsd represents USD value reserved for positions, while pool calculations may exclude pending trader PnL. This is a risk-control mechanism, not a separately reported treasury reserve. Fee funding: GMX documentation states the treasury receives fees from protocol-owned liquidity and 8.8% of V2 fees, after a 1.2% Chainlink allocation within the 10% treasury/oracle/keeper-cost bucket.

DeFiLlama presents the split as 10% to the protocol treasury. Contradiction/caveat: these figures use different gross-versus-net descriptions; neither establishes the treasury’s current asset balance. An approximately $35 million treasury figure appearing in a January 2026 governance proposal is an unverified governance claim, not an independently reconciled balance.

GMX V2 Perps does have a native token, GMX. The official docs list the token contract on Arbitrum as 0xfc5A1A6EB076a2C7aD06eD22C90d7E710E35ad0a and on Avalanche as 0x62edc0692BD897D2295872a9FFCac5425011c661; GMX is the protocol’s utility and governance token. For total vs circulating supply, market cap, FDV, holder concentration, insider wallets, emissions, unlocks, and on-chain function control, I cannot verify those items from the available evidence here.

Per your instruction set, these are Not verifiable as of 2026-09-04 without on-chain querying or an explorer/analytics cross-check. What is verifiable from the gathered sources is that GMX staking/reward mechanics have changed over time: one source states GMX stakers now receive protocol revenue primarily through token buybacks rather than direct ETH/AVAX distributions, while another says stakers earn ETH/AVAX fee revenue plus esGMX and Multiplier Points; these descriptions should be treated as a contradiction between secondary sources, not as settled fact. For allocations, one third-party market page repeats the commonly cited initial breakdown: 6M GMX for XVIX/Gambit migration, 2M GMX for Uniswap liquidity, 2M GMX for esGMX vesting, 2M GMX for the floor price fund, 1M GMX for marketing/collaborations/community developers, and 250k GMX to the team over 2 years.

This is best treated as a historical allocation claim, not fully independently verified here. For DEX liquidity depth and listings, DefiLlama shows GMX V2 Perps TVL on Arbitrum and a separate GMX liquidity figure, while GeckoTerminal shows a GMX/WETH pool on Arbitrum with only about $6.55K liquidity at the time captured; that suggests shallow visible pool depth on that venue, but I cannot confirm the main exchange listings beyond the fact that GMX is traded on Arbitrum/Avalanche venues mentioned in the sources.

A BTC crash below $10,000 would primarily stress GMX v2’s BTC markets and any LPs in those specific GM pools, rather than mechanically cascading across all markets, because GMX v2 uses isolated, independent pools. The main protocol-level defenses that would shape the outcome are price-impact caps, liquidation rules, and auto-deleveraging (ADL), all of which are designed to contain extreme imbalances and liquidations within the affected market. For the BTC market itself, GMX documents a 50 bps max negative price-impact cap for major markets including BTC, and the protocol states that price impact is computed from pool imbalance and is only charged or credited on position decrease/close.

In a sharp downside move, long positions with high leverage are the most likely to be liquidated; if liquidations would push net open interest beyond the market limit, GMX’s governance materials say ADL can be triggered. That means the stress response is likely to be a combination of liquidations, reduced ability for traders to exit at mid, and LP P&L deterioration in the BTC pool. For **Arbitrum vs.

Avalanche, the critical question is how much BTC exposure sits on each chain, but that split is Not verifiable as of 2026-09-04 because I cannot perform on-chain verification in this run. The same limitation applies to current BTC pool liquidity, open interest, and the exact liquidation buffer distribution by chain. From a risk-analysis standpoint, the likely stress outcomes are: higher realized losses for BTC LPs, forced de-risking of leveraged longs, wider effective execution costs from adverse price impact, and potentially temporary trading disruption if ADL or liquidation queues intensify**.

The protocol design suggests the shock should remain more localized to BTC-related exposure than a monolithic-pool design would allow.

GMX V2 Perps is not a pooled-stablecoin vault in the usual sense; its liquidation and solvency mechanics are market-level, so a 20% depeg matters only if the depegged asset is used as collateral or materially in the pool for a given market. The protocol states that a position is liquidated when remaining collateral, after unrealized losses, fees, and capped negative price impact, falls below the market minimum collateral threshold, which ranges from 0.25% to 1% of position size depending on configuration. It also says ADL can reduce profitable positions when pending PnL relative to pool value exceeds the configured threshold, and that pools can in rare cases become negative.

For a 20% collateral depeg, the stress effect is straightforward: any position using that collateral loses 20% of the collateral’s marked value immediately, which can push thinly-margined positions below liquidation thresholds and increase liquidations and ADL pressure. The exact loss to the protocol, LPs, or traders is Not verifiable as of 2026-09-04 because the required live chain-specific collateral composition, open interest, and pool balances were not provided and on-chain verification is unavailable in this run. Risk is chain- and market-specific on Arbitrum and Avalanche because GMX V2 uses isolated liquidity pools by market rather than a single unified pool.

The most defensible stress conclusion is that a 20% depeg would primarily hit the affected market’s LPs and traders through worse collateral value, more liquidations, and potentially ADL, while the broader protocol impact depends on the depegged asset’s share of that market’s collateral and liquidity, which is Not verifiable as of 2026-09-04.

If a top counterparty becomes insolvent, GMX V2’s design aims to keep the system solvent by socializing and redistributing the loss across LPs, traders and fee flows, rather than letting one default cascade through the protocol. Precise on-chain loss mechanics are Not verifiable as of 2026-09-04. ### 1. Setup: who is the “counterparty” in GMX V2 GMX V2 is an oracle-based, synthetic perps AMM where the main economic counterparties are:

• Liquidity providers (LPs / GM pools) – provide collateral that backs traders’ PnL.
• Traders – pay / receive PnL vs the pool.
• Market makers / keepers – handle ordering, liquidations, price updates. Protocol docs emphasize that LPs are effectively the house in most perps markets, taking the opposite side of trader PnL. ### 2. Stress: top trader / LP “insolvent” (large negative equity) Path 1 – Trader becomes insolvent (large loss > collateral):
• Loss is limited to the trader’s posted margin plus any cross-collateral the system allows; positions are liquidated when margin falls below maintenance.
• If oracle latency or extreme gaps prevent timely liquidation, the shortfall is effectively borne by the GM pool for that market: pool value drops by the excess PnL owed.
• That loss is socialized across all LPs in the affected pool via lower pool share value and lower future yield. Who absorbs it: LPs in that perps market; fee flows (trading / borrowing fees) may gradually repair the pool over time. Not verifiable as of 2026-09-04. Impact through contracts:
• Position and margin contracts mark positions to oracle prices.
• Liquidation contracts close insolvent positions and transfer remaining collateral to the pool / liquidators.
• Pool accounting reduces total pool value; LP token balances stay the same but represent a smaller claim. Path 2 – Large LP / market maker fails to honor off-chain obligations: GMX V2 is non-custodial; LP insolvency is expressed on-chain only as their pool share value dropping. There is no notion of an LP “defaulting” on PnL: the protocol automatically pays traders from pool assets. Who absorbs it:
• LP itself bears the economic loss via its pool share.
• Co-LPs and, indirectly, traders face knock-on effects: tighter risk parameters, reduced max position sizes, higher fees. These changes are governance / config-driven and Not verifiable as of 2026-09-04. ### 3. Compensation mechanisms GMX V2 does not advertise a formal insurance fund / backstop; loss absorption is primarily via:
• LP loss socialization.
• Ongoing protocol fees rebuilding pool value. Any additional compensation or ex post grants would depend on governance decisions (GMX DAO) and are Not verifiable as of 2026-09-04.

For the stress scenario of committed fraud by the DAO or owners, the practical risk for GMX V2 Perps is governance/administrative abuse, not a confirmed historical fraud event. The available sources show GMX V2 uses DAO-governed mechanisms and fee/treasury routing, while third-party risk analysis flags privileged roles and cross-chain governance asymmetry as material risk factors; however, no source here verifies that the DAO or owners have actually committed fraud on Arbitrum or Avalanche. The most credible stress case is that a DAO-controlled parameter change, treasury diversion, or privileged-role abuse could harm traders and LPs by altering fees, liquidity routing, or market protections.

Independent risk commentary specifically notes that compromised or overly powerful admin roles could extract value or create fraudulent message acceptance on some deployments, but it does not document an actual fraud occurrence for the main Arbitrum/Avalanche V2 system. What is verifiable from the sources is that GMX had a major V1 exploit in July 2025, and GMX publicly stated V2 was unaffected. That incident is relevant to operational risk and trust, but it is not evidence of DAO/owner fraud.

So the stress-answer is: severe governance abuse risk exists, especially around privileged roles and treasury/fee control, but actual committed fraud by the DAO or owners is not verifiable as of 2026-09-04.

GMX V2 Perps is not a single yield source; it is a set of market-specific LP pools, so a 30-day negative primary yield has to be assessed at the pool level rather than protocol-wide. In the available sources, I could not verify a protocol-wide on-chain negative 30d yield condition, so that specific stress scenario is Not verifiable as of 2026-09-04. What can be said from the web data is that the protocol’s yield is driven by trading activity and market microstructure: fees come from market making, swap fees, leverage trading, funding fees, liquidations, and asset rebalancing, so a sustained slowdown in these inputs would compress LP yield.

GMX V2’s per-market design also isolates risk by market, which means weakness in one pool does not automatically propagate to all pools. The source set shows both positive and weaker recent pool-level APYs across chains, which implies yield dispersion rather than a single uniform return stream: for example, Arbitrum ETH-USDC is shown with double-digit APY in one source, while other pool views show lower base yields or different APY snapshots. Because the results are inconsistent across aggregators and none provide a verifiable on-chain 30-day negative series in this run, the only defensible answer is that the stress case is not verifiable from the provided evidence.

Assessment — as of September 13, 2026. GMX V2 has real but hybrid governance, not a purely symbolic DAO. Staked GMX/esGMX produces non-transferable GMX_DAO voting power; ProtocolGovernor and GovTimelockController support on-chain governance. The documented process is: forum idea → RFC → 5-day Snapshot vote → optional Tally vote for on-chain execution.

Snapshot is therefore socially decisive for many proposals, while contract changes require on-chain execution with a stated 24-hour execution delay. Control map. The contracts use RoleStore, Config, ConfigTimelockController, GovTimelockController, and Timelock; roles include governance, configuration keepers, oracle/risk roles, and keepers. The Timelock manages upgrades, role assignments, and privileged operations. GMX’s public GitHub organization maintains the contracts, synthetics code, and interface repositories. Operational centralization. A governance-forum research brief reports a 2-of-3 upgrade multisig and a separate 4-of-6 treasury multisig, but this is not independently verified here and signer composition has changed: a later forum update records Saulius replacing Jonathan and Orion replacing Q in August 2026.

Exact current signer sets, independence, and chain-by-chain authority are therefore Not verifiable as of September 13, 2026. Voting concentration / top holders. Dune is unavailable in this run; top-holder concentration, delegation concentration, and current voting-power distribution are Not verifiable as of September 13, 2026. The 96.2% figure in the forum brief is an unverified secondary claim, not an on-chain result. Company/legal control. A 2022 governance proposal describes an independent “Labs” software-development/marketing entity responsible for contributor operations, frontend/backend development, domain ownership, and licensing, while DAO-controlled deployments remain separate. Current legal name, jurisdiction, registration number, directors, and binding app ToS entity are Not verifiable as of September 13, 2026.

The forum ToS uses placeholders such as “company_name” and does not identify a legal entity.

GMX V2 Perps is not verifiable on the evidence gathered as having a separately identified operating entity for the protocol itself; the only clearly sourced legal term located was GMX’s general terms, which state they are governed by German law and, for EU consumers, mandatory law of the consumer’s residence also applies. The protocol appears to operate in a no-KYC, self-custodial manner according to third-party reviews, but those reviews are not a substitute for a formal compliance policy. I found no reliable evidence in the gathered materials of a regulator action, court case, or sanctions designation against GMX or a named entity associated with the protocol, so active enforcement and sanctions status are not verifiable as of 2026-09-04.

Legal-structure risk remains: a decentralized front end/protocol can still face access, consumer-protection, AML, and securities-qualification scrutiny depending on jurisdiction, even where no KYC is required; however, that is a general regulatory risk assessment, not a verified enforcement finding. Data-protection terms were not clearly verifiable from the gathered materials, and any protocol-marketing claim about being “decentralized” or “no KYC” should be treated as unverified marketing unless confirmed in formal legal documents.

GLEIF LEI registry unavailable at scan time. OFAC SDN screening of 'GMX V2 Perps': no match. SEC litigation and administrative release feeds: no mention.

GMX V2 Perps does not issue its own stablecoin; it uses external collateral and settlement assets such as USDC and USDT, with flexible collateral support documented for active GM pools and positions. No web source reviewed here verifies a historical depeg event history for the stablecoins used by GMX V2 Perps, so the depeg count, last depeg date, and maximum depeg percentage are not verifiable as of 2026-09-06. The protocol is therefore treated as not having a protocol-issued stablecoin, while its stablecoin exposure remains externally issued and stablecoin_ids are not verifiable as of 2026-09-06.

GMX V2’s principal risks are concentrated in oracle/keeper dependence, pooled-liquidity solvency, smart-contract complexity, privileged configuration, and cross-chain/token dependencies. The protocol documents meaningful controls—caps, reserve factors, adaptive funding, audits, and a large bug bounty—but these reduce rather than eliminate tail risk. Dune/on-chain exposure, TVL, and Arbitrum-versus-Avalanche allocation were not independently verified: Not verifiable as of September 5, 2026.

GMX V2 Perps’ top strengths are: isolated market pools, which limit contagion to the specific market rather than the whole protocol; oracle-priced execution with low slippage, which improves trade pricing and reduces price-impact friction; capital efficiency and broader market support, including synthetic/non-custodied assets and a longer-tail listing model; real-yield liquidity incentives, since LPs earn from trading activity rather than relying mainly on emissions; and mature, self-custodial DeFi UX, with perpetuals, swaps, and leveraged trading available through a widely used Arbitrum/Avalanche deployment.