ORBION DOCS
WebsiteWhitepaper
  • 🔹Introduction
  • 🔹Core Architecture
  • 🔹Why Modular
  • 🔹Governance
  • 🔹Fee Model & Token Utility
  • 🔹Architecture Overview
  • Core Team
  • 🔹FAQ
  • Network
    • 🔹Overview
    • 🔹Public RPC Endpoints
    • 🔹Explorer & Faucet
    • 🔹Validator Setup
    • 🔹Network Parameters
  • Developer Guide
    • 🔹How to Connect with MetaMask
    • 🔹Deploy Smart Contracts on Orbion
    • 🔹Using the Testnet Faucet
    • 🔹Validator Setup Guide
  • RPC Access
    • 🔹Public RPC Specs
    • 🔹Rate Limits & Best Practices
    • 🔹Running a Node
  • for user
    • 🔹Tokenomics
    • 🔹Orbion Roadmap
  • Ecosystem
    • 🔹Orb Coin
    • 🔹Orbion Finance
    • 🔹Orbion Bridge
    • 🔹Orbion Tools (Telegram Bot Suite)
    • 🔹Orbion Locker
    • 🔹Orbion Explorer
    • 🔹Orbion SDK & API
    • 🔹Third-Party Integrations
Powered by GitBook
On this page
  1. RPC Access

Rate Limits & Best Practices

Orbion’s public RPC endpoints are a shared resource provided for developers, testnet validators, and dApp builders. To ensure fair usage and stable performance across the ecosystem, requests are rate-limited and monitored for abusive behavior.

This page outlines current limits, usage guidelines, and recommended patterns for efficient integration.


📊 Rate Limit Policy

Category
Limit

Requests per IP

20 requests per second (burstable)

Daily Cap

Soft cap at 250,000 req/day per IP

Payload Size

Max 1MB per request body

Concurrent Requests

5 per session recommended

WebSocket

Not supported yet

❗ Exceeding limits will result in temporary throttling (HTTP 429), progressive backoff, or IP cooldown.


⚠️ Throttling Behavior

When a client exceeds the permitted rate:

  • Requests may be delayed automatically (rate shaping)

  • Burst requests are deprioritized

  • IP cooldown is triggered on persistent abuse (up to 60 min)

  • Monitoring systems will blacklist aggressive bots or loops


✅ Best Practices for Developers

Follow these recommendations to avoid issues and improve your dApp’s RPC performance:

1. Avoid Repetitive Polling

  • Don't poll eth_blockNumber every 100ms — it wastes quota ⟶ Use block subscription (future) or check every 5–10s

2. Batch Requests When Possible

  • Combine multiple eth_calls into one batch using eth_batch

3. Use Caching for Static Reads

  • Cache contract metadata, eth_getCode, token symbols, etc. ⟶ Reduce load and speed up UX

4. Back Off Gracefully

  • Implement exponential backoff when receiving HTTP 429 ⟶ Respect server load and retry later

5. Separate Frontend & Backend Traffic

  • Use server-side proxy for backend interactions if needed ⟶ Prevent client-side rate collisions


🧠 When to Run Your Own Node

If you are:

  • Indexing large sets of logs

  • Running dashboards or explorers

  • Building bots, aggregators, or bridge relayers

  • Reaching >500k RPC calls/day

Then it's highly recommended to operate a full or archive Orbion node. See Running a Node for instructions.


Orbion’s public RPC is designed to accelerate early development — not to replace dedicated infrastructure. Please use it respectfully and help maintain network health for everyone.

PreviousPublic RPC SpecsNextRunning a Node

Last updated 6 days ago

🔹