Developers Forum for XinFin XDC Network

Local desktop tool for XDC (transaction signing, keystore + BIP39 support) — feedback welcome

David McDougall — Fri, 03 Apr 2026 18:52:19 +0000

Hello everyone,

I’ve built a desktop tool for interacting with the XDC network and wanted to share it here for feedback/testing.

It focuses on handling everything locally rather than relying on browser wallets or third-party sites.

Current features:

Local transaction signing
Keystore (JSON) generation
BIP39 seed phrase recovery with derivation path support
Address scanning + balance checking
No accounts, no telemetry

The goal is to provide a simple, transparent way to work with XDC directly from a local environment, while reducing reliance on browser wallets.

It’s open source, and releases include SHA256 + PGP verification so everything can be validated before use.

GitHub:
https://github.com/DITES01/xdc-local-desktop-access-tool

Any feedback, testing, or suggestions would be appreciated.

Thanks
David

Cannot access wallet

Retired Farmer — Wed, 01 Apr 2026 20:18:58 +0000

For years I've been using http://ewallet.xinfin.org to view wallet. Today it throws JSON errors and I can't access wallet. I have a 12 word mnemonic phrase and password. Any help would be much appreciated. Thanks!

XDCValidator Contract Upgrade: Modernizing Staking for the Next Era of XDC

Arturo — Tue, 31 Mar 2026 10:03:27 +0000

TL;DR: The XDCValidator contract (0x88) was deployed with Solidity 0.4.21 and has never received a major upgrade. The ecosystem has matured significantly since then. Liquid staking protocols, institutional staking services, and DeFi composability all demand a more flexible validator lifecycle. I'm proposing we use a contract upgrade as an opportunity to modernize the staking/unstaking mechanism, fix accumulated state inefficiencies, and unlock new use cases. Below are three concrete scenarios for community discussion.

Why Now?

The current XDCValidator contract has served the network well, but several realities make an upgrade worth discussing:

Compiler vintage. Solidity 0.4.21 predates significant compiler improvements (SafeMath built-ins, custom errors, overflow checks, ABI encoder v2). Newer Solidity versions offer better gas efficiency, security defaults, and developer ergonomics.
State hygiene. Over the network's lifetime the contract has accumulated storage artifacts (zeroed-out array entries, stale mappings) that waste gas and complicate on-chain queries. A migration is an opportunity for a clean slate.
The "30-day" wall that's actually 35-42 days. The contract uses block-number-based delays set at genesis: candidateWithdrawDelay = 1,296,000 blocks for masternode owners resigning, and voterWithdrawDelay = 432,000 blocks for voters unvoting. These are hardcoded constructor parameters with no governance mechanism to adjust them.

The 2-second block time is a theoretical target, not a guarantee. Real-world data from xdcscan tells a different story:

| Period | Avg block time | Effective owner withdrawal delay |
|---|---|---|
| Theoretical | 2.00s | 30.0 days |
| Last 30 days (Mar 2026) | 2.33s | ~35 days |
| Last 365 days | 2.33s | ~35 days |
| Last 90 days (includes Jan 2026 spikes) | 2.83s | ~42 days |
| Worst days (Jan 11-12, 2026) | 13.6s | Would imply ~204 days if sustained |

In practice, masternode owners resigning today should expect to wait ~35 days under normal conditions, and potentially longer during network congestion events. The block time has never consistently held at 2.00s. The network regularly averages 2.2-2.8s, and periodic spikes (Dec 26: 8.4s, Dec 28-30: 4-5s, Jan 10-12: 5-14s) push the effective delay even further.

For liquid staking protocols, this unpredictability on top of an already long delay is the binding constraint. Protocols must either (a) keep a large idle reserve buffer sized for worst-case timing, (b) force users to wait 35+ days, or (c) route through DEX secondary markets at a discount. All three options erode capital efficiency and hurt adoption.

