Developers Forum for XinFin XDC Network: AnilChinchawale

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

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

The Most Significant XDC Protocol Upgrade in Years

Published: January 2026

🚀 Executive Summary

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

🎯 Why This Release Matters

1. EIP-1559: Revolutionary Fee Market

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

Before (Legacy):

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

After (EIP-1559):

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

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

2. Cancun Instruction Set: Future-Ready EVM

XDC now supports the complete Ethereum Cancun upgrade, including:

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

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

3. Blob & KZG Cryptography Support

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

BLOBHASH opcode implementation
KZG cryptographic primitives
Blob transaction handling groundwork

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

4. Enterprise-Grade Stability

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

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

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

📊 Technical Deep Dive

EVM Performance Improvements

The v2.6.8 release includes substantial EVM optimizations:

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

New RPC Capabilities

Operators gain new tools for node management:

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

# New epoch information
xdpos_getBlockInfoByEpochNum(epochNumber)

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

Security Enhancements

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

🔧 What Developers Need to Know

Solidity v0.8.28 Support

You can now use the latest Solidity features:

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

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

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

Updated Gas Estimation

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

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

Chain Configuration

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

🏗 For Masternode Operators

Mandatory Upgrade

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

# Upgrade command
cd mainnet && bash upgrade.sh

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

New Configuration Options

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

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

# Increased default max peers
# Now defaults to 50 peers

Deprecated Flags (Remove from configs)

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

📈 Impact on XDC Ecosystem

For DeFi Protocols

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

For Enterprise Users

Improved reliability and uptime
Better cost predictability
Enhanced security guarantees

For Layer 2 Development

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

For Token Economics

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

🗓 Timeline

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

🔮 What's Next

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

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

📚 Resources

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

🎉 Conclusion

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

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

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

A 24/7 AI Assistant for XDC Network… Running Cheaper Than Your Netflix Plan

AnilChinchawale — Sun, 25 Jan 2026 18:29:04 +0000

How @askXDCbot is Revolutionizing Blockchain Community Support — And Why You Don't Need Expensive Infrastructure to Do the Same

The $5 AI Revolution

What if I told you that you could build an AI assistant that:

Answers thousands of questions daily
Works 24/7 without breaks
Speaks 50+ languages fluently
Costs less than a Netflix subscription

You'd probably think I'm exaggerating. I'm not.

Meet @askXDCbot — the AI-powered assistant for XDC Network that runs on a basic $5/month VPS. No GPU clusters. No Kubernetes. No Mac Mini. Just a simple server and the right tools.

The Problem We Solved

Every growing blockchain community faces the same challenge: the same questions get asked hundreds of times a day.

"What's the RPC endpoint?"
"How do I add XDC to MetaMask?"
"What are the masternode requirements?"

Community managers spend hours answering repetitive questions. New members wait for responses that sometimes never come.

There had to be a better way.

Enter askXDC: AI That Actually Helps

For Newcomers: Explains XDC in simple terms, guides wallet setup
For Developers: RPC endpoints, smart contract guides, code snippets
For Node Operators: Hardware specs, Docker commands, snapshot links
For Enterprises: Trade finance, RWA tokenization, compliance details

Try it: t.me/askXDCbot

The Infrastructure Myth: Busted

When people think about AI, they imagine massive GPU clusters and $10K/month cloud bills.

The Reality

What You Need	Specs
CPU	1–2 cores
RAM	1–2 GB
Cost	$5–15/month

The AI runs on Anthropic's servers. Your server just routes messages. A Raspberry Pi could handle it.

Where You Can Run This

☁️ $6/month DigitalOcean droplet
☁️ €4/month Hetzner VPS
💻 Your old 2015 MacBook
🥧 A Raspberry Pi 4
🖥️ That dusty office server

No excuses. Just build.

The Secret: Clawdbot

Clawdbot is the open-source framework powering askXDC.

It connects Claude AI to:

✅ Telegram
✅ Discord
✅ WhatsApp
✅ Slack
✅ Web interfaces

One brain. Every platform.

GitHub: github.com/clawdbot/clawdbot

10-Minute Setup

# Install
npm install -g clawdbot

# Setup
clawdbot onboard

# Launch
clawdbot gateway start

That's it. Your AI assistant is live.

Real Costs

Item	Monthly
VPS	$10–15
AI API	$5–50
Total	$15–65

vs. Human support: $3,000–5,000/month

Why XDC Needed This

XDC Network is building trade finance infrastructure with:

2,000+ TPS
Near-instant finality
Near-zero fees
ISO 20022 compatibility

But technology doesn't matter if people can't understand it.

askXDC bridges that gap. Instant answers. 24/7. Any language.

Try It Now

🤖 Bot: t.me/askXDCbot
🛠️ Build Your Own: github.com/clawdbot/clawdbot

Building the future of blockchain doesn't require millions in funding. Sometimes it just takes a $5 server and the right idea.

XDC Network v2.6.8 Cancun Upgrade: A Leap Forward in Performance and Compatibility

AnilChinchawale — Thu, 15 Jan 2026 12:07:47 +0000

The XDC Network has officially rolled out its v2.6.8 update, codenamed Cancun, marking a significant milestone in the evolution of this enterprise-grade blockchain platform. This release introduces full support for Ethereum’s Cancun hard fork features—including EIP-1559 activation on mainnet, improved EVM optimizations, and foundational upgrades supporting future scalability.

