JSON RPC API
Xone Chain’s public RPC endpoints are your gateway to the network. Every on‑chain action—querying balances, sending transactions, or deploying smart contracts—starts with a JSON‑RPC call.
Xone Chain is an L1 public chain based on Ethereum, fully compatible with Ethereum JSON-RPC API, and supports interaction with mainstream libraries such as Web3.js and Ethers.js. Developers can use JSON-RPC to access Xone Chain for account management, transaction sending, smart contract calling, and other operations.
Endpoint
Xone Chain provides multiple RPC endpoints for developers to connect to the main network or test network. All requests use the POST method.
Network | RPC Endpoint | Chain ID |
---|---|---|
Xone Mainnet |
| 0xe89 (3721) |
Xone Testnet |
| 0x20352b3 (33772211) |
Quick start
Query the latest block (cURL)
curl -X POST https://rpc.xone.org \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
Connect with Ethers v6
import { JsonRpcProvider } from "ethers";
const provider = new JsonRpcProvider("https://rpc.xone.org");
const block = await provider.getBlockNumber();
console.log(`Current block: ${block}`);
Connect with Web3.js v1
import Web3 from "web3";
const web3 = new Web3("wss://rpc-wss.xone.org");
const accounts = await web3.eth.getAccounts();
Tip: For production applications we recommend using a WebSocket endpoint for real‑time subscriptions (
eth_subscribe
).
Rate limits & best practices
- Public quota: 10 000 requests per IP per day (soft limit). If you need more throughput, consider hosting your own node or applying for an increased quota.
- Use batching: Group multiple calls in a single request to reduce latency (
eth_call
ð_estimateGas
are good candidates). - Prefer WebSocket for subscriptions: Event‑driven apps (price feeds, dashboards) should use
eth_subscribe
over a WebSocket endpoint instead of long‑pollingeth_getLogs
. - Handle retries & back‑off: Transient network errors can occur; implement exponential back‑off and idempotent logic on retries.
Common error codes
Code | Meaning | Typical Fix / Description |
---|---|---|
-32700 | Parse error | Invalid JSON |
-32600 | Invalid request | Request is malformed. Some providers also use this to signal that a method is unavailable or needs a paid tier. |
-32601 | Method not found | The method is not supported by this provider. Try another provider or a higher tier. |
-32602 | Invalid params | Check the parameters; they do not match the spec. |
-32603 | Internal error | Node reverted or request is malformed/invalid. |
-32000 | Invalid input | Missing or invalid parameters. |
-32001 | Resource not found | Method not supported. Switch method or provider. |
-32002 | Resource unavailable | Requested resource not available. |
-32003 | Transaction rejected | Transaction creation failed. |
-32004 | Method not supported | Method is not implemented. |
-32005 | Limit exceeded | Request exceeds defined limit. |
-32006 | JSON‑RPC version not supported | Protocol version not supported. |
Troubleshooting
METHOD_NOT_SUPPORTED
? Make sure you are calling the method on the correct network (mainnet vs testnet) and with the proper HTTP verb (POST
).
We ❤️ Feedback!
If you have any feedback or questions about this documentation, let us know We'd love to hear from you!