Developers Forum for XinFin XDC Network: s4njk4n

Hardened XDC Full Node 2026

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

This is just a note to myself. Posting here in case the thought bubbles and code snippets are useful for anyone else. I removed the article about the updated bootstrap script as I believe the version I created may no longer be current and don't want anyone to get stuck. If anyone really wants it, its still 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
sudo apt upgrade
sudo apt autoremove
sudo apt clean

Prerequisites

Then to install prerequisites, there is an appendix at the bottom of this article but if thinking of using anything in there, please read the appendix first as I have not rechecked it since having slow peer pickup on another node installed using the instructions in the Appendix. For the moment, if unsure, they just check the XinFin Github repo for official prerequisites installation.

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. Be careful with using $ as a character in the password in the useradd command below as it can be interpreted as a string variable even if its in the middle of the password.

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
AND THEN
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
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/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.

Appendix details just for me

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.

The following code is not to be used. Something in the new customised bootstrap script I wrote (not the official XinFin version) resulted in a node I just installed not picking up peers so all the below steps when installing prerequisites etc need to be double checked to see if they may have been related. This section is a mental note to me just until I've finished playing next time I install a new node:

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

    echo "Setting up Docker repository and installing Docker"

    # 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

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

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

[Informative] Upgrading XDC Clients from v1.4.4 (Old Directory Structure) to Newer v1.6.0

s4njk4n — Sun, 19 May 2024 04:10:39 +0000

Upgrade by node MIGRATION is a safer option for masternode operators (both validators and standby nodes). New article to upgrade via Migration is here.

Original upgrade article is below but please keep in mind if using it that you MUST ensure you have adequate backups of your keystore file or you may risk losing masternode status, losing any associated income and losing your masternode stake. The migration method is much safer so recommended approach is to use that via the link just above instead of the information below.

Info below kept only for reference for those who really need it.

We've had some operators request help on how to upgrade from the old v1.4.4 clients to the new v1.6.0 after unsuccessfully using upgrade.sh. (The reason it doesn't work is that the directory structures in the older client versions were different and have since been updated). Information below is a quick update from memory of how we've done it for other v1.4.4 clients.

Note that the steps below will involve waiting for the new client to sync the chain which seems to still take us around a week on any nodes we've got running on Gigabit ethernet.

Clients running in a production environment will need to minimise downtime, so will benefit from obtaining and decompressing a chain snapshot so it can be copied straight into the client as soon as it is completed with installation. We encountered some issues when doing this (details in the instructions below) and are working on putting together a solution which should be available in the next few days.

The instructions below are are a quick memory-dump guide from my head of the steps we used so definitely recommend you go through them first to make sure you understand and are happy with them before applying anything below.

TO UPDATE AN OLDER v1.4.4 XDC CLIENT to v1.6.0:

ssh to VPS

UPDATE THE OS:

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

BACKUP REQUIRED FILES TO HOME DIRECTORY:

cd ~
sudo cp ~/XinFin-Node/.env .
sudo cp ~/XinFin-Node/xdcchain/coinbase.txt .
sudo cp ~/XinFin-Node/xdcchain/keystore/UTC* .

SHUTDOWN THE CLIENT:

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

DELETE THE v1.4.4 CLIENT:

cd ~
sudo rm -rf XinFin-Node

WARNING THIS ABOVE COMMANDS WILL DELETE ALL NODE FILES ON YOUR MACHINE INCLUDING THE CHAIN WHICH THEN NEEDS TO BE RESYNCED ONCE THE CLIENT IS REINSTALLED. YOU MAY BE ABLE TO BACKUP THE CHAIN FILES BUT WE HAVE NOT TRIED THIS SO CANNOT SUGGEST ANYTHING. For the v1.4.4 clients we helped with, we just deleted the whole client and let them resync the chain from scratch after installing the new v1.6.0 client and restoring coinbase.txt, keystore file, and updating .env details. We were unable to get the current xdcchain.tar snapshot file working, and noted it contains some extra files/folders (and we noted is around 500GB download whereas a current completely synced client normally has a drive footprint of only around 360GB even including the OS). If you can get that snapshot working is the best option to start with. As an alternative we are in the process of creating a new chain snapshot in a few days time from one of our own 1.6.0 clients and plan to make download access to it available online for an XDC fee, but suggest everyone first try the official xdcchain.tar if going down this route as it is free.
The official snapshot is available at:
https://download.xinfin.network/xdcchain.tar

INSTALL THE v1.6.0 CLIENT VIA BOOTSTRAP SCRIPT:

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

SHUTDOWN THE NEW v1.6.0 CLIENT:

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

DELETE THE NEW coinbase.txt AND keystore FILES:

cd ~
sudo rm -rf ~/XinFin-Node/mainnet/xdcchain/coinbase.txt
sudo rm -rf ~/XinFin-Node/mainnet/xdcchain/keystore/UTC*

