Final report - Arbitrum and GMX Python tooling for onchain trading

DAO Programs & Initiatives Domain Allocator Offerings (prev Questbook)
1

We have released the CCXT and FreqTrade adapters for GMX. Now you can do algorithmic trading on your favourite decentralised futures exchange.

Purpose

The goal was to enable algorithmic trading on GMX using familiar tools algorithmic traders use on centralised exchanges. Some of the most adapted packages for this purpose are the CCXT connector middleware and the FreqTrade framework integration for backtesting and live execution of algorithmic strategies.

Both the CCXT adapter and the FreqTrade integration are now available for GMX.

Milestone 2: Delivered items

Milestone 2 was: CCXT is the top software library that algorithmic traders use to connect with different perpetual exchanges for trading. CCXT is used by 1,000+ traders and proprietary trading firms. We’d like to write a GMX adapter that allows CCXT users to connect to GMX as they connect to any other exchange.

The following have been delivered as part of the grant:

image
image1600×952 225 KB

image
image1664×350 24.8 KB

Milestone 3: Promotion and Twitter spaces

Milestone 3 was: Closing up the project and writing promotional, the post-mortem blog posts and hosting Twitter Spaces.

  • The blog post is here
  • For promotional Twitter spaces, we still need to get a contact from the Arbitrum DAO who helps us to organise this, and this is pending us getting this organised

Extra milestones

Bonus we delivered

  • GMX data collector: we developed an additional infrastructure application to get higher-quality data out of GMX markets for backtesting of algorithmic strategies (more on this later)
  • The adapter has been updated to the latest GMX 2.2 version (recently released)

image
image1600×615 160 KB

Bonus we could not get (was not part of the grant)

  • CCXT baseline merge: currently stuck. This was not part of the grant, but something we wish would happen. The current open-source module works as a drop-in replacement until the CCXT team is ready to maintain the GMX adapter as part of the baseline.
  • We have discussed with other projects that have received the official CCXT baseline status for their adapter, and there is usually a payment involved to the CCXT team.
  • Our proposal is for GMX to promote and link to the current GitHub repository in their documentation until/if CCXT is open to considering this adapter as part of their project. Because it is a drop-in replacement

Live trading on GMX

For all exchange adapters, middleware, and trading algorithms, the devil is in the details. The only way to build trading software is to trade with the software.

Trading Strategy deployed a directional trading vault which trades on GMX. It has been running for a few months in so-called forward testing.

  • This directional strategy combines mean reversion, trend following, and short-term BTC/ETH price prediction into a multi-strategy approach.
  • The vault is deployed on the Lagoon vault protocol, taking trades directly on GMX
  • Due to onchain nature of GMX, any of the multiple vault protocols can take positions on GMX, unlike other exchanges that often need a centralised custodian to deposit and withdraw assets in the exchange

image
image1600×583 125 KB

The returns have hovered between 0% and 30% annually since the strategy launch. During forward testing, we identified and addressed numerous execution issues (more below). Both live trade execution and strategy performance are reaching a level of quality at which we will feel comfortable opening this vault to the public.

During the forward testing period, you can find ~1000 onchain transactions for trades on this rebalancer address.

Developing trading algorithms for GMX

You can now develop trading algorithms for GMX as you would do for any FreqTrade-supported exchange.

We provide a tutorial here for a basic ADX-based breakout strategy.

You can find the tutorial here.

Trading firm adoption

Some trading firms have privately expressed interest in trading on GMX. However, the GMX’s 4 bps/6 bps fee structure is not always competitive for their strategies.

Because of GMX’s AMM nature, it does not have an internal price; instead, it uses a special fee structure in which the trade fee depends on whether you increase or decrease the open interest. This may make GMX attractive for certain funding-rate strategies, but it also makes it more difficult to run existing strategies built for more conventional exchanges.

As competition among new perpetual futures exchanges heats up, many newcomers are offering very attractive fee and airdrop schemes. This has hurt GMX, known for its deep liquidity for major coins like BTC and ETH. The real-world asset (RWA) boom has also changed the market landscape: as of this writing, GMX offers six TradFi assets.

Quality and testing

Our GMX directional vault on Arbitrum has executed 1000+ orders across ~100 positions. All packages include a continuous integration test suite to ensure that future maintenance work can be delivered easily.

Challenges and lessons learnt

The actual onchain smart contract execution for GMX is robust and quite easy to manage. There have been some other gaps that may make algorithmic trading on GMX difficult.

  • Offchain data was not readily accessible: At the time of our integration, GMX market data required more integration work than conventional exchange feeds. Data was distributed across its APIs, GraphQL indexer and onchain Reader contracts rather than exposed through a single standardised exchange interface. GMX also does not use a single oracle source for every market: Chainlink Data Streams are the primary source for most tokens, while other configured providers may be used as well. Standardised live and historical data are critical for algorithmic trading, so we developed an additional GMX data collector to normalise these sources.
  • GMX’s accounting and business logic differ from those of other exchanges in some unexpected ways. By default, profits from long positions are paid in the market’s long pool token. For example, profits from a BTC/USD long backed by WBTC and USDC may be paid in WBTC unless they are explicitly swapped into another token.
  • GMX offers various trading-pair denominations; GMX perpetual markets are USD-denominated, but they are not simple base-and-quote pairs. Each market has an index token, a long pool token, a short pool token and a collateral token. Depending on the collateral deposited and the desired receive token, opening or closing a position may involve additional token swaps.