Built on the Delegated Proof-of-Stake (DPoS) consensus model, this release enhances stability, efficiency, and compatibility with modern smart contract development tools and infrastructure.

You can track the upcoming activation block at the following countdown link:
🔗 https://xdcscan.io/block/countdown/98800200

🔗 https://xdcscan.com/block/countdown/98800200

This article highlights the major features, fixes, and improvements from the v2.6.8 Cancun Upgrade.

🚀 Key Highlights of the Upgrade

This release aligns XDC more closely with upstream Ethereum advancements while preserving its strengths in high-throughput enterprise applications.

1. EIP-1559 Activation on Mainnet

Scheduled for block #98,800,200.
Introduces dynamic fee markets for:
- Predictable gas pricing
- Reduced spam
- Base fee + burn mechanism

2. EVM Performance Boosts

Reduced memory consumption.
Faster contract execution.
Optimized opcode performance.

3. Stability Enhancements

Fixes implemented in:

Transaction pool behavior
Consensus edge cases
RPC performance
Block production

4. Solidity v0.8.28 Compatibility

Developers can utilize the latest Solidity compiler features.
Improved safety, overflow checks, and optimized bytecode.

5. Codebase Modernization

Upgraded internals include:

Migration to Go 1.23
Enhanced CI/CD
Extensive static analysis and linting
Cleaner, more maintainable repository

Upgrade Instructions for Node Operators

From mainnet directory, run:

bash upgrade.sh

This ensures a smooth transition to the new protocol rules.

⚙️ Protocol and EVM Enhancements

Key Ethereum Improvement Proposals added:

EIP-1559

Introduces base fee + tip model
More stable gas market
Integrated burn mechanism for long-term supply dynamics

EIP-1153 — Transient Storage

Reduces gas by allowing temporary, transaction-scoped storage

Additional EIPs Included

EIP-2565: Cheaper ModExp precompile
EIP-3651: Warm coinbase optimization
EIP-5656: MCOPY opcode for efficient memory copying
EIP-6780: Modified SELFDESTRUCT semantics
EIP-7516: BlobGas changes for prototype scalability models

These enhancements strengthen the XDC–Ethereum compatibility layer and support scalable HyFi (Hybrid Finance) applications.

🔧 Core Improvements and Bug Fixes

VM Refinements

Split of vm.Context into BlockContext and TxContext
Decreased memory allocations
Streamlined precompile and trace logic
Removed obsolete interfaces

Optimization Enhancements

Better jump destination analysis
Faster log and event handling
Improved gas estimation accuracy

Key Bug Fixes

Corrected blockHash returns in eth_getLogs
Resolved txpool overflows and block stall issues
Fixed divide-by-zero and nil pointer errors
Corrected “xdc”-prefix address encoding
Addressed consensus-based vote duplication
Eliminated redundant metrics
Improved downloader edge-case efficiency

Collectively, these updates deliver improved reliability—critical for supply chain, trade finance, and enterprise-grade operations.

🕸 Consensus, Networking & RPC Upgrades

Consensus Upgrades

Enforced signer uniqueness (prevent duplicates)
Better epoch timeout handling
Improved logging around consensus failures

Networking Enhancements

New RPCs:
- admin_addTrustedPeer
- admin_removeTrustedPeer
Default max peers increased to 50
HTTP + WebSocket on single port support
Metrics added for P2P dial attempts

RPC and CLI Extensions

New flag: --rpc-gascap (default 50M)
More accurate EstimateGas behavior
New DB ops:
- stats, compact, inspect, get, put, delete
Read-only DB mode
Improved chain config reporting
New API: xdpos_getBlockInfoByEpochNum

🧹 Code Quality, Tooling, and Network Deployments

Codebase Cleanup

Staticcheck applied across SA/ST/S-series warnings
Removal of deprecated Go API usage
Migration from ioutil to embed
Simplified database layers with dedicated rawdb

Build and CI Enhancements

Go toolchain → 1.23
golangci-lint → v1.63.4
Enforced:
- go mod tidy
- go generate
Migrated CLI to urfave/cli/v2

Devnet/Testnet Improvements

Updated gas limits (50M)
Better recovery logic
Updated bootnode lists
Efficient private networking

❌ Deprecations and Security Enhancements

Deprecated Components

Removed:

CLI flags
- --mine, --fast, --light, --XDCx-datadir
Whisper & ENS packages
Mobile builds (iOS/Android)
Legacy genesis files

Security Hardening

Applied CertiK audit fixes
Strengthened signature recovery
Upstream-aligned sender validation

Operator Warning — Hard Fork

All nodes must update before block #98,800,200, else they risk:

Consensus divergence
Invalid block production
RPC inconsistencies

📌 Final Thoughts

The v2.6.8 Cancun Upgrade reinforces XDC’s long-term focus on:

High performance
Enterprise readiness
Strong developer tooling
Ethereum compatibility
Secure and stable protocol evolution

This release lays the groundwork for advanced use cases in:

Real-world asset tokenization
Global trade finance
Cross-border settlements
High-throughput dApps

For full technical details, refer to the official GitHub release page.

test

