Developers Forum for XinFin XDC Network

Can't Access XDC Wallet

Ram — Sat, 14 Mar 2026 04:33:36 +0000

I've been trying to access my XDC wallet through myetherwallet but I noticed that my address is not listed. It use to be the first one. It's the same when trying to open up in XDC Wallet Connect.

Master Node Structure

Kenneth Cowan — Thu, 12 Mar 2026 16:17:07 +0000

Hi current plans support the change of our node structure to a Validator, Protector and Observer with yields of 10%, 8% and 4% respectively. There will be 108 total Validators, 216 total Protectors and 1000 Observers. At a 4% yield the observer is a fairly unappealing prospect. Would the community consider potentially swapping a large proportion of the Observers for Protectors. Say 450 Validators and 100 Observers instead of 1000 Observers. The mint demand remains constant but the yield of the Protector is far more appealing to the institutional and retail investor and will help to encourage reputable and regulated institutions to support our infrastructure

[Informative] February Insights: Key Highlights from Plugin’s Journey

Manuni Mistry — Wed, 04 Mar 2026 16:31:37 +0000

As we move further into 2026, Plugin continues to build steadily across its infrastructure, ecosystem, and developer tooling. From live product launches to meaningful backend milestones, this month brings exciting progress worth sharing.

📰 News

🔔 Plugin RPC — Now Live on XDC Mainnet & Apothem Testnet

Plugin RPC is officially live on both XDC Mainnet and Apothem Testnet. The service delivers fast, low-latency transactions with a smooth experience for users. To celebrate the launch, a limited-time freemium tier is available.

Work on the WSS (WebSocket) version is actively underway, with pipeline development in progress.

Explore Now: rpc.plugin.global

🏠 EquitEdge

Significant backend progress has been made on the FMS (Facility Management System). The following core modules are now fully operational:

Authentication Module — core user access and account management flows.
FMS KYC Workflow — KYC submission flow for FMS users, with approval handled via the EquitEdge Platform.
Membership Module — FMS users can now purchase membership plans directly through the system.

The foundational user onboarding, verification, and access control system is now fully operational on the backend, setting the stage for broader rollout.

🔗 Plugin Core Development Update

Upcoming focus areas include Off-chain Reporting (OCR) designed to aggregate data off-chain and reduce gas fees while preserving decentralization as well as CCIP integration to further strengthen understanding of the Plugin core. Technical discussions with key contributors are planned to finalize the OCR design and implementation approach.

🍽️ Food for Thought

Decentralization is often discussed in terms of ownership and governance, but its true backbone is the network of operators who keep systems running. Node operators are the unsung architects of distributed infrastructure contributing compute, maintaining uptime, and ensuring that no single point of failure can compromise the whole. As blockchain networks scale, the relationship between protocol developers and node operators becomes increasingly important. Operators provide the geographic distribution and redundancy that makes a network truly resilient. The more thoughtfully this relationship is built, the stronger and more sustainable the ecosystem becomes.

🧠 Plugin Quiz

What does "low-latency" mean in the context of blockchain?

👉 Reply with your answer in the comments!

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

EIP-7702 is available on devnet now

Daniel Liu — Tue, 24 Feb 2026 03:36:49 +0000

EIP-7702 is available on XDC devnet now. It was activated together with EIP-2935 and EIP-7623 at block number 3000600. We sincerely invite you to test it on devnet.

Mnemonic seed phrase brings up wrong derivation path and different wallet

Richard Daley — Wed, 18 Feb 2026 16:59:48 +0000

I have been using the XinFin Web Wallet with a 12 word mnemonic seed phrase and my password to access by XDC tokens, but now the same entries bring up an incorrect wallet number.
I have used Google and ChatGPT for answers, and so far I have tried accessing my wallet via DXC Pay (but get the wrong wallet), CAN'T use MyEtherWallet because I'm in the UK, tried Infinity Wallet by UltraNote but it crashed, Tried Rabby Wallet but it also has the same derivation path issues and can't find my old wallet. I tried MyCrypto Desktop, but again it showed me an incorrect wallet address.
I also scrolled down 500+ address options whilst in the XinFin Web Wallet to see if my own wallet was further down the list but with no luck.
Can anyone suggest a way to successfully access my correct address using my mnemonic phrase without it constantly bringing up a different empty address?
How can i get my seed phrase to bring up the address where my XDC tokens are stored?

