Private Gravity RPC Endpoints on a Dedicated Node

A Gravity RPC node is the server your app talks to when it needs chain data, transaction status, logs, or contract reads. Today the live production target is Gravity Alpha Mainnet, which Gravity documents as an Ethereum rollup using the Arbitrum Nitro stack. We run that node on dedicated hardware so your app gets a private Gravity RPC lane instead of competing inside a public pool.

Not in the staking sense. Gravity Alpha Mainnet is an Ethereum rollup on the Arbitrum Nitro stack with a centralized sequencer, so there is no permissionless, stake-to-earn validator like Ethereum or Solana. What we provision is what apps and indexers actually need: a fast, dedicated full or archive RPC node running the Nitro client, with trace and debug builds available for heavier workloads.

Yes. Gravity's live node guide is clear on this: you need a local data directory, an Ethereum mainnet RPC endpoint with unlimited eth_getLogs, and an Ethereum beacon chain RPC endpoint. The guide also requires the latest snapshot, because syncing from genesis is not supported due to historical data availability format changes. You can bring your own Ethereum endpoints or host them with us in the same region for tighter latency, and we plan around those upstream dependencies from day one.

For Gravity Alpha Mainnet the official chain ID is 1625 and the native token is G. Gravity's docs also list the official RPC endpoint and explorer references for the live network. If you are connecting a wallet, backend, or middleware stack, we use those live settings as the base and then point your services to your private RedSwitches endpoint once your server is ready.

Most teams do not need archive on day one. A full node is usually enough for wallets, dashboards, internal services, transaction tracking, and many dApps. Archive is the better fit when you need deeper historical state access, long-range research, forensic work, or heavier historical processing. Since Gravity's live network runs on Nitro today, we use this as our practical sizing approach for production Gravity RPC workloads.

Yes. Gravity's self-hosted node guide maps HTTP on 8547 and WebSocket on 8548, so a self-managed or managed dedicated deployment can serve both request-response traffic and subscription-driven workloads. We usually recommend HTTPS for standard app reads and broadcasts, then WebSockets for live event listeners, bots, notifications, and systems that need fresh block or log updates without constant polling.

Not every app needs it. If you are building a simple wallet, portfolio view, or basic dashboard, standard RPC methods are often enough. If you are running indexers, debugging failed contract behavior, reviewing incidents, or doing deeper engineering analysis, trace and debug become much more useful. Gravity's current node guide explicitly adds both endpoints, so we can expose them on your Dedicated Gravity RPC node when your workload needs more than plain reads and writes.

Yes. This is one of the biggest reasons teams choose us over a generic shared API. Our dedicated RPC platform supports keeping endpoints private with firewall rules and IP allowlisting, and our dedicated infrastructure also supports private networking, VPN-style access patterns, and direct server control with root and IPMI. If your RPC endpoint is part of your security boundary, that control matters.

No. Unlike shared RPC providers that bill per "compute unit" and throttle you past a quota, a dedicated node is a flat monthly price with unlimited requests and zero overages. One node equals all the throughput your hardware can serve. That makes budgeting predictable and removes the surprise bills that come with usage-based RPC pricing.

Shared RPC pools serve thousands of customers from pooled infrastructure, so you inherit rate limits, noisy-neighbor latency, and compute-unit billing. A RedSwitches node runs on single-tenant bare metal that is yours alone: reserved CPU, RAM, and NVMe, a dedicated 10/25 Gbps port, and a private endpoint you control. Performance tracks your hardware, not another tenant's traffic.

No. We provision from current snapshots so your node is live in hours rather than syncing from genesis for days. You can run it yourself with full root access, or choose our fully managed option where our engineers handle the sync, updates, and monitoring. Either way you receive a working private endpoint, not an empty server.

Yes. With 20+ Tier III locations across the US, EU, Asia, and Australia you can place your node in the same region as your users or a chain's sequencer to cut round-trip latency. Tell us your target region and we will recommend the closest facility. You can also run multi-region nodes for redundancy and split read and write endpoints.