AnilChinchawale — Mon, 24 Nov 2025 06:03:08 +0000

Fiat on-ramps like FinchPay make the process of cryptocurrency simple and safe for the end user.

🔧 Scaling Open-Source Collaboration: XDC Network GitHub Code Contribution & Review Workflow

AnilChinchawale — Wed, 02 Jul 2025 07:03:04 +0000

At the heart of any thriving open-source ecosystem lies a well-defined contribution workflow—one that promotes transparency, accountability, and high-quality code. To keep up with the growth of our developer community, we’re standardizing how code gets contributed, reviewed, and merged into our repositories.

Whether you’re a core contributor or just getting started, this guide outlines how we collaborate effectively on GitHub—and how that directly strengthens the XDC Network.

🚀 Step 1: Raise an Issue for Every Suggestion or Feature

All ideas begin with a conversation. That starts with a GitHub Issue.

🛠 Found a bug?
💡 Have a new feature in mind?
🧩 Want to propose an optimization or refactor?

👉 Create an issue in the appropriate GitHub repository before writing any code.

This ensures:

Transparent discussion and feedback
Avoidance of duplicate efforts
Alignment with the broader XDC Network roadmap

Each pull request (PR) must reference the related issue using Closes #123 or Fixes #456.

👩‍💻 Step 2: Code Contribution Flow

Contributors

Anyone—including Amanda, Liu Dan, Nolan, Galaxy Tarun, and the wider community—can contribute using this workflow:

Fork the repository and create a new branch from dev.
Implement your changes (bug fix, feature, or enhancement).
Write clear commit messages and follow code standards.
Submit a PR to the dev branch with:
- A link to the related issue
- A clear summary of the change
- Tags indicating if it’s a feature, fix, or breaking change

🚨 Breaking Changes

If your PR introduces breaking changes:

Add BREAKING CHANGE to the title and description
Provide documentation or migration instructions
Request explicit approval from Fisher

🔍 Step 3: Review & Approval

Reviewers

All PRs must be reviewed and approved by at least two of the following reviewers:

Liam
Wanwiset
AnilChinchawale

They will:

Review code quality and security
Validate against architectural guidelines
Approve when standards are met

No PR will be merged without 2 reviewer approvals.

⚙️ Step 4: Merge & Release

After review and approval:

The PR is merged into the dev branch.
Final merges into main happen via our release cycle and CI/CD.
All merges are traceable, auditable, and well-documented.

🌍 How This Supports the XDC Network

This workflow directly supports the growth, visibility, and reliability of the XDC Network:

📈 Improves visibility of network development across the ecosystem
🧠 Encourages innovation from contributors worldwide
🔗 Builds trust with enterprises, node operators, and ecosystem partners
📣 Signals transparency and openness to the global blockchain community

Every merged PR becomes public proof of collaboration, fostering community confidence and helping attract new talent, researchers, and integration partners.

💬 Summary

This workflow ensures:

High-quality, secure, and scalable code
Transparent contributor onboarding
Strict controls for breaking changes
Clear governance over core protocol development

🧠 Final Thoughts

Open-source is a team sport. With this workflow, we’re not just managing code—we’re building a movement.

If you're ready to contribute or just want to understand the process, open an issue and dive in. Together, we’ll continue to grow the XDC Network—securely, scalably, and openly.

XDC v2.5.0-beta1: Enhancing Performance, Security & Compatibility

AnilChinchawale — Tue, 04 Feb 2025 07:11:01 +0000

⏳ Scheduled Upgrade: Feb 14, 2025 at Block 71550000

The XDC upgrade brings significant improvements to the XDC Network, focusing on efficiency, Ethereum compatibility, and developer experience.

🔥 Key Enhancements:

1️⃣ Performance & EVM Optimization

Optimized VM execution by reducing redundant computations
Improved EVM reusability for better efficiency
New structured BlockContext & TxContext

2️⃣ Ethereum EIPs Implemented

EIP-1559: Dynamic gas fee structure
EIP-2565: Lowered gas cost for modular exponentiation
EIP-3651: Warm coinbase for gas efficiency
EIP-1153: Transient storage for contracts

3️⃣ RPC & API Enhancements

xdpos_getBlockInfoByEpochNum API added
Gas cap set to 50M via rpc-gascap flag
Admin tools: addTrustedPeer & removeTrustedPeer
Improved EstimateGas accuracy

4️⃣ Security & Code Refactoring

Fixed high pending special transactions issue
Fixed node memory leaks in AccountsManager
Standardized string formatting & removed unused imports

5️⃣ Network & Deployment Updates

WebSocket & HTTP can now share the same port
Increased max peers to 50
Reduced mainnet/testnet timeout to 10s
Bootnodes list updated
Upgraded to Go 1.22

📢 Node Operators & Developers – Upgrade Ready?

Stay tuned for the official upgrade guide and test compatibility early!

🔗 Full Release Notes: GitHub

XDC 2.0 Mainnet Release: Key Features and Enhancements

AnilChinchawale — Wed, 28 Aug 2024 09:25:20 +0000

Introduction

The blockchain ecosystem is set to experience a significant upgrade with the launch of XDC 2.0 on October 2, 2024, at block number 80370000. This mainnet release introduces several enhancements aimed at improving the network's efficiency, security, and user experience. One of the key highlights of this upgrade is the XDPOS Consensus Upgrade 2.0, which promises to revolutionize the way transactions are processed and validated.

