TL;DR
The Gnosis Chain team openly warns developers that their official public RPC at https://rpc.gnosischain.com comes with no SLA or availability guarantees — yet most guides send you there first. For a chain designed to run always-on payments, DAO tooling, and prediction markets that can’t afford downtime, that’s a mismatch worth addressing before you write a single line of production code. This guide covers every endpoint option for Gnosis Chain mainnet and Chiado testnet, explains why xDAI as the gas token changes your infrastructure assumptions, and shows you how to deploy a private endpoint in minutes.
What is a Gnosis Chain RPC endpoint
Gnosis Chain runs a standard Ethereum JSON-RPC API — the same eth_* methods, the same ABI encoding, the same familiar tooling. An RPC endpoint is the HTTPS or WebSocket URL your application sends those JSON-RPC calls to, whether it’s asking for the current block number, reading a multisig Safe’s pending transactions, or broadcasting a new CoW Protocol batch order.
What depends on the endpoint on Gnosis Chain specifically:
- Reading xDAI balances and ERC-20 token balances across 145,000+ validator addresses
- Querying conditional token contract states for prediction market outcomes
- Calling Safe multisig contract methods to read pending confirmations and transaction queues
- Emitting and listening to
eth_getLogsevents from DeFi protocols (CoW Protocol, Curve, Balancer, Gnosis Pay) - Broadcasting transactions to the mempool for inclusion in the next ~5-second block
- Fetching historical event logs for governance participation tracking and treasury analytics
- Running
eth_callsimulations for smart contract interactions before on-chain execution
The quality difference between a public and a private endpoint on Gnosis Chain is more consequential than it looks on paper. Because Gnosis is designed as a home for always-on coordination infrastructure — Safe wallets, DAO voting, payment streams — an endpoint that stumbles at 50 concurrent requests can silently degrade the user experience of products that were built assuming reliable, low-latency responses.
📖 You can review the full list of supported JSON-RPC methods in the Ethereum JSON-RPC API reference — Gnosis Chain implements the same standard API.
How Gnosis Chain RPC differs from Ethereum RPC
Gnosis Chain is EVM-compatible and implements the standard Ethereum JSON-RPC spec — but its chain parameters create meaningful differences that affect how you select and configure your RPC provider.
| Property | Ethereum Mainnet | Gnosis Chain |
|---|---|---|
| Block time | ~12 seconds | ~5 seconds |
| Gas token | ETH (volatile) | xDAI (USD-pegged stablecoin) |
| Chain ID | 1 | 100 |
| Consensus | PoS (Beacon Chain) | PoS (Gnosis Beacon Chain) |
| Finality | ~12.8 min (2 epochs) | ~2.5 min (faster epoch) |
| Validator minimum | 32 ETH | 1 GNO |
| Typical fee | Variable ($1–$100+) | Sub-cent (< $0.001) |
The two differences that matter most for RPC provider selection are the faster block time and the stablecoin gas model. At 5-second blocks, polling-based architectures generate roughly 2.4× more RPC requests against your plan quota than the same code running against Ethereum. And because fees are denominated in xDAI rather than ETH, any app doing fee estimation or gas display needs to understand it’s working in a stablecoin context — not a volatile asset — which changes how you surface cost data to users.
Gnosis Chain RPC endpoint options
Public vs private Gnosis Chain RPC endpoints
Gnosis is designed for the kind of applications that keep running — Safe wallets processing treasury transactions, prediction markets tracking outcomes, payment systems settling micro-transactions. A shared public endpoint, by definition, cannot guarantee that your application’s requests won’t be queued behind someone else’s.
Official public endpoints:
- Mainnet:
https://rpc.gnosischain.com - Mainnet (Gateway):
https://rpc.gnosis.gateway.fm - Chiado Testnet:
https://rpc.chiadochain.net - Chiado Testnet (Gateway):
https://rpc.chiado.gnosis.gateway.fm
⚠️ The Gnosis Core Team explicitly states that the official public RPC carries no SLA or availability guarantees. For production deployments — including Safe wallets, DAO tooling, or any payment-critical application — the Gnosis docs themselves recommend using professional RPC providers. Additionally, because Gnosis Chain is on Chainlist, any endpoint you find there should be treated as a discovery tool, not a production configuration. Replace Chainlist URLs with a managed endpoint before going live.
| Feature | Public endpoint | Private endpoint |
|---|---|---|
| Access | Free and open | Restricted access |
| Resources | Shared infrastructure | Dedicated resources |
| Best use case | Development & testing | Production workloads |
| Availability guarantee | None (no SLA) | Contractual uptime SLA |
| WebSocket support | Limited/unstable | Available |
| Archive data access | Not available | Available |
For chains designed to host always-on coordination infrastructure, a shared endpoint with no SLA is the one configuration that contradicts Gnosis Chain’s entire reliability premise.
Full node vs archive Gnosis Chain node
Gnosis Chain’s most important use cases — DAO governance participation tracking, prediction market resolution, Safe wallet historical audit trails — all require looking back at historical state. Knowing which node type you need is the difference between a query that returns in milliseconds and one that silently fails.
| Full node access | Archive node access |
|---|---|
| Current xDAI and ERC-20 balances | Historical balance at any past block |
| Real-time Safe multisig transaction monitoring | Complete transaction history for governance audit trails |
| Active prediction market contract state | Past conditional token resolution events via eth_getLogs |
| Live CoW Protocol batch order broadcasting | Historical DEX trade data for analytics and compliance |
| Current validator set and staking state | Full event log history for on-chain DAO voting records |
| Latest block data and mempool access | eth_getStorageAt calls against historical block numbers |
Chainstack supports archive nodes for Gnosis Chain. If you’re building governance analytics, compliance tools, or any application that needs to reconstruct the full history of Safe wallet approvals or prediction market outcomes, archive access is not optional.
HTTPS vs WebSockets
On a 5-second block chain, persistent WebSocket connections earn their overhead cost faster than on Ethereum. If your application subscribes to eth_subscribe for new blocks or pending transactions, you’ll see a WebSocket connection re-established every 24 blocks or fewer on Gnosis — connection overhead matters.
| Feature | HTTPS | WebSocket |
|---|---|---|
| Model | Request/response | Persistent connection |
| Complexity | Simple operationally | Requires reconnect/heartbeat logic |
| Best for | Safe transaction reads, contract calls, one-off queries | Real-time block subscriptions, eth_subscribe for log events, CoW Protocol order status monitoring |
| Latency | Standard | Lower for frequent updates |
| Connection overhead | Per request | One-time handshake |
WebSocket support is limited or unreliable on public Gnosis endpoints. For any production application subscribing to on-chain events, a managed provider with stable WebSocket infrastructure is the only viable path.
How to get a private Gnosis Chain RPC endpoint with Chainstack
Chainstack provides Gnosis Chain nodes for both Mainnet and Chiado Testnet, with WebSocket endpoints and archive data access available on paid plans.
- Log in to the Chainstack console (or create a free account)
- Create a new project
- Select Gnosis Chain as your blockchain protocol
- Choose network: Gnosis Mainnet or Chiado Testnet
- Deploy the node
- Open Access & Credentials and copy your HTTPS and WebSocket endpoints
- Run a quick connectivity check with
eth_blockNumberbefore wiring it into production code
Here’s a quick connection check using ethers.js:
const { ethers } = require("ethers");
// Connect to your Chainstack Gnosis Chain endpoint
const provider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ENDPOINT", {
chainId: 100, // Gnosis Chain mainnet chain ID
name: "gnosis"
});
async function checkConnection() {
const blockNumber = await provider.getBlockNumber();
console.log("Latest Gnosis Chain block:", blockNumber);
// Check xDAI balance of an address
const balance = await provider.getBalance("0x0000000000000000000000000000000000000001");
console.log("Balance (xDAI):", ethers.formatEther(balance));
}
checkConnection();
// Requires ethers v6. For v5, use ethers.providers.JsonRpcProvider instead.
📖 For the full integration guide, see the Chainstack Gnosis Chain tooling documentation.
Chainstack pricing for Gnosis Chain RPC
Chainstack’s pricing model bills per request regardless of method type — no compute-unit multipliers, no per-method surcharges. See the full Chainstack pricing page for plan details and overage rates.
| Plan | Cost | Requests/Month | RPS | Overage (per 1M extra) |
|---|---|---|---|---|
| Developer | $0 | 3M (~25 RPS) | ~25 | $20 |
| Growth | $49 | 20M | ~250 | $15 |
| Pro | $199 | 80M | ~400 | $12.5 |
| Business | $499 | 200M | ~600 | $10 |
| Enterprise | From $990 | 400M+ | Custom | From $5 |
Advanced options:
- Archive Node add-on — for historical state access, governance analytics, and compliance workloads
- Unlimited Node add-on — for request-intensive production workloads
- Dedicated Nodes: From $0.50/hour (+ storage)
How to estimate monthly cost
- Estimate your daily active users or bots interacting with the chain
- Count RPC calls per session: Safe reads, log queries, contract calls, transaction broadcasts
- Multiply by 30 for monthly volume
- Compare against plan request allocations
- Gnosis-specific note: At 5-second blocks, automated systems polling for new blocks will consume ~17,280 requests per day per poller — factor this in separately from user-driven traffic. A governance bot polling every block can exhaust a Developer plan’s daily allocation in under three hours.
Production readiness checklist
- Primary + fallback RPC provider configured
- Request timeout policy set (recommended: 10s for standard calls)
- Retry logic with exponential backoff implemented
- Credentials stored in env/secret manager (never hardcoded)
- Monitoring for latency, error rate, and throttling
- Alerts for sustained degradation
- WebSocket reconnect logic with missed-event backfill for
eth_subscribeconsumers - Chain ID validation (
100for mainnet,10200for Chiado) — prevents accidental cross-chain transaction submission eth_getLogsquery window tested against your provider before launch — some endpoints cap the block range per query- Use Chainstack Compare to benchmark endpoint latency before choosing a provider
Troubleshooting common Gnosis Chain RPC issues
| Issue | Likely Cause | How to Fix |
|---|---|---|
429 Too Many Requests | Hitting rate limits on public or shared endpoint | Move to a managed endpoint with higher RPS limits |
| WebSocket disconnects mid-session | Public WS endpoints are unstable; no heartbeat | Implement reconnect logic with exponential backoff; use a private endpoint with stable WS |
eth_getLogs returns empty results despite events existing | Block range too wide; some providers cap at 1,000–10,000 blocks per query | Paginate your log queries; verify provider’s block range limits |
| Transaction broadcast succeeds but doesn’t confirm | Insufficient xDAI for gas, or gas price below current basefee | Check xDAI balance; use eth_gasPrice to set appropriate gas; don’t hardcode gas values |
invalid chain ID error when signing | Wallet or signer configured for Ethereum (chain ID 1) instead of Gnosis (chain ID 100) | Explicitly set chainId: 100 in your provider configuration |
Stale state returned from eth_call | Full node hasn’t synced to latest; using outdated block tag | Use "latest" as block parameter; verify node sync status with eth_syncing |
Conclusion
A public Gnosis Chain endpoint that goes down during a governance vote isn’t just an inconvenience — it’s a failed quorum, a Safe transaction that can’t be confirmed, a prediction market settlement that hangs. The Gnosis Chain team documents this risk explicitly: their own public RPC carries no availability guarantee. For a chain built around coordination infrastructure that must keep running, that’s the configuration that breaks the most silently and costs the most to diagnose.
The pattern that works: start with a managed endpoint from day one, even on the Developer free tier. Configure a fallback provider. Implement WebSocket reconnect logic before you need it — not after your first production incident. Archive access isn’t optional if your application reads historical Safe transactions or past governance outcomes.
FAQ
Any Ethereum-compatible library works unchanged on Gnosis Chain. ethers.js, web3.js, viem, web3.py, and Foundry all connect by pointing at a Gnosis Chain endpoint with chainId: 100. The only adjustment required is ensuring you’re using xDAI for gas estimation rather than ETH — the API surface is identical.
No. The Gnosis Chain documentation explicitly states the official public RPC comes with no SLA or availability guarantees. For any application where downtime has real consequences — Safe multisig wallets, active DAO voting periods, payment streams — you need a managed endpoint backed by an uptime commitment. The public endpoint is appropriate for local development and initial testing only.
Gnosis Chain produces a block every ~5 seconds, roughly 2.4× faster than Ethereum’s 12-second blocks. An automated system that calls eth_blockNumber or eth_getBlockByNumber on every new block generates 17,280 requests per day — before any actual application logic runs. Structure your bot to batch calls where possible, use WebSocket subscriptions instead of polling where available, and account for this baseline consumption when sizing your plan.
It depends on your use case. If you only need to display current pending transactions and check current multisig state, a full node is sufficient. If you need to reconstruct a complete transaction history, audit past approvals, or backfill historical Safe events for compliance or analytics purposes, you need archive access. Most serious Safe integrations eventually require archive — plan for it early.
Chainlist is a useful discovery tool for adding Gnosis Chain to wallets, but any RPC URL sourced from Chainlist should be replaced with a managed private endpoint before going to production. Public endpoints listed on Chainlist are community-submitted and carry no reliability guarantees.
Chiado (Chain ID: 10200) mirrors Gnosis mainnet parameters — same 5-second block time, same xDAI gas token, same EVM compatibility — making it a high-fidelity staging environment. Chiado runs a semi-permissioned validator set managed by Nethermind, Gateway, and the Gnosis team for stability. Use Chiado for smart contract deployments, bridge testing, and pre-production validation before mainnet release. Testnet xDAI is available from https://faucet.chiadochain.net/.