Developers Forum for XinFin XDC Network: s4njk4n

FuelSharp NSW — A Practical Tool for Finding Cheaper Fuel

s4njk4n — Wed, 17 Jun 2026 01:56:33 +0000

FuelSharp NSW is a free web application that helps drivers in New South Wales find the cheapest petrol stations based on official government pricing data, while also taking personal discounts into account.

What it does

The app pulls live retail fuel prices directly from the NSW Government’s public Fuel API. Key features include:

An interactive map and ranked list of fuel stations
Filtering by fuel type (U91, E10, Diesel, P95, P98)
The ability to add personal discounts (e.g. NRMA, work fuel cards, loyalty programs)
Showing the real cheapest stations after applying your discounts

It also includes an optional feature to additionally display prices in XDC or USDC (on the XDC Network) using live exchange rates. Useful to know if you're paying with XDC/USDC via a payment card.

Who it’s for

FuelSharp NSW is designed for everyday drivers in New South Wales who want to save money on fuel. It is especially useful for people who:

Regularly fill up and want to make better-informed decisions
Have access to discounts or fuel cards but find it hard to work out which station is actually cheapest after discounts
Prefer a simple, free tool without subscriptions or paywalls

The app is a Progressive Web App (PWA), so it can be saved to your phone’s home screen and used like a native app.

How it works

FuelSharp NSW fetches current pricing data from the official NSW Government Fuel Price API. Users can enter their discount amounts for different fuel station brands. The app then recalculates prices and ranks stations based on your actual cost per litre after discounts.

The XDC and USDC price display is optional and pulls live rates from public APIs. No wallet connection is required.

Data Source

All fuel price data comes from the publicly available NSW Government Fuel Price Check API. There is no commercial partnership with the government or any fuel retailer.

Try it on XDC Outpost: https://xdcoutpost.xyz

[Informative]How to Run an XDC Full Node behind CGNAT - Maintaining Peer Count

s4njk4n — Wed, 27 May 2026 07:59:43 +0000

If you've ever tried to run a full XDC node from home (or on a cheap VPS) and noticed your peer count stuck at 5–10 peers, you're not alone — and it's probably not your fault.

What is CGNAT?

CGNAT (Carrier Grade Network Address Translation) is a technique used by many Internet Service Providers (ISPs) to stretch the limited supply of IPv4 addresses.

Instead of giving every customer their own unique public IP address, the ISP puts hundreds or even thousands of users behind a single public IP. Your home router already does NAT, but CGNAT adds a second layer of translation at the ISP level (often called “double NAT”).

The result?

Your node can reach out to the internet, but the outside world cannot reliably reach back in to your node.

Why This Kills XDC Node Performance

XDC (like most blockchain networks) relies on a healthy peer-to-peer mesh. Your node needs to accept incoming connections from other nodes to:

Maintain a solid peer count (ideally 20+)
Stay fully synced
Contribute meaningfully to the network

Behind CGNAT, incoming connections are blocked or dropped. The result is chronically low peer counts, slower block propagation, and frustration for home node operators.

Many users on consumer broadband, mobile broadband, or certain VPS providers are silently affected without realizing it.

The Solution: XDC_Node_Behind_CGNAT

We have just released a clean, lightweight, open-source tool that automatically solves this exact problem:

XDC_Node_Behind_CGNAT

How it works:

Runs as a background service on Ubuntu/Lubuntu 26.04 (or any Ubuntu-based system)
Checks your Dockerized XDC node’s peer count every hour directly inside the container (no RPC required)
If peers drop below a configurable threshold (default = 15), it automatically runs your existing peer.sh script to inject more bootnodes
Sends a clean notification to your iOS/Android phone via ntfy.sh so you know when it kicks in
Includes simple pause and restart scripts for manual control
Starts automatically on boot via systemd
Keeps logs in the same folder and auto-trims them to stay under 1 MB

It’s designed specifically for people running the official XDC Docker node.

Perfect for:

Home lab setups
Residential fiber / cable connections
Anyone stuck behind CGNAT or strict firewalls

Get it here:

→ XDC_Node_Behind_CGNAT

The project is MIT licensed, actively maintained, and already helping XDC node operators keep their nodes healthy without needing static IPs or complex port forwarding.

If you’re tired of watching your peer count hover in single digits, give it a try — it might be the simplest quality-of-life upgrade you can make to your XDC node today.

Enjoy!

[Informative]Hardened XDC Full Node 2026

s4njk4n — Sat, 28 Feb 2026 07:22:51 +0000

I removed the article about the unofficial bootstrap installation script. If anyone really wants it, its still available archived in the XDC Library on https://xdcoutpost.xyz/.

Lay and Secure the Server Foundations

Update the OS

To Install a New Node we first update and secure the OS:

sudo apt update -y && sudo apt upgrade -y && sudo apt autoremove -y && sudo apt clean -y

Prerequisites

Installing the XDC client on machines that have Intel CPUs, there are some considerations with one of the new Docker packages (docker-ce-rootless-extras) that must be removed. For simplicity, we've included it as a single set of instructions to use on any machine:

sudo apt-get install apt-transport-https ca-certificates curl git jq software-properties-common -y

# Remove any old Docker installations
sudo apt remove docker docker-engine docker.io containerd runc docker-compose -y
sudo rm -f /usr/local/bin/docker-compose

# Add Docker's official GPG key and repository
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

# Handle Intel compatibility issue by removing and holding the problematic package
sudo apt remove docker-ce-rootless-extras -y
sudo apt-mark hold docker-ce-rootless-extras
sudo systemctl restart docker

Create the Client's User

After updating the OS, we'll add a specific user to install the node under.

For the specific user's username, use up to 32 characters. Mix of numbers and lower case letters. First character must be a lower case letter.

For the specific users password, use up to 40 characters. Mix of numbers, upper and lower case letters, and symbols.

sudo groupadd my_new_user
sudo useradd -p "$(openssl passwd -6 'my_new_password')" my_new_user -m -s /bin/bash -g my_new_user  -G sudo

sudo reboot

SSH-Key Authentication

The benefit of using SSH key authentication as a sole means of access is that the VAST majority of port-scan to brute-force attempts are no longer even possible as the bots just move on if there's not even an ability to enter a password.

If you've not already done so and plan on using SSH key authentication to login to the server, remember to do these from your local terminal you'll be connecting to the VPS from:

ssh-keygen
ssh-copy-id -p<yourcustomSSHport> login@serverip

Lock Down SSH Access

Then secure the ssh access to the server:

sudo nano /etc/ssh/sshd_config

You'll want to uncomment the line "#Port 22", and change the port number to something custom.
Also set:

PermitRootLogin no
PasswordAuthentication yes
PubkeyAuthentication yes

The "root" user is a weakness on the server as it is an easy username for hackers to "guess". If they have the username, they only need to guess the password. However if we take away the easy "root" username as an option, we create another whole level of pain for hackers. That's why the "PermitRootLogin no" is set.