Main Feature Introduced

The main feature of XDC 2.0 is the XDPOS Consensus Upgrade 2.0. This upgrade aims to enhance the consensus mechanism, ensuring more secure and faster transaction validations. The new consensus model incorporates advanced algorithms to increase the efficiency of the network while maintaining its decentralized nature. This upgrade is crucial for accommodating the growing number of transactions and users on the platform.

Increase in Transaction Fees

With the XDC 2.0 upgrade, there will be a 50x increase in transaction fees starting from block number 80370000. While an increase in fees might initially raise concerns, it is essential to highlight that this change comes with significant benefits for the network and its users.

Before the Upgrade

Actual Transaction Cost/Fee: 0.0002265948 XDC ($0.00000637)

After the Upgrade

Actual Transaction Cost/Fee: 0.0044273125 XDC ($0.00012928)

Positive Impact on Masternode Owners
The increased transaction fees mean higher rewards for masternode owners. This incentivizes more participants to become masternodes, thereby enhancing the network's decentralization and security. Higher rewards will attract more validators, leading to a more robust and resilient blockchain network.

Maintaining Affordable Transaction Fees
Despite the increase, transaction fees on the XDPOS network will remain competitively low compared to other blockchain platforms. The upgrade ensures that users continue to enjoy affordable transaction costs while benefiting from a more secure and efficient network.

Disabling XDCx

Another significant change in this upgrade is the disabling of XDCx, effective from block number 80370000. This move aims to streamline the network operations and eliminate complexities associated with XDCx. By disabling XDCx, the network can focus on enhancing core functionalities and ensuring a smoother user experience.

Patch Implementations

The XDC 2.0 upgrade includes the implementation of several important patches:
EIP-2718: Standardizes transaction types, making it easier to add new transaction types in the future.
EIP-2930: Introduces access lists to improve transaction execution efficiency.
EIP-2929: Increases gas costs for certain operations to mitigate denial-of-service attacks.

New Methods and Features

The upgrade also brings new methods and features to the network:
debug_traceCall: Allows detailed tracing of transactions for debugging purposes.
eth_getBlockReceipts: Retrieves all receipts for a given block.
eth_GetTransactionAndReceiptProof: Provides proof of a transaction and its receipt, enhancing transparency and trust in the network.

What's Changed

Several technical improvements and fixes have been made to the network, including:

Adding missing checks in the consensus mechanism to ensure network integrity.
Enhancing logging capabilities with deep copy functionality.
Implementing workflows for EC2 RPC nodes for better scalability.
Fixing various bugs and improving parameter handling for smoother operations.
Renaming and updating functions to improve clarity and functionality.
Enabling the 0x address scheme by default, with an option to enable the xdc prefix flag.
Adding new block location fields to receipts for better traceability.

Steps to upgrade the XDC Mainnet Node: Choose Method 1 or Method 2

Method 1: Upgrade via Script

Navigate to the mainnet directory:

cd XinFin-Node/mainnet

Run the upgrade script:

bash upgrade.sh

Method 2: Manual Upgrade Command

Navigate to the mainnet directory:

cd XinFin-Node/mainnet

Pull the latest changes from the repository:

git pull

Stop the current Docker containers:

sudo docker-compose -f docker-compose.yml down

Pull the latest Docker image:

sudo docker pull xinfinorg/xdposchain:v2.0.0

Start the Docker containers with the updated image:

sudo docker-compose -f docker-compose.yml up -d

To verify that your node is running XDC v2.0.0, execute the following command:

sudo bash xdc-attach.sh

Conclusion

The XDC 2.0 mainnet release marks a significant milestone for the blockchain network. With its advanced consensus upgrade, increased rewards for masternode owners, and various technical improvements, XDC 2.0 is set to enhance the overall performance, security, and user experience. While transaction fees are increasing, they remain competitively low, ensuring that the network continues to be accessible and affordable for all users. The future of XDPOS looks promising as it continues to innovate and lead in the blockchain space.

Contract Verification issue in Apothem Explorer?

AnilChinchawale — Mon, 26 Aug 2024 08:20:51 +0000

Hello XDC Community,

We’ve recently received a query regarding issues with contract verification on the Apothem network. To help our developers investigate and resolve this matter, we kindly request those experiencing this issue to share the detailed steps they followed when the problem occurred.

Your input will be invaluable in helping us pinpoint the issue and provide an effective solution as quickly as possible.

Thank you for your cooperation and continued support!

Best regards,
Anil Chinchawale
XDC Network Team

[Informative] Stay Ahead: XDC Network Prepares for Solidity 0.8.23 Integration on XDC Mainnet – Upgrade Details Inside!

AnilChinchawale — Thu, 16 May 2024 08:27:50 +0000

The XDC Network team has announced an upcoming upgrade to the Ethereum Virtual Machine (EVM) used by the XDC Network's Mainnet, aimed at supporting the latest version of the Solidity smart contract programming language, version 0.8.23. This upgrade is a pivotal step to align with the latest advancements in the Ethereum ecosystem and ensure compatibility with the newest features and security enhancements introduced in Solidity 0.8.23. Following successful testing on the Apothem Network (Testnet) for a duration of more than two months, the team is preparing for a seamless transition to the upgraded EVM on the Mainnet.

