Developers Forum for XinFin XDC Network: Rushabh Parmar

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 to Speed Up XDC Network Node Sync Using Snapshots

Rushabh Parmar — Tue, 29 Jul 2025 14:01:27 +0000

Running a full node on XDCNetwork is crucial for decentralization, data verification, and direct interaction with the XDC Network. However, syncing a full node from scratch can be a time-consuming and resource-intensive process, potentially taking days or even weeks for archive nodes. This is where snapshots come in as a game-changer, offering a fast and efficient way to get your XDC Network node up and running.

This article will delve into what snapshots are, why they are essential for syncing, and provide a step-by-step guide on how to download and utilize them to set up a full node or archive node on the XDC Network.

What are Blockchain Snapshots?

In the context of blockchain, a *snapshot * is essentially a complete "photograph" of the blockchain's state at a specific block height. This snapshot captures all current account balances, smart contract states, and other relevant data, but crucially, it doesn't include the entire historical transaction data that led to that state. Think of it as having the finished painting without needing to re-watch every brushstroke.

Why are Snapshots Crucial for Syncing a Full Node or Archive Node on XDC Network?

The traditional method of syncing a full node or archive node on XDC Network involves downloading and verifying every single block from the genesis block (the very first block) up to the current one. This process requires significant computational resources and bandwidth. Snapshots offer several key advantages:

Faster Synchronization: By downloading a recent snapshot, your node can start from a pre-verified state, drastically reducing the sync time from days or weeks to hours. This allows new participants to join the network quickly and helps existing nodes recover faster from any disruptions.
Reduced Resource Consumption: Since you're not processing the entire blockchain history, snapshots minimize the CPU, memory, and bandwidth required for initial synchronization, making it more efficient to run nodes.
Improved Efficiency and Scalability: Faster node participation leads to a more distributed and robust network, contributing to overall network efficiency and scalability.
Enhanced Reliability: Snapshots provide a stable and verified starting point, reducing the potential for errors that can occur during a full blockchain download.

Essentially, snapshots provide a "shortcut" for nodes to quickly acquire the latest XDC Network state, enabling them to catch up and participate in the network much faster and with fewer resources.

Setting Up a Full Node on XDC Network with Snapshots: A Step-by-Step Guide

Prerequisites

A server or cloud instance (minimum 16 GB RAM, 1.5 TB storage)
Ubuntuoperating system
Basic Linux command-line knowledge

Setting up the Node Environment using Bootstrap

Its the primary options for setting up your XDC Network node environment: using the bootstrap.sh script for a quick setup

Using the Bootstrap Command for Quick Setup
This command automates the installation of necessary dependencies and sets up the basic node environment.

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

You will be prompted to enter:

XinFin Network (mainnet/testnet/devnet): Type mainnet for the main XDC Network.
XinFin MasterNode Name: Provide a name for your node (e.g.,Rushabh-Snapshot-Node).
Generate new private key and wallet address. If you have your own key, you can change after this and restart the node: Enter y or Y and continue

Once the installation on your Ubuntu server is complete, attach to the node using the following command to verify that the blockchain synchronization has begun

bash xdc-attach.sh

You can monitor the status of your node using the above command or by visiting the official stats page at https://xinfin.network/#stats Once you've confirmed that the node has begun syncing from the genesis block, stop the node by running:

bash docker-down.sh

After stopping your node, proceed to delete the existing XDC directory to prepare for the snapshot data

After deleting the XDC folder, you can now proceed to download and apply the latest snapshot.

To download the XDC Network Mainnet snapshot, use the appropriate command based on the type of node you’re setting up:

For a Full Node (latest state only): https://download.xinfin.network/xdcchain.tar
For an Archive Node (complete history): http://downloads.xinfin.network/xdcchain_archive.tar

Note: Snapshots are updated approximately every 20 days.

Once the xdc.tar file has been downloaded, extract the snapshot by running the following command:

tar -xvzf xdc.tar

This will unpack the archive and create the XDC directory containing the necessary blockchain data.

Once the XDC folder has been extracted, navigate into it and perform the following cleanup steps:

