Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Plugin RPC As A Service -Full Node Operator Guide

Overview — Node Operator Program

Power the Plugin RPC Network

Run a full XDC node, submit it to Plugin RPCaaS, and earn PLI for every compute unit your node serves. Your node handles standard JSON-RPC requests from the XDC network — all routing, authentication, quota enforcement, and restricted RPC methods are automatically blocked by the Plugin Gateway, preventing unauthorized or potentially sensitive requests from reaching your node.

Key highlights

  • Gateway-enforced security — Restricted methods (admin_, personal_, miner_*) are blocked at the gateway before reaching your node.

  • Earn per compute unit — Every RPC request served earns you CU credits — tracked in real time on your operator dashboard.

  • No public exposure needed — Your node only accepts connections from RPCaaS IPs — it's never directly exposed to the public internet.

How It Works

The flow from user request to your node and back

When a developer calls the Plugin RPCaaS endpoint, the request flows through our gateway before it ever reaches your node. Your node is never exposed to raw user traffic — the gateway handles auth, quota, method filtering, and load balancing.

1

User sends RPC request

Developer calls https://rpc.plugin.global/xdc_mainnet/<api-key> with a standard JSON-RPC method.

2

Gateway authenticates & checks quota

OpenResty validates the API key, checks the CU balance, enforces rate limits, and blocks any forbidden methods (admin_, personal_, etc.).

3

Request forwarded to your node

A healthy node from the operator pool is selected. Only safe read methods reach your node — it never sees blocked calls.

4

Your node responds

Your node processes the standard eth_, net_, web3_* call and returns the result.

5

CU credited to your account

The gateway logs the hit, charges the user's quota, and credits CU to your operator account for payout.

Requirements

What you need before submitting a node

Node requirements

Field
Requirement

Network

XDC Mainnet (or Apothem for testnet)

Node type

Full node

Software

XDC go-client (latest stable recommended)

Sync

Fully synced before submission

HTTP RPC

Enabled and reachable

WSS

Enabled and reachable (for WebSocket plan support)

Operator account

  • An XDC wallet address to register as operator

  • Access to the Operator Portal (request access via Discord)

  • Your node's public HTTP RPC URL (e.g. https://yournode.example.com)

  • Your node's public WSS URL (e.g. wss://yournode.example.com/websocket)

Masternode operators welcome. If you run an XDC masternode, you can participate by running a separate full node alongside it — the masternode keeps validating, the full node handles RPCaaS traffic.

Submitting Your Node

Step-by-step setup guide

1

Start your XDC node with RPC enabled

Make sure HTTP RPC and WebSocket are enabled and listening. Example flags:

Do not include admin, personal, miner, engine, clique, or txpool in the API list.

2

Firewall your node

Step 2 — Firewall your node

Allow RPC port access only from the RPCaaS gateway IP. Block all other public access to your RPC/WSS ports.

Running your XDC node inside Docker? Standard iptables INPUT rules and UFW do not block Docker-exposed ports — Docker inserts its own rules at a lower level that bypass them. Skip to the Docker section below.

Running directly on the host (no Docker)

Running inside Docker

UFW and iptables -A INPUT rules are bypassed by Docker's own iptables rules. Use the DOCKER-USER chain instead — Docker processes this chain first and honours rules placed here:

To verify the rules are in place:

To make these rules persistent across reboots, save them with iptables-save or use a package like iptables-persistent:

How to check if your ports are still exposed: From an external machine, run nmap -Pn -p 8545 YOUR.VPS.IP — if it shows open from a non-gateway IP, your firewall rules are not working and your node RPC is publicly accessible.

3

Register in the Operator Portal

Log in at the Operator Portal with your wallet. Go to Account, verify your email and connect Discord first, then click Submit Full Node Request, enter your HTTP RPC URL and WSS URL. The system will auto-detect your chain ID.

4

Wait for activation

The gateway runs an availability check on your node HTTP & WSS. Once both pass, your node status changes to Active and starts receiving traffic.

5

Monitor your earnings

Track daily hits and CU earned from your Operator Portal dashboard. Payouts are processed manually by the admin team on a rolling basis.

Firewall & Security

How to keep your node safe

Important: Never expose your node's RPC port publicly. Always restrict access to only the RPCaaS gateway IP: 3.134.33.101

Two layers of protection

Layer 1 — RPCaaS gateway (automatic): Our gateway blocks restricted methods before they reach your node. Users calling admin_*, personal_*, miner_*, engine_*, clique_*, or txpool_* get a -32601 error immediately — your node never sees these requests.

Layer 2 — your node config (recommended): As a second layer, disable those APIs at the node level too. If the gateway ever has a bug, your node is still protected.

RPCaaS gateway IP

Only allow this IP to connect to your RPC and WSS ports:

This IP may expand to multiple IPs if we add more gateway nodes. We will announce any changes in Discord with at least 48 hours notice.

Supported Methods

Which JSON-RPC methods your node needs to handle

Forwarded — Methods your node receives

Namespace
Examples

eth_*

eth_blockNumber, eth_getBalance, eth_call, eth_getLogs…

net_*

net_version, net_peerCount, net_listening

web3_*

web3_clientVersion, web3_sha3

debug_* (paid)

debug_traceTransaction, debug_traceBlockByNumber, debug_traceCall, debug_traceBlockByHash

trace_* (paid)

trace_block, trace_transaction, trace_filter

Blocked — Methods your node never receives

Namespace
Why blocked

admin_*

Node administration — dangerous to expose publicly