GitHub discussion

Some of the key features and improvements in Solidity 0.8.23 include:

EVM Upgrade 0.8.23
API Improvement eth_getAccountInfo / eth_estimateGas / eth_getLogs
Security Patch
EIP Patch
Support for custom errors and improved error handling
Improved code generation for smaller and more efficient bytecode
Better support for contract inheritance and virtual functions
Enhanced security features, such as stricter compiler checks and new language constructs for safer programming

Proposed changes

Proposed Changes in detail: https://github.com/XinFinOrg/XDPoSChain/releases/tag/v1.6.0

Hard Fork Release on XDC Mainnet
Target Date: 19 June 2024
Block Number: 76321000
Main feature: Support EVM 0.8.23

By upgrading the XDC EVM to support Solidity 0.8.23 and implementing these EIPs, developers building on the XDC Network will be able to leverage the latest features and improvements in the Solidity language, as well as benefit from the performance and security enhancements introduced by these EIPs. This upgrade will also ensure that the XDC Network remains compatible with the latest developments in the Ethereum ecosystem, as many popular tools, libraries, and frameworks are also being updated to support the newer versions of Solidity and the Ethereum London upgrade.

The XDC Network’s Protocol team deserves appreciation for their continuous efforts to improve and enhance the XDC Network’s protocol. They have been actively listening to feedback from the community and developers who participated in the XDC Network’s hackathons. By incorporating these valuable insights, the XDC Network team is committed to delivering a robust and developer-friendly ecosystem for building decentralized applications.

Developers building on the XDC Network are encouraged to follow the official channels and stay updated on the progress of this upgrade, as well as prepare their smart contracts and projects to be compatible with the new Solidity version once the upgrade is complete.

Community Call to Action:

XDC Network urges its community members, including developers and node operators, to upgrade their nodes at the earliest convenience to ensure a seamless transition to the new EVM version. Early adoption of the upgrade will contribute to the network's stability and security, fostering a thriving ecosystem for decentralized applications (dApps) and services.

Before proceeding with the node upgrade, We kindly advise all users to take of backup of ".env file & keystore directory" to a secure location. This precautionary step ensures that your essential information remains safe throughout the upgrade process.

Steps to upgrade the XDC Mainnet Node: Choose Method 1 or Method 2

Method 1: Upgrade via Script

Navigate to the mainnet directory:

cd XinFin-Node/mainnet

Run the upgrade script:

bash upgrade.sh

Method 2: Manual Upgrade Command

Navigate to the mainnet directory:

cd XinFin-Node/mainnet

Pull the latest changes from the repository:

git pull

Stop the current Docker containers:

sudo docker-compose -f docker-compose.yml down

Pull the latest Docker image:

sudo docker pull xinfinorg/xdposchain:v1.6.0

Start the Docker containers with the updated image:

sudo docker-compose -f docker-compose.yml up -d

To verify that your node is running XDC v1.6.0, execute the following command:

sudo bash xdc-attach.sh

Exciting Developments on the Horizon:

In addition to the EVM upgrade, the XDC Network is gearing up for the launch of XDC 2.0 on Mainnet, promising further advancements and enhancements to its protocol. XDC 2.0 Apothem is already live on Apothem Network, the Testnet for XDC, providing developers and entrepreneurs with comprehensive transaction-related details pertinent to the XDC Blockchain. This Testnet availability offers a valuable opportunity for exploration and testing before the launch on Mainnet. Stay tuned for updates on the Mainnet release of XDC 2.0. Meanwhile, you can explore its features and functionalities on XDC Apothem (Testnet) through the dedicated explorer: XDC Apothem Explorer.

The XDC Network's commitment to innovation and community-driven development is evident, and stakeholders are encouraged to engage with the community through official channels, such as the XDC Forum (XDC.Dev), to stay informed and contribute to the network's evolution.

For more information and updates, visit the XDC Network Official Website and join the discussions on the XDC Forum.

XDC Network Social Channels:

[Informative] Step-by-Step Guide: USDC Stablecoin Integration on XDC Blockchain

AnilChinchawale — Mon, 13 May 2024 14:14:56 +0000

In the world of cryptocurrencies, stablecoins play a crucial role in providing stability and reliability to transactions. The USDC (USD Coin) stablecoin is one such prominent example, known for its backing by US dollars on a 1:1 basis. This article outlines the process of deploying the USDC stablecoin on the XDC blockchain, detailing the steps followed and the resulting output.

Check out the “Deployment.md” file to know the deployment structure in a better way.

Installation (Prerequisites):

1. NVM Installation:

Begin by installing nvm (Node Version Manager), a tool for managing multiple Node.js versions.
Execute the following command in your terminal:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

2. Node and Yarn Installation:

This project requires specific versions of Node.js and Yarn.
Install Node.js version 16.14.0 and Yarn version 1.22.19 using nvm:

nvm install 16.14.0
nvm use 16.14.0
npm install -g yarn@1.22.19

3. Stablecoin-EVM Installation:

Clone the stablecoin-EVM repository and switch to the appropriate branch.

git clone https://github.com/XinFinOrg/stablecoin-evm
cd stablecoin-evm
git checkout xdcnetwork