Node Status APY

NileshPathak01 — Mon, 16 Feb 2026 15:07:39 +0000

Hi,

Is there any API wherein I as a node owner can pass Coinbase address and get the node status in return (CORE/ Standby/ Slashed).

If so, would like to use the APY to get the status on the fly and display on our Dapp Screen, rather than looking on the Xin Fin Dapp and applying the changes on our side manually (when the node status changes)

Thanks
Nilesh

Archive RPC

Trahwidhi — Mon, 16 Feb 2026 09:43:00 +0000

Hey everyone,

I'm currently working on a project and encountering some issues trying to query from block 1. I need an archive node, but the RPCs I've tried so far don't exactly works.

Here is what I've tested:

https://rpc.ankr.com/xdc - This throws an error whenever I query block 1 (I suspect it’s a standard full node and trims historical state).

https://arpc.xinfin.network & https://rpc.xdcrpc.com/ - These seem to have the archive data, but they block my frontend requests (http://localhost:5173) due to CORS policies.

Here is the exact error I get on the latter two:

Access to fetch at 'https://arpc.xinfin.network/' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

My questions:

Are there any free, public Archive RPC nodes available for XDC that support frontend/CORS requests?
If free options aren't available, are there any recommended paid providers that guarantee genesis block queries and allow custom origin headers?

Thanks in advance for any recommendations!

[Informative] January Insights: Key Highlights from Plugin’s Journey

Manuni Mistry — Tue, 10 Feb 2026 10:02:18 +0000

As we step into the early months of 2026, Plugin continues to scale its infrastructure and deepen its commitment to decentralization, reliability, and real-world adoption. With major network upgrades and meaningful progress across our ecosystem, the foundation for the year ahead is being firmly set.

📰 News

🔔 Plugin Network & Ecosystem Updates

Plugin Decentralized Oracle Network just received a major power boost. An additional 60+ nodes are selected for actively providing data feeds as Standard Nodes, significantly to strengthen the network. This bolsters decentralization across the PLI ecosystem, delivers institutional-grade reliability, and increases throughput for Real-World Asset (RWA) data feeds.

📈 2025 Achievements & 2026 Roadmap

We’re gearing up to unveil a comprehensive overview of Plugin’s 2025 milestones along with our 2026 roadmap. Exciting developments, new upgrades, and ecosystem expansions are on the way stay tuned for the official announcement coming very soon!

🏠 EquitEdge Ecosystem Update

We have completed the smart contract and successfully tested the ability to mint our investment token using the ERC3643 standard, marking a significant step toward fully on-chain real-world asset investing. The platform is being built to allow users to invest seamlessly using USDC, which will simplify onboarding and improve accessibility for a wider audience. Once the underlying property milestones are fulfilled, the corresponding investment tokens will be released to investors, completing the investment lifecycle with transparency and trust at every stage.

🔗 RPC as a Service Update

The RPC-as-a-Service (HTTP) is now live on testnet for the moderator community to begin testing. Feedback is actively being collected, and improvements are underway to ensure the service is stable, reliable, and optimized for all use cases.

Work on the WSS (WebSocket) version is ongoing and will be made available soon for further testing, providing real-time connectivity and expanded functionality for developers and moderators alike.

🍽️ Food for Thought

Decentralization is no longer just about removing intermediaries — it’s about building systems that scale responsibly. As oracle networks grow stronger, reliability and execution become just as important as innovation. The future of Web3 belongs to networks that can handle real-world demand without compromising trust.

🧠 Plugin Quiz

What does “on-chain governance” refer to?