Delete the nodekey file:

rm -rf nodekey

Delete the transactions.rlp file:

rm -rf transactions.rlp

After removing these files, return to the mainnet directory and open the .env file.
In the configuration, locate the ENABLE_RPC variable and set it to true to enable RPC access:

ENABLE_RPC=true

In the .env file, you’ll find the ENABLE_RPC parameter set to false by default. Update it to enable RPC access by changing it to: ENABLE_RPC=true

If you are setting up a full node, you can now start your node without any additional changes.

However, if you are configuring an archive node, you must modify the start-node.sh script by adding the following flag: --

gcmode=archive

Note: This flag is only required for archive nodes to retain full blockchain history.

Once you've made the necessary changes, start your node with:

bash docker-up.sh

You can monitor your node’s status by attaching to the console using the following command:

bash xdc-attach.sh

Alternatively, you can view real-time sync progress and network activity on the official stats page:https://xinfin.network/#stats

If your node is not connecting to peers or you're experiencing issues with peer discovery, run the following command to manually connect to the network:

bash peer.sh

This will help your node establish connections with other active nodes on the XDC Network.

After executing the command, your node will begin establishing connections with peers on the XDC Network, allowing it to sync and participate in the network more effectively.

Accessing the RPC Endpoint: Once your node is fully synced, you can use its dedicated RPC endpoint.

The RPC port used is 8989.
The WebSocket port used is 8888.

If you've configured your server's firewall to allow external access to these ports (which is necessary for dApps to connect from outside your server), you would replace localhost with your server's public IP address or domain name.

Conclusion

Setting up a dedicated RPC node on the XDC Network, especially for DApps requiring high performance and reliability, is greatly simplified by leveraging snapshots. By following this comprehensive guide, you can efficiently set up and synchronize your XDC full node, providing a robust and responsive gateway for your decentralized applications to interact with the XDC blockchain. Snapshots are an invaluable tool for maintaining a healthy and efficient decentralized ecosystem, ensuring seamless communication and robust data management for developers and network operators alike.

Securely Broadcast Offline-Signed Crypto Transactions Across XDC, Ethereum, Bitcoin, Solana & XRP

Rushabh Parmar — Fri, 23 May 2025 07:37:51 +0000

In the evolving landscape of cryptocurrency, ensuring the security of transactions is paramount. Broadcasting raw, offline-signed transactions stands out as a robust method to safeguard private keys while maintaining transaction efficiency. The XDC Network's Raw Transaction Broadcast Tool offers a streamlined, non-custodial solution to propagate these transactions across multiple blockchains, including XDC, Ethereum, Bitcoin, Solana, and XRP.

🔐 Understanding Raw Offline Transactions

A raw transaction is a serialized data structure, often in hexadecimal format, encompassing all necessary transaction details—sender, recipient, amount, fees, and signatures—ready for network broadcast. When these transactions are signed in an offline environment, they become offline transactions, ensuring that private keys remain isolated from internet-connected devices. This approach enhances security by mitigating exposure to potential online threats.

🛡️ Benefits of Offline Signing

Enhanced Security: Private keys never touch online systems, reducing vulnerability to hacks and malware.
Improved Privacy: Offline signing keeps sensitive data away from internet exposure.
Hardware Wallet Compatibility: Seamlessly integrates with devices like Ledger, Trezor, and D'CENT for secure transaction signing.
Cold Storage Integration: Facilitates transactions from air-gapped systems without compromising key safety.

🌐 Introducing the XDC Raw Transaction Broadcast Tool

Accessible at https://broadcast.xinfin.network/build/raw-tx, this web-based utility empowers users to broadcast raw, signed transactions across multiple blockchain networks. Key features include:

Multi-Chain Support: Compatible with XDC, Ethereum, Bitcoin, Solana, and XRP networks.
Transaction Decoding: Automatically parses and displays transaction details for verification before broadcasting.
QR Code Functionality: Enables scanning of transaction data from offline devices, facilitating secure and error-free broadcasting.
Non-Custodial Design: Does not require private keys or wallet access, ensuring user control over funds.

