Using Relix RPC (HTTP & WebSocket)

Relix exposes a standard Ethereum-style JSON-RPC interface. If your code already talks to other EVM networks, it can usually speak to Relix just by changing the RPC URL and chain ID.

For Relix Testnet, the primary public endpoint is:

• HTTP RPC: https://rpc-testnet.relixchain.com

• Chain ID: 4127

• Native token: RLX

WebSocket support, when enabled, follows the same JSON-RPC semantics and is intended for real-time subscriptions (new blocks, pending transactions, logs, and so on).

---

1. JSON-RPC basics

The Relix RPC implements the usual EVM methods, such as:

• eth_blockNumber – latest block height

• eth_getBalance – account balance in RLX

• eth_call – read-only contract calls

• eth_sendRawTransaction – submitting signed transactions

• eth_getLogs – reading on-chain events

Each request is a JSON object with:

• jsonrpc: protocol version (always "2.0")

• method: the RPC method name

• params: method-specific parameters

• id: a client-chosen identifier to match responses

---

2. Simple HTTP call with curl

A quick way to verify that your environment can reach Relix is to query the latest block number:

curl -X POST https://rpc-testnet.relixchain.com \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": 1
  }'

A successful response looks like:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x123456"
}

The result is a hex-encoded block number. You can convert it to decimal in your application if needed.

---

3. Using HTTP RPC from a Node.js client

Most applications will not use raw curl, but instead rely on a client library. The example below uses ethers.js v6:

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://rpc-testnet.relixchain.com", {
  name: "relix-testnet",
  chainId: 4127,
});

async function main() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Relix Testnet block number:", blockNumber);

  const address = "0xYourAddressHere...";
  const balance = await provider.getBalance(address);
  console.log("Balance (RLX):", balance.toString());
}

main().catch(console.error);

Key points:

• The provider points directly to the Relix HTTP endpoint.

• The chainId is explicitly set to 4127 to avoid confusion with other networks.

You can use the same pattern for other libraries such as viem, web3.js, or your own lightweight client.

---

4. WebSocket RPC for real-time usage

WebSocket endpoints are designed for streaming-style workloads:

• Watching new blocks as they are produced

• Tracking logs that match specific filters

• Reacting to events without polling every few seconds

When a WebSocket endpoint for Relix is available (for example, wss://...), the JSON-RPC layer remains the same; only the transport changes from HTTP to WebSocket.

A typical ethers.js setup might look like this:

import { WebSocketProvider } from "ethers";

const wsProvider = new WebSocketProvider("wss://your-relix-websocket-endpoint", {
  name: "relix-testnet",
  chainId: 4127,
});

wsProvider.on("block", (blockNumber) => {
  console.log("New block on Relix:", blockNumber);
});

For log subscriptions, many clients expose helpers (such as provider.on(filter, callback)), which internally use the JSON-RPC eth_subscribe / eth_unsubscribe methods over WebSocket.

If you plan to rely heavily on subscriptions (for example, indexing or real-time dashboards), it is recommended to:

• Run your own node or gateway where possible, or

• Coordinate with the infrastructure provider on expected load and subscription patterns.

---

5. Handling errors and rate limits

Any public RPC will enforce some form of protection against abusive or accidental overload. Your code should be ready to:

• Handle JSON-RPC errors — responses with an error field, including a code and message.

• Back off on repeated failures — avoid tight retry loops; include small delays and bounded attempts.

• Limit very heavy calls — for example, large eth_getLogs ranges or extremely frequent polling.

Some practical habits:

• Cache responses that do not change frequently (for example, chain ID, static contract metadata).

• Use pagination or block range windows when scanning logs.

• Monitor how often your services call the RPC and adjust polling intervals where it does not affect user experience.

---

6. Environment configuration

For larger projects, it helps to centralize your Relix RPC configuration:

export const RELIX_RPC_HTTP = "https://rpc-testnet.relixchain.com";
export const RELIX_CHAIN_ID = 4127;

Then, in your services:

• Use RELIX_RPC_HTTP everywhere you create providers or low-level RPC clients.

• Store keys and secrets (if any) separate from the RPC URL, typically in environment variables or a secrets manager.

This approach makes it easy to:

• Swap endpoints if you later run your own node or gateway.

• Add additional networks (e.g. a future Relix mainnet) without touching core logic.

---

7. Verifying connectivity

After wiring your client to Relix RPC, a simple checklist helps confirm everything is correct:

1. eth_chainId returns 0x102F (hex for 4127).

2. eth_blockNumber increases over time when you query it repeatedly.

3. eth_getBalance returns a sensible value for a known funded address.

4. Transactions sent through eth_sendRawTransaction appear on the explorer at https://testnet.relixchain.com.

Once these checks pass, your application is effectively connected to Relix and ready to use the network as a standard EVM chain, both over HTTP and, where available, WebSocket transports.