Developers Forum for XinFin XDC Network


Posted on • Updated on

[Feedback] The Pitfalls of Developing on XDC Network: A Critical Assessment

Developing on the XDC Network has been a challenging and, frankly, disappointing experience for many developers. Despite its claim to EVM compatibility, the stark reality is that most code that runs smoothly on other EVM chains hits a wall on XDC's mainnet.

  1. Non 100% EVM Compatibility
    A significant drawback of the XDC Network is its inconsistent EVM compatibility. While it professes to support the Ethereum Virtual Machine (EVM), developers have encountered numerous issues deploying their smart contracts. This inconsistency not only creates frustration but also raises questions about the network's reliability and developer-friendliness.

  2. Lack of Developer Support and Tools
    The lack of comprehensive developer tools, particularly blockchain explorers, significantly hampers the development experience on XDC. These tools are slow, error-prone, and fail to provide the necessary support for efficient smart contract deployment and debugging. This deficiency, coupled with a dearth of support from the broader EVM ecosystem, deters developers from fully leveraging the XDC Network.

  3. Limited Community Grants and Funding
    The absence of substantial grants and funding opportunities for projects on the XDC Network further exacerbates its shortcomings. While initiatives like DAOFIN may promise a change, the current lack of financial support stifles innovation and limits the growth potential of projects within the ecosystem.

  4. Unclear Positioning: Layer 1 or Private Blockchain?
    The ambiguity surrounding XDC's positioning as either a Layer 1 blockchain or a private network focused solely on trade finance raises concerns about its long-term viability. Without a clear strategic direction, developers are left uncertain about the network's future trajectory and its suitability for their projects.

  5. Inadequate Blockchain Explorers and RPC Stability
    The subpar quality of blockchain explorers, exemplified by Blocksccan, further compounds the challenges faced by developers on XDC. Incomplete or inaccurate information provided by these explorers undermines transparency and usability, making them unsuitable for institutional use. Additionally, the instability of RPCs exacerbates development difficulties and hampers project scalability.

In conclusion, while the XDC Network may boast certain advantages, such as a dedicated community, its numerous shortcomings and unresolved issues pose significant barriers to widespread adoption and developer confidence. Addressing these challenges is crucial for the network to realize its potential and establish itself as a credible competitor in the blockchain landscape.

Discussion (7)

supersnips profile image
  • The XDC Network is a robust Layer-1 (and has always been a Layer-1) committed to innovation and supporting a diverse range of decentralized applications across various industries. The network's design facilitates the effective use of public RPC and WebSockets on the Apothem Test network, which has proven to be reliable for Layer-2 projects and developers, particularly highlighted during Hackathons, without significant issues.
    Encountered issues can ALWAYS be raised in Github to be resolved ASAP. It is important to report issues, so that XDC Devs can look into it.

  • The XDC Network's ecosystem is vibrant and continuously expanding. This ecosystem is supported by a variety of developer tools and resources designed to streamline the development process. Detailed Feedback is always appreciated, so that it can be updated/fixed, if there is any issue encountered or you would like to see different tools.

  • Check out the Ecosystem projects here: , there are so many non-Tradefinance dApps and the list is continuously growing.

  • XDC Network actively seeks to support projects through various initiatives, including DAOFIN. The strategic positioning as a Layer-1 blockchain is clear and focused, dedicated to being at the forefront of blockchain technology. Grant Applicants need to reflect this. Innovation and an mvp goes a long way...

On a sidenote- Only heard really good Feedback so far regarding ANKR integration, look into it:

annondev profile image
AnnonDEV Author • Edited on

Lets start with this, deploy this on mainnet withour using ANKR RPC. (one RPC in whole blockchain works with this):

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

/// @title Migration contract
/// @author FreezyEx (
/// @notice A contract to migrate from old to new token version

