Ethereal Docs
  • Introduction
    • What is Ethereal?
  • Public Testnet
  • Trading
    • Perpetual Futures
      • Margining
      • Order Types
      • Positions
      • Funding Rates
      • Market Specifications
      • Liquidations
      • Auto Deleveraging
      • Subaccounts
      • Price Oracles
  • Points
    • Staking sENA
    • Season Zero
  • developer-guides
    • Trading API
      • Quick Start
      • Message Signing
      • Accounts & Signers
      • Order Placement
      • System Limits
      • Products
      • Token Transfers
      • Supported Tokens
      • Websocket Gateway
    • Python SDK
  • Protocol Reference
    • API Hosts
    • Contracts
    • Audits
Powered by GitBook
On this page
  • Overview
  • Burst Protection
  • Current Limits and Shared Quotas
  • X-RateLimit-* Headers
  • Points
  • Account Limits
  • Order Limits
  1. developer-guides
  2. Trading API

System Limits

Overview

The Trading API uses a comprehensive rate limiting system that tracks both IP addresses and wallet addresses through a time-weighted point system. Each API call consumes a predetermined number of points from your available quota within a rolling time window. Point consumption varies by endpoint, with some routes consuming different amounts and others consuming no points at all.

Burst Protection

In addition to standard rate limits, the API implements burst limits to ensure stable performance. While you may have points remaining in your general quota, burst limits prevent rapid consumption by imposing a smaller window restriction. This distributes request traffic more evenly throughout the rate limit period, preventing API overload and maintaining consistent response times.

Current Limits and Shared Quotas

The system currently allows 70,000 points per 1-minute window with a 20,000 point burst cap per 10-second window. Both HTTP API calls and WebSocket connections share the same point pool, with WebSocket streams consuming points upon connection and subscription. This unified approach ensures fair resource allocation across all API interactions.

The point consumption per endpoint has not been finalized and will be adjusted in future updates.

X-RateLimit-* Headers

All rate-limited HTTP API endpoints return the following headers to provide insight into your remaining points:

Retry-After: <seconds until rate limit resets>
X-RateLimit-Limit: <total points allowed in the time window>
X-RateLimit-Remaining: <points remaining in the current time window>
  • Retry-After: Indicates the number of seconds until the rate limit window resets. If you've exceeded your rate limit, this header tells you how long to wait before making additional requests.

  • X-RateLimit-Limit: Shows the total number of points available in your current time window (1 million points by default).

  • X-RateLimit-Remaining: Displays the number of points you have remaining in the current time window. This decreases with each API call according to the point cost of the specific endpoint.

Points

For simplicity, the current rate limits are generalised into three categories: low, medium, and high. Each API endpoint is categorised into one of these point consumption levels:

  • Low: 1 point per request

  • Medium: 10 points per request

  • High: 100 points per request

All endpoints are classified into one of these categories to provide a straightforward understanding of their relative impact on your rate limit quota.

Points per endpoint may change at any time and the notes here may not always be the most up to date.

All websocket connections consume 100 points per connection.

Account Limits

  • Maximum 50 open positions per subaccount (for efficient onchain verification)

  • No limit on number of subaccounts per trader

  • Liquidations checked at each Pyth Lazer price update interval

Order Limits

  • A maximum of 200 orders

PreviousOrder PlacementNextProducts

Last updated 3 days ago

Page cover image