You also need to determine whether password logins are even required for any user (or if you'll just manage with SSH key authentication). If using SSH key authentication only (MUCH MUCH MUCH safer, then set "PasswordAuthentication no" instead and just use the SSH keys to connect. If your local machine is ever damaged or you lose the keys, you can just access your VPS provider's hypervisor console in their dashboard and login to your node via that to either add a new key directly/manually, or temporarily open up SSH to copy a new key in, before locking it down to ssh key authentication only again.

Then restart the SSH service:

sudo service ssh restart

If SSH changes are failing, you can check if your VPS provider has additional override setings and where they are. For example:

sudo grep -rE '^\s*PermitRootLogin' /etc/ssh/

And then modify what you need to.

Firewall

Then we establish the firewall:

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 30303
sudo ufw allow <yourSSHport>
sudo ufw enable
sudo reboot

Make sure you allow your SSH port before you reboot, otherwise you won't be able to connect to your VPS by SSH after rebooting. You may still be able to get in through a virtual terminal in your VPS provider's dashboard in that case and can then hopefully allow the port that way so you can get back in via SSH.

Fail2Ban Intrusion Protection System

Then to protect against repetitive automated brute-force intrusion attempts we set up fail2ban:

sudo apt install fail2ban
sudo cp -p /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Then put these lines in the sshd section:

enabled = true
filter = sshd
port = ssh
banaction = iptables-multiport
findtime = 86400
# 86400 seconds = 1 day
bantime = -1
# -1 = ban forever
maxretry = 3
# 3 attempts in 1 day = ban
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Then complete the fail2ban process:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

To check who is banned:

sudo fail2ban-client status sshd

To unban an IP address:

sudo fail2ban-client set sshd unban <ip address>

Download the Chain Tarball

Now we download the chain tarball to avoid the slow sync from genesis. Make sure you're SSH'd in as the specific user, not root. We'll use a "screen" session to avoid broken pipes and will use "aria2c" to optimise a multiconnection download and ensure we can "resume" the download if it is broken for whatever reason.

sudo apt install screen
sudo apt install aria2

Run a screen session with:

screen

To detach a screen session but keep it running in the background, use:

Ctrl+A
and then press
D

To see a list of available screen sessions:

screen -ls

To reattach a screen session:

screen -r <sessionname>

To permanently close/exit a screen session just use:

exit

So.. Now that we're in our screen session, lets download the XDC chain tarball:

mkdir ~/chaindl
cd ~/chaindl
aria2c -x 8 -s 8 -k 1M https://download.xinfin.network/xdcchain.tar

If for whatever reason it is interrupted and needs to resume, we can add the --continue flag to the aria2c command.

Detach the screen session and come back later. You can peek in on it every now and then with the commands above. When it is finished, we need to decompress it. Once again, we can do this via a screen session and then detach it to protect the whole process from interruption.

To decompress it in the screen session:

sudo tar -xvf xdcchain.tar  # Creates XDC directory

Then clean it up:

cd XDC
sudo rm -rf nodekey  # Remove old node key
sudo rm -rf transactions.rlp  # Clean up pending transactions

Install the XDC Node Client

Now to install the node using method 3 (from here https://github.com/XinFinOrg/XinFin-Node) and customise it:

cd ~
git clone https://github.com/XinFinOrg/XinFin-Node.git
cd XinFin-Node/mainnet
cp env.example .env
sudo nano .env

In the .env file, set your node name, email and set gcmode to "full" instead of "archive".
Then save and exit.
Note: there is also a gcmode setting in start_node.sh but this is a backup/default if the environment variable isn't already set. It defaults to "archive" if not set.

Then start the node briefly for 10 seconds or so and then shut it down again.. This creates some of the directories we need:

sudo bash docker-up.sh
sudo bash docker-down.sh

Now clean up the new directories by removing the chain files we dont need etc:

cd ~/XinFin-Node/mainnet/xdcchain
sudo rm -rf XDC
sudo rm -rf *.log

Now we move the earlier decompressed chain files into the new node:

sudo mv ~/chaindl/XDC .

Now we restart the node:

cd ~/XinFin-Node/mainnet
sudo bash docker-up.sh

Troubleshoot Peer Issues

Let the node sync.
If you're not picking up peers, then you can run the peer.sh script (while the node is running):

cd ~/XinFin-Node/mainnet
sudo bash peer.sh

If you get an error, then check the container name. I have noted that the docker containers have had different names at different stages or perhaps with different methods I'm not sure. To check the container name use:

sudo docker ps

Then edit the peer.sh script and update the hard-coded container name in there:

sudo nano peer.sh

If you had to do the container-name update in the script then run the peer.sh script again:

sudo bash peer.sh

The node should now pick up peers relatively quickly (ie it should be up to perhaps 15-20 peers within 10-15 minutes).

Residual "Open" Ports

The Docker port bindings will not be affected by ufw. This means that you will still see ports 8888 and 8989 showing as open if you scan the VPS ports with nmap from a terminal external to the VPS:

nmap -Pn -p 8888 Your.VPS.IP.ADDRESS
nmap -Pn -p 8989 Your.VPS.IP.ADDRESS

However, by default in the .env file, the environment variable "ENABLE_RPC=false" is set and this makes the start_node.sh script not expose the RPC/WS in the docker container. The ports 8888 and 8989 still show as open however as the docker proxy answers the handshake. So, even if someone tries to access those "open" ports, sorry nobody is home.

To actually decrease the attack surface even further we can simply disable to docker port bindings by editing the docker-compose.yml file:

cd ~/XinFin-Node/mainnet
sudo nano docker-compose.yml

Once you've opened the file, just use # to comment out the 2 port lines that handle the container port bindings for 8888 and 8989 as show here:

    ports:
      - "30303:30303"
      # - "8989:8545"
      # - "8888:8546"

Now just stop and restart the node. Then try the nmap scans again and those ports will now show as closed.

Node Migrations

If this is a node migration, once syncing has completed, remember to docker-down.sh the old and new nodes. Then delete the keystore file on the new node. Then scp the keystore file across from the old node to put it in the keystore directory on the new node.

sudo scp -P <OldNodePortNumber> username@IPaddress:~/XinFin-Node/mainnet/xdcchain/keystore/UTC* xdcchain/keystore/

Then just docker-up.sh the new node.

Voila. New node!

Android/iOs Push Notifications

To receive Android/iOs push-notifications if your client/node goes offline, set up the free open-source XDC Sentinel tool.

To receive Android/iOs push-notifications of changes in Governance status of staked nodes + arrival alerts for Masternode Educational Rewards, set up the free open-source XDC Tycoon tool.

[Informative]XDC Node Peering Guide

s4njk4n — Fri, 02 Jan 2026 12:11:10 +0000

Introduction

Deploying a node on the XDC Network is a straightforward process, but users occasionally encounter challenges where the node fails to connect to peers effectively. This can manifest as the blockchain downloading slowly or halting, with peer counts remaining stuck at 0–1 for extended periods. This issue prevents the node from fully syncing with the network, participating in consensus (and earning rewards).

The first time we encountered this, we tested further by deploying nodes across multiple data centers from a specific VPS provider in different geographic locations, and the problem persisted. Initial checks confirmed that essential configurations were generally ok, such as disabling firewalls (e.g., ufw not enabled on mainnet nodes). The issue for us turned out to be an externally blocked port 30303 but there are several other potential causes that need to be considered whenever this issue arises.

This guide expands on our original troubleshooting steps by incorporating additional diagnostic methods and updated best practices as of 2026. We’ll cover how XDC nodes acquire peers, some common root causes of issues and their detailed solutions as well as some preventive measures you can take. While this focuses on mainnet XDC nodes, similar principles apply to Apothem testnet nodes (which use port 30304 instead of 30303).

How XDC Nodes Acquire Peers

Understanding peer acquisition is key to diagnosing issues. When an XDC node starts:

Initial Bootstrapping: The node connects to a predefined set of “bootnodes” listed in the bootnodes.list file. These are trusted, always-online nodes that serve as entry points to the network.

Peer Discovery and Propagation: Once connected to the bootnodes, the node then queries them for additional peers. Incoming connections are also accepted if the node is discoverable.
Networking Protocols: Peering occurs over TCP/UDP on port 30303 for mainnet (or 30304 for testnet). The node advertises itself via UDP for discovery and uses TCP (RLPx) for data exchange. The default maximum peer count (maxpeers) is set to 25 in XDC configurations, so counts above this are rare unless customized.

Ongoing Maintenance: Peers are dynamically added and dropped based on factors like latency, reliability, and network health. The node also supports UPnP (Universal Plug and Play) for automatic port mapping on compatible routers.

If any step fails due to network blocks, configuration errors or faulty bootnodes, then the peer count remains low, leading to isolation from the network.

Common Causes of Low or Zero Peers

In our experience, the most frequent culprits of low or zero peers are:

Port 30303 Blocked or Not Forwarded: This was the cuplrit for us that we mentioned above. Even if local checks show the port as open, external factors like firewalls, VPS provider restrictions, router NAT settings, or ISP blocks can prevent incoming connections.
Firewall or Security Group Misconfigurations: Tools like ufw, iptables, or cloud provider security groups (e.g., AWS EC2, Google Cloud) can block traffic despite appearing inactive.
Resource Constraints: High memory usage from peering surges can cause nodes to slow or crash, indirectly affecting peer connections. Older hardware or unoptimized setups exacerbate this.
Outdated or Faulty Bootnodes List: The bootnodes.list file may contain inactive, unreachable, or deprecated nodes.
Network or Sync Issues: Slow internet, geographic latency, or incomplete blockchain sync can deter peers. Testnet/mainnet port mismatches can also contribute to this.
Nodekey or Cache Problems: Corrupted nodekey files or stale peer databases can hinder fresh connections.

For completeness, we always recommend ruling out port issues first.

Comprehensive Solutions

Follow these steps in order. We’ll start first with port verification, then address bootnodes, followed by using an official script peer.sh included in the XDC nodes that allows forcing addition of peers. Then we'll finish off with restarts and monitoring.

Step 1: Verify and Open Port 30303

Even if you believe the port is open, double-check externally.

Tools Needed
Install nmap on a separate machine on a network external to the node (not the VPS or server the XDC node is running on):

sudo apt install nmap

Check Port Status
Run nmap from that separate external machine, replacing YOUR.NODE.IP with your XDC node’s public IP:

nmap -p 30303 YOUR.NODE.IP

If STATE shows “closed” or “filtered,” the port is blocked.
Alternative: If your node is running on a LAN that is local to you, for example in your office, you can instead use online tools like https://canyouseeme.org/ (enter port 30303), but prefer external nmap for security.

Address Firewalls (e.g., ufw)
SSH into your node:

ssh -l root -p 22 YOUR.NODE.IP # Adjust username/port/IP

Check firewall:

sudo ufw status verbose

If active and blocking 30303, allow it:

sudo ufw allow 30303/tcp
sudo ufw allow 30303/udp
sudo ufw reload

For iptables or other firewalls, consult your OS docs.

For VPS Providers (e.g., AWS, DigitalOcean)
Log into your provider’s console and check security groups/inbound rules. Add rules for TCP/UDP on 30303 from any IP (0.0.0.0/0).
If blocked at the provider level, submit a support ticket to unblock it.

For Local Servers/Routers
Enable port forwarding on your router: Forward TCP/UDP 30303 to your node’s LAN IP. You can find your node’s LAN IP by running either of the following commands in the terminal of your node:

ifconfig

ip addr

Power cycle the router after changes.
Check with ISP for port blocks; request unblocking if needed.

After changes, retest with nmap as above and then reboot the server:

sudo reboot

Step 2: Update the Bootnodes List

If ports are open but peers remain low, replace bootnodes.list.
SSH into your node:

ssh -l root -p 22 YOUR.NODE.IP

Navigate to the mainnet directory:

cd ~/XinFin-Node/mainnet

Stop the node:

sudo bash ./docker-down.sh

Backup the old file:

sudo mv bootnodes.list bootnodes.list.old

Download the latest official list (as of 2026):

sudo wget -O bootnodes.list https://raw.githubusercontent.com/XinFinOrg/XinFin-Node/master/mainnet/bootnodes.list

Note: This is the official XDC Network GitHub version.

For quicker peer pickup, delete the nodekey (forces fresh identity):

sudo rm -rf ../xdcchain/XDC/nodekey

Restart the node:

sudo bash ./docker-up.sh

Step 3: Force Peer Connections with peer.sh

Before resorting to restarts or resyncs, we can try the peer.sh script. This utility manually adds peers from your bootnodes.list to kickstart connections, often resolving issues without data loss or extended downtime. It’s especially useful for temporary glitches or outdated discovery processes.

Ensure your XDC node is running (start it with sudo bash ./docker-up.sh if necessary).
Navigate to the mainnet directory (or testnet for Apothem nodes):

cd ~/XinFin-Node/mainnet

For best results, always update bootnodes.list before running peer.sh (as outlined in Step 2).
Execute the peer.sh script:

sudo bash ./peer.sh

Monitor the output for confirmation of added peers. You can then check the peer count in the node console by using sudo bash ./xdc-attach.sh and running net.peerCount, or admin.peers, or by viewing the XDC Network Stats page. You can use the exit command to exit the console when needed.

This step can avoid more invasive actions like container restarts or full resyncs. If successful, proceed to verification. For more details on how peer.sh works, see the dedicated Appendix at the end of this article.

Step 4: Handle Resource or Sync Issues

Monitor memory/CPU with htop or top. If high, upgrade hardware or optimize (e.g., limit maxpeers in config).

If your XDC node (mainnet or testnet) is stuck during synchronization, you can either restart the Docker container (a quicker fix that preserves existing data) or resync from scratch (note: a thorough reset can also be done using the latest chain snapshot and this will be much quicker than manually syncing from scratch). Always back up critical data first to avoid losing access to your wallet, staked tokens or node configuration. Step by step instructions are as follows. For testnet issues, repeat steps but use port 30304 and Apothem configs.

Backup Data (Mandatory Before Any Restart or Resync)
Before proceeding, back up your node’s key files and data to prevent irreversible loss. This is crucial because subsequent steps can involve deleting/overwriting directories.

Locate Your Node’s Directory: Navigate to your XinFin-Node installation folder (e.g., ~/XinFin-Node/mainnet for mainnet or ~/XinFin-Node/testnet for testnet).
Backup the Keystore: The keystore contains your private keys. Copy the entire keystore folder (or specific files like UTC — [DateTime] — [Address]) to a backup location and preferably also keep a copy on a secure external device.

mkdir ~/backup_XDCnode
sudo cp -r xdcchain/XDC/keystore ~/backup_XDCnode

Backup your Coinbase address: Stored in coinbase.txt.

sudo cp xdcchain/XDC/coinbase.txt ~/backup_XDCnode

Backup Chain Data (Optional but Recommended for Quick Restoration): If you have enough drive space and want to preserve your current blockchain state (e.g., for debugging later), tar and copy the entire xdcchain/XDC folder.

sudo tar -czvf xdc_chain_backup.tar.gz ~/XinFin-Node/mainnet/xdcchain/XDC
sudo cp xdc_chain_backup.tar.gz ~/backup_XDCnode

Backup Configuration Files: Copy .env (environment variables) and any custom configs.

cp .env ~/backup_XDCnode

For Testnet (Apothem): The process is similar, but files will be in the testnet subfolder instead of mainnet. Use port 30304 and Apothem-specific configs.

Store backups offline and securely. Test restoring them in a safe environment to ensure they’re valid.

Option 1: Restart the Container (Quick Fix for Stuck Sync)
This preserves your existing data and is ideal if the issue is temporary (e.g., high resource usage). It restarts the Docker container without deleting chain data.

Stop the Container: Gracefully stop it to avoid data corruption.

sudo bash ./docker-down.sh

Optionally inspect Logs for Issues:

sudo tail -50 xdcchain/<logfile_name>

Common fixes: Optimize config (e.g., set maxpeers to limit connections) or free up resources (close other processes).
Restart the Container:

sudo bash ./docker-up.sh

Monitor Sync Progress: Attach the node console.

sudo bash ./xdc-attach.sh

In the console, use eth.syncing command to check block height sync status, use admin.peers command to list connected peers, use net.peerCount to see how many peers are connected, and use exit command to exit the console. You can also view overall network stats at https://xinfin.network/ or https://apothem.network/ for testnet.

For Testnet: Repeat using port 30304 and Apothem configs.

This should resolve minor sync hangs without full data loss. If unresolved, proceed to resync.

Option 2: Resync from Scratch (Thorough Reset for Persistent Issues)

If restarting doesn’t help (e.g., corrupted data), resync by wiping the chain data and starting over. Use a snapshot for faster sync (days instead of weeks); otherwise, it syncs from genesis (very slow). Backups as described above are essential here.

Stop the Node/Container: As in Option 1 above.
Delete Existing Chain Data: Remove the corrupted or stuck data (but ensure backups are done first as described above in Option 1!).

sudo rm -rf xdcchain/XDC  # DANGER: MAKE SURE YOU HAVE BACKUPS FIRST

For full resync without snapshot, skip the snapshot step below. This will sync from block 0 (expect 1–2 weeks on decent hardware).

Download a Snapshot (Recommended for Speed):
Snapshots update ~every 20 days.
Mainnet:
Full node: https://download.xinfin.network/xdcchain.tar
Archive node: http://downloads.xinfin.network/xdcchain_archive.tar

Testnet (Apothem):
Snapshots may not always be available; check https://download.xinfin.network/apothem.tar. If not available, check with XinFin or community forums. If unavailable, resync from genesis.

wget https://download.xinfin.network/xdcchain.tar

Extract and Clean Up the Snapshot (and move it into the correct directory):

sudo tar -xvf xdcchain.tar  # Creates XDC directory
cd XDC
sudo rm -rf nodekey  # Remove old node key
sudo rm -rf transactions.rlp  # Clean up pending transactions
cd ..
sudo mv XDC ~/XinFin-Node/mainnet/xdcchain/ # Use testnet/devnet if needed

For archive nodes, edit start-node.sh or .env to add gcmode=archive.

Configure and Start the Node: Edit .env if needed (e.g., ENABLE_RPC=true etc). Copy back keystore and coinbase.txt from backups if wiped. Start:

sudo bash ./docker-up.sh.

Monitor and Verify: As in Option 1 above, the node should now sync from the snapshot’s block height. If peers are low:

sudo bash ./peer.sh

For Testnet: Use Apothem snapshot if available, port 30304, and configs (e.g., NETWORK=apothem in .env). Repeat steps but with testnet folder/scripts.

Additional Tips

Resource Monitoring: As mentioned, use htop or top to watch CPU/memory. If high during resync, limit peers or upgrade the server.
Security: After resync, verify your node on the stats page. Enable firewalls (e.g., open only ports 30303 for mainnet, 30304 for testnet).
If Issues Persist: Check XDC community forums, GitHub repos, or stats page for known network problems.
Time Estimates: Restart: Minutes. Resync with snapshot: Hours to days. From scratch: Weeks.

Verification and Monitoring

Wait 1–2 hours post-restart.
Check peer count on: XDC Network Stats
If peers climb to 10–25, the issue is resolved. Congratulations! If problems continue, check XDC forums for further information/help.

Preventive Measures

Regularly update your node software via official repos.
Monitor XDC announcements for updates (e.g., bootnode changes).
Join community channels: XDC.Dev Forum, GitHub, X.com.
Consider running multiple nodes for redundancy.

Appendix: The peer.sh Script

What it is Used For

The peer.sh script is a helper utility included in the XDC node installation (found in the ~/XinFin-Node/mainnet directory). It is designed to assist in troubleshooting peer connection issues by manually forcing the node to connect to known peers. This is particularly useful when automatic peer discovery fails due to network configuration problems, outdated bootnodes, or temporary network glitches, helping to kickstart the syncing process and increase the peer count.

What it Does

The script automates the process of adding peers to your XDC node. Since the current XDC client is based on Go-Ethereum (geth), it leverages the node’s JavaScript console (via xdc-attach.sh) to execute the admin.addPeer() command for each enode listed in the bootnodes.list file. This manually establishes connections to trusted bootnodes, bypassing potential discovery failures. Once connected, these bootnodes can propagate additional peers, improving overall network participation and sync speed.

How to Use It

Ensure your XDC node is running (start it with sudo bash ./docker-up.sh if necessary).
Navigate to the mainnet directory (or testnet for Apothem nodes)

cd ~/XinFin-Node/mainnet

For best results, always update bootnodes.list before running peer.sh. See above article for instructions on how to do this.
Then execute the peer.sh script:

sudo bash ./peer.sh

Monitor the output for confirmation of added peers. You can then check the peer count in the node console by using sudo bash ./xdc-attach.sh and running net.peerCount, or admin.peers, or by viewing the XDC Network Stats page. You can use the exit command to exit the console when needed.

In case of any technical queries on XDC Network, feel free to drop your queries on XDC.Dev forum.

Quick links

XinFin.org
XDC Chain Network Tools and Documents
XDC Network Explorer
XDC Dev Forum
XDC Testnet/Devnet Faucet — Blocksscan

XDC Social Links

X.com
GitHub
Telegram
Facebook
LinkedIn
YouTube

[Informative]How to run a 2nd XDC Network node on a LAN that has only a single existing public IP address

s4njk4n — Sat, 12 Apr 2025 23:28:41 +0000

2025-12-29 Update: This article is no longer current. To run a second xdc node on a single IP at present, all that is required is:

Set start-node.sh --port setting to whatever P2P port you want to use (other than 30303 which is presumably already taken on your LAN's NAT)
Set P2P port mappings in the docker-compose.yml for whatever P2P port you want to use
Firewall/UFW port opening for the P2P port may not be required as Docker port bindings in the docker-compose.yml I think supercede firewall settings. If unsure and the node isnt picking up peers, open the port in the firewall.
Internet facing router NAT settings should be set to forward the P2P port you have chosen to the LAN IP address of the machine that is operating the second node

That's about it! Good luck!

You can safely ignore the article below.

Just a quick note for the XDC Knowledge Base.

Perhaps as a developer you want multiple RPCs so you want to run multiple nodes on a LAN. Running multiple nodes on an existing LAN with a single public IP had some challenges. A solution is shown below (using remote public IP for P2P, and then public IP of current LAN along with the relevant port to provide RPC access).

Attempt 1 (Unsuccessful)

In start-node.sh, changed "--port 30303" to a different port and set it to forward that port through the LAN router's NAT.
Also changed port bindings in docker-compose.yml to match.
Outcome was only 1 peer at best and that dropped off as well.
Noted the bootnodes.list in the new node was smaller than older ones so tried using the bootnodes.list from the older nodes instead. No improvement. Same issue.

Attempt 2 (Worked!)

Use 2 servers

Continue running the Node on the existing LAN; but
Also get an external VPS with its own public IP
Make sure ssh is installed on both
Set up ssh key on the LAN machine and ssh-copy-id to the VPS

Set up 2 reverse SSH tunnels from the LAN machine to the VPS (one for TCP, and one for UDP).

Ensure to disallow remote command execution on the tunnels.

For TCP

Use port 30303 for the TCP tunnel to keep it simple.

For UDP

SSH tunnels dont allow UDP normally so we manage this by using socat to temporarily convert UDP to TCP for transmission through the 2nd reverse ssh tunnel.
First we install socat on the VPS to convert the incoming UDP on 30303 at the VPS -> to TCP on the VPS end of the second reverse SSH tunnel.
Then we also set up socat on the LAN machine to convert incoming TCP on the 2nd reverse SSH tunnel port -> back to UDP directed at 30303 on the local machine.

Automation for reboot

Set up autossh and also socat as systemd services on the LAN machine.
Set up socat as a systemd service on the VPS.
(And make sure to have the XDC client auto start on reboot via an entry in the root crontab on the LAN machine).

Firewalls

Make sure ufw is set correctly to allow required ports on the VPS and the local LAN machine.
Make sure the router firewall is not interfering.
Make sure the VPS provider isn't blocking outgoing SSH.

Then in the XDC node start-node.sh

Continue to use "--port 30303"
Add "--nat extip:VPS_IP_ADDRESS" so the node will advertise its P2P availability at the VPS public IP address on port 30303
No need to modify the docker-compose.yml from default as all ports on the local machine will remain the same and dont need any modification

In effect with the instructions above, the end result is an XDC node running on the LAN behind a local NAT but for all intents and purposes, the rest of the XDC network sees its public IP as that of the VPS we are tunnelling to. This allows the node's P2P networking component to be done through the VPS IP address.

Notes

To access the RPC, just forward a port via the NAT and then access the RPC using the LAN’s public IP address (along with the port your forwarding via your NAT).
Oracle Cloud free-tier has free VPSs with public IP addresses.
Hands are a bit full at present so I'll only look at publishing the further details for the system services setup later if there's demand.

[Informative] New Send-Offline Helper for XDC Network Deployed

s4njk4n — Wed, 05 Mar 2025 23:24:30 +0000

Can be accessed for live usage here: https://s4njk4n.github.io/XDC_Send_Offline_Helper/

General information on XDC Network Send-Offline-Functionality can be found here: https://medium.com/xinfin/send-offline-functionality-sof-a-secure-way-to-transact-xdc-coins-3734eaa81365

Designed to work as the ONLINE half of the system for offline transactions (but with the additional flexibility of being able to choose a specific RPC if you want). Simple to use via a mobile phone browser. You can save the bookmark on your mobile web browser or even "Save to Homescreen" on iPhones to save it as a webapp with its own desktop icon on your phone. It is set to use the XDC logo for the icon on your phone in this case.

To use this send offline helper:

Specify an RPC (if you want to use a different one to the default Ankr one specified). You can find a list of current public XDC RPCs at https://chainlist.org/chain/50
Enter the XDC address you are sending from. Page accepts both 0x and xdc prefix formats. Then press "Get Transaction Parameters".
You will then be presented with the "Gas Limit Suggestion", "Nonce", and "Suggested Gas Price". These are the numbers to use in your offline transaction builder (the OFFLINE half of the Send Offline Functionality).
Build the transaction with your offline transaction builder.
Once completed/signed on the OFFLINE device, you just need to get the signed transaction data into the "Broadcast Signed Transaction" box at the bottom of the Send Offline Helper page we created.
One way to do this is to manually enter it.
A simpler way, if your offline transaction builder presents a QR code, is to just point your camera at the QR code, THEN press the "Scan QR Code" button. If it has been scanned, you will see your same transaction populate the box in the Send Offline Helper.
Then you just press the "Broadcast Transaction" button and you're done.

Notes:

If your QR scan did not work, you can manually turn off the scanner by pressing the red "Stop Scanner" button that has appeared at the bottom of the page.
GitHub Repo is at https://github.com/s4njk4n/XDC_Send_Offline_Helper
As always, please make sure to read and fully understand what this does and how it works before deploying your own for your usage

[Informative] Backing up XDC Geth Client Chain Database (Chain Snapshot)

s4njk4n — Sat, 29 Jun 2024 06:07:29 +0000

Our GitHub repo here shows how to regularly take an automated snapshot of the chain database from the XDC Geth Client and move it to a webserver with (semi)-dynamic access gating.

We had this running as a Rapid-Snapshot-as-a-Service but will shortly decommission the server and are releasing this information into the wild :) We've already done the legwork so if you want to learn how to backup your own node's chain database or learn how to create a semi-dynamic access gated webserver please read on!

General Points:

It is based on there being 2 servers
We assume you have set up ssh-key authentication for Server 1 to be able to access Server 2
For access-gating in this instance there are NO personal or private details on the webserver at all so we don't care too much about storing the user_credentials.csv file in plain text. Each username/password combination can almost be considered as a unique access token that has just been split into 2 pieces

Server 1 - XDC_Client_Server

Server 1 is running the XDC Client (Contents are in the XDC_Client_Server folder in this repo.
On Server 1, the XDC Client is located as normal at /root/XinFin-Node/ (We had this one installed as root)
On Server 1, the Chain_Backup directory is located at /root/Chain_Backup

In the Chain_Backup directory:

chain_backup_bot.sh is the script that performs all the steps of shutting down the XDC node, creating a timestamp, creating a tarball containing the current chain database from the client, cleaning up, securely copying the snapshot to the Download server (Server 2)
events.log is the log file that the bash scripts log events to. Useful to know where it was up to in case it fails for some reason. Also useful for determining how long it takes your server to perform certain tasks. How long does it take to create the tarball? How long does it take the copy the tarball to Server 2 given your available bandwidth?
generate_credentials.sh is used to generate new sets of download credentials along with an expiry date and how many IP addresses they will each be valid for. Each time it runs it copies the current version of user_credentials.csv from the download server to use as its base. (So the version on Server 2 is your source of truth). After generating credentials, it copies it back to Server 2.
user_credentials.csv is the generated file containing user credentials
"snapshot" subdirectory - this is where your snapshot tar files are created
the chain_backup_bot.sh execution is controlled by a root crontab entry of:

0 23 * * * /root/Chain_Backup/chain_backup_bot.sh

Server 2 - Snapshot_Download_Server

Server 2 has Nginx installed to gate access to our snapshot files
LetsEncrypt has been used to provide SSL/TLS encryption. Some information on SSL/TLS for Nginx (but using OpenSSL) can be found in this article and still shows where the relevant SSL certificate and private key information is within Nginx: https://www.xdc.dev/s4njk4n/ssltls-encryption-for-xdc-node-rpcs-k15
Htpasswd has been used to provide basic authentication credentials to Nginx. Some information on using htpasswd with Nginx can be found here: https://www.xdc.dev/s4njk4n/controlling-access-to-xdc-node-rpc-endpoints-3en3
Nginx IP ACL's have also been used. Further information about Nginx IP ACLs can be found via a link in this article: https://www.xdc.dev/s4njk4n/controlling-access-to-xdc-node-rpc-endpoints-3en3
/var/log/nginx/ contains access.log , error.log , custom.log . These log files are defined in /etc/nginx.nginx.conf
/etc/nginx/nginx.conf contains nginx configuration including the log files mentioned above
/etc/nginx/sites-available/default contains Nginx server blocks for default server, SSL server, and http redirect to https server
SSL server block just mentioned contains SSL information and location blocks. The location block for the webserver’s /snapshot location is restricted by Nginx IP address ACL & also gated by basic authentication. The "#Add-new-IPs-here" line is used by our scripts to locate whereabouts in the file to insert new IP addresses that should be authorised to access the /snapshot location.

In the Chain_Backup_DL_Server_Control directory:

The "users" directory contains a plain text file for each username. The filename is the username. Within the file, the first line is the username, the second line shows how many IP addresses that username is authorised to access the snapshot from, and the lines below that show any IP addresses that have been used and authorised so far by that user.
The "users/expired" directory is where expired user files are move to once the associated username's credentials have expired.
access_manager_bot-pause.sh sets a flag that pauses the actions of access_manager_bot.sh
access_manager_bot-restart.sh deletes the pause flag created by the script above. This effectively restarts the looping an actions of the access_manger_bot.sh
access_manager_bot-start_looping.sh starts a loop that keeps running the access_manager_bot.sh script every few seconds
access_manager_bot.sh is where some of the magic happens. It is our user access management script that controls user management/expiry and dynamic access gating to the snapshot
events.log is the log file our scripts log events to. Useful for troubleshooting if any issues occur you can figure out where things were up to
last_expiry_check is a script-generated plain text file containing the date that the last expiry check was run on users
snapshot_rotation_bot.sh is the script that switches out the old snapshot for the new one (if one exists) when it is run
user_credentials.csv is our source of truth for user credentials. Even the script on our other server that generates user credentials uses this file as its base to work from when adding more user credentials
working_custom.log is one of our script’s working files when processing access logs and implementing dynamic user access gating
the looping execution of our access-management script and timing of snapshot-switching are both initiated by the following entries in the root crontab:

@reboot /bin/bash /root/Chain_Backup_DL_Server_Control/access_manager_bot-start_looping.sh
0 23 * * * /bin/bash /root/Chain_Backup_DL_Server_Control/snapshot_rotation_bot.sh

Access our GitHub repo here for the scripts etc

Good luck and I hope this server scripting comes in useful for somebody in the ecosystem whether it be how to identify and manage the steps to backup an XDC Geth Node's chain database, or alternately how to use log-based (semi)-dynamic access gating to webserver resources.

@s4njk4n

[Informative] PublicNexus: Service Update

s4njk4n — Sat, 29 Jun 2024 00:18:07 +0000

This information is being posted for historical record information sake only in case it comes in handy for a future developer who needs something similar for a project. It only relates to our initial Alpha/Proof-Of-Concept. Enterprise development work that was done isn’t solely ours and will remain private.

Updated Github content here.

We had actually already onboarded a new team member to manage enterprise RPC deployments (currently employed as a senior solutions architect by a large US multinational tech provider and who's day-to-day job at present involves enterprise deployments with Cloudflare, Kubernetes, load balancers, redundant ingress etc and who's clients include the largest bank in our country, several government departments and multi-billion dollar corporates in Asia Pacific. Even better is that he's already familiar with the XDC ecosystem :) As of yesterday, our expected delivery date for a fully-redundant native-XDC Enterprise-grade service WAS 3 weeks.

We will have further discussions with other developers in the ecosystem before making a final decision on what to do with our actively running servers, however it is looking very much like we will discontinue the service and pause further development as it isn't really required to add ourselves as another service provider in the space (and resources may deliver more ecosystem benefit if allocated elsewhere).

Progress Update

The initial intent of PublicNexus was to fill a perceived need by the general community and basic developers however on further discussions and examining the publicly available RPCs on the XDC Network, it has become apparent that this need has already been filled by Ankr (and so PublicNexus isn't really required).

This is based on the following as of today (29/06/2024):

The Ankr site offers public RPC access allowing up to 20requests/sec. This is more than the average community member and basic developer would need for general transactions via their Web3 wallet.
If actually signing up for their "Freemium" service then this rate limit is increased to 30requests/sec. This is also more than the average community member and basic developer would need for general transactions via their Web3 wallet.
Their Premium service offers a rate limit of 1500requests/sec at a cost (at present for Node API) of USD$0.02/1000requests.

Let's assume that an XDC node providing an RPC is running on a VPS costing $100/month (arbitrary figure plucked out of the air; there are better more expensive VPSs available and similarly the XDC client can also run on cheaper VPSs if expecting less load).

$100/month = 5M requests/month via Ankr.

The generous limit shown above means that developers working with an active commercial product may be better off using the Ankr paid service.

A load balancer covering all public RPC's doesn't seem to be required.

As one developer from a prominent project on the XDC network indicated in a public forum regarding how they operate:

Their project runs its own Archive node (as others don't need it)
For all Full node RPC requests they send them to Ankr

For general community and basic developers, it seems that the best option is Ankr as a first point of contact.

As mentioned above, the content in this repo is provided more as a record in case of future need and only consists of early Alpha content.

Things to remember if deploying

WSS support will require use of

a2enmod mod_proxy_wstunnel

The "Origin_Check" directory we used was located at /root/Origin_Check.
The "tmp" directory is literally the /tmp location to hold the temp file for calculations and the file lock to prevent concurrency of instances.

Updated Github content here.

Wishing everyone well in the ecosystem!

@s4njk4n

[Informative] PublicNexus RPC/WSS Now Available at Chainlist.org

s4njk4n — Tue, 25 Jun 2024 06:06:22 +0000

Hands-full and full-steam-ahead so just a quick community update. Life continues to get simpler and the landscape stronger for XDC Network users and devs :)

Xdcchain.xyz PublicNexus RPC/WSS stable access points are now listed and available on Chainlist.org!

Chainlist.org makes it easy to connect your wallet to PublicNexus stable access points

XDC Mainnet: https://chainlist.org/chain/50

Apothem Testnet: https://chainlist.org/chain/51

Helpful hint: if you ever see a PublicNexus access point showing as “down” on Chainlist.org, just refresh the page and Kaboom 💥 PublicNexus has been “magically” fixed! 😉

Note for existing users: Please note that we have removed the trailing slash from the addresses of our access points

[Informative] PublicNexus RPC/WSS Upgrade Completed - Mainnet/Apothem, RPC/WSS, xdc/0x prefixes all now supported

s4njk4n — Wed, 19 Jun 2024 04:21:04 +0000

Quick update to the community that we have completed several days of dev work and deployed our planned upgrades to PublicNexus.

New PublicNexus Features

PublicNexus is now live with access points for:

Mainnet Standard RPC
Mainnet 0x-enabled RPC
Mainnet Standard WSS
Mainnet 0x-enabled WSS
Apothem Standard RPC
Apothem 0x-enabled RPC
Apothem Standard WSS
Apothem 0x-enabled WSS

Full details for each access point are available here.

We have tightened up the timing of automated tests run to identify public RPC/WSS's that fail or start to lag, such that the maximum exposure is now 15sec before PublicNexus fixes itself by removing the problematic RPC/WSS (instead of 1min as previously).

We will be adding support for Mainnet and Apothem ARCHIVE nodes shortly.

PublicNexus and xdcchain.xyz

Since first becoming involved with the XDC Project in July 2017, the operators of xdcchain.xyz and PublicNexus have been committed to providing quality information, services, infrastructure and other contributions to the decentralised XDC Network.

Our approach has been to privately foster growth by providing appropriate solutions where necessary and possible. This has led to the birth of xdcchain.xyz and PublicNexus (amongst other initiatives).

As part of our commitment to providing quality offerings to the XDC Network, PublicNexus servers have been colocated in a data centre that services both government and industry clients, and offers 1Gb/10Gb fibre pair connectivity.

The highest user-reported data-throughput from our servers (when downloading our XDC Blockchain Daily Snapshot for Rapid Node Deployment) has been 2.4Gbit/sec (works out to ~17min to download the entire XDC chain snapshot).

What we have planned next

We have already deployed several XDC Geth Clients and their associated RPC/WSS endpoints over the last few months (incl multicore CPUs, 32GB RAM) and we will look at integrating these gradually into the backend of PublicNexus
We will be adding ARCHIVE NODE access point URLs for both Mainnet and Apothem
We will consider tightening further the RPC/WSS endpoint testing times during future update deployments
Lots more... (but some has to remain under wraps for now until closer to deployment)

What YOU can do

PublicNexus as a stable access point for the community is more effective when there are more working RPC/WSS endpoints on the backend. The more access points available, the less the impact of any one endpoint going down.

The number of requests that go to a faulty endpoint before it is excised can be successfully diluted by the total number of working endpoints available at that point in time.

An RPC can be simple to run and can even be set up to run at your home/office. It also doesn't need to run 24/7 and can always catch up with the rest of the chain when it is switched on. We will be working on publishing information that will make it simpler for the average community member to run and secure their own RPC endpoint on hardware they may already have. If after doing so, you would like to help the community by donating some access from your own RPC or WSS endpoint to the backend of PublicNexus, please reach out to us at xdcchain.xyz@outlook.com and we can look at possibly integrating it as well.

Other than that, just enjoy the simplicity and reliability of using the RPC/WSS access points we've provided and let us know if you encounter any issues!

——-

If anyone requires commercial access to a private reliable fault-tolerant high-speed RPC cluster, let us know and we may be able to help facilitate that separately.

- s4njk4n

[Informative] Layer 2 RPC Stable Access Point Deployed - https://publicnexus.xdcchain.xyz

s4njk4n — Thu, 13 Jun 2024 09:09:47 +0000

EDIT: The latest updates since this article below was published can be found HERE.

Full (open source) information on content and deployment is available on our Github here. Deploy your own or use ours for free :)

You can also see some of our other current and planned dev projects at https://xdcchain.xyz

To solve public/community RPC availability issues we've built a type of "Layer 2 RPC Stable Access Point" with integrated health-checks.

Publicnexus is a load-balancer with all known public RPCs on XDC network set as its origin/backend servers.

It checks each RPC's block height in parallel once per minute. If no response, or wrong response, or if the block height is greater than 4 blocks behind highest-block-height result from the cycle, then that RPC is removed from the list of origin/backend servers and no further RPC traffic will be directed there. (So max exposure time to any problematic RPC should be about 1 minute before Publicnexus fixes itself).

Conversely, if an RPC improves to meet criteria again, then it gets re-added to the list of origin/backend servers and will once again commence receiving RPC traffic.

To mitigate potential load on public RPCs from unexpectedly high volume single-party usage we've added in a throttling mechanism for each IP address. The allowed-rate-per-IP is set to be adequate for general public users. (If anyone requires private reliable high-speed RPC access, let us know and we may be able to help facilitate that separately).

The various rate-limit / throttling settings will also prevent its use for DOS and other malicious activity.

Project is in alpha. Current RPC settings if wanting to test:

RPC details available here.

Because Publicnexus uses all known public RPCs, it means this access point only supports the xdc prefix at the moment. A secondary access point can be added at a later point specifically for supporting the 0x-prefix if needed)

Server setup

Server running Ubuntu 22.04

Deployed on server:

apache2 (modules enabled: proxy, proxy_http, proxy_balancer, lbmethod_byrequests, ssl, ratelimit)
certbot (for LetsEncrypt CA cert/key)
python3
ufw
fail2ban

apache2

Should already be deployed on your server
Enable modules with:

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests
a2enmod ssl
a2enmod ratelimit

certbot and python3

Install, get certificate, and set up apache SSL configs with:

apt install certbot python3 python3-certbot-apache -y
certbot --apache

ufw

Install and setup firewall:

apt install ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 443
ufw allow 22
ufw enable
reboot

Port 22 is default SSH port. You can see instructions on how to change it by modifying /etc/ssh/sshd_config as described in this article.
Port 443 for SSL

fail2ban

Follow instructions in this article.

Further security

Also recommend:

Setting up ssh-key authentication to access the server
Consider disabling passwords or if keeping passwords then consider making them VERY long and complex consisting of upper/lower case letters, numbers + symbols. Disabling password login to root account can also be helpful as it is an easy to guess username on your server so it is easier to bruteforce.

Apache config

This is located in:

/etc/apache2/sites-enabled/000-default.conf <-- Certbot will write http to https redirects in here
/etc/apache2/sites-enabled/000-default-le-ssl.conf <-- Certbot will add your SSL setup in here You will need to modify these files to replace with your own domain name of course if you are establishing your own system. Also need to add load balancer configuration as shown.

Scripts/Files

Our scripts are located at ~/RPC_Check/

rpc_check.sh - This performs all the functions required to check RPCs, interpret responses, modify the load-balancer's origin servers, and (gracefully) apply the new origin server addresses. Note: curl is set to allow max 10sec for an RPC to respond. No response in this time = broken RPC. Also remember to set your variables at the top of this file with absolute path locations etc. as we are going to run this script as a cron job. Also at present the permitted lag in block height allowed by the script for an RPC to retain its "Active" status we have arbitrarily set to 4 blocks - which would be about 8 seconds based on an average block time of 2sec on the network. After further testing a more appropriate block-height lag tolerance may be determined.
rpc_check-pause.sh - In the event that you need to modify files manually and don't want rpc_check.sh running, this script will create a pause flag that inhibits the actions of rpc_check.sh.
rpc_check-restart.sh - This script deletes the pause flag so rpc_check.sh will then kick off where it left off.
rpc_pool.csv - This is a csv file containing 3 fields about each RPC it can potentially send traffic to: The RPC address/URL, that RPC's health-status, that RPC's last recorded block height
events.log - Our log file. By default, rpc_check.sh will limit this file to the last 5000 lines of log history. You can allow a longer history by just modifying rpc_check.sh.

rpc_check.sh is set to run minutely as a cron job:

crontab -e

Then in the crontab file:

* * * * * /bin/bash /root/RPC_Check/rpc_check.sh >/dev/null 2>&1

To do

Further determine the optimal maximum permissible block height lag. This will become apparent with further usage.

Please see our GitHub for full information and actual script/configuration files. (Or better yet, head on over to https://xdcchain.xyz to check out details of Publicnexus and our other projects!)

[Informative] Upgrade XDC-Client v1.4 to v1.6 by MIGRATION

s4njk4n — Thu, 06 Jun 2024 16:00:48 +0000

Please read this article and ensure you understand it completely before implementing anything described. If you're not sure about anything at all, please clarify it with someone who can help before you implement anything. If you post on xdc.dev someone will respond and clarify for you. (And most of all if you are a masternode operator, please make sure you have all appropriate backups of the keystore file from your node before doing anything!)

This article describes the process to upgrade your XDC Client from v1.4 to v1.6 by MIGRATING it to a new VPS. This is a safer option than deleting/reinstalling as all your files on the existing node remain intact until you are happy that your new node is up and running fine. If you encounter any immediate issues on the new node, it gives you the option of just going back to using the old/existing node until you have sorted out whatever is the issue you're experiencing with the new node.

Definitions

VPS1 = The VPS your current v1.4 XDC Client is running on.
username1 = Username of VPS1.
IPaddress1 = IP address of VPS1.
XDC-Client1 = XDC Client running on VPS1.

and:

VPS2 = The VPS you will be setting up your new v1.6 XDC Client on.
username2 = Username of VPS2.
IPaddress2 = IP address of VPS2.
XDC-Client2 = XDC Client running on VPS2.

Now we begin...

First go and arrange a new VPS to use as VPS2. You'll find information on system requirements for your VPS here:
https://xinfin.org/docker-setup

SSH to VPS2 in your Terminal

ssh username2@IPaddress2

Once logged into VPS2, update the OS:

sudo apt update
sudo apt upgrade
sudo apt autoremove
sudo apt clean

Install XDC-Client2 via Bootstrap script:

sudo su -c "bash <(wget -qO- https://raw.githubusercontent.com/XinFinOrg/XinFin-Node/master/setup/bootstrap.sh)" root

You'll be asked a few questions during installation of your node with the bootstrap script above.
Answer "mainnet" when asked about that.
Select "y" regarding private key etc. (We're going to replace the keystore later anyway).

Shutdown XDC-Client2:

cd ~/XinFin-Node/mainnet
sudo bash ./docker-down.sh

Download the current chain snapshot using either:

The Rapid Download snapshot from https://xdcchain.xyz if you have a download command from there. It will be the one that looks something like:

Example: sudo wget -c -O xdcchain.xyz_snapshot.tar "https://nzYS66oEzxybde:CHiJzMnJ354Y3x@xdcchain.xyz/snapshot/xdcchain.xyz_snapshot.tar?authorisedip=nzYS66oEzxybde"

The official XinFin snapshot:

sudo wget https://download.xinfin.network/xdcchain.tar

Then logout of VPS2:

logout

SSH to VPS1

ssh username1@IPaddress1

Navigate to the XDC-Client1 directory:

cd ~/XinFin-Node

Shutdown XDC-Client1:

(It is very important that you do this now to avoid a conflict later on the network with XDC-Client2)

Depending on the version of your XDC-Client1 installation, you may have to use:

sudo docker-compose -f docker-services.yml down

sudo docker-compose -f docker-compose.yml down

If neither of those commands has worked for you to shutdown XDC-Client1, please reply to this article in the comments. DO NOT PROCEED WITH FURTHER STEPS ON EITHER VPS UNTIL XDC-Client1 HAS BEEN SUCCESSFULLY SHUTDOWN (or it may interfere with XDC-Client2 receiving rewards or operating correctly)

After shutting down XDC-Client1, we then logout:

logout

SSH to VPS2

ssh username2@IPaddress2

Navigate to the mainnet directory:

cd ~/XinFin-Node/mainnet

Next we need to decompress the snapshot

If you've used the xdcchain.xyz snapshot file, then you'll use:

sudo tar -xvzf xdcchain.xyz_snapshot.tar

OR
If you've used the official XinFin snapshot, then you'll use:

sudo tar -xvzf xdcchain.tar

Delete any pre-existing chain database files on XDC-Client2:

sudo rm -rf xdcchain/XDC

Move the new chain snapshot files to the correct location:

sudo mv XDC xdcchain/XDC

Delete the new coinbase.txt and keystore files in XDC-Client2:

sudo rm -rf xdcchain/coinbase.txt
sudo rm -rf xdcchain/keystore/UTC*

Copy your coinbase.txt from VPS1 to VPS2:

sudo scp username1@IPaddress1:~/XinFin-Node/xdcchain/coinbase.txt xdcchain/coinbase.txt

Copy your Keystore file from VPS1 to VPS2:

sudo scp username1@IPaddress1:~/XinFin-Node/xdcchain/keystore/UTC* xdcchain/keystore/

Copy your .env file from VPS1 to your HOME directory on VPS2:

sudo scp username1@IPaddress1:~/XinFin-Node/.env ~

Open the .env file you just copied from XDC-Client1 in nano:

sudo nano ~/.env

Take note of the name of your node and the contact email address you used

Type them in a notepad if u need.

Then close nano by using:

Ctrl+X

Open the NEW .env for XDC-Client2 in nano (we don't need to specify a path as we're already in the ~/XinFin-Node/mainnet/ directory):

sudo nano .env

Put the name of your node into the INSTANCE_NAME field.
Put the email address you used into the CONTACT_DETAILS field.
Ignore the other fields in the file (including the Private Key field).

Then close and save the .env file by using:

Ctrl+X
Y
Press Enter

Delete the old .env file from your HOME directory:

sudo rm -rf ~/.env

Start XDC-Client2:

sudo bash ./docker-up.sh

Wait 10 minutes and then check your node's status on https://xinfin.network or https://stats.xdc.org

If you are operating a masternode (validator or standby node), you should also check you node is showing properly on https://master.xinfin.network and isn't slashed. If your node is showing as slashed or isn't showing at all on the site then there may be another issue that you'll need to troubleshoot.

If you are operating a masternode (validator or standby node), you should also check your appropriate rewards are continuing to arrive in your correct wallet at the correct intervals. If you are not receiving your expected rewards then there may be another issue that you'll need to troubleshoot.

If all looks fine then congratulations you have now migrated your node!

Once you are happy that your node migration has been successful and if you want to clear a few hundred GB of drivespace on VPS2 to allow for growth of the chain, you can consider deleting the chain snapshot file you downloaded by using the relevant command for whichever snapshot file you downloaded and used:

sudo rm -rf ~/XinFin-Node/mainnet/xdcchain.tar

OR:

sudo rm -rf ~/XinFin-Node/mainnet/xdcchain.xyz_snapshot.tar

In case of any technical queries on XDC Network, feel free to drop your queries on XDC.Dev forum.

Quick links:

XinFin.org
XDC Chain Network Tools and Documents
XDC Network Explorer
XDC Dev Forum
Beta — XDC Web Wallet
XDC faucet
XDC faucet - Blocksscan

XinFin — XDC Social Links:

Twitter
GitHub
Telegram
Facebook
LinkedIn
YouTube