Developing a Position Management System for Perpetual DEXs

We develop custom position management systems for perpetual DEXs – from a simple tracker to a full risk manager with automatic stop-losses and margin management. Perpetual DEXs (dYdX, GMX, Hyperliquid, Gains Network) enable leveraged trading with no expiry date and no centralized custodian. But their standard UI doesn't cover programmatic control: bots, vaults, automation protocols require their own solution. Our team has over 5 years of experience in DeFi development and guarantees transparent integration with any perpetual DEX. This article breaks down the architectural differences of key perpetual DEXs, shows a real integration with GMX v2, and provides ready-made templates for tracking and risk management.

What are the architectural differences between orderbook and AMM perpetual DEXs?

Orderbook-based (dYdX v4, Hyperliquid)

Classic orderbook, but on-chain or with off-chain orderbook and on-chain settlement. dYdX v4 is a separate Cosmos appchain, Hyperliquid is its own L1. Interaction via REST API and WebSocket, similar to CEX.

Peculiarity of dYdX v4: transactions are sent not via Ethereum RPC but via Cosmos SDK. Different client, different formats. @dydxprotocol/v4-client-js is the official SDK.

Hyperliquid: its own HTTP API and WebSocket. Signing via EIP-712 (EVM-compatible). Fastest throughput among on-chain perps.

AMM-based (GMX v2, Gains Network)

Positions are opened against a liquidity pool, not a counterparty. Price impact exists, no orderbook. GMX v2 uses synthetic assets via Chainlink price feeds.

GMX v2 contracts: ExchangeRouter for opening/closing positions, OrderVault for storing collateral until execution. All operations via createOrder() with parameters.

How is liquidation price calculated on different exchanges?

Position tracker

A component that continuously monitors open positions:

interface Position { id: string; exchange: "dydx" | "gmx" | "hyperliquid"; market: string; // "ETH-USD" side: "long" | "short"; size: bigint; // in USD entryPrice: number; currentPrice: number; unrealizedPnl: number; liquidationPrice: number; leverage: number; margin: bigint; fundingPaid: number; // accumulated funding payments } 

Data sources: WebSocket subscriptions to position updates (dYdX, Hyperliquid), polling via REST every 5–30 seconds (GMX via subgraph or direct contract calls).

Risk manager

Monitors proximity to liquidation and executes stop-loss/take-profit:

const riskThresholds = { liquidationWarning: 0.15, // 15% to liquidation → alert autoReduceAt: 0.10, // 10% to liquidation → reduce position emergencyCloseAt: 0.05, // 5% to liquidation → close completely }; const distanceToLiquidation = (position: Position): number => { const current = position.currentPrice; const liq = position.liquidationPrice; if (position.side === "long") return (current - liq) / current; return (liq - current) / current; }; 

Add margin – first line of defense. When approaching liquidation price – automatically add collateral instead of closing. Cheaper on gas and preserves position. Requires a reserve USDC balance on the wallet.

Partial close – in heavy situations, reduce size by 30–50%. Reduces risk without full exit.

Emergency close – full close with a market order. High slippage, but when facing real liquidation threat, losing 1–2% on slippage is better than a 5–15% liquidation penalty.

Funding rate monitor

Funding payments on perpetuals are hidden costs that, with the wrong sign, eat PnL. We track:

// For longs: positive funding rate → you pay // For shorts: positive funding rate → you receive const calculateFundingCost = ( position: Position, fundingRate8h: number, // e.g., 0.0001 = 0.01% periods: number ): number => { const sign = position.side === "long" ? -1 : 1; return position.size * fundingRate8h * periods * sign; }; 

If accumulated funding cost exceeds expected profit on the position – candidate for closing regardless of PnL.

Integration with GMX v2: step-by-step guide

GMX v2 is the most complex popular perpetual DEX for integration because all operations are asynchronous via order keeper.

1. Import GMX contracts via npm install @gmx-v2/contracts.
2. Connect Viem provider and get an instance of ExchangeRouter.
3. Create and sign CreateOrderParams.
4. Send transaction with executionFee.
5. Handle callback afterOrderExecution().

// Opening a long position on ETH IExchangeRouter.CreateOrderParams memory params = IExchangeRouter.CreateOrderParams({ addresses: IExchangeRouter.CreateOrderParamsAddresses({ receiver: address(this), callbackContract: address(this), // our contract gets callback uiFeeReceiver: address(0), market: ETH_USD_MARKET, initialCollateralToken: USDC_ADDRESS, swapPath: new address[](0) }), numbers: IExchangeRouter.CreateOrderParamsNumbers({ sizeDeltaUsd: 10_000 * 1e30, // $10,000 position (30 decimals) initialCollateralDeltaAmount: 1_000 * 1e6, // $1,000 collateral (USDC 6 decimals) triggerPrice: 0, // market order acceptablePrice: minAcceptablePrice, executionFee: executionFee, callbackGasLimit: 700_000, minOutputAmount: 0 }), orderType: Order.OrderType.MarketIncrease, decreasePositionSwapType: Order.DecreasePositionSwapType.NoSwap, isLong: true, shouldUnwrapNativeToken: false, referralCode: bytes32(0) }); exchangeRouter.createOrder{value: executionFee}(params); 

The order is executed by GMX keeper nodes asynchronously. Callback afterOrderExecution() on your contract signals execution. If the keeper doesn't execute within a certain time – order can be canceled via cancelOrder().

Liquidation price calculation on GMX

borrow_fee accumulates over time – it must be considered when calculating current state. GMX provides the Reader contract with getPositionInfo() that returns up-to-date data including fees.

Exchange comparison table

Stack and infrastructure

TypeScript + viem for GMX on-chain interactions. @dydxprotocol/v4-client-js for dYdX. WebSocket clients for real-time data. PostgreSQL + TimescaleDB for history of positions and PnL. Redis for caching current state. Grafana dashboard with metrics for all open positions.

Timeline estimates

Position tracking system for one perpetual DEX with alerts – 3–5 days. Full system with risk management, auto-margin-add and stop-loss/take-profit for one protocol (GMX or dYdX) – 1–1.5 weeks. Multi-protocol system (GMX + dYdX + Hyperliquid) – 2–3 weeks. Cost is determined after clarifying target exchanges and automation requirements.

Get a consultation on your project – we'll assess complexity and timeline. We deliver turnkey in 2–3 weeks.