After configuring the environment and setting up the prerequisites, the deployment process involves several key steps to ensure the stability and functionality of the stablecoin-EVM project. Below are the detailed deployment commands along with their functionalities:

yarn
yarn compile
yarn hardhat typechain
yarn test

4. Configurations:

Create and configure the .env file with the necessary parameters.

echo "[]" > blacklist.remote.json
cp .env.example .env
vi .env

Sample .env Configuration:

DEPLOYER_PRIVATE_KEY="0x......"
TOKEN_NAME=USDC
TOKEN_SYMBOL=USDC
TOKEN_CURRENCY=USD
TOKEN_DECIMALS=6
PROXY_ADMIN_ADDRESS="0x......"
OWNER_ADDRESS="0x......"
MASTER_MINTER_OWNER_ADDRESS="0x......"
GAS_MULTIPLIER=110
BLACKLIST_FILE_NAME=blacklist.remote.json

Note:

Ensure PROXY_ADMIN_ADDRESS differs from OWNER_ADDRESS.
PAUSER_ADDRESS is optional, will be OWNER_ADDRESS if not set
BLACKLISTER_ADDRESS is optional, will be OWNER_ADDRESS if not set
LOST_AND_FOUND_ADDRESS is optional, will be OWNER_ADDRESS if not set

5. Deployment on Testnet(XDC Apothem):

# forge script -vv --broadcast --legacy scripts/deploy/deploy-fiat-token.s.sol --rpc-url https://earpc.apothem.network/
yarn deploy:xdc:test

Output:

== Return ==
0: contract FiatTokenV2_2 0xC6386Aa0b5d25b7827ed23C7e66865A0CB87c90e
1: contract MasterMinter 0x8983d06244F6E503a4640e36C4d86dB532729F90
2: contract FiatTokenProxy 0xf16f48Ba54282Be2C9D267a56fDA6Caad3329600

Interaction with FiatToken contract

Roles: The FiatToken has a number of roles (addresses) which control different functionality:

masterMinter (0x8983d06244F6E503a4640e36C4d86dB532729F90)

adds and removes minters and increases their minting allowance minters - create and destroy tokens.

pauser (0x774fc390A602706811F49d826Ec10Bbf1135c8a0)

pause the contract, which prevents all transfers, minting, and burning.

blacklister (0x2230091cD557A3211296d7A2E8d85E22064945C8)

prevent all transfers to or from a particular address, and prevents that address from minting or burning.

owner (0x774fc390A602706811F49d826Ec10Bbf1135c8a0)

re-assign any of the roles except for admin.

admin (0x486a98b0f5d84d265e2403dfbb6ad1abe52ecb91)

manage the proxy-level functionalities such as switching the implementation contract.

rescuer (0x2230091cD557A3211296d7A2E8d85E22064945C8)

transfer any ERC-20 tokens that are locked up in the contract Circle will control the address of all roles.

FiatToken Contract Interaction

Owner

The owner of the FiatToken contract can set the masterMinter role to point to the address of the MasterMinter contract. This enables the MasterMinter contract to call minter management functions on the FiatToken contract:

configureMinter(minter, allowance) - Enables the minter and sets its minting allowance.
removeMinter(minter) - Disables the minter and sets its minting allowance to 0.
isMinter(minter) - Returns true if the minter is enabled, and false otherwise.
minterAllowance(minter) - Returns the minting allowance of the minter.
Owner adds and removes controllers, sets the address of the minterManager, and sets the owner. Re-assign any of the roles except for admin
transferOwnership updates the owner role to a new address.
transferOwnership may only be called by the owner role.
transferOwnership(address newOwner) Interaction with FiatTokenProxy contract

Admin

Manage the proxy-level functionalities such as switching the implementation contract
changeAdmin updates the admin role to a new address.
changeAdmin may only be called by the admin role.
changeAdmin(address newAdmin) Interaction with FiatTokenProxy contract

configureController

configureController(controller, minter) - The owner assigns the controller to manage the minter. This allows the controller to call configureMinter, incrementMinterAllowance and removeMinter.
Note: configureController(controller, 0x00) is forbidden because it has the effect of removing the controller.
controller - each controller manages exactly one minter. A controller can enable/disable its minter, and modify the minting allowance by calling functions on the MasterMinter contract, and MasterMinter will call the appropriate functions on the minterManager.
When a controller calls a function on MasterMinter, the MasterMinter will call the appropriate function on the FiatToken contract on its behalf. Both the MasterMinter and the FiatToken do their own access control.
configureController(address _controller, address _worker) Interaction with MasterMinter contract
https://apothem.blocksscan.io/tx/0x17d854f2f13f1ef6d5769655c1d08c878246a66073e94196a11555f0c6922318

configureMinter

configureMinter(allowance) - A controller enables its minter and sets its allowance. The MasterMinter contract will call the minterManager contract on the controller's behalf.
configureMinter(uint256 _newAllowance) Interaction with MasterMinter contract
https://apothem.blocksscan.io/tx/0x8e9d6ce4b87af03bb5a5eeb97ce3d421b733b531c7995d7d50163fc2bfd0a8b3

Other Function Summary