Important detail: resign() only unlocks the owner's own voter stake, not the full candidacy cap. Other voters who staked on that candidate must separately call unvote() (with a ~12-day effective delay at current block times) to retrieve their funds. withdraw() must be called individually per withdrawal entry (specific blockNumber + index), there is no batch withdrawal.

Ecosystem competitiveness. Other networks have already moved to dynamic or queue-based unstaking:
- Ethereum: epoch-based churn limit (~8 validators/epoch), exit times range from hours to weeks depending on demand
- Polkadot: RFC-0097 introduces dynamic unbonding from 2 days (empty queue) to 28 days (high demand)
- Cosmos: 21-day unbonding with per-block queue maturation
- Avalanche: ACP-273 proposes reducing minimum staking from 14 days to 48 hours

XDC's flat 30 days with zero flexibility is an outlier.

Current Mechanism (Deployed at 0x88)

For context, here's the live on-chain state of the contract, queried via eth_getStorageAt against mainnet RPC and cross-referenced with the verified source on xdcscan:

Contract Parameters (immutable since genesis)

Parameter	Storage slot	On-chain value	Real-world effect
`candidateWithdrawDelay`	`0x0e`	1,296,000 blocks	~35 days at current avg 2.33s/block
`voterWithdrawDelay`	`0x0f`	432,000 blocks	~12 days at current avg 2.33s/block
`minCandidateCap`	`0x0b`	10,000,000 XDC	Stake required to propose a masternode
`minVoterCap`	`0x0c`	25,000 XDC	Minimum vote amount
`maxValidatorNumber`	`0x0d`	18	Genesis relic, consensus layer overrides to 108
Compiler	-	Solidity 0.4.21	No overflow protection, known compiler bugs

Live Network State (queried March 2026)

Metric	Value	Notes
Contract balance	2,580,878,498 XDC (~$80M)	All staked funds held here
`candidateCount`	253	Active candidates registered
`ownerCount`	219	Includes resigned owners who are still counted
`candidates[]` array length	529	Entries ever created (never shrinks)
Active (non-zero) entries	253	47.8% of the array
Ghost (zeroed-out) entries	276	52.2% waste, gas overhead on every enumeration
Consensus active set	108 masternodes	Set by XDPoS v2, not the contract's `maxValidatorNumber`
Current block	~100,783,000	~7.4 years of blocks at avg 2.33s

Withdrawal Flow Today

Owner calls resign(candidateAddress) → isCandidate set to false, owner's own stake scheduled for release at block.number + 1,296,000.
Owner waits ~35 days in practice (1.296M blocks at real-world avg of 2.33s/block, can stretch to 40+ days during congestion spikes).
Owner calls withdraw(blockNumber, index). Must specify the exact block number and array index. No batch withdrawal.
Voters on the same candidate must independently call unvote() → their stake is released after block.number + 432,000 (~12 days actual).

Key Limitations

Block-count based delays, not timestamp-based. The effective wait drifts with block time fluctuations. At the recent 90-day average of 2.83s/block, the owner delay stretches to ~42 days.
No parameter governance. candidateWithdrawDelay and voterWithdrawDelay are constructor-set with no admin function to adjust them.
maxValidatorNumber is stale. Contract says 18, consensus layer uses 108. The parameter serves no active purpose.
ownerCount only increments. resign() does not decrement ownerCount, meaning it includes all historical owners. This inflates the denominator in any governance calculation that uses it.

The Three Scenarios

Scenario A: Three-Tier Exit Queue (Simple & Predictable)

Concept: The withdrawal lock duration depends on how many masternodes are currently pending withdrawal at the time you resign. Three tiers create a clear incentive structure: exits are fast when the queue is light, moderate at normal load, and fall back to the full 30 days only under heavy exit pressure.

Queue depth (pending withdrawals)	Lock duration	Rationale
< 5 nodes	3 days	Low pressure, network is healthy, fast exits are safe
5 - 10 nodes	14 days	Moderate pressure, allow exits but with a buffer
> 10 nodes	30 days	High pressure, full lock to protect network stability

Parameter	Value
Queue model	Real-time count of pending withdrawals
Tier boundaries	5 and 10 (tunable via governance)
Lock assignment	Snapshot at time of `resign()`