abstract contract Context {
function _msgSender() internal view virtual returns (address payable) {
return payable(msg.sender);

function _msgData() internal view virtual returns (bytes memory) {
    this; // silence state mutability warning without generating bytecode - see
Enter fullscreen mode Exit fullscreen mode


interface IERC20 {
function decimals() external view returns (uint256);
function totalSupply() external view returns (uint256);
function balanceOf(address account) external view returns (uint256);
function transfer(address recipient, uint256 amount) external returns (bool);
function allowance(address owner, address spender) external view returns (uint256);
function approve(address spender, uint256 amount) external returns (bool);
function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);

abstract contract ReentrancyGuard {
uint256 private constant _NOT_ENTERED = 1;
uint256 private constant _ENTERED = 2;

uint256 private _status;

constructor() {
    _status = _NOT_ENTERED;

modifier nonReentrant() {
    require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
    _status = _ENTERED;
    _status = _NOT_ENTERED;
Enter fullscreen mode Exit fullscreen mode


contract Ownable is Context {
address private _owner;
address private _previousOwner;

event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

constructor () {
    address msgSender = _msgSender();
    _owner = msgSender;
    emit OwnershipTransferred(address(0), msgSender);

function owner() public view returns (address) {
    return _owner;

modifier onlyOwner() {
    require(_owner == _msgSender(), "Ownable: caller is not the owner");

function renounceOwnership() public virtual onlyOwner {
    emit OwnershipTransferred(_owner, address(0));
    _owner = address(0);

function transferOwnership(address newOwner) public virtual onlyOwner {
    require(newOwner != address(0), "Ownable: new owner is the zero address");
    emit OwnershipTransferred(_owner, newOwner);
    _owner = newOwner;
Enter fullscreen mode Exit fullscreen mode


contract Migrate is ReentrancyGuard, Context, Ownable{

// we want to track who has already migrated to V2
mapping(address => bool) private claimed;
address public immutable deadWallet = 0x000000000000000000000000000000000000dEaD;

IERC20 public tokenV1; //address of the old version
IERC20 public tokenV2; //address of the new version
uint256 public rate; // 1 token V1 ---> 1 * rate token V2

bool public migrationStarted;

/// @notice Emits event every time someone migrates
event MigrateToV2(address addr, uint256 amount);

/// @param tokenAddressV1 The address of old version
/// @param tokenAddressV2 The address of new version
/// @param _rate The rate between old and new version
constructor(IERC20 tokenAddressV1, IERC20 tokenAddressV2, uint256 _rate) {
    tokenV2 = tokenAddressV2;
    tokenV1 = tokenAddressV1;
    rate = _rate;

/// @notice Enables the migration
function startMigration() external onlyOwner{
    require(migrationStarted == false, "Migration is already enabled");
    migrationStarted = true;

/// @notice Disable the migration
function stopMigration() external onlyOwner{
    require(migrationStarted == true, "Migration is already disabled");
    migrationStarted = false;

/// @notice Updates "tokenV1", "tokenV2" and the "rate"
/// @param tokenV1addr The address of old version
/// @param tokenV2addr The address of new version
/// @param _rate The rate between old and new version
function setTokenV1andV2(IERC20 tokenV1addr, IERC20 tokenV2addr, uint256 _rate) external onlyOwner{
    tokenV1 = tokenV1addr;
    tokenV2 = tokenV2addr;
    rate = _rate;

/// @notice Withdraws remaining tokens
function withdrawTokens(uint256 amount) external onlyOwner{
    require(migrationStarted == false, "Impossible to withdraw tokens if migration still enabled");
    tokenV2.transfer(msg.sender, amount * 10**(tokenV2.decimals()));

/// @param v1amount The amount of tokens to migrate
/// @notice Migrates from old version to new one
///   User must call "approve" function on tokenV1 contract
///   passing this contract address as "sender".
///   Old tokens will be sent to burn
function migrateToV2(uint256 v1amount) public nonReentrant(){
    require(migrationStarted == true, 'Migration not started yet');
    uint256 amount = v1amount * 10 ** tokenV1.decimals();
    uint256 userV1Balance = tokenV1.balanceOf(msg.sender);
    require(userV1Balance >= amount, 'You must hold V1 tokens to migrate');
    uint256 amtToMigrate = v1amount * rate * 10 ** tokenV2.decimals();
    require(tokenV2.balanceOf(address(this)) >= amtToMigrate, 'No enough V2 liquidity');
    tokenV1.transferFrom(msg.sender, deadWallet, amount);
    tokenV2.transfer(msg.sender, amtToMigrate);
    emit MigrateToV2(msg.sender, amtToMigrate);
Enter fullscreen mode Exit fullscreen mode


ruslan_wing profile image
ruslan wing

Here is the list of the Public RPC on XDC Network you need to select the RPC according to your smart contract if you are using Hardhat, metamask, Truffle, Ethereum remix or any other tool which require 0x prefix address output then you need to use ERPC and if you want 0x prefix address output you can use any public RPC

All the RPC are available on XDC Network according to the Developer requirement. User just need to select the correct RPC

Link to the detail guide

annondev profile image
AnnonDEV Author

99% of the errors on the explorers. Total generic error. Not able to identify the error.

timmor90 profile image

Pretty much spot on, and VERY confusing when dealing especially with deployments that havent has an issue on other chains.

Erpc, not erpc, the blockexplorer, the biggest frustration is that no one seems to have an answer why it doesnt work.

Why does the explorer not track or display all transaction or data properly? This should be the backbone of any network.

sean_ profile image

Thanks for posting this and we appreciate the critical feed back. We understand that you must have faced some issue but without the context like what tools you used and what errors you faced it becomes hard for us to understand the issues and hence the challenge to work on it.

If you can share the screenshots of the issues and errors faced and the the steps to reproduce the same, we will really appreciate it.

vrushali_panchal profile image
Vrushali Panchal

Thank you for pointing this out. We appreciate the effort put into analyzing and assessing the challenges developers may face while working on the XDC Network. Your insights are valuable to us as we strive to improve the platform and provide better experiences for developers and users alike.

Could you please share a brief summary of all the issues mentioned, along with steps to reproduce them?