Data & developers
- Reading time
- 5 minutes
- Last source check
- July 26, 2026
- Published by
- GMX Referral Codes Editorial Desk
Build a GMX trading bot safely
A GMX trading bot is not one script that watches a price and sends a market order. A reliable system separates market data, strategy decisions, risk approval, transaction construction, signing, submission and post-trade reconciliation.
GMX orders use oracle data and keeper execution. Transaction submission only creates an order request; it does not guarantee the expected fill. The bot must track both the creation transaction and the later execution, cancellation or freeze outcome.
In this guide
Key takeaways
- 01Begin with a read-only observer and measured paper decisions.
- 02Keep signals, risk approval, signing and reconciliation separate.
- 03Track the keeper outcome after the creation transaction.
- 04Bound acceptable price and model all holding costs.
- 05Stop new exposure whenever data or reconciliation becomes uncertain.
Start with a read-only scanner
Build the data path before introducing a wallet. Read prices, listed markets, open interest, funding, borrowing and available liquidity from official surfaces. Store raw source fields, network, marketToken and retrieval time. Generate hypothetical decisions without submitting anything.
Run this observer long enough to see stale responses, fallback-host behavior, negative funding, network interruptions and duplicate base assets. A strategy that only works on clean snapshots is not ready for capital.
type Snapshot = {
network: string;
marketToken: string;
totalOpenInterestUsd: number;
longFundingApr: number;
observedAt: number;
};
function candidate(snapshot: Snapshot) {
const fresh = Date.now() - snapshot.observedAt < 30_000;
const deepEnough = snapshot.totalOpenInterestUsd >= 1_000_000;
const unusualFunding = Math.abs(snapshot.longFundingApr) >= 0.20;
return fresh && deepEnough && unusualFunding;
}
// This function emits a research flag. It does not place a trade.Separate signal, policy and execution
The signal service should describe an observation, not hold a private key. A risk-policy service checks maximum position size, leverage, aggregate exposure, collateral concentration, acceptable price impact, current funding, data freshness and daily loss limits. Only approved intents reach execution.
Give every intent a unique identifier and make order creation idempotent. Network timeouts can leave a submitted transaction in an unknown state. Query the chain and indexed events before retrying so the bot does not double its desired exposure.
| Component | Responsibility | Must not do |
|---|---|---|
| Market-data collector | Fetch, validate and timestamp official data | Sign transactions |
| Strategy | Produce a proposed side, market and size | Bypass risk limits |
| Risk engine | Approve, resize or veto the intent | Infer missing live data |
| Executor | Build, simulate, sign and submit approved orders | Invent strategy decisions |
| Reconciler | Track execution, cancellation, freeze and position state | Assume submission equals a fill |
Model GMX order execution
GMX uses a two-step order process. The wallet transaction creates an order with parameters such as market, collateral, size and acceptable price. A keeper later obtains signed price data and attempts execution against contract rules.
A trigger price crossing does not prove the order filled. Execution can fail because of acceptable price, insufficient execution fee, invalid collateral state, liquidity limits, leverage constraints or another protocol rule. Reconciliation must read the resulting order and position events.
Price impact and acceptable price
GMX position price impact depends on how the trade changes long and short open-interest balance. A trade that improves balance can receive positive impact; a trade that worsens it can pay negative impact. This cost is separate from the position fee and Oracle spread.
Never submit an unbounded acceptable price. Compute it from the latest validated Oracle range plus a strategy-specific tolerance, then simulate the transaction. If the market moves beyond that tolerance, let the order fail or rebuild a new intent through risk approval.
Funding, borrowing and holding time
Near-live funding and borrowing values from markets/info are annualized and scaled by 1e30. Decode them before risk evaluation. A bot holding for one hour needs an hourly estimate, but it should also stress a rate jump because funding adapts with open-interest imbalance.
Funding and borrowing are separate. Positive long funding means longs pay under the documented sign convention. Borrowing is currently charged to the side with larger open interest. Add swap costs when collateral changes and account for all costs in expected edge.
Protect the signer
Use a dedicated wallet with deliberately limited capital. Keep signing outside the market-data and strategy processes. Store keys in a managed signer or hardware-backed service that supports the target chain, and never log secrets or full signed payloads.
Allow-list chain IDs, contract addresses and method selectors. Read current official contract addresses during deployment, then pin the reviewed values in configuration. GMX warns that logic contract addresses can change, so an upgrade should require review rather than automatic trust.
- Set a maximum notional per market and a lower default for new listings.
- Use a global kill switch independent of the strategy process.
- Require a fresh balance and position read before every order.
- Reject a chain or contract mismatch before signing.
- Rotate operational credentials and alert on unexpected nonce activity.
Test failure modes before capital
Unit tests should cover fixed-point conversions, negative values, duplicate symbols and boundary limits. Integration tests should use forked chain state or a tightly controlled small-capital wallet. A paper model should simulate delayed execution and slippage rather than marking fills at the signal midpoint.
Monitor source age, API latency, RPC health, pending transaction age, keeper outcome, position divergence and realized costs. Stop new orders when reconciliation falls behind. The safest default during uncertainty is no new exposure, not a guessed state.
Know what an API backtest misses
Hourly funding history and candle data do not recreate the exact Oracle range, pool imbalance and keeper delay of every historical trade. A backtest that ignores path-dependent price impact or assumes immediate fills will overstate performance.
Use backtests to reject weak ideas, then forward-test the full event pipeline. Compare expected price, submitted acceptable price, actual execution price, fees, funding, borrowing and gas for every completed order. Keep the measurement loop independent from the signal logic.
Primary sources
These sources were checked on July 26, 2026. Protocol parameters can change.
- 01GMX Docs: Frontend integration
- 02GMX Docs: Contracts
- 03GMX Docs: Positions and order types
- 04GMX Docs: Markets REST API
Referral disclosure
10% off eligible GMX position fees
Code PRO maps to GMX's tier-2 discount on eligible opening and closing position fees. The link is sponsored; the discount and protocol risks are unchanged.
Frequently asked questions
Does GMX have a trading API?
GMX publishes market-data APIs, contracts, frontend-integration documentation and SDK surfaces. Trading requires wallet-signed onchain transactions rather than a centralized-exchange API key.
Can a GMX bot trade without a keeper?
The normal order flow depends on keeper execution after the order-creation transaction. A submitted creation transaction is not the final fill.
Should a bot use the Oracle midpoint as its expected fill?
No. Execution uses the applicable min or max Oracle price plus position price impact and fee rules. The midpoint is only a useful display reference.
Where should a GMX bot store its private key?
Prefer a managed or hardware-backed signer isolated from data and strategy services. Use a dedicated, limited-capital wallet and strict contract and chain allow-lists.
Is a high funding rate a profitable trading signal?
Not by itself. Funding can reflect persistent imbalance and price risk. A strategy must include execution costs, borrowing, price impact, holding time and adverse market movement.
Continue learning