🧭 Step-by-Step Guide to Broadcasting Transactions

Prepare Your Signed Transaction Offline: Utilize your preferred wallet or tool to create and sign the transaction in an offline environment, generating a raw transaction hex string.
Access the Broadcast Tool: Navigate to https://broadcast.xinfin.network/build/raw-tx on an internet-connected device.
Select the Appropriate Network: Choose the blockchain network corresponding to your transaction.
Input the Raw Transaction: Paste the signed transaction hex into the provided field or scan the QR code if available.
Verify Transaction Details: Review the decoded information to ensure accuracy.
Broadcast the Transaction: Click the "Publish" button to send the transaction to the selected network.
Confirm Submission: Upon successful broadcast, the tool will display the transaction hash for tracking purposes.

📸 Leveraging QR Code Functionality

The tool's QR code feature enhances the offline-to-online workflow:

Scanning: Easily import signed transactions from offline devices by scanning QR codes.
Sharing: Generate QR codes for transactions to facilitate secure sharing and storage.

🔒 Security and Non-Custodial Design Emphasis

Security is paramount when handling cryptocurrency transactions, and the XDC broadcast tool is built with that in mind. It is a non-custodial tool, meaning it never takes control of your assets or keys at any point. You do not create accounts or input private keys; you only input signed transactions, which by design cannot be used to derive your private key or alter your balance except as intended. This ensures that you retain full custody of your cryptographic keys and coins at all times.

🚀 Conclusion & Call to Action

Broadcasting raw offline transactions is a smart strategy for anyone serious about crypto security. The XDC Network's multi-chain broadcast tool makes this process accessible and convenient, whether you're sending an XDC transaction broadcast from a cold wallet, pushing an Ethereum raw transaction from a safe offline signer, or handling Bitcoin, Solana, or XRP transfers. By incorporating offline signing and this broadcast utility into your workflow, you gain peace of mind that your keys are safe while still enjoying the flexibility to transact on major blockchains.

Call to Action: Ready to enhance your crypto transaction security? Start using the raw transaction broadcast tool today. Head over to https://broadcast.xinfin.network/build/raw-tx and give it a try with a small test transaction. Experience how straightforward it is to broadcast raw crypto transactions offline. By adopting this tool, you're taking control of your crypto in the most secure way possible. Developers and power users alike are encouraged to incorporate offline signing and broadcasting into their workflow—let's make the crypto ecosystem safer, one offline-signed transaction at a time.

Disclaimer

Cryptocurrency transactions involve significant risks, including but not limited to market volatility, technological failures, and regulatory changes. Users are strongly advised to conduct their own research and consult with qualified professionals before engaging in any cryptocurrency activities.

XDC Safe Transaction Builder: Streamlining Multisig Transactions

Rushabh Parmar — Tue, 11 Feb 2025 11:51:55 +0000

Introduction

XDC Safe is a multisig wallet built for the XDC Network, designed to enhance security and streamline transactions for teams and organizations. In our latest update, we have introduced the Transaction Builder, a powerful tool that allows users to batch multiple transactions into a single confirmation process. This makes interacting with smart contracts and performing complex operations significantly more efficient.

What is the Transaction Builder?

The Transaction Builder in XDC Safe enables users to create and execute multiple transactions in a single batch, reducing manual confirmations and improving efficiency.

Key Features

Batch Transactions: Group multiple actions (such as token transfers, approvals, and contract calls) into one transaction, reducing execution steps.
User-Friendly Interface: A visual interface allows users to easily add, edit, and review transactions before execution.
Smart-Contract Interactions: Interact with any verified smart contract directly from XDC Safe.
Simulation Capabilities: Users can simulate transactions to preview the expected outcome and gas fees before execution.
**Security & Efficiency: **Reduces the number of on-chain interactions, enhancing security and optimizing transaction costs.

Why We Added the Transaction Builder to XDC Safe

XDC Safe was developed to provide seamless multisig functionality for XDC users, ensuring secure and efficient management of assets and contract interactions. The Transaction Builder further enhances this experience by allowing users to interact with smart contracts in a more streamlined way, eliminating the need to confirm each transaction separately.