How it works:

Validator calls resign().
Contract reads pendingWithdrawalCount (number of validators currently in the withdrawal pipeline).
If < 5 → assign 3-day lock.
If 5-10 → assign 14-day lock.
If > 10 → assign 30-day lock.
Withdraw after lock expires (unchanged).

Why liquid staking loves this: Under normal network conditions, the exit queue rarely has more than a handful of nodes pending at once. A liquid staking protocol operating 20 masternodes could rotate nodes with just a 3-day turnaround, small enough to serve redemptions from a thin buffer without sacrificing yield. When the queue gets crowded, the longer delays kick in automatically, giving the protocol a clear signal to pause redemptions or route to secondary markets.

Trade-offs:

Simple to implement and reason about, just two if checks.
Tier boundaries (5 / 10) need tuning based on network size; could be made governance-adjustable.
Lock is fixed at resign time, so a validator who resigns at queue depth 4 gets 3 days even if 20 more resign in the next block.

Scenario B: Continuous Dynamic Duration Based on Queue Depth (Polkadot-Inspired)

Concept: Instead of hard tiers, the lock duration scales smoothly between a floor and ceiling based on the number of masternodes currently pending withdrawal. Below 5 nodes the lock approaches its minimum; above 10 it ramps toward the maximum; and it caps at 30 days.

Parameter	Value
Minimum lock (0 nodes pending)	2 days
Maximum lock (≥ 10 nodes pending)	30 days
Fast zone	< 5 nodes pending → 2-7 days
Transition zone	5-10 nodes pending → 7-30 days
Scaling curve	Linear between breakpoints (or sigmoid for smoother UX)

Formula:

if pendingNodes < 5:
    lockDays = 2 + (pendingNodes * 1)            // 2d → 6d
else if pendingNodes <= 10:
    lockDays = 7 + (pendingNodes - 5) * 4.6      // 7d → 30d
else:
    lockDays = 30                                  // hard cap

How it works:

Validator calls resign().
Contract reads pendingWithdrawalCount.
Lock duration is computed from the formula above.
Assign lockDuration to this withdrawal entry.
Withdraw after lock expires (unchanged).

Example at current network size (~108 active masternodes):

Nodes currently pending withdrawal	Lock duration	Zone
0	2 days	Fast
1	3 days	Fast
2	4 days	Fast
4	6 days	Fast
5	7 days	Transition
7	16 days	Transition
10	30 days	Cap
15	30 days	Cap

Why liquid staking loves this: In the common case (1-3 nodes cycling out), the lock is 2-5 days. A liquid staking protocol can keep a minimal reserve buffer and serve redemptions almost in real-time. The smooth curve also means there's no "cliff" at a tier boundary. Protocols can forecast lock times with a simple view function call before deciding whether to initiate a withdrawal.

Trade-offs:

Slightly more complex than tiered (requires on-chain math), but still a single storage read + arithmetic.
Lock duration isn't known until the moment of resignation (though a previewLockDuration() view function makes this transparent).
Elegant security guarantee: if many nodes rush to exit, the lock automatically stretches to 30 days, protecting the network without any governance intervention.

Scenario C: Adaptive Churn Limit with FIFO Queue (Ethereum-Inspired)

Concept: Validators enter a FIFO exit queue on resign(). The network processes exits at each epoch boundary, but the processing speed adapts based on queue depth: fast when the queue is short, throttled when it's deep.

Queue depth	Exits processed per epoch	Post-queue lock	Effective behavior
< 5 nodes	5 per epoch (drain immediately)	48 hours	Near-instant: queue clears in one epoch
5 - 10 nodes	2 per epoch	48 hours	Moderate: queue drains over several epochs
> 10 nodes	1 per epoch	7 days	Slow: deliberate pacing + extended lock

Parameter	Value
Queue model	FIFO, processed at epoch boundary
Epoch duration	900 blocks (~30 min at 2s blocks)
Churn rate adapts every	Epoch (re-evaluated based on current queue depth)

