Developers Forum for XinFin XDC Network

Tokenizing the Cacao Trade

XDC Foundation — Thu, 07 May 2026 13:13:50 +0000

The Opportunity

Tokenization has matured rapidly over the past several years, but the momentum has been concentrated in a familiar place—traditional financial instruments. Tokenized funds, treasuries, and credit products dominate the conversation because their underlying assets are already structured, verified, and widely trusted. The plumbing for moving such instruments on-chain has improved dramatically.

What remains less developed is the foundation beneath tokenized assets, particularly when those assets originate in the physical economy. Commodities, shipments, and receivables are defined by documents, provenance, and multi-party verification. A bag of cacao does not become a tokenized receivable simply because someone says it does. It becomes one when the farm that grew it, the shipment that carries it, the contract that sells it, and the buyer that receives it can all be traced and trusted.

Substantial progress has been made digitizing trade documents themselves. The unresolved gap, however, lies in connecting those documents to tokenized financial products in a way that is verifiable, trusted, and usable in real trade finance workflows. This straightforward but consequential observation became the focus of the pilot described below.

Participants

The pilot brought together four organizations, each contributing a distinct layer of the workflow. Together they form a stack in which physical provenance, commercial activity, financial structuring, and on-chain settlement are linked rather than siloed.

Process, Flows, and Outcomes

The workflow began at the ground level. Blockticity issued farm-level Certificates of Authenticity (COAs) for the licensed cacao farms supplying the crop. These COAs established an on-chain record of the upstream production sources behind the shipment — an auditable foothold tying the eventual financial instrument back to specific, verified producers.

After Seedcore sourced and consolidated cacao from those verified farms, Blockticity issued a shipment-level COA for the export batch. That shipment COA referenced the underlying farm COAs and linked the cacao consignment to its origin, supplier, buyer, contract details, and related trade documentation. The result was a single on-chain record that resolved cleanly from farmer to export shipment.

In parallel, XDC Foundation worked with Brickken to establish the financial layer. The authenticated COA and supporting trade documents were uploaded to Brickken's platform as part of the offering setup, and the required onboarding and compliance steps were completed there so the offering could be created and tested. From there, a tokenized receivable was deployed on the XDC Network, supported by the authenticated documentation tied to the underlying cacao shipment. Investors onboard to the Brickken platform, which also manages the lifecycle of the tokenized asset.

The Connection That Mattered

The defining feature of the pilot was the relationship between the two layers. Rather than duplicating data or bridging assets directly, the tokenized asset on XDC referenced authenticated records created by Blockticity. This allowed participants to review and verify the link between the financial instrument and the underlying cacao shipment before participating — a meaningful shift from the typical pattern, in which investors must take provenance largely on faith.

The Workflow, Step by Step

To make the orchestration easier to follow, the pilot can be viewed as a sequence of connected steps. Each participant played a specific role in moving the process from verified cacao provenance to a tokenized trade finance asset on XDC Network.

Verifying cacao farms. Blockticity issued farm-level COAs for the licensed cacao farms thatsupplied the crop.
Shipment formation. Seedcore sourced cacao from those verified farms and consolidatedit into an export shipment.
Shipment-level COA. Blockticity created a shipment-level COA that referenced the farmCOAs and connected the shipment to its origin, supplier, and supporting trade documents.
Issuer onboarding. Seedcore onboarded to the Brickken platform as an asset issuer andcompleted the required compliance steps.
Tokenized receivable on XDC. Certificates of Authenticity and receivables documents wereused to deploy the tokenized asset on XDC.
Investor verification. Participants could review the authenticated records and verify theconnection between the financial instrument and the underlying cacao shipment.

Conclusion

For years, real-world asset tokenization has been held back by an unspoken assumption: that the gap between paper-based, multi-party trade processes and on-chain financial instruments is too messy to bridge in any reproducible way. This pilot demonstrates otherwise.

Three outcomes stand out. First, provenance and finance were joined without being conflated. Blockticity's COAs did not become the receivable; they grounded it. The tokenized asset on XDC referenced authenticated records rather than re-creating them, preserving the integrity of each layer while making the link verifiable to anyone. Second, the workflow was navigable for every participant. A Philippine cacao exporter, an authenticity provider, a tokenization platform, and a Layer 1 network operated through their existing tools and obligations — including ASTM and EUDR-aligned authentication and platform-level compliance — rather than reorganizing around new ones. Third, the value proposition for the upstream economy is direct. When a smallholder farm's licensed status is anchored on-chain, and a shipment built from those farms backs a verifiable receivable, capital can move toward producers with materially less friction and materially more trust.

What the pilot proves is that the missing layer in real-world asset tokenization is not better tokens or faster chains, but verifiable connective tissue between physical commodities and the financial instruments that represent them. Brickken structures the offering, Seedcore anchors the commercial reality, and Blockticity certifies the underlying truth. XDC Network makes that connectivity load-bearing — a trade-finance-optimized Layer 1 where provenance records and financial instruments can reference each other natively, without translation.

The blueprint extends well beyond cacao. Coffee, cocoa, coconut, timber, fisheries, agricultural receivables, and shipment-backed credit all share the same foundational requirement — and now share a working pattern for meeting it.

Problems running RPC nodes

king aaron — Thu, 07 May 2026 07:56:26 +0000

Is it normal to use snapshots to synchronize RPC nodes and generate normal logs?

Starting nodes with enode://2c19c70a9c4134936926bbf1 .......................... WARN [05-07|15:02:43.394] The flag XDCx-datadir or XDCx.datadir is deprecated, please remove this flag WARN [05-07|15:02:46.445] Head state missing, repairing chain number=101,599,567 hash=9df8cf..c991b8 WARN [05-07|15:02:47.694] [initial] initial v2 related parameters WARN [05-07|15:02:47.702] [initial] miner wait period period=2 WARN [05-07|15:02:47.703] [initial] finish initialisation

How long should this phase take? I haven't seen any new logs for an hour, and I'm starting to doubt if it's even working.

I set it up using Docker, following this setup: https://www.xdc.dev/ruslan_wing/setting-up-an-rpc-node-server-for-your-dapp-on-xdc-network-a-comprehensive-guide-3dm9

[Informative] April Insights: Key Highlights and Developments from Plugin’s Journey

Pooja Balaji — Wed, 06 May 2026 19:29:24 +0000

Another month, another wave of progress in 2026. Plugin continues to deliver on its promise of building robust, reliable blockchain infrastructure while pushing on-chain innovation to new heights. Here's what's new.

📰 News

⛓️Expanding On-Chain Data Coverage

PluginDON is setting a new benchmark for on-chain data integration, purpose-built for Real World Assets on the XDC Network. Price feeds were just the starting point, the vision has always been something far greater.

We are proud to announce the successful completion of a Proof of Concept that validates how RWA data can be seamlessly brought from off-chain sources onto the blockchain, unlocking richer and more transparent on-chain intelligence than ever before.

Building on this milestone, we are now broadening on-chain coverage to capture the complete picture around RWA tokens

Here's what's now covered :

● Holder Distribution
● Transfer Activity
● Total Supply
● Market Capitalization

This expansion strengthens PluginDON’s role in bridging real-world financial data with decentralized infrastructure.

⚙️PluginDON CCIP: Binance Integration Update

Following the initial CCIP expansion phase, current work is focused on establishing secure RPC interoperability between XDCNetwork and Binance-linked infrastructure.

Key focus areas this month include:
● RPC routing and endpoint compatibility analysis
● Cross-chain message verification design
● Infrastructure-level security hardening
● Node communication protocol alignment

This phase represents a shift from conceptual expansion to technical implementation planning.

🔄 Plugin VRF Update: Enhanced Timeout Mechanism

As part of ongoing improvements to the Plugin VRF system, we are introducing an expanded timeout mechanism to improve request reliability and reduce pending states.

With this update, the node response window will be extended, ensuring that VRF requests are not left stuck in a pending state due to temporary delays or network conditions.

What’s improving:
● Expanded timeout window for VRF requests
● Reduced risk of requests remaining in pending state
● Improved reliability of random number fulfillment
● More resilient node response handling

🍽️ Food for Thought:

Real-world assets are only as trustworthy as the data that represents them. Bridging the physical and digital isn't just about tokenization, it's about ensuring every data point, from ownership to market movement, is verifiable and tamper-proof. In a world where trust is the scarcest resource, on-chain transparency isn't a feature. It's the foundation.

🧠 Plugin Quiz:

What is the purpose of RPC in blockchain infrastructure?

👉 Reply with your answer in the comments!

Understanding the XDC Network Slashing Mechanism: Ensuring Network Stability

Rushabh Parmar — Tue, 05 May 2026 06:23:02 +0000

Introduction

The XDC Network, powered by its XDC 2.0 consensus mechanism, employs a slashing mechanism to maintain network stability and ensure validator accountability. Unlike punitive slashing systems in other blockchains, XDC's approach focuses on corrective measures that balance network efficiency with fairness to node operators.

This article explores how slashing works, its impact on network performance, and practical solutions for masternode operators to avoid slashing events.

Why Slashing is Critical for Network Performance

The Timeout Problem

In XDPoS, masternodes create blocks in a round-robin fashion. When a masternode fails to create a block during its designated turn, the entire network experiences a 10-second timeout before the next masternode proceeds.

Impact Example:

If 27 masternodes (25% of the 108-node network) are underperforming:

Wasted time per epoch: 27 nodes × 6 average turns × 10 seconds = 1,620 seconds
Normal epoch duration: 1,800 seconds
Performance degradation: 47.4%
Network throughput: Reduced from 2,000+ TPS to ~1,050 TPS

Without slashing, these underperforming masternodes would continue degrading network performance indefinitely. With slashing, the network automatically excludes them, restoring full operational efficiency.

How XDC Slashing Works

The Slashing Trigger

Primary Condition: A masternode that fails to sign any block during an entire epoch (900 blocks) will be slashed.

The system evaluates complete inactivity over an epoch, not isolated missed blocks. This prevents false positives from temporary network hiccups while identifying genuinely unresponsive masternodes.

The Slashing Cycle

Phase 1: Performance Monitoring

Each epoch consists of 900 blocks (approximately 30 minutes):

Epoch N (900 blocks, ~1800 seconds)
├── Masternodes take turns creating blocks
├── Block Signer smart contract records all signatures
└── Block 900 (Checkpoint): Performance evaluation

Phase 2: Detection and Slashing

At the checkpoint block:

for each masternode M in MasternodeSet {
    signatures = BlockSigner.getSignatureCount(M, currentEpoch);

    if (signatures == 0) {
        slashMasternode(M);
        addToSlashedList(M, currentEpoch + 4);
    }
}

Key Point: Zero signatures = automatic slashing. Partial participation = no slashing.

Phase 3: Exclusion Period (4 Epochs)

Once slashed, a masternode enters a 4-epoch exclusion period (~2 hours):

Epoch N: Masternode slashed (0 signatures)
├── Epochs N+1 to N+4: Excluded from block creation
│   └── Can still verify/sign blocks created by others
└── Epoch N+5: Eligible for reinstatement

During Exclusion:

Cannot create blocks
Can verify and sign blocks (demonstrates liveness)
This activity is required for recovery

Phase 4: Automatic Reinstatement

After 4 epochs, the masternode automatically rejoins if:

It signed blocks during the exclusion period
Stake remains locked in the smart contract
No additional slashing events occurred

Byzantine Fault Tolerance and Network Safety