How to Use the XDC Safe Transaction Builder

1. Access the Transaction Builder

Navigate to the New Transaction section in XDC Safe and select Transaction Builder.

2. Select a Smart Contract

Enter the XDC address of the smart contract you want to interact with.

3. Specify the ABI

For contracts verified on XDCScan Explorer, the ABI will be automatically fetched.
If not, manually enter the ABI in the provided input field.

4. Select a Method

Choose the method you wish to execute from the available contract functions.
XDC Safe supports both read and write functions.

5. Define Parameters

The interface will display the parameters for the selected method.
If necessary, enter values such as token amounts or recipient addresses.

6. Add to Batch

Click Add Transaction to include it in the batch.
You can continue adding multiple transactions before executing them all at once.

7. Review and Execute

Before submission, review the batched transactions.
You can also bookmark, download, or share the transaction batch with other signers for approval.

8. Confirm and Sign

Once reviewed, confirm the transaction.

Depending on your multisig setup, other signers will need to approve before execution.

Advantages of Using the XDC Safe Transaction Builder

✅ Efficiency: Reduce the number of confirmations needed for multiple transactions.
✅ Security: Minimizes the number of interactions, lowering potential attack surfaces.
✅ Cost-Effective: Reduces overall gas fees by bundling transactions.
✅ Seamless Collaboration: Share and execute transaction batches easily with multiple signers.

Conclusion

With the addition of the Transaction Builder, XDC Safe has become even more powerful, allowing users to interact with smart contracts efficiently and securely. This update ensures that teams and organizations managing funds and contracts on the XDC Network can streamline their processes while maintaining top-tier security.

💡 For any questions regarding XDC Safe or the XDC Network, feel free to engage with the community at XDC.dev

🔗 Start using the XDC Safe Transaction Builder today: XDC Safe 🚀

While XDC Safe offers a robust multisig experience, users exploring multisig solutions on the XDC Network can also try other wallets like Orry and Yodaplus Vault. Both platforms provide secure, multi-signature wallet management tailored for teams, allowing users to safeguard assets, co-sign transactions, and maintain control in a decentralized manner. Exploring these alternatives can help users choose the best fit for their specific workflow and governance needs

Disclaimer:

The information provided in this article is for educational and informational purposes only. It does not constitute financial, investment, or legal advice. Users are encouraged to conduct their own research and exercise caution when interacting with smart contracts and multisig wallets. While we strive to keep content accurate and up to date, we do not guarantee the security, functionality, or availability of any third-party tools or platforms mentioned, including XDC Safe, Orry, and Yodaplus Vault. Use at your own risk.

Update: XDC Apothem Network Experiences Surge in Traffic: Public RPC Update

Rushabh Parmar — Thu, 05 Sep 2024 16:12:03 +0000

On 4th September, the XDC Apothem Network’s public RPC (https://erpc.apothem.network) experienced temporary downtime due to increased traffic. Over 24 hours, the public RPC saw 17.15 million hits, which made the service unavailable for some users.

In response, the DevOps team quickly addressed the issue. They started by adding a node balancer and deploying multiple additional nodes across all public RPC endpoints. This step aims to distribute traffic more evenly and avoid similar problems in the future.
A rate limit has been applied to the public RPC to protect the network from DDoS attacks further. If users encounter a rate limit when connecting, it is recommended that they set up a dedicated RPC for a more stable and reliable connection. For details on setting up a dedicated RPC, refer to the guide here: https://www.xdc.dev/ruslan_wing/setting-up-an-rpc-node-server-for-your-dapp-on-xdc-network-a-comprehensive-guide-3dm9.

For Non-Technical Users:
If you’re a non-technical user, you can also get a paid dedicated RPC (for Mainnet or Apothem Network) from third-party providers like Ankr, Indsoft, Blocksscan, NowNodes, Tatum, or Asternodes. These providers offer reliable services without the need to set it up yourself.
These steps should help prevent future downtime and improve the overall stability of the public RPC.