👉 Reply with your answer in the comments!

TokenXSender launches a secure, scalable token distribution solution supporting XDC Network

Amir Neghabian — Tue, 10 Feb 2026 03:11:40 +0000

Token distribution is a core requirement for every crypto project—but it doesn’t need to be complex or time-consuming.

Tokenxsender is a modern token sender platform built to help crypto projects distribute tokens efficiently, securely, and at scale. Designed with simplicity and performance in mind, Tokenxsender enables teams to send tokens to multiple addresses in just a few clicks.

Backed by VitalVEDA, Tokenxsender offers a reliable solution for bulk token transfers, making it an ideal cost-effective tool for airdrops, rewards, token sales, and contributor payouts.

What Is Tokenxsender?

Tokenxsender is a streamlined token distribution service that allows projects to:

Send tokens in bulk to multiple wallet addresses
Track transactions in real time
Execute secure and reliable on-chain transfers
Manage distributions with ease, regardless of team size
Built for Modern Web3 Needs

Tokenxsender is designed to support today’s multi-chain ecosystem.

Supported Blockchain Network:

XDC
Binance Smart Chain (BSC)
Polygon
Ethereum
Base
Arbitrum

Supported Wallets:

MetaMask
Wallet Connect
Trust Wallet
Coinbase Wallet
Phantome

And many other major wallets.

Key Features:

Bulk Token Sending
Distribute tokens to multiple addresses in a single, streamlined process.
Real-Time Tracking
Monitor transaction status, confirmations, and transaction hashes instantly.
Secure & Efficient Infrastructure:
Fast, reliable, and secure transactions built on trusted blockchain networks.
User-Friendly Interface

Our platform is designed to be intuitive and accessible, catering to teams of all technical levels, thereby ensuring seamless onboarding and flexibility across various Web3 ecosystems.

Use Cases:

Tokenxsender supports a wide range of token distribution scenarios, including:

Airdrops and reward programs
Token sales and vesting distributions
Community engagement and incentive campaigns
Payroll, contributor rewards, and performance incentives

Send Tokens Effortlessly with Tokenxsender

With Tokenxsender, token distribution becomes smooth, transparent, and scalable. Whether you’re rewarding your community or managing large-scale payouts, the platform provides all the tools needed to execute distributions efficiently.

Backed by VitalVEDA and built for the future of Web3, Tokenxsender is redefining how crypto projects send tokens—simple, secure, and scalable.

Web: https://tokenxsender.com/
Smart contract Link: https://xdcscan.com/address/0x1fAb9c2d73259aDab6C4154d9ADA1e60951a683A

[PROPOSAL] UNITY Protocol: ISO 20022 Settlement Bridge for Hospitality & QuickBooks

Bpwll81 — Sun, 01 Feb 2026 21:18:57 +0000

GRANT PROPOSAL: UNITY PROTOCOL
Submission Category: Applications & Integrations / RWA Infrastructure
I. Team & Applicant Information
Applicant Name: Brad Powell
Organization: Powell Incorporated (In Formation)
Legal Status: LLC (Colorado, USA - Filing Pending)

Wallet Address: xdcba20e18817b93894f4667b8f7c5d5d1ba94cf271

Website: www.powellincorporated.com