The XDC Network maintains Byzantine Fault Tolerance through its 75% finality requirement:

BFT Parameters:

Finality requires: 81 validator signatures (75% of 108)
Network tolerates: Up to 27 faulty/offline masternodes
Critical threshold: If 28+ masternodes are slashed, finality becomes impossible

Slashed Nodes	Active Nodes	BFT Status
0-10	98-108	✅ Excellent
11-27	81-97	✅ Safe
27	81	⚠️ Critical
28+	<81	❌ Broken

Double Validation Integration

XDC's slashing mechanism integrates with its Double Validation system:

How It Works:

Block Creator: Creates block per round-robin schedule
Block Verifier: Randomly selected to verify and co-sign
Finalization: Requires both signatures

Slashing Impact:

Slashed masternodes are excluded from block creator rotation
Can still participate as random block verifiers
Allows demonstration of liveness for recovery

Solutions to Avoid Slashing

Alternative: Third-Party Masternode Services

If you do not have the technical resources, infrastructure, or time to maintain a masternode yourself, there are several third-party services and volunteers willing to provide professional masternode hosting and management services. These providers handle all technical aspects including:

Infrastructure setup and maintenance
24/7 uptime management
Security hardening and updates
Failover and redundancy
Technical support and troubleshooting

Available Third-Party Services:

IndSoft - Professional masternode hosting
NODE FORGE - Managed validator services
Zeeve - Enterprise blockchain infrastructure
BlockDaemon - Institutional-grade node operations
Tatum - Blockchain infrastructure platform
NOWNodes - Node hosting and API services
Asternodes - Validator management services
Ankr - Decentralized node infrastructure
thirdweb - Web3 infrastructure provider
GOLDSKY - Blockchain data infrastructure

Important Considerations:

When selecting a third-party service provider:

Research their track record and uptime history
Understand their fee structure
Verify their security practices
Check their support responsiveness
Review client testimonials
Ensure they have experience with XDC Network

DISCLAIMER: XDC Network does not officially endorse any third-party services. Please perform due diligence and research before proceeding with any service provider. You remain responsible for your staked XDC and masternode performance.

For Self-Hosted Masternodes:Infrastructure Requirements

Hardware Specifications

Minimum Requirements:

CPU: 12+ core
RAM: 32 GB
Storage: 2 TB NVMe SSD
Network: 100 Mbps (1 Gbps recommended)

Why This Matters:

Insufficient CPU → slow block processing
Insufficient RAM → system swapping and delays
HDD instead of SSD → missed signing windows
Unstable network → failed peer communication

Network Infrastructure

Critical Requirements:

Static Public IP (mandatory)
99.99%+ uptime SLA (use tier-3+ data centers)
DDoS protection
Low latency (<100ms to network peers)
Redundant connectivity

1. Proper Node Setup

Follow the official setup guide:

Repository: https://github.com/XinFinOrg/XinFin-Node

Setup Steps:

# Clone the official repository
git clone https://github.com/XinFinOrg/XinFin-Node
cd XinFin-Node

# Run the setup script
./setup.sh

# Key configuration parameters:
# - Static IP address
# - Port 30303 open for P2P
# - Proper keystore and password
# - Adequate system resources

Essential Configuration:

--syncmode "full": Complete blockchain sync
--mine: Enable block creation
Firewall: Open port 30303, restrict RPC access

2. Implement Hot Standby Architecture

Setup:

┌─────────────────────┐         ┌─────────────────────┐
│  Primary Masternode │         │  Hot Standby Node   │
│  - Active mining    │◄───────►│  - Synced, ready    │
│  - Signing blocks   │         │  - Not mining       │
└─────────────────────┘         └─────────────────────┘

Critical Rules:

Never run both nodes with same key simultaneously (causes double-signing → 100% rewards loss)
Keep standby fully synced at all times
Document failover procedure
Practice failover monthly
Target failover time: <5 minutes

3. Regular Maintenance

Update Schedule:

Critical patches: Within 24 hours
Protocol upgrades: Per XDC Team announcements
Regular updates: Monthly maintenance windows

Planned Maintenance:

# Update procedure
cd XinFin-Node && git pull origin master
docker-compose up -d

# Restart (target: <10 minutes downtime)
docker-compose down
docker-compose up -d

# Verify node is signing blocks within 5 minutes

4. Security Hardening

Firewall Configuration:

# Basic firewall setup
ufw default deny incoming
ufw default allow outgoing

# Allow P2P (essential)
ufw allow 30303/tcp

# Allow RPC only from localhost
ufw allow from 127.0.0.1 to any port 8545

# Allow SSH from trusted IPs only
ufw allow from YOUR_ADMIN_IP to any port 22

ufw enable

Key Protection:

Use strong passwords (25+ characters)
Store keys in encrypted files with restricted permissions (chmod 600)
Never store unencrypted private keys on servers

5. Verify Network Connectivity

Check Peer Connections:

# Check peer count (should be >10)
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'admin.peers.length'

# Add peers manually if needed
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'admin.addPeer("enode://PEER_ID@IP:PORT")'

Target: Maintain 15-30 peer connections for optimal resilience.

6. Ensure Continuous Sync

Verify Sync Status:

# Check current block number
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'eth.blockNumber'

# Compare to network: https://xinfin.network

# Check sync status
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'eth.syncing'
# Should return "false" if fully synced

Action Guidelines:

<10 blocks behind → Monitor
10-100 blocks behind → Check peers and connectivity
>100 blocks behind → Investigate immediately, may need restart

7. Pre-Launch Checklist

Before activating your masternode:

Hardware meets recommended specifications
Static IP configured and tested
Node deployed from official repository
Full blockchain sync completed
Firewall configured correctly
Hot standby node synced
Failover procedure documented and tested
Keys secured properly
10,000,000 XDC staked
KYC completed

8. Daily Operational Checks

Daily:

Verify sync status (within 10 blocks)
Check peer count (>10 peers)
Review system logs for errors

Weekly:

Verify standby node is synced
Test failover readiness
Check for software updates

Monthly:

Update node software
Test complete failover
Security audit
Backup configurations

Recovery After Slashing

If your masternode gets slashed, follow this recovery process:

Step 1: Confirm Slashing (5 Minutes)

Check your status:

Visit https://xdcscan.com
Enter your masternode address
Verify epoch performance shows 0 signatures

Step 2: Diagnose Root Cause (30 Minutes)

Issue	Check	Solution
Node offline	Service status	Restart service
Out of sync	Sync progress	Wait for completion
No peers	Peer count	Add peers manually
Disk full	Disk usage	Clear space
Memory issues	System resources	Restart, upgrade RAM

Step 3: Fix the Issue (1 Hour)

Restart Node:

docker-compose restart
docker-compose logs -f --tail 100

# Verify sync resumption
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'eth.syncing'

Add Peers:

# Check firewall
ufw status

# Verify P2P port
netstat -tuln | grep 30303

# Add peers
bash peer.sh

Step 4: Demonstrate Liveness (4 Epochs)

During the 4-epoch exclusion:

Your node can verify and sign blocks (even though it can't create them)
This demonstrates operational status
Target: Sign >50% of blocks during exclusion

Step 5: Automatic Reinstatement (Epoch N+5)

Your masternode automatically rejoins if:

You signed blocks during exclusion
Stake remains locked
No additional slashing occurred

Verify Recovery:

Node creates blocks again within first few hundred blocks of epoch N+5
Check your signatures in Block Signer contract
Confirm address in active masternode list

Best Practices Summary

Do's ✅

Use tier-3+ data centers or reputable cloud providers
Maintain a fully synced hot standby node
Follow official setup guide: https://github.com/XinFinOrg/XinFin-Node
Keep software updated with security patches
Use strong security practices (firewall, key protection)
Verify sync status daily
Document all procedures
Test failover monthly
Maintain adequate system resources
Keep >10 peer connections

Don'ts ❌

Never run two nodes with same key simultaneously
Don't use unreliable infrastructure
Don't ignore software updates
Don't skip regular maintenance
Don't store unencrypted private keys
Don't let node fall >100 blocks behind
Don't operate without failover plan
Don't use insufficient hardware
Don't neglect firewall configuration
Don't skip pre-launch checklist

Conclusion

The XDC Network's slashing mechanism maintains network stability through:

Correction over punishment - Technical issues allow recovery
Transparent enforcement - Automated via smart contracts
Network efficiency - Excludes underperforming nodes to maintain throughput
Byzantine fault tolerance - Ensures security up to 25% faulty nodes

Key Takeaways

For Prevention:

Robust infrastructure eliminates slashing risk
Proper configuration and maintenance are critical
Hot standby provides failover capability
Regular checks catch issues early

For Recovery:

Slashing is temporary, not permanent
Demonstrate liveness during exclusion
Automatic reinstatement after 4 epochs
Fix root cause to prevent recurrence

By following these guidelines, masternode operators can avoid slashing while contributing to a stable, high-performance XDC Network.

Resources

Masternode Setup: https://github.com/XinFinOrg/XinFin-Node
Documentation: https://docs.xdc.network
Network Explorer: https://xdc.blocksscan.io/
Technical Whitepaper: https://xinfin.org/docs/whitepaper-tech.pdf
Community: https://xdc.dev
Telegram: https://t.me/xinfintalk

Integrating AI with Smart Contracts on XDC Network

Rushabh Parmar — Sat, 02 May 2026 05:44:09 +0000

🎯 What You Will Build

In this guide you will manually deploy a real, working AI-powered smart contract on XDC Apothem Testnet step by step. Here is the contract we deployed live while writing this article:


Contract Address	`0xE031843227668f530DC0E59Bb093ED6763Dcd84D`
Deploy TX	`0x7fa75b52...c7843`
Loan Application TX	`0xe95ba331...4387`
AI Score Submission TX	`0xcf230923...edf9`
Network	XDC Apothem Testnet (Chain ID 51)
AI Score	711 / 1000
Risk Category	MEDIUM
Decision	✅ APPROVED

You can verify every transaction right now on XDCScan Testnet.

Introduction

Blockchain and Artificial Intelligence are two of the most transformative technologies of our time. Separately they are powerful. Together they unlock entirely new possibilities — smarter contracts, automated decision-making, and decentralized intelligence.

XDC Network is a perfect platform for this combination:

EVM compatible — write contracts in Solidity, use standard tools like Hardhat
Near-zero gas fees (~$0.00001 per transaction)
2-second finality — AI decisions confirmed almost instantly
2,000 TPS — scales to high-frequency AI-triggered actions

What Are We Building?

An AI-Powered Loan Approval System — a real-world pattern used in trade finance and credit scoring:

[ User calls applyForLoan() on-chain ]
              ↓
[ AI model analyzes applicant off-chain ]
              ↓
[ Oracle submits credit score on-chain ]
              ↓
[ Contract automatically APPROVES or REJECTS ]
              ↓
[ Decision is permanent and publicly verifiable ]

This is called the oracle pattern — the standard way to connect AI (off-chain) with smart contracts (on-chain). The AI runs off-chain because it is too expensive to run ML models on-chain. A trusted "oracle" wallet then submits the result to the smart contract.

Prerequisites

Tool	Version	Install
Node.js	v18+	nodejs.org
Python	v3.10+	python.org
MetaMask	Latest	metamask.io
Git	Any	git-scm.com

Step 1 — Add XDC Apothem Testnet to MetaMask

Open MetaMask → Settings → Networks → Add Network and fill in:

Field	Value
Network Name	XDC Apothem Testnet
RPC URL	`https://erpc.apothem.network`
Chain ID	`51`
Currency Symbol	`TXDC`
Block Explorer	`https://testnet.xdcscan.com`

Then get free test XDC from the faucet:

👉 https://faucet.apothem.network

Important: You need two wallets for this tutorial — one as the Deployer (contract owner) and one as the Oracle (the AI result submitter). Create both in MetaMask and fund both from the faucet.

Step 2 — Set Up the Project

Open your terminal (Command Prompt on Windows) and run:

mkdir xdc-ai-demo
cd xdc-ai-demo
npm init -y
npm install --save-dev hardhat@2.22.19 @nomicfoundation/hardhat-ethers@3 ethers@6 dotenv --legacy-peer-deps

Once installed, initialise Hardhat:

npx hardhat init

When prompted, select "Create a JavaScript project" and accept all defaults.

Step 3 — Configure Hardhat for XDC Apothem

Create a .env file in the root of your project — never commit this to Git:

DEPLOYER_KEY=your_deployer_private_key_here
ORACLE_KEY=your_oracle_private_key_here

To export a private key from MetaMask: click your account → Account Details → Export Private Key. Use test-only wallets only.

Add .env to .gitignore:

echo ".env" >> .gitignore

Now update hardhat.config.js:

require("@nomicfoundation/hardhat-ethers");
require("dotenv").config();

module.exports = {
  solidity: "0.8.20",
  networks: {
    apothem: {
      url:      "https://erpc.apothem.network",
      accounts: [process.env.DEPLOYER_KEY, process.env.ORACLE_KEY],
      chainId:  51,

      // ⚠️  XDC-specific settings — required for successful deployment
      // After the XDC 2.0 upgrade, Apothem minimum gas price is 12.5 gwei
      // XDC does NOT support EIP-1559 — always use gasPrice (not maxFeePerGas)
      gasPrice: 12500000000,   // 12.5 gwei in wei
    }
  }
};

Step 4 — Write the Smart Contract

Delete the default contracts/Lock.sol and create contracts/AIScoreOracle.sol:

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

/// @title AIScoreOracle
/// @notice AI-powered loan approval contract on XDC Network
/// @dev Live on Apothem: 0xE031843227668f530DC0E59Bb093ED6763Dcd84D
contract AIScoreOracle {

    address public owner;
    address public trustedOracle;     // Wallet that submits AI scores
    uint256 public approvalThreshold; // Minimum score to get approved (0–1000)
    uint256 public totalApplications;

    struct Application {
        address applicant;
        uint256 aiScore;          // AI credit score (0–1000)
        string  riskCategory;     // "LOW", "MEDIUM", "HIGH", "PENDING"
        bool    approved;
        bool    processed;
        uint256 timestamp;
    }

    mapping(address => Application) public applications;
    address[] public applicantList;

    event LoanApplied(address indexed applicant, uint256 timestamp);
    event AIScoreSubmitted(
        address indexed applicant,
        uint256 score,
        string  risk,
        bool    approved
    );

    modifier onlyOwner()  { require(msg.sender == owner,         "Only owner");  _; }
    modifier onlyOracle() { require(msg.sender == trustedOracle, "Only oracle"); _; }

    constructor(address _oracle, uint256 _threshold) {
        owner             = msg.sender;
        trustedOracle     = _oracle;
        approvalThreshold = _threshold;
    }

    /// @notice Any user can apply for a loan (once per address)
    function applyForLoan() external {
        require(applications[msg.sender].timestamp == 0, "Already applied");

        applications[msg.sender] = Application({
            applicant:    msg.sender,
            aiScore:      0,
            riskCategory: "PENDING",
            approved:     false,
            processed:    false,
            timestamp:    block.timestamp
        });

        applicantList.push(msg.sender);
        totalApplications++;
        emit LoanApplied(msg.sender, block.timestamp);
    }

    /// @notice Oracle submits the AI credit score for an applicant
    function submitAIScore(address applicant, uint256 score) external onlyOracle {
        require(score <= 1000,                          "Score must be 0-1000");
        require(applications[applicant].timestamp != 0, "No application found");
        require(!applications[applicant].processed,     "Already processed");

        Application storage app = applications[applicant];
        app.aiScore   = score;
        app.processed = true;
        app.approved  = score >= approvalThreshold;

        if      (score >= 800)               app.riskCategory = "LOW";
        else if (score >= approvalThreshold) app.riskCategory = "MEDIUM";
        else                                 app.riskCategory = "HIGH";

        emit AIScoreSubmitted(applicant, score, app.riskCategory, app.approved);
    }

    /// @notice Read the loan decision for any address
    function getDecision(address applicant) external view returns (
        uint256 score,
        string memory risk,
        bool    approved,
        bool    processed,
        uint256 appliedAt
    ) {
        Application memory app = applications[applicant];
        return (app.aiScore, app.riskCategory, app.approved, app.processed, app.timestamp);
    }

    /// @notice Total number of applicants ever
    function getApplicantCount() external view returns (uint256) {
        return applicantList.length;
    }
}

What each function does

Function	Who Calls It	What It Does
`applyForLoan()`	Any user	Registers a loan application on-chain
`submitAIScore(address, uint256)`	Oracle only	Submits AI score, triggers approve/reject
`getDecision(address)`	Anyone	Reads the stored decision for any address
`getApplicantCount()`	Anyone	Returns total number of applicants

Step 5 — Compile the Contract

npx hardhat compile

Expected output:

Compiled 1 Solidity file successfully (evm target: paris).

Step 6 — Write the Deploy Script

Delete scripts/deploy.js and recreate it:

// scripts/deploy.js
const hre = require("hardhat");

async function main() {
  const [deployer, oracle] = await hre.ethers.getSigners();

  console.log("Deploying AIScoreOracle to XDC Apothem...\n");
  console.log("Deployer :", deployer.address);
  console.log("Oracle   :", oracle.address);

  const deployerBalance = await hre.ethers.provider.getBalance(deployer.address);
  console.log("Balance  :", hre.ethers.formatEther(deployerBalance), "TXDC\n");

  // Deploy: pass oracle address and approval threshold of 700 out of 1000
  const AIScoreOracle = await hre.ethers.getContractFactory("AIScoreOracle");
  const contract      = await AIScoreOracle.deploy(oracle.address, 700, {
    gasLimit: 2_000_000,      // Set manually — XDC estimateGas is unreliable
    gasPrice: hre.ethers.parseUnits("12.5", "gwei")  // Apothem minimum after XDC 2.0
  });

  await contract.waitForDeployment();

  const contractAddress = await contract.getAddress();
  const deployTx        = contract.deploymentTransaction();

  console.log("Contract deployed!");
  console.log("Address  :", contractAddress);
  console.log("TX Hash  :", deployTx.hash);
  console.log("Explorer :", `https://testnet.xdcscan.com/address/${contractAddress}`);
  console.log("TX Link  :", `https://testnet.xdcscan.com/tx/${deployTx.hash}`);
}

main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Step 7 — Deploy to XDC Apothem

npx hardhat run scripts/deploy.js --network apothem

You will see output like:

Deploying AIScoreOracle to XDC Apothem...

Deployer : 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5
Oracle   : 0xE65AbC44aa93B25320D9BB9eB6B5cEa3C0a21872
Balance  : 1000.0 TXDC

Contract deployed!
Address  : 0xE031843227668f530DC0E59Bb093ED6763Dcd84D
TX Hash  : 0x7fa75b52a379b20a1c3a4d8966a7c78f1ac29ba69eb25dded01185dcc66c7843
Explorer : https://testnet.xdcscan.com/address/0xE031843227668f530DC0E59Bb093ED6763Dcd84D
TX Link  : https://testnet.xdcscan.com/tx/0x7fa75b52a379b20a1c3a4d8966a7c78f1ac29ba69eb25dded01185dcc66c7843

Open the Explorer link — your contract is live on XDC Apothem! 🎉

Step 8 — User Applies for a Loan

Write an interaction script. Create scripts/apply.js:

// scripts/apply.js
const hre = require("hardhat");

const CONTRACT_ADDRESS = "YOUR_DEPLOYED_CONTRACT_ADDRESS";

async function main() {
  const [deployer] = await hre.ethers.getSigners();

  const AIScoreOracle = await hre.ethers.getContractFactory("AIScoreOracle");
  const contract      = AIScoreOracle.attach(CONTRACT_ADDRESS);

  console.log("Applying for a loan from:", deployer.address);

  const tx = await contract.applyForLoan({
    gasLimit: 300_000,
    gasPrice: hre.ethers.parseUnits("12.5", "gwei")
  });
  await tx.wait();

  console.log("Application submitted!");
  console.log("TX Hash  :", tx.hash);
  console.log("TX Link  :", `https://testnet.xdcscan.com/tx/${tx.hash}`);

  // Check pending status
  const [score, risk, approved, processed] = await contract.getDecision(deployer.address);
  console.log("\nOn-chain status:");
  console.log("  Risk      :", risk);       // PENDING
  console.log("  Processed :", processed);  // false
  console.log("  Score     :", score.toString());
  console.log("\nWaiting for AI oracle to score this application...");
}

main().catch((err) => { console.error(err); process.exit(1); });

Run it:

npx hardhat run scripts/apply.js --network apothem

Output from our live deployment:

Applying for a loan from: 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5
Application submitted!
TX Hash  : 0xe95ba3312aa0e710fb45cc6980c271a499570c65d89eb45cadda118719d64387
TX Link  : https://testnet.xdcscan.com/tx/0xe95ba3312aa0e710fb45cc6980c271a499570c65d89eb45cadda118719d64387

On-chain status:
  Risk      : PENDING
  Processed : false
  Score     : 0

Waiting for AI oracle to score this application...

Step 9 — AI Oracle Submits the Score

Now the oracle wallet submits the AI-generated score. Create scripts/submit_score.js:

// scripts/submit_score.js
const hre = require("hardhat");

const CONTRACT_ADDRESS = "YOUR_DEPLOYED_CONTRACT_ADDRESS";
const APPLICANT        = "THE_APPLICANT_WALLET_ADDRESS";
const AI_SCORE         = 711;   // Replace with your AI model's output (0–1000)

async function main() {
  // Use the second signer — the oracle wallet
  const [, oracle] = await hre.ethers.getSigners();

  const AIScoreOracle = await hre.ethers.getContractFactory("AIScoreOracle");
  const contract      = AIScoreOracle.attach(CONTRACT_ADDRESS);

  console.log("Oracle wallet     :", oracle.address);
  console.log("Applicant         :", APPLICANT);
  console.log("AI Credit Score   :", AI_SCORE, "/ 1000");
  console.log("Approval Threshold: 700 / 1000");
  console.log("Decision          :", AI_SCORE >= 700 ? "APPROVE" : "REJECT");
  console.log("\nSubmitting AI score to blockchain...");

  const tx = await contract.connect(oracle).submitAIScore(APPLICANT, AI_SCORE, {
    gasLimit: 300_000,
    gasPrice: hre.ethers.parseUnits("12.5", "gwei")
  });
  await tx.wait();

  console.log("\nAI score committed on-chain!");
  console.log("TX Hash  :", tx.hash);
  console.log("TX Link  :", `https://testnet.xdcscan.com/tx/${tx.hash}`);

  // Read final decision
  const [score, risk, approved, processed] = await contract.getDecision(APPLICANT);
  console.log("\nFinal decision from contract:");
  console.log("  AI Score   :", score.toString(), "/ 1000");
  console.log("  Risk Level :", risk);
  console.log("  Processed  :", processed);
  console.log("  Decision   :", approved ? "APPROVED ✅" : "REJECTED ❌");
}

main().catch((err) => { console.error(err); process.exit(1); });

Run it:

npx hardhat run scripts/submit_score.js --network apothem

Output from our live deployment:

Oracle wallet     : 0xE65AbC44aa93B25320D9BB9eB6B5cEa3C0a21872
Applicant         : 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5
AI Credit Score   : 711 / 1000
Approval Threshold: 700 / 1000
Decision          : APPROVE

Submitting AI score to blockchain...

AI score committed on-chain!
TX Hash  : 0xcf230923452c8d054435b685ce67f7ad138e4b37e1688e2e8a6852b8af12edf9
TX Link  : https://testnet.xdcscan.com/tx/0xcf230923452c8d054435b685ce67f7ad138e4b37e1688e2e8a6852b8af12edf9

Final decision from contract:
  AI Score   : 711 / 1000
  Risk Level : MEDIUM
  Processed  : true
  Decision   : APPROVED ✅

Step 10 — Verify Everything On-Chain

Open the live contract on XDCScan Testnet:

👉 https://testnet.xdcscan.com/address/0xE031843227668f530DC0E59Bb093ED6763Dcd84D

Transactions tab — all 3 transactions visible:

TX Hash	Action	Gas Used
`0x7fa75b52...`	Contract deploy	907,449
`0xe95ba331...`	`applyForLoan()`	161,014
`0xcf230923...`	`submitAIScore(711)`	83,122

Events tab — two on-chain events emitted:

LoanApplied(
  applicant = 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5,
  timestamp = 1746...
)

AIScoreSubmitted(
  applicant = 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5,
  score     = 711,
  risk      = "MEDIUM",
  approved  = true
)

Read Contract tab — call getDecision(0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5):

score     → 711
risk      → MEDIUM
approved  → true
processed → true
appliedAt → 1746...

Every decision is permanent, immutable, and publicly verifiable — no central authority, no trust required.

Step 11 — Replace Demo AI with a Real Model

In submit_score.js the score is hardcoded as 711. In production, replace that with a real ML model call.

Python scikit-learn example:

# ai_model.py
import joblib
import numpy as np

model = joblib.load("credit_model.pkl")

def get_ai_score(applicant_address: str) -> int:
    """
    Fetch applicant data, run the model, return a score 0–1000.
    """
    features = fetch_applicant_features(applicant_address)
    probability = model.predict_proba([features])[0][1]
    return int(probability * 1000)

Then expose it as an API:

# oracle_api.py  (Flask)
from flask import Flask, jsonify, request
from ai_model import get_ai_score

app = Flask(__name__)

@app.route("/score", methods=["POST"])
def score():
    address = request.json["address"]
    return jsonify({ "score": get_ai_score(address) })

And call it from your Hardhat script:

// In submit_score.js — replace the hardcoded score:
const response = await fetch("http://localhost:5000/score", {
    method:  "POST",
    headers: { "Content-Type": "application/json" },
    body:    JSON.stringify({ address: APPLICANT })
});
const { score: AI_SCORE } = await response.json();

Everything else — the Solidity contract, the Hardhat scripts, the on-chain verification — stays exactly the same.

Important XDC Developer Notes

These are lessons learned from our actual deployment:

Issue	Root Cause	Fix
`under min gas price`	XDC 2.0 upgrade raised Apothem minimum	Use `12.5 gwei` minimum
`estimateGas` returns null	XDC Apothem doesn't support `eth_estimateGas` reliably	Set `gasLimit` manually
EIP-1559 tx rejected	XDC does not support type-2 transactions	Use `gasPrice` not `maxFeePerGas`

Full Live Transaction Summary

All transactions verified on XDCScan Testnet:

Step	TX Hash	Link
Deploy contract	`0x7fa75b52...c7843`	View ↗
Apply for loan	`0xe95ba331...4387`	View ↗
AI score (711) submitted	`0xcf230923...edf9`	View ↗

Key Takeaways

XDC is fully EVM-compatible — Solidity and Hardhat work exactly as on Ethereum
The oracle pattern is the standard way to bridge AI (off-chain) and smart contracts (on-chain)
XDC Apothem gas settings: minimum 12.5 gwei, always set gasLimit manually, avoid EIP-1559
XDC's near-zero fees make per-user AI-triggered actions economically viable at scale
Every decision is permanent, immutable, and verifiable on XDCScan Testnet

Resources

How Data-Driven UI UX Design Improves Usability, Engagement, and Conversion Rates

Umar siddique — Wed, 29 Apr 2026 07:45:14 +0000

Digital products are no longer judged only by how they look. Users expect websites, apps, platforms, and dashboards to be fast, simple, useful, and easy to navigate. If a product feels confusing or difficult to use, users can leave within seconds and choose another option.
This is why data-driven UI UX Design has become so important. Instead of making design decisions based on personal opinions, assumptions, or trends, data-driven design uses real user behavior to improve the overall experience. It helps teams understand what users want, where they struggle, and what actions they are most likely to take.
When used correctly, data-driven design can improve usability, increase engagement, and support better conversion rates. It allows businesses to create digital experiences that are not only visually appealing but also practical, measurable, and aligned with user needs.

What Is Data-Driven UI UX Design?

Data-driven UI UX design is the process of using research, analytics, testing, and feedback to guide design decisions. It helps designers understand how users interact with a digital product and what changes can make the experience better.
This data can come from many sources, including:

Website analytics
Heatmaps
Session recordings
User surveys
Usability testing
A/B testing
Customer feedback
Conversion tracking
Support tickets

For example, if analytics show that users are leaving a signup page before completing the form, designers can investigate why. The issue might be too many form fields, unclear instructions, poor mobile design, or a lack of trust signals.
Without data, teams may only guess what the problem is. With data, they can identify the issue more accurately and improve the experience with purpose.

Why Data Matters in Modern Product Design

Good design is not just about colors, fonts, icons, or layouts. It is about helping users complete their goals with less effort. A beautiful interface may attract attention, but if users cannot understand what to do next, the design is not effective.
Data helps remove guesswork from the design process. It shows how users actually behave rather than how teams assume they behave. This is important because internal teams often view a product differently from first-time users.
For example, a product team may believe that a navigation menu is simple, but user recordings may show that visitors are struggling to find important pages. Similarly, a call-to-action button may look visually attractive, but click data may show that users are ignoring it.
A skilled UI UX Design Agency may use this type of data to create interfaces that balance business goals with user expectations. The result is a design that feels natural, supports user journeys, and encourages meaningful action.

How Data-Driven Design Improves Usability

Usability is one of the most important parts of any digital experience. It refers to how easily users can interact with a product and complete their tasks.
Data-driven design improves usability by identifying friction points. These are moments where users feel confused, delayed, or frustrated. Common usability problems include unclear navigation, long forms, slow-loading pages, poor mobile layouts, weak content hierarchy, and confusing buttons.
By analyzing user behavior, design teams can find and fix these problems. For example, heatmaps may show that users are clicking on an image because they think it is a button. This signals that the design needs clearer visual cues. Form analytics may show that users abandon a checkout process at a specific field. This could mean the field is unnecessary, confusing, or asking for sensitive information too early.
Improving usability often involves small but powerful changes, such as:

Making buttons more visible
Reducing unnecessary steps
Simplifying navigation
Improving page structure
Using clearer labels
Making content easier to scan
Optimizing the mobile experience
Improving accessibility

When users can move through a product smoothly, they are more likely to stay, explore, and complete important actions.

How Data-Driven Design Increases Engagement

User engagement shows how actively people interact with a digital product. It can be measured through actions such as clicks, scroll depth, time on page, repeat visits, feature usage, video views, or completed tasks.
Data-driven design improves engagement by helping teams understand what users find valuable. If users spend more time on certain sections of a page, that content may be highly relevant. If they ignore a feature, it may need better placement, clearer explanation, or improved onboarding.
Engagement also depends on how well the design matches user intent. A visitor who lands on a pricing page likely wants clarity, comparison, and confidence. A user opening a dashboard likely wants quick access to key information. A first-time app user needs guidance and reassurance.
When designers study user behavior, they can create experiences that feel more relevant and useful. This may include personalized recommendations, better onboarding screens, interactive elements, improved content flow, or clearer product education.
The more relevant the experience feels, the more likely users are to interact with it.

How Data-Driven UI UX Design Improves Conversion Rates

Conversion rate is one of the clearest ways to measure design performance. A conversion can mean different things depending on the product or business. It may include signing up for a newsletter, booking a demo, creating an account, purchasing a product, downloading a resource, or submitting a contact form.
Data-driven design improves conversions by reducing friction and making the next step easier to understand. Many users do not convert because the design fails to answer their questions or build enough confidence.
For example, if users visit a landing page but do not click the main CTA, the problem may be unclear messaging, weak visual hierarchy, missing social proof, or poor button placement. If users add products to a cart but do not complete checkout, the issue may be unexpected costs, a complicated checkout process, or limited payment options.
Design teams can use data to test and improve these areas. They may experiment with different headlines, CTA text, page layouts, form lengths, trust badges, testimonials, or pricing displays.
The goal is not to pressure users. The goal is to make decisions easier by giving users the right information at the right time.

The Role of A/B Testing in Design Decisions

A/B testing is a useful method for comparing two versions of a design. It helps teams understand which version performs better based on actual user behavior.
For example, a team may test two different signup page layouts. Version A may have a short form with minimal text, while Version B may include more explanation and trust signals. After enough users interact with both versions, the data can show which one leads to more completed signups.

A/B testing can be used for many design elements, including:

Headlines
CTA buttons
Page layouts
Images
Form fields
Pricing sections
Navigation menus
Onboarding flows

This approach helps teams avoid making design decisions based only on personal preference. Instead, they can use measurable results to choose the version that works better for users and business goals.

How No-Code Development Supports Faster Testing

Speed is important in modern product design. Traditional development cycles can take time, especially when teams need to test multiple design ideas. This is where No code development can support data-driven design.
No-code tools allow teams to create landing pages, prototypes, forms, dashboards, and MVPs without writing complex code. This makes it easier to launch design experiments, collect data, and make improvements quickly.
For startups, agencies, and product teams, this can reduce the time between idea and validation. Instead of waiting weeks to test a new layout or feature concept, teams can create a working version, measure user behavior, and decide what to improve next.
When no-code development is combined with data-driven UI UX design, businesses can move faster while still making informed decisions.
Key Metrics to Track
To improve usability, engagement, and conversions, teams should focus on the right metrics. Some of the most useful include:

Bounce rate: Shows how many users leave after viewing one page.
Click-through rate: Measures how often users click specific links or buttons.
Conversion rate: Tracks how many users complete a desired action.
Drop-off rate: Identifies where users leave a process.
Time on page: Shows how long users spend with content.
Task completion rate: Measures whether users can complete key actions.
User feedback: Explains the reasons behind user behavior

These metrics become more valuable when combined. Numbers can show what is happening, while feedback can explain why it is happening.

Final Thoughts

Data-driven UI UX design helps businesses create digital products that are easier to use, more engaging, and more effective at converting users. It replaces guesswork with evidence and allows teams to make smarter design decisions.
By studying user behavior, testing ideas, and improving based on real insights, businesses can create experiences that serve both users and business goals. In a competitive digital environment, the products that perform best are not always the ones with the most complex designs. They are often the ones that understand their users the best.

FAQs

1. What is data-driven UI UX design?

Data-driven UI UX design uses analytics, user feedback, testing, and behavior insights to guide design decisions and improve the user experience.
2. How does data-driven design improve usability?

It helps identify where users struggle, such as confusing navigation, long forms, or unclear buttons, so teams can remove friction and simplify the experience.
3. Can UI UX design increase conversion rates?

Yes. Better design can make user journeys clearer, reduce hesitation, and encourage users to complete actions such as signing up, purchasing, or booking a demo.
4. Why should a business hire a UI UX Design Agency?

A UI UX Design Agency can bring research, strategy, testing, and design expertise together to create user-focused digital products that support business growth.
5. How does no-code development help with design testing?

No-code development allows teams to build and test pages, prototypes, and MVPs faster, making it easier to collect data and improve designs quickly.

Using the XDC Network RPC: A Practical Guide for Developers, Wallets, and Integrations

Omkar Mestry — Tue, 28 Apr 2026 13:12:21 +0000

If you are building on, integrating with, or transacting on the XDC Network, you will need an RPC endpoint. RPC (Remote Procedure Call) is the URL your wallet, dApp, or backend uses to read from and write to the blockchain. Without it, your software cannot talk to the network.

The two canonical lists of XDC RPC providers are on Chainlist:

Mainnet (Chain ID 50, native asset XDC): https://chainlist.org/chain/50
Apothem Testnet (Chain ID 51, native asset TXDC): https://chainlist.org/chain/51

Anyone developer, exchange, custodian, dApp team, or end user can pick any of the endpoints listed there. No permission needed; just a working URL.

XDC Mainnet RPC providers (Chain ID 50)

Widely used public HTTP endpoints:

https://rpc.xinfin.network
https://rpc1.xinfin.network
https://erpc.xinfin.network
https://earpc.xinfin.network (archive endpoint)
https://rpc.xdc.org
https://rpc.xdc.network
https://rpc.xdcrpc.com
https://erpc.xdcrpc.com

WebSocket endpoints:

wss://rpc.xdcrpc.com/ws
wss://erpc.xdcrpc.com/ws
wss://ews.xinfin.network/ws

Established commercial RPC-as-a-service providers also expose XDC Mainnet endpoints, including Ankr, Tatum, and Dwellir.

XDC Apothem Testnet RPC providers (Chain ID 51)

Use Apothem for development and testing. Test TXDC is free from the faucets at https://faucet.apothem.network and https://faucet.blocksscan.io.

HTTP endpoints:

https://rpc.apothem.network
https://erpc.apothem.network
https://apothem.xdcrpc.com

WebSocket endpoint:

wss://ws.apothem.network

"Free" public RPCs are not really free at scale

Every RPC endpoint public or commercial has rate limits. Public/community URLs are fine for development, wallets, and light-traffic apps. Once your application starts generating real load, you will hit throttling, timeouts, or outright blocking.

Commercial providers expose the same trade-off explicitly: a free tier with a hard request cap, then paid tiers above it. As a reference point, Ankr's freemium tier on XDC has historically been around 30 requests/sec, with paid premium going up to ~1,500 req/sec at roughly USD $0.02 per 1,000 requests — cheap on a unit-cost basis, but it scales with your call volume. Verify current pricing on the provider's site before committing.

There is no genuinely free, unlimited, production-grade RPC for XDC or any other major chain.

How RPC is actually provided on a decentralised network

XDC is decentralised, so there is no single "official" RPC. Anyone who can run a node can expose an endpoint, which is why the Chainlist directory grows over time. In practice, RPC reaches end users through four layers:

Public/community endpoints — free, rate-limited, no SLA. Good for development and low-traffic use.
Commercial RPC-as-a-service (Ankr, Tatum, Dwellir, etc.) — free tiers for moderate use, paid tiers for production volume, optional dedicated managed nodes (e.g. archive nodes) for institutions.
Projects building on XDC providing RPC to their own customers as part of their product — either by running their own infrastructure or by routing customers to a commercial provider.
Self-hosted nodes — run by exchanges, custodians, indexers, and any team for whom XDC is core infrastructure.

The reason the market is layered like this is simple: someone has to fund and maintain the servers. A single free, unlimited, ultra-reliable public RPC would attract everyone, saturate, and stop being reliable. The layered market is how that catch-22 gets resolved in practice.

Run your own RPC node, the right call for serious users

For institutions and any project that depends on XDC for core operations, the right answer is to run your own node. The setup is well documented and the hardware needs are modest.

Why it matters:

No rate limits — you control throughput.
Privacy — your queries and transaction broadcasts stay inside your own network.
Latency — a node in your own VPC is materially faster than any external endpoint.
No vendor lock-in — no third-party outage, throttling, or pricing change can take you down.
Predictable cost — pay for hardware and bandwidth, not per request.

This should be a baseline requirement, not an optimisation, for:

Exchanges (CEX and DEX), custodians, and institutional wallet providers
Banks, payment processors, and regulated entities
Block explorers, analytics platforms, and indexers

Setup resources:

Dedicated/private RPC server setup guide: https://www.xdc.dev/ruslan_wing/setting-up-an-rpc-node-server-for-your-dapp-on-xdc-network-a-comprehensive-guide-3dm9
Full-node repository: https://github.com/XinFinOrg/XinFin-Node
XDC documentation: https://docs.xdc.network and https://docs.xdc.community

A standard production setup is two full nodes behind a load balancer plus a separate archive node for historical queries, with monitoring on sync status, peer count, and disk health.

When you need RPC, and when you don't

A centralised trading system does not need RPC for its core matching engine. Trades are off-chain, inside the exchange's own systems. RPC only matters at deposit and withdrawal edges.
A decentralised exchange (DEX) lives on-chain. Every swap and quote depends on RPC, and RPC quality directly drives user experience.

Recommendations

Development and testing — use Apothem with the public RPC URLs above.
Small production app or wallet — public Mainnet endpoints with fallback logic across two or three URLs; move to a paid commercial plan as traffic grows.
Exchanges, custodians, wallet providers, banks, and core-XDC operations — run your own RPC node. Treat it as required infrastructure.

FAQ

What is an RPC, in plain English?
A URL your software uses to read from and write to the blockchain. Without it, your application has no way of seeing or interacting with the chain.

Mainnet (50) vs Apothem (51)?
Mainnet uses real XDC. Apothem uses free test TXDC. Use Apothem for development; Mainnet for production.

HTTP vs WebSocket (wss://)?
HTTP is request-response — fine for normal reads and writes. WebSocket keeps a connection open and lets you subscribe to events (new blocks, contract logs) in real time — needed for trading bots, indexers, and live dashboards.

Do I need an archive node?
Only if you need to query historical state — explorers, analytics, audit/accounting systems. Most apps don't.

How much does paid commercial RPC cost?
Cheap per request (around $0.02 per 1,000 on Ankr's premium tier historically), but total cost scales with your call volume. Always check the provider's current pricing.

Why doesn't the XDC Network just provide one definitive RPC?
Doing so means running an operating business with capacity, support, and liability obligations. It is also self-defeating: a single free, reliable, unlimited RPC would be used by everyone and saturate. The layered market — community, commercial, self-hosted — is how decentralised networks solve this in practice.

What if my public RPC goes down?
Reads time out, transactions fail to broadcast. Production apps should run their own node or, at minimum, keep a list of fallback URLs and rotate on failure.

The full and most current list of providers is always on Chainlist:

Mainnet: https://chainlist.org/chain/50
Apothem: https://chainlist.org/chain/51

How to Integrate XDC Network: A Technical Guide

Omkar Mestry — Thu, 23 Apr 2026 08:44:46 +0000

How to Integrate XDC Network: A Technical Guide

A complete technical walkthrough for integrating the XDC Network into custodial wallets, exchanges, and any backend application.

If your team is already building on EVM chains like Ethereum, Polygon, or BNB Chain, integrating XDC will feel familiar — it's fully EVM-compatible, forked from go-ethereum, and runs the same tooling (Ethers.js, Web3.py, Hardhat, Truffle, MetaMask). The main thing to watch for is the xdc address prefix, which we'll cover in detail.

Let's dive in.

1. Overview

The XDC Network is an enterprise-grade, EVM-compatible Layer-1 blockchain using XDC 2.0 consensus (an evolution of XinFin Delegated Proof-of-Stake). It's purpose-built for tokenized trade finance, real-world asset (RWA) settlement, and cross-border payments.

Key stats:

~2-second block times
Sub-cent gas fees (often < $0.0001 per transfer)
Up to 108 masternodes securing finality
ISO 20022 messaging support
R3 Corda interoperability

Because XDC is EVM-compatible, most Ethereum tooling works out-of-the-box. The only material difference a custodian or application must handle is the address prefix: XDC natively uses an xdc prefix in place of 0x, while the underlying address bytes are identical.

2. Network Parameters

Mainnet

Parameter	Value
Network Name	XDC Network
Chain ID	`50`
Native Currency	XDC
Block Time	~2 seconds
Consensus	XDC 2.0
Min Gas Price	0.25 Gwei
Public RPC	`https://rpc.xinfin.network` `https://rpc.xdc.org`
WebSocket	`wss://ws.xinfin.network`
Block Explorer	`https://www.xdcscan.com` `https://www.xdcscan.io`

Apothem Testnet

Parameter	Value
Network Name	XDC Apothem Network
Chain ID	`51`
Native Currency	TXDC
Block Time	~2 seconds
Consensus	XDC 2.0
Min Gas Price	0.25 Gwei
Public RPC	`https://rpc.apothem.network` `https://erpc.apothem.network`
WebSocket	`wss://ws.apothem.network`
Block Explorer	`https://testnet.xdcscan.com` `https://apothem.xdcscan.io`
Faucet	`https://faucet.apothem.network` `https://faucet.blocksscan.io`

Production tip: Run your own full node or subscribe to a commercial RPC provider (Ankr, GetBlock, Thirdweb, NOWNodes) for production. Public endpoints are fine for development but have rate limits and no SLA.

3. Address Format (Critical)

This is the one thing that trips up every new integrator, so read this section carefully.

XDC addresses are semantically identical to Ethereum addresses — derived via secp256k1 key generation and Keccak-256 hashing, producing a 20-byte (40 hex character) address. The only difference is the prefix:

XDC-native display uses xdc → xdcA4e66f4Cc17752f331eaC6A20C00756156719519
EVM-native display uses 0x → 0xA4e66f4Cc17752f331eaC6A20C00756156719519

The 40 hex characters after the prefix are always identical. Only the 2-character prefix swaps.

Conversion Rules

Normalize addresses at your I/O boundary:

Internally, store and sign using the 0x form — required by all Ethereum libraries (ethers.js, web3.js, etc.).
On input, if a user pastes an xdc-prefixed address, strip xdc and prepend 0x before signing or submitting.
On output (deposit addresses shown to users, explorer links, confirmations), display in xdc form for XDC ecosystem conformity.

Address Conversion Utility

// Minimal address conversion helper (JavaScript / TypeScript)

function toEvm(address) {
  if (!address) return address;
  if (address.toLowerCase().startsWith('xdc')) {
    return '0x' + address.slice(3);
  }
  return address;
}

function toXdc(address) {
  if (!address) return address;
  if (address.toLowerCase().startsWith('0x')) {
    return 'xdc' + address.slice(2);
  }
  return address;
}

function isValidXdcAddress(address) {
  const evm = toEvm(address);
  return /^0x[a-fA-F0-9]{40}$/.test(evm);
}

⚠️ Signed transactions must always use the 0x form internally. The xdc prefix is a display convention — the JSON-RPC node and the EVM itself operate on raw 20-byte addresses.

4. Prerequisites

Node.js 18+ (or Python 3.10+, Go 1.21+, Java 11+ — whichever matches your stack)
Ethers.js v6 or Web3.js v4 (or language-equivalent SDK)
Access to an RPC endpoint (self-hosted full node or commercial provider)
A secure key management system (HSM, KMS, or MPC) for custodial signing
Test funds from the Apothem faucet for testnet validation

5. Integration Architecture

A typical custodial integration has four components:

Node / RPC Layer — a full node or commercial RPC for reading chain state, estimating gas, and broadcasting transactions.
Block Indexer — a worker service that follows the chain head (with confirmations), detects deposits to custodied addresses, and records balances.
Signing Service — an isolated service (HSM/KMS/MPC) that constructs, signs, and submits withdrawal transactions. Never exposes private keys to the application layer.
API Layer — the user-facing REST/GraphQL interface. Responsible for address format normalization.

6. Integration Steps

6.1 Connect to the Network

Ethers.js v6:

const { JsonRpcProvider } = require('ethers');

const provider = new JsonRpcProvider('https://rpc.xinfin.network', {
  name: 'xdc',
  chainId: 50
});

const blockNumber = await provider.getBlockNumber();
console.log('Latest block:', blockNumber);

Web3.py:

from web3 import Web3

w3 = Web3(Web3.HTTPProvider('https://rpc.xinfin.network'))
assert w3.is_connected(), 'RPC connection failed'
print('Chain ID:', w3.eth.chain_id)        # 50
print('Latest block:', w3.eth.block_number)

6.2 Generate a Deposit Address

For each user account, derive a fresh address using standard EVM wallet derivation (BIP-39 mnemonic + BIP-44 path). XDC's registered SLIP-44 coin type is 550, though many integrations reuse Ethereum's 60.

const { Mnemonic, HDNodeWallet } = require('ethers');

const mnemonic = Mnemonic.fromPhrase(process.env.SEED_PHRASE);
const root     = HDNodeWallet.fromMnemonic(mnemonic, "m/44'/550'/0'/0");
const account  = root.deriveChild(userIndex);

const evmAddress = account.address;              // 0x...
const xdcAddress = 'xdc' + evmAddress.slice(2);  // xdc... (for display)

// Persist { userId, derivationIndex, xdcAddress }
// NEVER persist the private key — derive on demand from the HSM-held seed

6.3 Monitor Deposits

Poll or subscribe to new blocks. For each block, iterate transactions and match the to field (or XRC-20 Transfer log topic) against your indexed deposit addresses. Wait for at least 10–15 confirmations on mainnet before crediting.

provider.on('block', async (blockNumber) => {
  const block = await provider.getBlock(blockNumber, true);
  for (const tx of block.prefetchedTransactions) {
    if (watchedAddresses.has(tx.to?.toLowerCase())) {
      await enqueueDepositConfirmation(tx.hash, blockNumber);
    }
  }
});

6.4 Process Withdrawals

const tx = {
  to:       toEvm(userProvidedAddress),   // accept xdc... or 0x...
  value:    ethers.parseEther('10.5'),    // 10.5 XDC
  gasLimit: 21000n,
  gasPrice: ethers.parseUnits('0.25', 'gwei'),  // XDC minimum
  chainId:  50,
  nonce:    await provider.getTransactionCount(hotWalletAddress)
};

const signed   = await signer.signTransaction(tx);     // signer = HSM/KMS
const response = await provider.broadcastTransaction(signed);
const receipt  = await response.wait(12);              // 12 confirmations

6.5 XRC-20 Token Transfers

XRC-20 is functionally identical to ERC-20 — same ABI, same Transfer(address,address,uint256) event signature, same allowance model. Your existing ERC-20 code works unchanged.

const erc20Abi = [
  'function balanceOf(address) view returns (uint256)',
  'function decimals() view returns (uint8)',
  'function symbol() view returns (string)',
  'function transfer(address to, uint256 amount) returns (bool)',
  'event Transfer(address indexed from, address indexed to, uint256 value)'
];

const token = new ethers.Contract(tokenContractAddress, erc20Abi, signer);

const decimals = await token.decimals();
const amount   = ethers.parseUnits('100', decimals);
const tx       = await token.transfer(toEvm(recipient), amount);
await tx.wait(12);

7. Token Standards

Standard	Equivalent To	Use Case
XRC-20	ERC-20	Fungible tokens, stablecoins, utility tokens
XRC-721	ERC-721	Non-fungible tokens (NFTs), unique assets
XRC-1155	ERC-1155	Multi-token contracts (fungible + NFT in one)

All three standards are byte-for-byte compatible with their ERC counterparts at the ABI level. OpenZeppelin contracts compile and deploy unchanged.

8. Gas and Fee Handling

Mainnet minimum gas price is 0.25 Gwei — below this, transactions stay pending indefinitely.
Standard native XDC transfer = 21,000 gas (~0.00000525 XDC, typically under $0.0001).
XRC-20 transfers = ~50,000–65,000 gas depending on contract implementation.
Use eth_estimateGas for contract calls; add a 10–20% safety buffer.
Always verify receipt status == 1 — a receipt alone doesn't mean the tx succeeded.

9. Security Considerations

Store signing keys exclusively in HSM, cloud KMS (AWS/GCP/Azure), or MPC custody. Never plaintext keys in memory or config files.
Segregate hot/warm/cold wallets — keep no more than operational float (~5% of AUM) in any hot wallet.
Enforce withdrawal-address allowlisting and velocity limits per user and per time window.
Require multi-party approval for treasury movement above a threshold.
Wait 12–15 confirmations before crediting mainnet deposits; 20+ for high-value.
Reject deposits sent to contracts you don't control — credit only to externally-owned addresses you've derived.
Always validate chainId == 50 on signed transactions to prevent cross-chain replay.
Monitor for chain reorgs — rare on XDC 2.0, but confirmation-depth buffers protect against edge cases.
Rate-limit RPC calls and implement automatic failover between multiple providers.

10. Testing Checklist (Apothem Testnet)

Complete every item on Apothem before moving to mainnet:

[ ] Connect to Apothem RPC, confirm chainId == 51
[ ] Request TXDC from the faucet to test hot wallet
[ ] Generate 5+ deterministic deposit addresses; verify xdc ↔ 0x conversion is lossless
[ ] Send a test deposit; confirm detection, credit at correct confirmation depth, correct user mapping
[ ] Execute a native TXDC withdrawal; verify status, nonce handling, on-chain balance
[ ] Deploy or use an existing XRC-20 test token; run full deposit + withdrawal flow
[ ] Simulate RPC outage; confirm failover to secondary provider
[ ] Simulate incorrect-prefix input (0x in xdc field and vice versa); confirm normalization
[ ] Simulate below-minimum-gas tx; confirm graceful rejection
[ ] Run a 24-hour soak test at representative transaction volume

11. Sample RPC Calls

eth_chainId

curl -X POST https://rpc.xinfin.network \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

# -> {"jsonrpc":"2.0","id":1,"result":"0x32"}   (0x32 = 50)

eth_blockNumber

curl -X POST https://rpc.xinfin.network \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

eth_getBalance

curl -X POST https://rpc.xinfin.network \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance",
       "params":["0xA4e66f4Cc17752f331eaC6A20C00756156719519","latest"],
       "id":1}'

Note: JSON-RPC payloads use 0x, not xdc — the RPC layer expects standard Ethereum format on the wire.

12. Official Resources

Resource	URL
Primary Documentation	https://docs.xdc.network
Community Documentation	https://docs.xdc.community
Mainnet Explorer	https://www.xdcscan.com https://www.xdcscan.io
Testnet Explorer	https://testnet.xdcscan.com https://apothem.xdcscan.io
Apothem Faucet	https://faucet.apothem.network https://faucet.blocksscan.io
GitHub — XinFin Org	https://github.com/xinfinorg
ChainList (Mainnet)	https://chainlist.org/chain/50
ChainList (Testnet)	https://chainlist.org/chain/51
Developer Forum	https://www.xdc.dev

Wrapping Up

If you're building an EVM-compatible wallet, exchange, or application, integrating XDC is genuinely one of the fastest onboarding paths you'll find — most of your existing Ethereum stack works unchanged. The three things to get right are:

Address prefix handling — normalize at I/O, sign with 0x internally.
Gas pricing — respect the 0.25 Gwei minimum.
Testing on Apothem — don't skip the checklist.

Got questions or hit a snag during integration? Drop a comment below, open a thread on the XDC Developer Forum, or reach out via the official channels. The XDC developer community is active and responsive — you won't be stuck for long.

Happy building. 🚀

Crypto Feels Like Whatever People Are Doing

Quincy Jones — Thu, 16 Apr 2026 18:40:02 +0000

One thing I’ve started to notice about crypto, and I didn’t really get this at first, is that it’s not actually dictated by what’s “best” or even what’s most advanced. It’s dictated by activity. Just whatever people are doing at scale, that becomes the space, at least for a period of time.

Like when things are hot, it feels obvious. Everyone’s trading, everyone’s posting, there’s new projects every day, people are jumping chains, minting, flipping, whatever it is. And because that activity is so loud, it kind of defines reality. It’s like, okay this is crypto right now. This is what matters.

NFTs had that moment. Memecoins had that moment. Even certain ecosystems, they didn’t just win because they were better technically, they won because people were there, doing things, interacting, creating momentum. And momentum is weirdly one of the most powerful forces in this space.

But then things slow down, and it almost feels like everything disappears. Prices drop, timelines get quiet, nobody is really talking the same way anymore. And it can feel like the whole space just… died or something. But it didn’t, it just changed form.

Because what’s happening underneath during those slower periods is honestly kind of more important, it’s just not as visible. Builders are still there, probably even more focused because there’s less noise. People are working on infrastructure, fixing problems, trying to actually make things usable instead of just exciting. It’s not flashy, it doesn’t go viral, but it’s real.

There’s almost like two versions of crypto. The one you see during hype cycles, and the one that actually gets built when nobody is paying attention. And they don’t really look the same at all.

The hype version is fast. It’s social. It’s easy to understand. You can jump in, participate, feel like you’re part of something immediately. And that’s why speculation becomes such a big part of it, because speculation itself is activity. It creates movement, and movement pulls people in.

But the quieter version, it’s slower, more technical, sometimes kind of boring if we’re being honest. But that’s where a lot of the real foundation gets laid. The stuff that actually sticks around longer than a cycle.

And I think the interesting part is how those two phases feed into each other.

Because the things that get built in the quiet don’t just stay there. They come back during the next hype cycle, just in a different form. Usually simplified, sometimes repackaged, but they’re rooted in that earlier work that nobody really saw at the time.

So yeah, crypto is driven by activity, but not all activity is the same. Some of it is loud and temporary, and some of it is quiet and foundational. And if you only pay attention to one, you get a really incomplete picture of what’s actually going on.

It’s not just what people are building, it’s what people are choosing to do at scale. That’s what defines the space, at least in that moment.

Security Update: KYC/KYB Document Accessibility Incident, Fully Resolved.

Omkar Mestry — Thu, 16 Apr 2026 14:27:58 +0000

Published by: XDC Innovation Lab — Security & Compliance Team
Date: 16 April 2026

Summary

The XDC Innovation Lab is issuing this update to inform the community about a recently identified and fully resolved security incident involving the accessibility of KYC/KYB verification documents submitted during the masternode application process.

Transparency and trust are core to the XDC ecosystem. We believe it is important to communicate openly about what happened, what was done, and what has changed.

What Happened?

Our team identified a configuration vulnerability that allowed certain KYC/KYB verification documents — submitted as part of the masternode onboarding process — to become temporarily accessible via direct URL access without proper authentication.

To clarify, the XDC masternode KYC/KYB process requires applicants to submit only a single-page verification certificate confirming the identity and role of a Director/Trustee/Partner within their organisation, certified by an authorised signatory such as a Company Secretary, Notary Public, or Lawyer. No additional personal documents are collected beyond this single certificate.

What Was Done?

Upon discovery, the Foundation treated this as a Priority 0 (P0) incident and took the following immediate actions:

Access revoked — Public accessibility to all affected documents was immediately revoked
Vulnerability patched — The configuration issue was identified and a fix was deployed
Verification completed — Internal testing confirmed that no KYC/KYB documents remain publicly accessible
Root cause analysis — A thorough root cause analysis was completed to understand how the exposure occurred
Logs preserved — System logs were preserved for forensic review

What Has Changed?

We have implemented significant improvements to our security infrastructure:

Enhanced encryption — All KYC/KYB documents are now stored under encryption with strict access controls
Strengthened access controls — Multi-layer authentication and authorisation checks have been implemented for all document access endpoints
Continuous monitoring — Automated monitoring is now in place to detect any unauthorised access attempts
Updated protocols — Our KYC/KYB data handling and classification policies have been revised and strengthened
Regular audits — Periodic access control audits and penetration testing have been scheduled as ongoing practice

Decentralised by Design

It is important to note that XDC is a decentralised network. The Foundation does not centrally control or manage KYC/KYB processes, nor is any such data stored in a single centralised location. The decentralised nature of the network ensures that no single entity has unilateral control over validator data. All KYC/KYB processes are designed with decentralisation principles in mind, with appropriate encryption and distributed security safeguards.

Community Acknowledgement

We want to sincerely thank the community members who promptly flagged this concern. Your vigilance plays a vital role in strengthening the security and integrity of the XDC ecosystem. Our team is reaching out directly to each individual who raised this issue to provide clarity and gather feedback on the improvements made.

Our Commitment

The XDC Foundation takes the security and privacy of validator documentation with the utmost seriousness. We are committed to maintaining the highest standards of data protection and will continue to invest in strengthening our security infrastructure.

We believe that transparency in addressing such incidents is essential to building and maintaining the trust that our community, validators, and institutional partners place in the XDC Network.

XDC Innovation Lab
Building a Secure and Decentralised Future

HELP !!!

Ox — Mon, 13 Apr 2026 12:08:10 +0000

HI
TODAY IVE LOGGED INTO MY XDC ACCOUNT VIA LEDGER DEVICE AND MY ACCOUNT / WALLET IS NOT AVAILABLE PLEASE ADVISE (SEE PICS)
MY LEDGER HAS THE RECENT UPDATE IT SEEMS THAT XDC XFIN HAVE DELETED MY WALLET AS IT STATES
"WE DO NOT HAVE A NETWORK WITH THIS NAME" (PLEASE SEE PIC)

(0xab3Feb0A1Bc12AA9EE428f0303c0A72d43662Dbc)

XDC Network — Validator (Masternode) Tech Specs & Best Practices

Omkar Mestry — Wed, 08 Apr 2026 09:24:39 +0000

XDC Network — Validator (Masternode) Tech Specs & Best Practices

XDC Network at a Glance

XDC Network is an enterprise-grade, EVM-compatible Layer 1 blockchain purpose-built for trade finance, cross-border payments, and real-world asset (RWA) tokenization. Founded by XinFin in 2017 and mainnet-live since June 2019, the network combines public transparency with private subnet capabilities, delivering near-instant finality, near-zero gas fees, and ISO 20022 compliance — making it one of the most business-ready blockchains in production today.

Key Milestones

Year	Milestone
2017	XinFin founded in Singapore by Ritesh Kakkad and Atul Khekade
2019	KYC Enabled XDC mainnet goes live (June 1)
2021	XDC Foundation established; partnership with SBI Holdings Japan for trade finance expansion
2022	ITFA & TFDi membership; KYC-compliant validator layer recognized by regulators
2023	149+ million new transactions recorded; Ankr & SBI integrations deepen enterprise reach
2024 Q3	XDC 2.0 launched — Chained HotStuff BFT consensus, forensic monitoring, subnet support; CertiK audit completed
2024 Q4	XDC DAO launched (Masternode Senate, Judiciary, People's House); Deutsche Telekom MMS launches a masternode; Etherscan integrates XDC to power XDCScan
2025	Circle integrates native USDC & CCTP V2 on XDC; 21Shares launches XDC ETP on Swiss exchange; Kraken & Binance.US list XDC; VERT Capital announces $1B tokenization pipeline on XDC; Bitso integration for LATAM cross-border payments; XDC surpasses $300M total staked value and 800M+ transactions
2025 H2	GENIUS Act signed into U.S. law — XDC Foundation represented at key regulatory discussions; MiCA Crypto Alliance joined in Europe
2026 Q1	Token Terminal partnership — XDC analytics available via Bloomberg Terminal integration; MVXDC index appears on Bloomberg Terminal, expanding institutional visibility; Contour Network (backed by HSBC, Citi, Standard Chartered) acquired by XDC venture arm

Network at a Glance (as of early 2026)

Metric	Value
Total transactions processed	104M+
Active wallets	2M+
Validator masternode candidates	300+ (108 active Validators · 432 Protector Nodes · 1,000 Observer Nodes)
Smart contracts deployed	717,000+
Total blocks produced	101M+
Mainnet uptime	7+ years continuous

1. Network Overview

Parameter	Value
Consensus	XinFin Delegated Proof of Stake (XDPoS 2.0) — Chained HotStuff BFT protocol (shipped Q4 2024)
Active validator set	108 Masternodes per epoch
Epoch length	900 blocks (~30 minutes)
Block time	~2 seconds
Finality	Deterministic — confirmation = finalization (~6 seconds under XDC 2.0)
Throughput	2,000–2,500+ TPS
BFT guarantee	Network safe as long as adversarial masternodes remain below ⅓ of each epoch's validator set; misbehaviour is provable via on-chain forensics
EVM compatibility	Full — Solidity 0.8.28 supported
Compliance	ISO 20022 financial messaging standard; MiCA-aligned

2. Staking Requirements

Parameter	Requirement
Minimum stake	10 Million XDC per masternode (no upper limit)
KYC	Mandatory — notarised proof of identity (individual or corporate) + address, uploaded on-chain and publicly visible
Resignation lock-up	30 days before staked XDC can be retrieved
Estimated APR	10% (Validator) · 8% (Protector) · 4% (Observer) — subject to change

3. Node Types Under XDC 2.0

Node Type	Role	Max Nodes	Staking	Rewards
Core Validator (Masternode)	Validates transactions, proposes/finalises blocks, governance voting	108	10M XDC min	10%
Protector Node (new in 2.0)	Hot backup for Core Validators (4 Protectors per Validator); takes over during disruptions	432	10M XDC min	8%
Observer Node (new in 2.0)	Non-block-producing; observes consensus, broadcasts transactions	1,000	10M XDC min	4%
Full Node	Stores full ledger, propagates transactions	Unlimited	None	None
Archive Node	Full historical blockchain data; for analytics, explorers, deep queries	Unlimited	None	None

Node selection order: The top 108 most voted candidates become active Core Validators. The next 432 are assigned as Protector Nodes (4 per Validator). Beyond that, the next 1,000 serve as Observer Nodes. Full Nodes and Archive Nodes have no cap and do not participate in consensus.

4. Hardware & Infrastructure Specs

Minimum Requirements

Component	Specification
CPU	4+ cores
RAM	32 GB+
Disk	2 TB+ SSD (500+ IOPS; more is better) — dedicated database partition
OS	Ubuntu 24.04+, CentOS (latest), or RHEL (latest), Windows, Mac OS
Network	Dedicated static public IP, directly internet-facing (no NAT)
Hosting	Minimum Tier 3+ IDC (data centre) environment

5. Uptime & Availability

Requirement	Target
Uptime SLA	100% — masternodes must be online and operational 24/7/365
Slashing risk	Node downtime may result in "slashed" status
Reward impact	Rewards per epoch are proportional to blocks signed; downtime = missed rewards
Backup strategy	Always maintain a secure backup of your Coinbase address and Keystore file. Loss = inaccessible node requiring network resignation

6. Security Best Practices

Key Management

Use a hardware wallet for the staking/owner wallet
Keep Keystore file backed up offline in multiple secure locations
Coinbase address (node identity) backup is critical — if lost, the masternode is unrecoverable
For institutional setups, consider Fireblocks or similar MPC custody via WalletConnect v2

Infrastructure Security

Harden the OS (disable root SSH, use key-based authentication, change the default SSH port)
Keep Docker and node software on the latest stable version
Run behind DDoS mitigation if possible
Enable automatic security updates for the host OS
Install fail2ban to protect against SSH brute-force attempts

Firewall & Port Configuration

For a Validator / Protector / Observer node (not serving public RPC traffic), only port 30303 should be open to the internet. All other non-essential ports must remain closed.

Port Reference:

Port	Protocol	Purpose	Validator / Protector / Observer	Public RPC Node
30303	TCP + UDP	P2P peer discovery & communication	✅ OPEN	✅ OPEN
8989	TCP	HTTP JSON-RPC API	❌ CLOSED	✅ OPEN (IP-restricted)
8888	TCP	WebSocket endpoint	❌ CLOSED	✅ OPEN (IP-restricted)
22 (or custom)	TCP	SSH admin access	✅ OPEN	✅ OPEN

Recommended UFW configuration for a Validator / Protector / Observer masternode:

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 30303                # P2P — required
sudo ufw allow <your_ssh_port>      # SSH — required, do NOT skip
sudo ufw enable

⚠️ Critical: Always allow your SSH port before enabling the firewall or rebooting. Otherwise you will lock yourself out of the server. If this happens, use your VPS provider's web console to regain access.

Additional hardening notes:

On cloud providers (AWS, GCP, Azure, DigitalOcean), you must also configure provider-level Security Groups — host-level UFW alone isn't enough.
If running a public RPC node, restrict ports 8989 / 8888 to specific IP allowlists — never leave them open to the world.
Audit firewall rules periodically: sudo ufw status verbose.
Block all other inbound ports by default; review any open ports against this table quarterly.

Operational Security

Separate the masternode owner wallet from day-to-day operational wallets
Use dedicated infrastructure — avoid sharing servers with other workloads
Complete KYC with a valid, current corporate or individual identity document
Maintain an incident response runbook for key compromise or node failure scenarios

7. Monitoring & Maintenance

Area	Recommendation
Node stats	Monitor via XinFin Stats (mainnet) or the masternode dashboard
Block explorer	XDCScan.io and XDCScan.com for transaction and validator monitoring
Third-party analytics	PrimeXDC Node Dashboard for independent node analysis
Token Terminal	Staking Market Cap · Number of Validators
Alerting	Set up alerts for peer count drops, missed block proposals, disk space thresholds, and memory/CPU usage
Software updates	Track the XinFinOrg GitHub repo and XDC developer forum for protocol upgrades. Coordinate upgrades promptly — late upgrades risk consensus incompatibility
Log management	Centralise Docker container logs; retain for debugging and audit purposes
Health checks	Automate periodic RPC health checks and block height comparisons against public explorers

8. Reward Economics (Indicative)

Metric	Value
Reward cycle	Every epoch (900 blocks / ~30 min)
Total block reward pool	86,400,000 XDC + transaction fees
Reward distribution	Proportional to blocks signed/validated in each epoch

Reward Split by Node Tier

Node Tier	Reward Share
Core Validator (Masternode)	10%
Protector Node	8%
Observer Node	4%

9. Deployment Quick-Start

Docker (recommended)

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

Follow the prompts to select mainnet, name your node, and generate or import your keys.

Testnet: Always test your setup on Apothem (apothem.network) before going live on mainnet.

Network Snapshots

Snapshots allow faster node synchronisation by downloading a pre-synced copy of the blockchain instead of syncing from genesis.

XDC Network Mainnet Snapshots:

Node Type	Download Link
Full Node	https://download.xinfin.network/xdcchain.tar
Archive Node	http://downloads.xinfin.network/xdcchain_archive.tar

Apothem Testnet Snapshots:

Node Type	Download Link
Full Node	http://downloads.apothem.network/xdcchain.tar
Archive Node	http://downloads.apothem.network/xdcchain_archive.tar

Applying a Snapshot

After downloading the snapshot, follow these steps to spin up your node. Run these commands from inside the XinFin-Node/mainnet/ directory (or testnet/ for Apothem):

# 1. Stop the running node (if already running)
bash docker-down.sh

# 2. Extract the snapshot — NOTE: use -xvf, not -xvzf
#    The xdcchain.tar is a POSIX tar archive, not gzipped
tar -xvf xdcchain.tar

# 3. Back up your existing chain data (safer than rm -rf)
mv xdcchain/XDC xdcchain/XDC_backup

# 4. Move the extracted snapshot into place
mv XDC xdcchain/XDC

# 5. Start the node back up
bash upgrade.sh

Important notes:

Do not use tar -xvzf — the snapshot is a POSIX tar archive, not gzipped, and the z flag will throw an error.
Keep the XDC_backup folder until you've confirmed the node is syncing correctly from the snapshot. Once verified, you can safely delete it to free disk space.
Always verify your coinbase.txt and keystore/ files are intact in xdcchain/ after the swap. If missing, restore them from your backup.
Monitor sync progress on stats.xinfin.network or xdcscan.io.

10. Compliance & Governance

All validators must pass KYC (PDF format, uploaded on-chain). Refer to the KYC Document Format for requirements
Entities with criminal records, anonymous identities, or intentions to fork are disqualified
Validators participate in governance voting on protocol upgrades and XIPs (XDC Improvement Proposals)
XDC 2.0 introduced a DAO structure with three chambers: Masternode Senate, Judiciary, and People's House
Network is aligned with MiCA (EU) regulatory standards and ISO 20022 financial messaging compliance

11. Frequently Asked Questions (FAQs)

Q: How much XDC do I need to run a masternode?
You need a minimum of 10,000,000 XDC staked to become a masternode candidate. There is no upper limit. Each masternode you operate requires its own separate 10M XDC stake.

Q: Can I run more than one masternode?
Yes. You can run as many masternodes as you wish, but each one must independently meet the 10M XDC staking requirement, have its own dedicated server infrastructure, and complete separate KYC.

Q: What is the maximum number of masternodes allowed on the network?
The network supports a tiered structure: 108 Core Validator nodes, 432 Protector Nodes, and 1,000 Observer Nodes — totalling 1,540 staked node slots. The top 108 most voted candidates become active Validators, the next 432 serve as Protector Nodes, and the following 1,000 are Observer Nodes.

Q: What happens if my masternode goes offline?
If your node goes down, it may be marked as "slashed." You will miss block rewards for the epochs your node is offline, and prolonged downtime can affect your standing in the validator set. Ensure your infrastructure is always operational.

Q: What is the difference between a Validator and a Standby node?
Validator Masternodes (108 per epoch) actively validate transactions and produce blocks. Standby Masternodes are identical in setup but remain on standby — they are activated only when the number of active Validators drops below 108.

Q: How are rewards distributed?
Rewards are paid every epoch (900 blocks / ~30 minutes). The total block reward pool is 86,400,000 XDC plus transaction fees. Core Validators receive 10%, Protector Nodes receive 8%, and Observer Nodes receive 4%. Within each tier, rewards are proportional to blocks signed and validated.

Q: Can I withdraw my staked XDC at any time?
No. If you resign from your masternode, there is a mandatory 30-day lock-up period before you can retrieve your staked 10M XDC.

Q: What happens if I lose my Coinbase address or Keystore file?
Losing your Coinbase address means your masternode becomes inaccessible, and you will need to resign from the network. Losing your Keystore or private key means your funds are permanently inaccessible and you will not receive any further rewards. Always maintain secure offline backups of both.

Q: Is KYC mandatory? What format is required?
Yes, KYC is mandatory for all masternode operators. You must upload a notarised proof of identity (individual or corporate) and address in PDF format. This information is visible on the public network. Refer to the KYC Document Format for full requirements.

Q: Who is disqualified from running a masternode?
Entities or individuals that are anonymous, have a criminal record, intend to fork the XDC software, or do not comply with local laws are disqualified from becoming masternode operators.

Q: Can I set up on Windows or do I need Linux?
Both are supported. You can use the One-Click Installer for Windows and Linux, or deploy via Docker (recommended for production). Supported Linux distributions include Ubuntu 24.04+, CentOS, and RHEL.

Q: Does my server need a public IP?
Yes. Your masternode must face the internet directly with a dedicated static public IP address, without NAT.

Q: Can I use a cloud provider / VPS instead of dedicated hardware?
Yes. A VPS is optional but highly recommended if you don't have dedicated hardware that meets the specs. Ensure your provider can deliver the required CPU, RAM, disk, and network uptime.

Q: Which ports should I open on my firewall?
Only port 30303 (TCP + UDP) should be open to the internet for a Validator, Protector, or Observer node. Keep your SSH port open for admin access (22 or a custom port), but block everything else including RPC (8989) and WebSocket (8888). Only open 8989 / 8888 if you are explicitly running a public RPC node, and restrict them to specific IP allowlists.

Q: Can I test the setup before going live on mainnet?
Yes. XDC provides a testnet called Apothem (apothem.network) where you can test your entire masternode setup without using real XDC. This is strongly recommended before deploying to mainnet.

Q: Are there third-party masternode hosting services?
Yes, there are third-party service providers that can help with setup and hosting. However, XDC Network does not officially endorse any third-party services — always perform your own due diligence before engaging one.

Q: Can institutional operators use custody solutions like Fireblocks?
Yes. Institutions and enterprises can use Fireblocks via WalletConnect v2 to manage masternode staking with MPC-based custody, governance automation, and transaction policy controls.

Q: How do I check my masternode status?
You can monitor your node via stats.xinfin.network (mainnet), the masternode dashboard, or the XDCScan block explorer at xdcscan.io.

Q: What are the common setup errors?
The two most common issues are: (1) outdated Docker — install docker-compose version 1.21+; (2) port conflicts — if port 30303 is already in use, terminate the existing container and try again.

Q: How does XDC handle DDoS and spam attacks?
While XDC's transaction fees are extremely low, they are not zero. This means flooding the network requires a significant amount of XDC, making sustained spam attacks economically impractical. The network also employs on-chain forensic monitoring to detect and penalise malicious behaviour.

Q: What is an epoch?
An epoch is a cycle of 900 blocks on the XDC Network, completing in approximately 30 minutes. Validator selection, reward distribution, and governance actions are all structured around epochs.

Q: What are network snapshots and why should I use them?
Snapshots are pre-synced copies of the blockchain database. Instead of syncing your node from the genesis block (which can take days), downloading a snapshot lets you get up and running much faster. They are available for both mainnet and the Apothem testnet, in Full Node and Archive Node variants.

Q: How do I use a snapshot to speed up node setup?
Stop your node, extract the downloaded xdcchain.tar (using tar -xvf, not -xvzf), back up the existing xdcchain/XDC folder, move the extracted XDC folder into xdcchain/, and restart your node with bash upgrade.sh. It will resume syncing from the snapshot's block height instead of from zero. Always verify the snapshot source matches the official XDC download links before use.

Q: What is the difference between the Full Node and Archive Node snapshot?
The Full Node snapshot contains the current blockchain state needed for normal validation and transaction processing. The Archive Node snapshot includes the entire historical blockchain data from genesis — it's significantly larger and is only needed if you run analytics, block explorers, or dApps that require deep historical queries.

12. Key Ecosystem Partners & Integrations

Partner / Integration	Role
SBI Holdings (Japan)	Trade finance joint venture; R3 Corda cross-chain PoC
Deutsche Telekom MMS	Infrastructure provider; operates a masternode
Circle (USDC / CCTP V2)	Native stablecoin and cross-chain transfer support
Archax	Regulated digital securities exchange; tokenised funds (BlackRock, State Street, Fidelity)
21Shares	XDC ETP on SIX Swiss Exchange (Ticker: XDCN); also listed on Euronext Amsterdam
Token Terminal	Institutional-grade on-chain analytics for XDC — integrated with Bloomberg Terminal for real-time dashboards, API access, and Data Room
Bloomberg Terminal	MVXDC index listed, providing professional-grade market access and institutional discovery for XDC
Securitize	U.S. Treasury tokenization (USTY)
Bitso	LATAM's largest crypto platform; cross-border remittance integration
Mercado Bitcoin	$15M+ fixed-income RWA token issuance on XDC
VERT Capital	Up to $1B in tokenised debt and receivables
Plug and Play	RWA Accelerator program (2 cohorts completed)
Kraken & Binance.US	Tier 1 exchange listings (2025)

Key References

Resource	Link
Official setup guide	https://xinfin.org/setup-masternode
Docker setup	https://xinfin.org/docker-setup
Node architecture docs	https://docs.xdc.network/xdcchain/developers/node_operators/node_architecture/
Tech specs	https://xdc.org/network/tech-specs
Developer forum	https://xdc.dev
GitHub	https://github.com/XinFinOrg/XinFin-Node
Testnet (Apothem)	https://apothem.network
Block explorer	https://xdcscan.io · https://xdcscan.com
PrimeXDC Node Dashboard	https://nodes.primexdc.com/
Bloomberg Terminal (21Shares ETP)	https://www.bloomberg.com/quote/XDCN:NA
Token Terminal (XDC analytics)	https://tokenterminal.com
Token Terminal — Staking Market Cap	https://tokenterminal.com/explorer/projects/xdc/metrics/staking-market-cap
Token Terminal — Number of Validators	https://tokenterminal.com/explorer/projects/xdc/metrics/number-of-validators
KYC document format	Google Doc
Mainnet Snapshot (Full Node)	https://download.xinfin.network/xdcchain.tar
Mainnet Snapshot (Archive Node)	http://downloads.xinfin.network/xdcchain_archive.tar
Testnet Snapshot (Full Node)	http://downloads.apothem.network/xdcchain.tar
Testnet Snapshot (Archive Node)	http://downloads.apothem.network/xdcchain_archive.tar