If you need any help with FreqTrade, CCXT or GMX, please hop into our Discord. We are happy to answer any questions that technical integrators may have

2

Hi @miohtama and the Trading Strategy team,

Thank you for providing a transparent, rigorous, and technically grounded final report. Below is feedback from a governance and ecosystem perspective, followed by a few specific questions.

1. Empirical Validation Over Simulated Tests: Deploying a live directional vault on Arbitrum and logging ~1,000 onchain execution transactions across ~100 positions demonstrates genuine technical skin in the game. This goes well beyond basic unit tests.

Proactive Scope Expansions: Delivering the standalone GMX Data Collector and proactively upgrading compatibility for GMX v2.2 addresses the fragmented state of GMX’s offchain/indexer data feeds and adds meaningful open-source value to Arbitrum’s developer ecosystem.

Architectural Honesty: Highlighting practical frictions—such as pool-token profit settlement mechanics, oracle data variance, and dynamic open-interest fee sensitivity—provides essential operational intelligence for other builders looking to tap into GMX liquidity.

2. Opinion & Governance Observations: Upstream Integration & Long-Term Viability: The primary operational bottleneck identified is the CCXT baseline merge bottleneck. While the adapter functions as a drop-in replacement today, third-party forks face maintenance decay over time. The DAO and GMX governance should evaluate whether formal coordination or joint sponsorship with the CCXT core team makes strategic sense to ensure official, ongoing maintenance.

DAO Coordination Deficit: Milestone 3 highlighting difficulty connecting with DAO marketing/events coordination illustrates an ongoing operational pain point for builders. The Domain Allocators and Foundation community liaisons should formalize a standard liaison pipeline for funded teams completing milestone deliverables.

Target Strategy Fit: Given GMX’s fee mechanics and pool-asset profit payouts, quantitative adoption on Arbitrum will likely skew toward funding-rate arbitrage, cross-venue basis trades, and directional swing strategies rather than high-turnover algorithmic market making. Documentation and tutorials should lean into these structurally compatible strategies.

3. Questions for the Team & Allocators: Maintenance & Versioning Lifecycle: Now that the grant deliverables are complete, what is Trading Strategy’s roadmap for maintaining compatibility as GMX smart contracts and CCXT upstream libraries continue to evolve?

Upstream Merging Pathway: Has the team engaged in preliminary discussions with GMX core contributors or the GMX DAO regarding co-sponsoring or formally requesting the official CCXT baseline listing?

Data Infrastructure Access: Is the newly built GMX Data Collector packaged for direct deployment by independent quantitative researchers, or does it depend on proprietary hosted infrastructure?

Coordination for Milestone 3: Has the Questbook/Domain Allocator team or the Arbitrum Foundation events desk reached out to schedule the concluding promotional spaces and wrap up Milestone 3?

3

Technical Review & Architecture Analysis

This evaluation examines the architectural mechanics, execution dynamics, data normalization, and market microstructure implications surfaced in the report.

1. Architectural & Middleware Stack

Quant Strategy (FreqTrade / Custom Python)
                  │
                  ▼
         Unified CCXT API Calls
                  │
                  ▼
   ┌──────────────────────────────┐
   │  GMX CCXT Adapter / Wrapper  │
   └──────────────┬───────────────┘
                  │
         ┌────────┴────────┐
         ▼                 ▼
 ┌───────────────┐  ┌──────────────────────┐
 │ Offchain Data │  │ Onchain Execution    │
 │ Normalization │  │ (GMX v2.2 Synthetics)│
 └───────┬───────┘  └──────────┬───────────┘
         │                     │
  - Data Collector      - Reader Contracts
  - GraphQL Indexer     - ExchangeRouter
  - Chainlink Streams   - Settlement Keepers
  • CCXT Standardization Layer:
    • Translates standard REST/WebSocket order paradigms (create_order, fetch_ticker, fetch_ohlcv, fetch_positions) into EVM transactions compatible with GMX’s asynchronous, two-step execution pattern (deposit/order request $\rightarrow$ keeper settlement).
    • Provides non-Python middleware bindings, decoupling strategy code from Web3-native contract ABI management.
  • Onchain Execution Engine:
    • Integrates directly with GMX v2.2 synthetic market contracts.
    • Employs Lagoon protocol directional vaults to manage custody, nonces, gas limits, and automated trade rebalancing on Arbitrum One.
    • Verified against onchain activity: ~1,000 transactions across ~100 distinct positions from the rebalancer contract (0x350c2d78c06d4d6963eeb6cd44a5a038aab41d3f).

2. Deep Dive: Technical Findings & Failure Modes