removeController(controller) - The owner disables the controller by setting its minter to 0x00.
setMinterManager(minterManager) - The owner sets a new contract to the minterManager address. This has no effect on the old minterManager contract. If the new minterManager does not implement the MinterManagementInterface or does not give this instance of the MasterMinter contract permission to call minter management functions then the controller calls to configureMinter, incrementMinterAllowance, and removeMinter will throw.
incrementMinterAllowance - A controller increments the allowance of an enabled minter (incrementMinterAllowance will throw if the minter is disabled). The MasterMinter contract will call the minterManager contract on the controller's behalf.
removeMinter - A controller disables a minter. The MasterMinter contract will call the minterManager contract on the controller's behalf.

Minting

A minter mints tokens via the mint method. The minter specifies the amount of tokens to create, and a _to address which will own the newly created tokens. A minter may only mint an amount less than or equal to its minterAllowance. The minterAllowance will decrease by the amount of tokens minted, and the balance of the _to address and totalSupply will each increase by amount.

minter - each minter is managed by one or more controller. The minter cannot perform any actions on the MasterMinter contract. It interacts only with the FiatToken contract.

Only a minter may call mint.
Minting fails when the contract is paused.
Minting fails when the minter or _to address is blacklisted.
Minting emits a Mint(minter, _to, amount) event and a Transfer(0x00, _to, amount) event.
mint(address _to, uint256 _amount) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0xac92593cd874e48ae8366048784c57489da4e884d892c5cfbf2ce30a3982b2f4

Transfer

Transfer function is used to transfer token from one address to another.
A blacklisted address will be unable to call transfer or transferFrom, and will be unable to receive tokens.
approve was not allowed for blacklisted addresses in FiatToken versions <2.2 but available in versions 2.2+. See "Blacklisting" section for more details.
transfer, transferFrom, and approve will fail if the contract has been paused.
transfer(address to, uint256 value) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0xd851a277d3dd7b7026862b309f524714de4307ac39d166eeed885fb6a2c5cc1b

Approve

approve was not allowed for blacklisted addresses in FiatToken versions <2.2 but available in versions 2.2+. See "Blacklisting" section for more details.
approve will fail if the contract has been paused.
approve(address spender, uint256 value) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0xf146cf6e8c2248314e0a28e0e2b49b7cec63b63396ebdd7dc5c74f85d1834249

transferFrom

A blacklisted address will be unable to call transferFrom, and will be unable to receive tokens.(approve was not allowed for blacklisted addresses in FiatToken versions <2.2 but available in versions 2.2+.)
transferFrom will fail if the contract has been paused.
transferFrom(address from, address to, uint256 value) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0x1c8edfe82d18cee41403c12f5c1a92891c327170656cecebdb62b346a095e121

Burning

A minter burns tokens via the burn method. The minter specifies the amount of tokens to burn, and the minter must have a balance greater than or equal to the amount. Burning tokens is restricted to minter addresses to avoid accidental burning of tokens by end users. A minter with a minterAllowance of 0 is allowed to burn tokens.
A minter can only burn tokens which it owns. When a minter burns tokens, its balance and the totalSupply are reduced by amount.

Burning tokens will not increase the minterAllowance of the address doing the burning.
Only a minter may call burn.
Burning fails when the contract is paused.
Burning fails when the minter is blacklisted.
Burning emits a Burn(minter, amount) event, and a Transfer(minter, 0x00, amount) event.
burn(uint256 _amount) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0x9ee433418b91890558b7b2a0f36b419225f204a0762a7079171dd5a33a921bbc

Blacklisting

Addresses can be blacklisted. A blacklisted address will be unable to transfer tokens, mint, or burn tokens.

In FiatToken versions <2.2, A blacklisted address is unable to call approve, increaseAllowance, decreaseAllowance, or authorize future pull payments using permit. Nor can it be authorized to pull payments from other addresses. This has been changed in v2.2 where a blacklisted address can perform the above functions. But they are still blocked from transferring the assets in any way. and therefore any operations on modifying the allowance of blacklisted addresses are considered meaningless.

blacklister

prevent all transfers to or from a particular address, and prevents that address from minting or burning.
updateBlacklister(address _account) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0x4c819ab975ba9d5ea34819ecae43e21acc607866a32f785518ff1a719288bb9b

Adding a blacklisted address

Circle blacklists an address via the blacklist method. The specified account will be added to the blacklist.
Only the blacklister role may call blacklist.
Blacklisting emits a Blacklist(account) event
blacklist(address _account) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0x470f68ec887dcf135b0a715cad4385e0e14915fdb4f502f8deb4afc2a8d8183b

Removing a blacklisted address

Circle removes an address from the blacklist via the unblacklist method. The specified account will be removed from the blacklist.
Only the blacklister role may call unblacklist.
Unblacklisting emits an UnBlacklist(account) event.
unBlacklist(address _account) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0xd463a25cf32bfc8c3d9d1aa3d25fccd9ad9f55ddd3b768f411eef53ce5b3d7cd

Pausing

The entire contract can be paused in case a serious bug is found or there is a serious key compromise. All transfers, minting, burning, and adding minters will be prevented while the contract is paused. Other functionality, such as modifying the blacklist, removing minters, changing roles, and upgrading will remain operational as those methods may be required to fix or mitigate the issue that caused Circle to pause the contract.

Pause