How it works:

Validator calls resign() → enters the exit queue with a sequence number. Post-lock duration is assigned at this point based on current queue depth.
At each epoch boundary, the contract reads the current queue depth and processes exits accordingly.
If queue < 5 → process up to 5 exits this epoch. Post-lock for new resignations: 48 hours.
If queue 5-10 → process up to 2 exits this epoch. Post-lock for new resignations: 48 hours.
If queue > 10 → process only 1 exit this epoch. Post-lock for new resignations: 7 days.
Withdraw after post-lock expires.

Note: the churn rate adapts as the queue drains. A queue of 25 doesn't process at 1/epoch the whole time. Once it drops below 10, it speeds up to 2/epoch, then 5/epoch below 5.

Example queue scenarios (traced through adaptive processing):

Queue depth at resign	Post-lock (fixed at resign)	Queue drain breakdown	Total estimated time
0 (you're the only one)	48h	1 epoch (~30min)	~2 days
3 (light traffic)	48h	1 epoch, all 4 clear at 5/epoch	~2 days
7 (moderate)	48h	3 epochs at 2/epoch, then 1 at 5/epoch = 4 epochs (~2h)	~2 days
12 (heavy)	7 days	3 at 1/epoch → 3 at 2/epoch → 1 at 5/epoch = 7 epochs (~3.5h)	~7 days
25 (extreme)	7 days	16 at 1/epoch → 3 at 2/epoch → 1 at 5/epoch = 20 epochs (~10h)	~7.5 days

Why liquid staking loves this: Under normal conditions (1-4 nodes exiting), the entire queue flushes in a single epoch and exit time is just 2 days. The protocol can predict its exact queue position and calculate withdrawal timing deterministically. When exit pressure rises, the system automatically shifts to a more conservative pace, giving protocols a clear signal to adjust their redemption flow.

Trade-offs:

Most complex to implement (requires epoch hooks or a keeper-based trigger + adaptive rate logic).
The dual lever (churn rate + post-lock duration) gives fine-grained control but adds cognitive overhead.
When the queue is deep (> 10), exit times are still dramatically better than the current 30 days, but the 7-day post-lock provides a meaningful security buffer.
Churn rate boundaries (5 / 10) should be governance-adjustable as the network grows.

Additional Upgrade Opportunities

Since we'd be touching the contract anyway, it would be worth bundling other improvements:

Compiler upgrade to Solidity ≥0.8.x (built-in overflow protection, custom errors, gas optimizations)
Array compaction for the candidates list (eliminate zeroed entries, reduce gas for enumeration)
Event coverage for all state-changing operations (currently some paths emit no events)
ownerCount bookkeeping to accurately reflect the active validator set
Withdrawal batching. Currently withdraw(blockNumber, index) requires one call per entry; a withdrawAll() that claims all mature entries in a single transaction would drastically improve UX
View functions for queue position, estimated lock duration, pending withdrawal count, and total exiting stake
Timestamp-based delays instead of block-count, decoupling the lock period from block time fluctuations
KYC flow improvements with proper access control and state management
SafeMath / overflow protection for all arithmetic (native with 0.8.x)

Comparison Matrix

Feature	Current XDC	Scenario A (3-Tier)	Scenario B (Dynamic Curve)	Scenario C (Adaptive Churn)
Min unlock (< 5 pending)	~35d actual (1.296M blocks)	3 days	2 days	~2 days
Moderate unlock (5-10 pending)	~35d actual (1.296M blocks)	14 days	7-30 days	~2 days (queue wait + 48h)
Max unlock (> 10 pending)	~35d actual (1.296M blocks)	30 days	30 days	~7-7.5 days (queue wait + 7d)
Delay type	Block-count (drifts with block time)	Timestamp-based	Timestamp-based	Epoch + timestamp
Voter delay	~12d actual (432K blocks)	Unified with owner	Unified with owner	Unified with owner
Batch withdrawal	No (per-entry)	Yes	Yes	Yes
Predictability	Fixed	Very high (3 tiers)	Medium (continuous)	High (position-based)
Liquid staking friendly	Poor	Good	Very good	Excellent
Implementation complexity	-	Low	Low-Medium	Medium-High
Security under mass exit	Same 30d always	Full 30d fallback	Scales to 30d automatically	Throttled churn + 7d post-lock
Consensus layer changes	No	No	No	Possibly (epoch hooks)

What I'd Like to Hear From the Community

Which scenario resonates most with how you think XDC should evolve?
Are there hybrid approaches? For example, Scenario B (dynamic duration) + Scenario C (churn limit) combined.
What's the right security floor? Is 48 hours too aggressive for the minimum lock? Should it be 7 days?
Upgrade mechanism. Should this be a full contract migration with state transfer, or an upgradeable proxy pattern going forward?
Backwards compatibility. How do we handle existing stakers and pending withdrawals during migration?

The 30-day fixed lock was a reasonable default at launch, but the XDC ecosystem has outgrown it. Liquid staking, institutional staking services, and DeFi protocols all need a more dynamic validator lifecycle. Let's design it together.

References:

Nexus OrderBook DEX Apothem Testnet Launch

NEXUS — Mon, 30 Mar 2026 22:09:44 +0000

🚀 We're excited to launch the first fully on-chain orderbook DEX built on XDC Apothem Test Network — and we need your help to test it!

What makes Nexus Orderbook DEX different?
Most "DEXs" use AMM liquidity pools (like Uniswap). Nexus runs a real limit orderbook entirely on-chain — every order, match, and trade is executed by smart contracts, with no off-chain components other than a data indexer for chart/candlestick data. This is only possible on XDC thanks to its 500M gas block limit, speed, and efficiency — orders of magnitude beyond typical Ethereum limits — which makes complex on-chain matching economically viable.

What you can do:
-Place limit & market orders
-Create your own trading pairs
-Earn maker rebates & pay tight taker fees
-View real-time charts, depth, and trade history
-We need testers!
-We're currently live on XDC Apothem Testnet (free test tokens via the Faucet tab). Your feedback helps us find bugs and fine-tune the experience before we launch on XDC Mainnet at some point in the future.

👉 Try it now at this url: https://trade.thenexusportal.io/

Connect your wallet, grab some TXDC and test tokens from the faucet steps, and start trading. Drop any bugs or feedback, every test helps get us closer to a mainnet launch.

How to Host an XDC Masternode Using Fireblocks via WalletConnect (Step-by-Step Guide)

XinFin XDC Network — Tue, 24 Mar 2026 09:13:40 +0000

Running a Masternode on the XDC Network requires staking 10,000,000 XDC, completing KYC, and securely managing validator funds.

For institutions and enterprises, using Fireblocks via WalletConnect v2 provides institutional-grade custody, governance automation, and transaction policy control.

This guide walks through the complete process using your referenced application flow and screenshots.

Why Use Fireblocks for XDC Masternode Hosting?

Fireblocks is an institutional digital asset custody and operations platform used by exchanges, fintechs, funds, and enterprises.

Multi-Layer Security

1️⃣ MPC-CMP Wallet Technology

Private keys are split into encrypted shares.
No single entity ever holds the full private key.
Eliminates single-point key compromise risk.

2️⃣ Secure Hardware (Intel SGX)

Signing operations occur inside secure enclaves.
Protects against malware and insider threats.

3️⃣ Policy Engine – Automated Governance Controls

The Policy Engine automates governance policies for transaction rules and admin approvals.
It allows you to configure rules that dictate how transactions are handled and approved.

You can define rules to:

Automatically approve transactions
Block transactions
Require additional signers

Rules can be applied using filters such as:

Transaction amount thresholds
Smart contract interaction
Specific destination addresses

Policy Engine rules can be configured for:

Internal wallets
Network connections
Exchanges
Fiat providers
Whitelisted addresses
Smart contract wallets

This is extremely valuable for Masternode staking because:

Large 10M XDC deposits can require multi-admin approval
Only approved validator contracts can be interacted with
Unstaking can require additional governance checks

4️⃣ Admin Quorum & MFA

Multi-admin approval workflows
Role-based access control
Multi-factor authentication enforcement
This makes Fireblocks ideal for institutional masternode operators.

Prerequisites Before Starting

Before beginning:

Fireblocks workspace with Web3 Wallet enabled
Minimum 10,000,000 XDC in your Fireblocks vault
Masternode server deployed and coinbase address generated
KYC document in PDF format

Masternode Application URLs:

Mainnet: https://mn.xinfin.network
Testnet: https://mn.apothem.network

Step-by-Step: Host XDC Masternode via Fireblocks

STEP 1: Open Masternode Application & Select WalletConnect v2

Visit the Masternode App.
Click Login (top right corner).

On the login page:

Under Network Provider, select: WalletConnect v2
Click Save

This initiates a WalletConnect session.

STEP 2: Scan QR Code with Fireblocks

After selecting WalletConnect:

A QR code window appears labeled Fireblocks
You will see:

Mobile / WebApp toggle
QR Code
“Scan this QR Code with your phone”

Action:

Open Fireblocks Web3 Wallet (Mobile App or Web UI)
Scan the QR code
Approve session request

This connects your Fireblocks vault to the XDC Masternode dApp.

STEP 3: Connect Vault to dApp

After scanning:
A popup appears: Connect vault to dApp

You will see:

Vault Account dropdown
Blockchain selection
Default fee rate (Medium / Fast)

Action:

Select the correct Vault account containing 10M+ XDC
Confirm Blockchain (XDC Network)
Click Connect Vault

Now your Fireblocks wallet is connected to the Masternode app securely via WalletConnect v2.

STEP 4: Click “Become a Candidate” & Stake 10,000,000 XDC

After successful login:

Click Become a candidate (top right)

You will now see the Masternode staking interface.

Inside the “Become a MasterNode” panel, You will see:

Minimum requirement: 10,000,000 XDC
Deposit will be locked
Stake field (pre-filled 10,000,000)
TX fee displayed

⚠️ The deposit will be locked as part of validator staking.

Now, In the highlighted section, You must enter:
Coinbase Address

This is your node’s validator address, generated when setting up your masternode server.

Example format:
xdc……………………………………b

⚠️ Important:

This is NOT your Fireblocks wallet address
It is your masternode server’s coinbase address

Once Stake amount confirmed & Coinbase address entered, Click on the Apply button.

STEP 5: Approve Transaction in Fireblocks

Once Apply is clicked:

Fireblocks will prompt a transaction approval

Depending on Policy Engine rules:

It may auto approve
It may require multiple signers
It may require admin quorum

Approve transaction securely.

STEP 6: Transaction Confirmation

After approval:

Transaction is broadcast to XDC Network
You will receive a transaction hash
Stake becomes locked
Node enters validator candidate pool

You can verify transaction on:
https://xdcscan.com

What Happens Next?

After staking:

Your masternode enters validator selection cycle
Once approved in an epoch
It becomes active validator
Begins earning rewards

Why Fireblocks is Ideal for Institutional Masternodes

Using Fireblocks provides:

Institutional custody of 10M+ XDC stake
Governance enforcement through Policy Engine
Multi-signature style MPC security
Hardware-enclave signing
Vault-level segregation of validator funds
Controlled unstaking workflows

This reduces operational and governance risk significantly compared to browser wallets.

Useful Links

Disclaimer

This article is intended strictly for educational and informational purposes only. It does not constitute financial, investment, or legal advice.

Running a masternode on the XDC Network, including staking requirements and infrastructure setup, involves technical, operational, and financial considerations. Readers are encouraged to conduct their own research (DYOR) and consult with qualified professionals before making any decisions related to digital assets or blockchain participation.

The mention of platforms such as Fireblocks or technologies like WalletConnect is for informational purposes only and does not imply endorsement.

By following this guide, you acknowledge that any actions taken are at your own risk.

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