Gnosis RPC Endpoints: Chain Settings, Public Access, and Production Setup

Quick recommendation: which Gnosis RPC setup fits your project?

If you are building a prototype, running a script, or testing a wallet connection, a public Gnosis RPC endpoint is usually enough. It gives you immediate access to chain ID 100 without signup. For production applications that serve real users, you will want a managed RPC service with predictable throughput, monitoring, and a path to dedicated nodes when your request volume grows.

Use this table to match your workload to the right endpoint type:

OnFinality provides both shared and dedicated Gnosis RPC options. You can review RPC pricing and the Gnosis network page for current details.

Gnosis Chain settings at a glance

Gnosis Chain is an EVM-compatible network. Most Ethereum tooling works with minimal changes. Here are the core parameters you will need when adding Gnosis to a wallet or a Web3 library:

Note that Gnosis uses xDAI as its gas token. Users pay transaction fees in xDAI, not in a separate token. This is a common point of confusion when bridging assets or setting up a new wallet.

Connecting with curl, ethers.js, and wallet config

The fastest way to verify an endpoint is a simple eth_chainId call. Replace the placeholder with your own endpoint if you are using a private service.

curl -X POST https://gnosis.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

The response should return 0x64, which is hexadecimal for 100.

For JavaScript applications, ethers.js v6 works out of the box:

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider('https://gnosis.api.onfinality.io/public');

const network = await provider.getNetwork();
console.log(network.chainId); // 100n

const block = await provider.getBlockNumber();
console.log('Current block:', block);

If you use viem, the setup is similar:

import { createPublicClient, http } from 'viem';
import { gnosis } from 'viem/chains';

const client = createPublicClient({
  chain: gnosis,
  transport: http('https://gnosis.api.onfinality.io/public'),
});

const blockNumber = await client.getBlockNumber();

To add Gnosis to a browser wallet such as MetaMask, use the following network configuration:

{
  "chainId": "0x64",
  "chainName": "Gnosis",
  "nativeCurrency": {
    "name": "xDAI",
    "symbol": "XDAI",
    "decimals": 18
  },
  "rpcUrls": ["https://gnosis.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://gnosisscan.io"]
}

Common JSON-RPC methods on Gnosis

Gnosis supports the standard Ethereum JSON-RPC API. The methods you will use most often include:

• eth_blockNumber – latest block height
• eth_getBalance – xDAI balance for an address
• eth_call – read-only contract interaction
• eth_getLogs – event logs, often used by indexers
• eth_sendRawTransaction – broadcast a signed transaction
• eth_getTransactionReceipt – transaction status and logs

Because Gnosis is EVM-equivalent, contract deployment and interaction follow the same patterns as Ethereum. The main differences are gas costs, block times, and the set of deployed contracts.

If you rely on eth_getLogs for indexing, check the block range limits of your endpoint. Public endpoints often cap the number of blocks you can query in a single call. Managed services typically allow larger ranges, and dedicated nodes give you control over the limits.

When to move from public to dedicated Gnosis RPC

Public endpoints are shared. That means your requests compete with other users, and you may see rate limiting or slower responses during peak times. For many developers, this is fine for development and low-traffic applications. But as your project grows, you will hit limits that affect user experience.

Consider moving to a dedicated Gnosis node when:

• Your application sends a high volume of requests per second.
• You need consistent response times for a user-facing dApp.
• You rely on archive data for historical queries.
• You want to avoid rate limits and noisy-neighbor effects.
• You need WebSocket support for subscriptions (check availability with your provider).

OnFinality's dedicated node offering provides isolated Gnosis infrastructure. You can also start with a shared plan and upgrade later. The RPC pricing page outlines the options.

Production readiness checklist for Gnosis RPC

Before you ship, run through these checks to avoid common pitfalls:

1. Endpoint redundancy – Use at least two RPC providers or endpoints. Configure your application to fail over if one becomes unresponsive. This prevents a single point of failure.
2. Chain ID verification – Always confirm you are connected to chain ID 100. A misconfigured endpoint could connect to a testnet or a different chain.
3. Gas token awareness – Ensure your users understand that transaction fees are paid in xDAI. If you sponsor transactions, budget accordingly.
4. Rate limit planning – Know the request limits of your endpoint. For public endpoints, assume low limits. For managed services, check the plan details.
5. Archive requirements – If you query historical state (e.g., balance at an old block), you need an archive node. Confirm with your provider.
6. Monitoring – Set up alerts for RPC errors, latency spikes, and failed transactions. A simple health check can catch issues early.
7. WebSocket vs HTTP – If you need real-time events, check whether your provider supports WebSocket subscriptions. HTTP is sufficient for most read/write operations.

Debugging common Gnosis RPC issues

Even with a good endpoint, you may encounter errors. Here are typical symptoms and fixes:

For nonce-related errors, see our article on blockchain nonces.

Evaluating Gnosis RPC providers

When comparing providers, look beyond the headline price. Consider these factors:

• Supported methods – Does the provider support the JSON-RPC methods you need, including eth_getLogs and archive queries?
• Transport options – HTTP is standard. WebSocket may be available for subscriptions.
• Rate limits – Understand the requests per second and daily caps. Public endpoints are usually heavily limited.
• Archive data – If you need historical state, confirm archive support.
• Failover and redundancy – Does the provider offer multiple regions or automatic failover?
• Support and SLA – For production, a support channel and clear uptime expectations matter.
• Pricing model – Pay-per-request, subscription, or dedicated node pricing. Match to your usage pattern.

OnFinality provides Gnosis RPC as part of its API service. You can compare plans on the pricing page and see all supported networks.

Key Takeaways

• Gnosis Chain uses chain ID 100 and xDAI as its native gas token.
• Public RPC endpoints are fine for development but may be rate-limited for production.
• Use the provided curl, ethers.js, and wallet config examples to connect quickly.
• For production, consider a managed or dedicated Gnosis RPC endpoint to avoid noisy-neighbor issues.
• Always implement failover and monitor your RPC usage.
• OnFinality offers Gnosis RPC with options for shared and dedicated infrastructure.

Frequently Asked Questions

What is the Gnosis RPC endpoint? A Gnosis RPC endpoint is a URL that accepts JSON-RPC requests for the Gnosis Chain network (chain ID 100). OnFinality provides a public endpoint at https://gnosis.api.onfinality.io/public and dedicated options.

What is the chain ID for Gnosis? Gnosis Chain uses chain ID 100 (hex: 0x64).

What is the native token of Gnosis? The native gas token is xDAI (XDAI), with 18 decimals.

Can I use MetaMask with Gnosis? Yes. Add a custom network with the settings provided in this article.

Does Gnosis support WebSocket RPC? WebSocket support depends on the provider. Check with your RPC provider for availability.

How do I get xDAI for testing? You can bridge assets to Gnosis or use a faucet if available. For testnet xDAI, look for a Gnosis testnet faucet.

What are common Gnosis RPC errors? Common issues include rate limiting, block range errors for eth_getLogs, and nonce problems. See the debugging section above.

Is Gnosis RPC free? Public endpoints are typically free but limited. Managed and dedicated services have associated costs. See RPC pricing for details.