COPY THE OLD coinbase.txt AND keystore FILES INTO THE NEW CLIENT:

sudo cp ~/coinbase.txt ~/XinFin-Node/mainnet/xdcchain/
sudo cp ~/UTC* ~/XinFin-Node/mainnet/xdcchain/keystore/

MAKE SURE YOU DONT HAVE ANY OTHER RANDOM SIMILARLY-NAMED KEYSTORE FILES IN THE HOME DIRECTORY BEFORE YOU RUN THE COPY COMMAND ABOVE ON YOUR UTC* FILE AS IT WILL COPY THEM ALL TO THE NEW CLIENT'S keystore DIRECTORY. IF YOU HAVE MORE THAN ONE FILE IN YOUR HOME DIRECTORY BEGINNING WITH "UTC", YOU WILL NEED TO PUT THE SPECIFIC FILE DETAILS INTO THIS COPY COMMAND SO ONLY THE RIGHT ONE IS MOVED INTO THE NEW CLIENT

CHECK AND MAKE NOTE OF NODE NAME AND CONTACT DETAILS FROM OLD .env FILE:

sudo nano .env

To exit use Ctrl+X

OPEN THE NEW .env FILE IN THE NEW CLIENT:

sudo nano ~/XinFin-Node/mainnet/.env

UPDATE THE NODE NAME
UPDATE THE CONTACT DETAILS
IGNORE THE NEW PRIVATE KEY FIELD. APPARENTLY THERE'S NOTHING WE NEED TO DO WITH THIS
SAVE THE FILE: CTRL+X, press Y, Press

NOTE YOU WILL ALSO NEED TO CONSIDER RESTORING ANY OTHER CUSTOMISATIONS (eg custom port mappings in .yml file, or customisations to your start-node.sh script for --enable-0x-prefix etc.. if you have made any modifications you will need to redo them at this point).

REBOOT YOUR VPS:

sudo reboot

SSH TO YOUR VPS AGAIN

RESTART THE NEW v1.6.0 CLIENT:

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

LOGOUT OF YOUR VPS, WAIT FOR 30-60 MINS THEN CHECK YOUR NODE'S STATUS AND CLIENT VERSION ON:
https://xinfin.network
or
https://stats.xdc.org

YOU CAN ALSO CHECK THE CLIENT VERSION BY ATTACHING THE JAVASCRIPT CONSOLE:

cd ~/XinFin-Node/mainnet
sudo bash ./xdc-attach.sh

To exit the console, use the "exit" command

IF THE NODE SHOWS AS BEING ONLINE, WITH THE CORRECT VERSION, AND IS SYNCING OK, THEN CONSIDER WHETHER YOU NEED ANY FURTHER BACKUPS OF YOUR KEYSTORE FILE. ONCE DONE WITH THAT, WE CAN DELETE THE .env , coinbase.txt , AND keystore FILES WE PLACED IN THE HOME DIRECTORY:
SSH TO THE VPS

cd ~
sudo rm -rf .env
sudo rm -rf coinbase.txt
sudo rm -rf UTC*

MAKE SURE YOU DONT HAVE ANY OTHER RANDOM SIMILARLY-NAMED KEYSTORE FILES IN THE HOME DIRECTORY BEFORE YOU RUN THIS COMMAND AS IT WILL DELETE EVERYTHING STARTING WITH "UTC"

LOGOUT OF YOUR NODE AND YOU'RE ALL DONE!

[WIP]Nonce utility in broadcast.xinfin.network not working

s4njk4n — Sat, 04 May 2024 05:48:00 +0000

When going to https://broadcast.xinfin.network and selecting the Nonce utility, usually we can either paste in an address or type it in manually.

Pasting into the Address box at present doesn't seem to work (?is pasting disabled). Have tested with Firefox/Brave/Chrome.

If manually typing an address into the Address field, the Type field then says Invalid and the Nonce remains as - (and no number is shown).

Inspecting via browser shows these errors below so looks like part of it is maybe RPC and CORS issue?

Access to XMLHttpRequest at 'https://xinpayrpc.xinfin.network/' from origin 'https://broadcast.xinfin.network' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

2.8bd6b7bd.chunk.js:1
POST https://xinpayrpc.xinfin.network/ net::ERR_FAILED

Uncaught (in promise) Error: Invalid JSON RPC response: ""
at Object.InvalidResponse (2.8bd6b7bd.chunk.js:1:1546114)
at i.onreadystatechange (2.8bd6b7bd.chunk.js:1:1726034)

Can someone take a look and/or change the RPC being used?

Thanks

ADD: Interestingly it is possible to paste 44 characters as an address (including the xdc prefix)... but XDC addresses normally only have 43 characters when including the xdc prefix.. And if adding an extra character so pasting works, the Address textbox then won't allow deleting any characters.. Looks like it wants to maintain 44 characters... So the Address remains incorrect and the Type field remains Invalid and the Nonce field remains as -.