Backend

Details how to fetch trade data from off-chain services

Backend services, for the purpose of managing trades, do not provide anything that can't be fetched or listened to directly on-chain.

It is recommended to use gTrade backends when possible however to improve resilience against RPC issues - service is optimized for uptime.

DNS

Common DNS syntax - backend-<network>.gains.trade

NOTE: No auth is required for accessing REST GET endpoints and the WebSocket event stream. However, rate limiting is in place, so please fetch data only as necessary and rely on the event stream to keep your data updated.

Backend types

You can find backend return types HERE

v10 Update

As of v10, the SDK now offers normalization for both trading variables and trades.

Current version: @gainsnetwork/[email protected]

For most SDK interactions you will need tradingVariables object. Learn below how to fetch it and transform it to use within SDK.

Example: fetching and transforming trading variables

For detailed `/trading-variables` information, see "Common Endpoints" section below

Example: getting all trades for current address

Example: converting TradeContainerBackend to TradeContainer

Example: converting array of FeeBackend to FeeFrontend

Common Endpoints

Trading Variables

Provides main data necessary for opening, closing, and managing trades. Payload also contains all active trades (allTrades).

Request:

GET /trading-variables

Response:

Open Trades

Returns all open trades (matches deprecated allTrades output from /trading-variables endpoint). Optionally specify trader address for filtering.

Request:

GET /open-trades GET /open-trades/<address> Response:

User Trading Variables

Provides useful trader specific data, such as pending order IDs and fee tiers.

Request:

GET /user-trading-variables/<address>

Response:

Historical Trades

Provides all historical trades (open & closed) for a given address

Request:

GET /personal-trading-history-table/<address>

Provides all open & closed trades in last 24hrs

GET /trading-history-24h

Response (same for both historical endpoints):

Event Stream

As mentioned in Events, backend event streams can serve as proxies for on-chain trade events. The stream will publish both unconfirmed and confirmed events. Unconfirmed events are published until the risk a block is reorged is negligible, at which point a confirmed event is sent. For most integrations, only confirmed events (liveEvent) need to be listened to.

Backends also publish structured, post-processed events based on what on-chain event has just taken place. For example, registerTrade provides a full trade struct following the raw event MarketOrderExecuted. This is to limit how much clients need to fetch additional data.

Structure:

Common event names:

  • liveEvents - raw on-chain events. Payload is identical to on-chain event.

  • registerTrade - trade has been registered

  • unregisterTrade - trade has been closed

  • updateTrade - trade SL/TP has been updated

  • updateLeverage - trade leverage updated (collateral removed or added)

  • updatePositionSize - trade position size updated (adding to position or partial close)

  • tradingVariables - updated /trading-variables payload

  • currentBlock - L2 block number for network

  • currentL1Block - L1 block number for network

  • deepReorg - Reorg has been detected - refresh data

  • new-trade-history - New trade history document

Last updated

Was this helpful?