> For the complete documentation index, see [llms.txt](https://docs.plugin.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plugin.global/plugin-rpcaas/plugin-rpc-as-a-service-full-node-operator-guide.md). # 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. {% stepper %} {% step %} ## User sends RPC request Developer calls `https://rpc.plugin.global/xdc_mainnet/` with a standard JSON-RPC method. {% endstep %} {% step %} ## Gateway authenticates & checks quota OpenResty validates the API key, checks the CU balance, enforces rate limits, and blocks any forbidden methods (admin\_*, personal\_*, etc.). {% endstep %} {% step %} ## 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. {% endstep %} {% step %} ## Your node responds Your node processes the standard eth\_*, net\_*, web3\_\* call and returns the result. {% endstep %} {% step %} ## CU credited to your account The gateway logs the hit, charges the user's quota, and credits CU to your operator account for payout. {% endstep %} {% endstepper %} ## 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`) {% hint style="info" %} **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. {% endhint %} ## Submitting Your Node *Step-by-step setup guide* {% stepper %} {% step %} ## Start your XDC node with RPC enabled Make sure HTTP RPC and WebSocket are enabled and listening. Example flags: ```bash --http --http.addr 0.0.0.0 --http.port 8545 \ --http.api eth,net,web3,debug,trace \ --ws --ws.addr 0.0.0.0 --ws.port 8546 \ --ws.api eth,net,web3,debug,trace ``` Do **not** include `admin`, `personal`, `miner`, `engine`, `clique`, or `txpool` in the API list. {% endstep %} {% step %} ## 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)** ```bash # Allow RPCaaS gateway to reach your RPC port iptables -A INPUT -p tcp --dport 8545 -s 194.163.189.137 -j ACCEPT iptables -A INPUT -p tcp --dport 8545 -j DROP # Same for WebSocket port iptables -A INPUT -p tcp --dport 8546 -s 194.163.189.137 -j ACCEPT iptables -A INPUT -p tcp --dport 8546 -j DROP ``` **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: ```bash # Block all external access to RPC port except from RPCaaS gateway iptables -I DOCKER-USER -p tcp --dport 8545 ! -s 194.163.189.137 -j DROP # Block all external access to WebSocket port except from RPCaaS gateway iptables -I DOCKER-USER -p tcp --dport 8546 ! -s 194.163.189.137 -j DROP ``` To verify the rules are in place: ```bash iptables -L DOCKER-USER -n -v ``` To make these rules persistent across reboots, save them with `iptables-save` or use a package like `iptables-persistent`: ```bash apt install iptables-persistent netfilter-persistent save ``` > **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. > {% endstep %} {% step %} ## 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. {% endstep %} {% step %} ## 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. {% endstep %} {% step %} ## 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. {% endstep %} {% endstepper %} ## Firewall & Security *How to keep your node safe* {% hint style="warning" %} **Important:** Never expose your node's RPC port publicly. Always restrict access to only the RPCaaS gateway IP: 194.163.189.137 {% endhint %} ### 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: ``` 194.163.189.137 ``` {% hint style="info" %} 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. {% endhint %} ## 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. {% hint style="info" %} **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. {% endhint %} ## 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. {% hint style="warning" %} Make sure your operator wallet address is correct in the portal — on-chain payouts cannot be reversed. {% endhint %} ## 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 194.163.189.137 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.