A. Asymmetric Settlement & P&L Token Accounting

  • Mechanic: In standard CEXs and unified perps (e.g., dYdX, Binance, Hyperliquid), positions settle in a single quote currency (typically USD/USDC/USDT). GMX v2.2 isolates liquidity across four asset components per market:
    $$\text{Market} = {\text{Index Token, Long Pool Token, Short Pool Token, Collateral Token}}$$
  • Technical Impact:
    • By default, positive P&L on long positions is denominated and paid in the market’s long pool asset (e.g., WBTC for BTC/USD longs), rather than cash/stable collateral.
    • If a strategy requires USD cash-flow accounting, closing a winning position triggers a secondary auto-swap transaction. This exposes the trading engine to:
      1. Secondary swap slippage.
      2. Dynamic AMM swap fees.
      3. Additional execution latency and gas overhead.

B. Market Data Fragmentation & Oracle Divergence

  • Offchain Data Ingestion Deficit:
    • Unlike centralized exchanges offering low-latency WS order book L2/L3 feeds and standardized REST endpoints, GMX requires multi-source aggregation:
      1. GraphQL Subgraphs: Historical state, trade logs, and fee accrual (prone to indexing lag).
      2. Onchain Reader Contracts: Live collateral availability, borrow rates, and open interest parameters.
      3. High-Frequency Oracles: Chainlink Data Streams (pull-based low-latency feeds) combined with secondary oracle feeds.
  • Solution Delivered: The team engineered a dedicated, standalone GMX Data Collector to normalize these heterogenous sources into uniform OHLCV and market-depth streams suitable for FreqTrade backtesting engines.

C. Microstructure & Fee Asymmetry vs. Centralized Exchanges

  • Dynamic Open Interest (OI) Impact:
    • Fees are not static maker/taker tiers; base fees sit at 4–6 bps, adjusted dynamically by pool skew. Opening a trade that widens pool imbalance incurs punitive fees; opening a trade that rebalances pool skew receives discounted rates.
  • Algorithmic Viability:
    • Unsuitable: High-Frequency Trading (HFT) and traditional low-edge statistical arbitrage ($<10\text{ bps}$ margins) are mathematically unviable due to cumulative base fees, keeper execution gas, and balance-skew penalties.
    • Suitable: Medium-to-low frequency momentum, trend-following (ADX breakouts), funding-rate capture, and cross-venue basis arbitrage where holding periods span hours to days and profit margins absorb 10–20 bps round-trip friction.

3. Critical Upstream & Operational Risks

Risk Factor Root Cause Technical / Operational Consequence
Upstream Bitrot CCXT core merge stalled behind commercial listing fees. The codebase lives in a standalone repository (tradingstrategy-ai/web3-ethereum-defi). If GMX rolls out contract upgrades (e.g., v2.3+) or CCXT refactors internal abstractions, downstream bots will break unless actively maintained.
Two-Step Keeper Latency GMX trades require keeper execution onchain. Latency between order submission and keeper execution introduces execution price slippage relative to offchain signals.
State Desynchronization Dual dependency on RPC nodes and indexers. Out-of-sync RPC nodes or subgraph indexing latency can cause bots to misread open position sizes or miscalculate liquidation prices.

4. Technical Assessment Summary & Recommendation

  • Quality of Engineering: High. Building an abstraction that bridges CCXT/FreqTrade to an asynchronous AMM perp architecture while forward-testing with 1,000+ live transactions is a complete, battle-tested deliverable.
  • Key Technical Recommendation for Quantitative Users:
    1. Enforce Stablecoin Settlement Flags: Ensure the adapter explicitly specifies collateral and payout token routing on position close if strategy accounting assumes USD parity.
    2. Run Dedicated Data Collector Instances: Quant desks should self-host the newly developed data collector alongside private Arbitrum One RPC endpoints to mitigate public indexer latency and oracle desync.
    3. Target Holding Periods $> 4\text{ hours}$: Limit deployment to structural strategies (funding arbitrage, trend breakout) rather than rapid mean-reversion, ensuring expected alpha outpaces the 8–15 bps effective round-trip cost.
1 Like
4

@Arb_Junior’s observation regarding “Empirical Validation Over Simulated Tests” highlights the exact threshold separating theoretical governance from production-grade capital execution.

The Trading Strategy team has delivered a highly robust data infrastructure for quantitative traders. However, reviewing this success exposes a severe Asymmetric Data Deficit within the broader ecosystem: retail quantitative traders now possess better deterministic, real-time tracking on Arbitrum than the actual Domain Allocators and Delegates who fund them.

If the DAO is funding empirical data infrastructure for traders and protocols, it must urgently establish Sovereign Empirical Telemetry for its own treasury. We cannot continue to audit multi-million dollar grant deployments using static, self-reported PDFs while the protocols we fund operate on sub-second, on-chain data pipelines.

Excellent delivery by the developer team. It establishes a technical baseline that the Arbitrum DAO’s own internal accountability architecture must now rise to meet.

1 Like