Circle will pause the contract via the pause method. This method will set the paused flag to true.
Only the pauser role may call pause.
Pausing emits a Pause() event. Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0x209102ba166bec1f0ce1f4286e975e33b7d05d9bdac8cb4101ff277d581a1637

Unpause

Circle will unpause the contract via the unpause method. This method will set the paused flag to false. All functionality will be restored when the contract is unpaused.
Only the pauser role may call unpause.
Unpausing emits an Unpause() event. Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0x8c0d303e34beabb4548cdf4a9a3ca1ccb75b02645a945c7f30381545f0882872

Rescuer

updateRescuer updates the rescuer role to a new address.
updateRescuer may only be called by the owner role.
https://apothem.blocksscan.io/tx/0xe7b3882182f90d8eaf8fb015330d52b8bf9cc75c27785c06620fede53a589f66
rescueERC20(address tokenContract, address to, uint256 amount) Interaction with FiatTokenV2_2 contract
https://apothem.blocksscan.io/tx/0xad1c01da0e44b2ef5a756ecaef6066dc4f84e4de12e7a369a17aa76c1e9d3602

In conclusion, deploying the USDC stablecoin on the XDC blockchain opens up new avenues for stable and reliable transactions within the cryptocurrency ecosystem. With a clear understanding of the deployment process and the interaction dynamics outlined above, users can confidently navigate through the steps required to integrate this stablecoin solution.

[Informative] Update on WalletConnect issue with FireBlocks & Fathom!

AnilChinchawale — Tue, 09 Apr 2024 07:11:24 +0000

As the blockchain ecosystem continues to evolve, ensuring seamless interoperability and compatibility across various platforms and protocols becomes paramount. In this vein, our team is proud to announce significant strides in integrating FireBlocks, Fathom, and WalletConnect into our ecosystem, aimed at enhancing the functionality of XRC20 tokens. Here's a breakdown of our current initiatives and future plans:

•⁠ ⁠We're developing Sample an app featuring XRC20 token's Read & Write capabilities.
•⁠ ⁠Initial testing of these functions will be done using the 0x Prefix ERPC.
•⁠ ⁠We'll ensure functionality with the xdc prefix for consistency across the network.
•⁠ ⁠Instructional videos will be created for clarity on both processes.

Explore here: https://wc-fb.vercel.app/

In case of incompatibilities with the xdc prefix:

•⁠ ⁠We'll employ the 0x prefix RPC as a rapid workaround with WalletConnect/FireBlocks.
•⁠ ⁠Engaging with Fireblocks to support the updated XDC 1.5.0 and activate 0x prefix compatibility.
•⁠ ⁠Post-update, we’ll conduct comprehensive end-to-end testing across Fathom and FireBlocks.

For extended xdc prefix support:

•⁠ ⁠We're identifying relevant GitHub repositories and libraries for address validation.
•⁠ ⁠New SDK will be integrated to discern XDC MainNet & TestNet addresses, ensuring transaction creation regardless of prefix variations.
•⁠ ⁠This will ensure transactions are recognized with either xdc or 0x prefix.

Our approach assumes that FireBlocks operates a full node with xdc prefix compatibility.

Leave your feedback and suggestions in the comment section below.

XDC Network Official Website: https://xinfin.org/

XDC Forum: XDC.Dev

XDC Network Social Channels:

[Informative] A Step-by-Step Guide to Updating XDC Network’s Token Circulating Supply through XDC — BlocksScan API

AnilChinchawale — Wed, 27 Mar 2024 10:47:21 +0000

In the world of blockchain and cryptocurrencies, maintaining accurate token data is crucial for transparency and credibility. One key aspect of token information is the circulating supply, which reflects the total number of tokens available in the market and actively being traded. To ensure that circulating supply data is up-to-date and accurate, token issuers often need to update it. In this article, we’ll explore how to update the circulating supply of XRC tokens using API endpoints provided by the XDC Network’s BlocksScan platform.

Step 1: Accessing the API Documentation
Before we begin, we need to familiarize ourselves with the API endpoints provided by the XDC Network’s BlocksScan platform. The API documentation can be found at: API Docs. This documentation provides details on how to interact with the API, including the parameters required and the expected response format.

Step 2: Retrieving Circulating Supply | Total Supply Data
To retrieve the circulating supply or total supply data for a specific XRC token, we’ll make a GET request to the following API endpoint:

Replace with the address of the XRC token contract whose circulating supply you want to update in other platform like CMC and enter “circulatingsupply” or “totalsupply”, whichever you want to update. This API endpoint will return the current circulating supply | totalsupply of the specified token.

Step 3: Access CMC Admin Panel

Visit “Self Report” under the Person icon and “Total Supply” field to update the Circulating Supply | Total Supply Data
Click on the “Connect API End point”.
Submit the details by entering the respective endpoint.
Once the details get updated on CMC, the data will get updated here.

Conclusion
By following the steps outlined in this article, token issuers can easily update the circulating supply data for XRC tokens using the API endpoints provided by the XDC Network’s BlocksScan platform. Maintaining accurate and up-to-date token data is essential for transparency and trust within the cryptocurrency community, and APIs play a crucial role in facilitating this process.

XDC Network Official Website: https://xinfin.org/

XDC Forum: XDC.Dev