personal_*

Wallet/key management — never appropriate in a proxy

miner_*

Mining control — not relevant for RPC service

engine_*

Consensus engine — CL/EL communication only

clique_*

PoA admin — internal consensus use only

txpool_*

Raw mempool access — blocked at gateway

These are rejected by the gateway with -32601 method not supported before ever reaching your node.

CU Weights Explained

How compute units are calculated per request

Every RPC method has a Compute Unit (CU) cost. Heavier methods — ones that scan more data, require more processing, or put more load on the node — cost more CU. This keeps the pricing fair for users and means operators are compensated proportionally for the real work their node does.

How CU is calculated

  • Simple reads (eth_blockNumber, eth_getBalance) — 1–2 CU. Minimal node load.

  • Call / estimate (eth_call, eth_estimateGas) — 10–30 CU. Requires EVM execution.

  • Log scans (eth_getLogs) — variable CU based on block range. Wider range = more CU.

  • Trace/debug (debug_traceTransaction, trace_block) — 50 CU. Archive node operations, very expensive.

  • Batch requests — sum of each method's individual CU.

Block range pricing (eth_getLogs etc.)

Scan methods like eth_getLogs have tiered pricing based on how many blocks are requested. A narrow range (e.g. 1–100 blocks) costs a flat low rate. Wider ranges cost progressively more CU. Requests spanning from genesis (earliest) with no upper bound are rejected outright.

The full live method cost table is available in the User Docs → Method Costs section.

For node operators: CU weights reflect the real cost to your node. A debug_traceTransaction at 50 CU earns you 50× what a simple eth_blockNumber earns. Archive nodes that support trace/debug methods earn significantly more per request.

Earnings & Payouts

How you get paid for serving traffic

How earnings work

  • Every request your node successfully handles earns CU credits to your operator account.

  • CU earnings are tracked in real time on your Operator Portal dashboard under Daily Hits.

  • Earnings accumulate daily and are visible per-day in the dashboard.

  • Only requests that complete successfully count — errors or timeouts do not earn CU.

Payout process

  • Payouts are settled on-chain in PLI to your registered operator wallet.

  • Settlement is processed manually by the Plugin admin team on a rolling basis.

  • You do not need to do anything — the admin initiates the on-chain transfer.

  • Payout frequency and minimum thresholds will be communicated via Discord.

Make sure your operator wallet address is correct in the portal — on-chain payouts cannot be reversed.

Monitoring

Keeping your node healthy

Availability checks

The gateway runs periodic availability checks against your node's HTTP RPC and WSS endpoints. If a check fails:

  • Your node's fail counter increments.

  • After consecutive failures it is marked Offline and removed from the routing pool.

  • Once it recovers and passes checks it is automatically marked Online and re-added.

Operator dashboard

Your Operator Portal shows:

  • Node status — Online / Offline / Pending

  • Daily hits — request count and CU earned per day

  • Response time — last recorded latency for RPC and WSS

  • Fail count — consecutive availability check failures

If your node goes offline unexpectedly, check your firewall rules first — make sure 3.134.33.101 is still whitelisted.

FAQ

Can a masternode participate as an operator?

Yes, masternode operators can participate — but you need to run a separate full node, not the masternode itself. Masternodes are lightweight validator nodes and don't store full chain data, so they can't answer RPC queries. Run a full node alongside your masternode, submit that to RPCaaS, and your masternode keeps validating as normal.

Do I need to expose my node publicly to the internet?

No. You should do the opposite — restrict your RPC port to accept traffic only from 3.134.33.101. Your node never talks directly to end users. All traffic comes through RPCaaS's internal gateway, so you can keep it fully firewalled from the public internet.

Which RPC methods does my node actually need to support?

eth_*, net_*, web3_* for standard requests. Optionally debug_traceTransaction, debug_traceBlockByNumber, debug_traceBlockByHash, debug_traceCall, trace_block, trace_transaction, trace_filter for paid advanced plans (requires archive node). You do NOT need admin_*, personal_*, miner_*, engine_*, clique_*, or txpool_* — those are blocked at the gateway and never forwarded.

What happens if my node goes offline?

The gateway detects the failure within minutes via its availability check. Your node is marked Offline and removed from the routing pool — traffic automatically goes to other healthy nodes. Once your node recovers and passes availability checks, it's automatically added back and resumes receiving traffic. You won't earn CU while offline.

Does my node need to be an archive node?

A full node works for standard eth_*, net_*, web3_* requests. An archive node is required if you want your node to serve debug_* and trace_* methods, which earn significantly more CU. If you submit a full node and a user requests a trace method, the request may be routed to an archive node in the pool instead of yours.

What are CU weights and why do some methods cost more?

Compute Units (CU) reflect the real cost of each method to the node. Simple reads like eth_blockNumber cost 1 CU. Heavy operations like eth_getLogs over a wide block range or debug_traceTransaction (50 CU) cost more because they put much more load on the node. As an operator, you earn CU proportional to what you serve — so expensive calls earn you more.

When and how will I get paid?

Payouts are settled on-chain in PLI to your registered operator wallet. The Plugin admin team processes payouts manually on a rolling basis. You don't need to do anything — just make sure your operator wallet address in the portal is correct since on-chain payments can't be reversed.

Can I submit multiple nodes?

Yes. You can register multiple nodes under the same operator account. Each node is tracked independently for availability, hits, and earnings. More healthy nodes in the pool means more traffic capacity for the network.

PreviousXDCPay - Mainnet
NextPlugin Validators

Last updated