Repository URL: [https://github.com/Bpwll81/powell-inc-website]

Whitepaper URL: [https://docs.google.com/document/d/1SM33_yfX58HIRc4BMacbxeXiFDl15p6QsIvFCJTEDZg/edit?usp=sharing]

Team Background & Vision: I am not a "crypto-native" developer; I am a veteran of the hospitality industry. With over 30 years of experience—from the dish pit to management—I have lived through the inefficiencies of legacy payroll and restaurant accounting. I know the pain of waiting for checks, the cost of friction, and the stress of razor-thin margins.

UNITY Protocol is not an abstract coding experiment. It is a solution built by an industry insider to solve a specific, painful problem: The "Last Mile" of Settlement. My goal is to take my 30 years of "kitchen logic"—where efficiency is survival—and apply it to the XDC blockchain, creating a seamless, stress-free financial rail for the businesses that feed our economy.

II. Project Description UNITY Protocol is a specialized RWA (Real World Asset) infrastructure designed to bridge legacy accounting systems—specifically QuickBooks and "Hey Chef" restaurant management software—with the XDC Network.
While traditional payroll settlement is slow, costly, and opaque,

UNITY utilizes the XDC blockchain to enable instant, ISO 20022-compliant settlement for SMBs. The protocol solves two critical failures in the current market:
Integration: Crypto payroll exists but lacks integration with the tools businesses actually use. UNITY provides the middleware to settle on-chain without leaving the QuickBooks interface.
Asset Stability: The protocol differentiates itself through a dual-asset stability model:

UNITY (UNT): The primary XRC-20 settlement token, backed by a diversified basket of 5 precious metals.
UGLD: A specialized reserve token representing "Senior Rights" to physical gold reserves, minted specifically at 5,000oz intervals to ensure deep institutional backing.

Project Media (Demo):
Concept/Demo Video: [https://youtube.com/shorts/eaXlTxe6dvw?si=NfSWqyZftYub29ig]

Project Goals: Our primary goal is to become the standard ISO 20022 Settlement Layer for the hospitality industry. By leveraging XDC's low gas fees and high transaction speed, we aim to:
Reduce payroll processing costs for SMBs by 40%.
Eliminate the 2-3 day float period for employee payments.
Provide a "Bail-Free" asset storage solution for corporate treasuries using our 5-metal basket.

III. Milestones & Roadmap

Phase 1: Liquidity Genesis & Mainnet Activation (Month 0-3)
Status: In Progress (Smart Contracts Deployed on Testnet)
Key Deliverable: Deployment of $95,000 USD into XDC/UNT liquidity pools to scientifically defend a listing price of $0.005.
Funding Required: $95,000 (Liquidity) + $35,000 (Asset Acquisition)

Phase 2: The "Payroll Bridge" & Hey Chef Integration (Month 4-9)
Key Deliverable: Launch of the proprietary UNITY Payroll Interface, featuring deep API integration with "Hey Chef" restaurant management software and QuickBooks.
Metric: Successful settlement of the first 100 restaurant payroll transactions on the XDC mainnet.
Funding Required: $25,000 (Development & Hardware Testing)

Phase 3: Local Adoption & Hardware Deployment (Month 10-18)
Key Deliverable: Deployment of POS (Point of Sale) hardware to brick-and-mortar businesses in Colorado.
Metric: Onboarding 50+ local merchants to accept/settle in UNT.

Phase 4: Asset Realization & Founder Funding (Target: $1.00 UNT)
Trigger Event: Upon UNT achieving a stable valuation of $1.00.
Sustainability Mechanism: At this valuation, the Founder's Allocation (1.225 Billion UNT) activates to underwrite physical expansion. This ensures the project's long-term capital needs (Resort Construction) are self-funded, eliminating reliance on future grants.

Phase 5: Global Expansion
Key Deliverable: Licensing the UNITY Payroll/Hospitality stack to international operators.

IV. Budget Total Request: $200,000 (paid in XDC)
Allocation Breakdown:
Liquidity Seeding ($95,000): Strictly allocated to XDC/UNT DEX pools to establish the $0.005 entry price and ensure low slippage for payroll clients.

Strategic Reserve Assets ($35,000): Purchase of the 5-Metal Basket (Gold 50%, Silver 25%, Platinum 10%, Palladium 10%, Copper 5%).
Note: Copper allocation is capped at 5% to mitigate state-level sales tax and storage inefficiencies.

Security & Legal Framework ($35,000):
$20,000: Full Smart Contract Audit (CertiK/Hacken).
$15,000: Formal Legal Opinion Letter (US-based Counsel) for asset-token classification.

Development & Integration ($20,000):
Retainer for Senior Developer consultant to finalize API adapters and Technical Sales Engineering.

Hardware & Testing Infrastructure ($5,000):
Purchase of test tablets, POS terminals, and hardware wallets for the Phase 2 Beta Pilot.

Logistics & Security ($10,000):
Securing a "Bail-Free" Segregated Vault (e.g., Brinks/Malca-Amit) plus Year 1 Insurance/Storage fees.

V. Sustainability & Matching Funds UNITY achieves self-sufficiency through transaction fees (0.1%) and the Phase 4 Founder Funding mechanism.

Matching Capital Strategy: We are actively submitting proposals for a $600,000 Private Seed Round (targeting 3 Strategic Investors @ $200k each). This XDC grant will serve as the "Matching Anchor" to unlock that private capital, bringing the total initial capitalization to $800,000 for the launch year. Ultimately, I am looking for a "slow" yes, instead of a "fast" no. Thank you all for your time and consideration for my project.

XDC Network v2.6.8: The Cancun Upgrade Goes Live on Mainnet

AnilChinchawale — Fri, 30 Jan 2026 14:26:51 +0000

The Most Significant XDC Protocol Upgrade in Years

Published: January 2026

🚀 Executive Summary

XDC Network has successfully activated its most significant protocol upgrade to date with v2.6.8, bringing Ethereum Cancun-equivalent features to the XDC mainnet at block 98,800,200. This release marks a major milestone in XDC's evolution, introducing EIP-1559 fee markets, advanced EVM capabilities, and substantial performance improvements that position XDC as one of the most technically advanced enterprise-grade blockchains.

🎯 Why This Release Matters

1. EIP-1559: Revolutionary Fee Market

The activation of EIP-1559 fundamentally transforms how transaction fees work on XDC Network:

Before (Legacy):

Users guess gas prices
Overpayment is common
Fee volatility during congestion
All fees go to validators

After (EIP-1559):

Predictable base fees
Automatic fee adjustment
Better UX for wallets and dApps
Base fee burned (deflationary pressure)

Impact: Users and developers now enjoy a more predictable, efficient fee mechanism that's already proven on Ethereum. This is critical for enterprise adoption where cost predictability matters.

2. Cancun Instruction Set: Future-Ready EVM

XDC now supports the complete Ethereum Cancun upgrade, including:

EIP	Feature	Benefit
EIP-1153	Transient Storage	Gas-efficient temporary storage
EIP-3651	Warm Coinbase	Cheaper access to block producer
EIP-5656	MCOPY Opcode	Efficient memory operations
EIP-6780	SELFDESTRUCT Changes	Improved security model
EIP-7516	BLOBBASEFEE Opcode	Blob transaction support

Impact: Smart contract developers can now use Solidity v0.8.28 features, deploy contracts optimized for Cancun, and benefit from significant gas savings.

3. Blob & KZG Cryptography Support

This release introduces infrastructure for EIP-4844 (Proto-Danksharding) readiness:

BLOBHASH opcode implementation
KZG cryptographic primitives
Blob transaction handling groundwork

Impact: XDC is now positioned to support Layer 2 scaling solutions and data availability sampling—critical for future scalability.

4. Enterprise-Grade Stability

Extensive bug fixes and optimizations address real-world operational issues:

Fixed: Transaction pool overflow issues
Fixed: Block production stalls
Fixed: RPC accuracy improvements
Fixed: Memory leaks in node operations
Fixed: Consensus edge cases

Impact: Masternode operators experience more reliable block production and reduced maintenance overhead.

📊 Technical Deep Dive

EVM Performance Improvements

The v2.6.8 release includes substantial EVM optimizations:

┌─────────────────────────────────────────┐
│ Performance Improvements                │
├─────────────────────────────────────────┤
│ • Refactored VM context architecture    │
│ • Reduced memory allocations            │
│ • Optimized precompile handling         │
│ • Improved jumpdest analysis            │
│ • Better EstimateGas accuracy           │
└─────────────────────────────────────────┘

New RPC Capabilities

Operators gain new tools for node management:

# New trusted peer management
admin_addTrustedPeer("enode://...")
admin_removeTrustedPeer("enode://...")

# New epoch information
xdpos_getBlockInfoByEpochNum(epochNumber)

# Database CLI tools
XDC db stats
XDC db compact
XDC db inspect

Security Enhancements

CertiK audit findings addressed
Hardened consensus signature validation
Improved sender recovery for pending transactions
Enforced signer uniqueness using public keys

🔧 What Developers Need to Know

Solidity v0.8.28 Support

You can now use the latest Solidity features:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.28;

contract CancunFeatures {
    // Transient storage (EIP-1153)
    // Useful for reentrancy guards without storage costs

    // MCOPY for efficient memory operations
    // BLOBHASH for L2 data availability
}

Updated Gas Estimation

// Gas estimation is now more accurate
const gasEstimate = await provider.estimateGas({
    to: contractAddress,
    data: encodedData
});

// EIP-1559 transaction format
const tx = {
    to: recipient,
    value: ethers.parseEther("1.0"),
    maxFeePerGas: ethers.parseUnits("25", "gwei"),
    maxPriorityFeePerGas: ethers.parseUnits("1", "gwei"),
    type: 2  // EIP-1559 transaction
};

Chain Configuration

{
  "chainId": 50,
  "cancunBlock": 98800200,
  "eip1559Block": 98800200
}

🏗 For Masternode Operators

Mandatory Upgrade

⚠️ This is a consensus-breaking upgrade. All nodes MUST upgrade before block 98,800,200.

# Upgrade command
cd mainnet && bash upgrade.sh

# Verify version
./XDC version
# Should show: v2.6.8

New Configuration Options

# RPC gas cap (default: 50M)
--rpc-gascap 50000000

# Enable HTTP and WS on same port
--http --ws --http.port 8545

# Increased default max peers
# Now defaults to 50 peers

Deprecated Flags (Remove from configs)

# These flags are NO LONGER SUPPORTED:
--mine          # Removed
--fast          # Removed  
--light         # Removed
--XDCx-datadir  # Removed

📈 Impact on XDC Ecosystem

For DeFi Protocols

More predictable transaction costs
Gas optimizations reduce operational costs
New opcodes enable more efficient contracts

For Enterprise Users

Improved reliability and uptime
Better cost predictability
Enhanced security guarantees

For Layer 2 Development

Blob transaction infrastructure ready
KZG cryptography support
Foundation for data availability solutions

For Token Economics

EIP-1559 base fee burn mechanism
Potential deflationary pressure on XDC
More sustainable validator economics

🗓 Timeline

Date	Event
Jan 7, 2026	v2.6.8 release published
Jan 2026	Mainnet activation at block 98,800,200

🔮 What's Next

With Cancun features now live, the XDC development roadmap focuses on:

Layer 2 Scaling - Leveraging blob transaction support
Cross-chain Interoperability - Enhanced bridge capabilities
Developer Tooling - Improved debugging and analytics
Continued Performance - Further EVM optimizations

📚 Resources

Release Notes: GitHub v2.6.8
Upgrade Guide: XDC Documentation
Block Explorer: xdcscan.io

🎉 Conclusion

XDC Network v2.6.8 represents a watershed moment for the ecosystem. By achieving feature parity with Ethereum's Cancun upgrade while maintaining XDC's unique advantages—2-second block times, near-instant finality, and enterprise-grade reliability—this release solidifies XDC's position as a leading blockchain for trade finance and enterprise applications.

The combination of EIP-1559 fee markets, advanced EVM capabilities, and comprehensive stability improvements creates a more powerful, predictable, and developer-friendly platform. Whether you're building DeFi protocols, enterprise solutions, or Layer 2 infrastructure, XDC v2.6.8 provides the foundation for the next generation of blockchain applications.

For technical questions or integration support, join the XDC Developer community on Telegram.