Developers Forum for XinFin XDC Network: Omkar Mestry

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

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

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

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

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

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

XDC Mainnet RPC providers (Chain ID 50)

Widely used public HTTP endpoints:

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

WebSocket endpoints:

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

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

XDC Apothem Testnet RPC providers (Chain ID 51)

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

HTTP endpoints:

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

WebSocket endpoint:

wss://ws.apothem.network

"Free" public RPCs are not really free at scale

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

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

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

How RPC is actually provided on a decentralised network

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

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

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

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

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

Why it matters:

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

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

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

Setup resources:

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

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

When you need RPC, and when you don't

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

Recommendations

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

FAQ

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

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

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

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

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

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

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

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

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

How to Integrate XDC Network: A Technical Guide

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

How to Integrate XDC Network: A Technical Guide

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

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

Let's dive in.

1. Overview

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

Key stats:

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

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

2. Network Parameters

Mainnet

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

Apothem Testnet

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

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

3. Address Format (Critical)

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

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

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

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

Conversion Rules

Normalize addresses at your I/O boundary:

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

Address Conversion Utility

// Minimal address conversion helper (JavaScript / TypeScript)

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

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

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

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

4. Prerequisites

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

5. Integration Architecture

A typical custodial integration has four components:

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

6. Integration Steps

6.1 Connect to the Network

Ethers.js v6:

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

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

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

Web3.py:

from web3 import Web3

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

6.2 Generate a Deposit Address

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

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

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

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

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

6.3 Monitor Deposits

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

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

6.4 Process Withdrawals

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

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

6.5 XRC-20 Token Transfers

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

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

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

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

7. Token Standards

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

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

8. Gas and Fee Handling

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

9. Security Considerations

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

10. Testing Checklist (Apothem Testnet)

Complete every item on Apothem before moving to mainnet:

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

11. Sample RPC Calls

eth_chainId

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

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

eth_blockNumber

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

eth_getBalance

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

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

12. Official Resources

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

Wrapping Up

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

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

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

Happy building. 🚀

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

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

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

Summary

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

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

What Happened?

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

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

What Was Done?

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

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

What Has Changed?

We have implemented significant improvements to our security infrastructure:

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

Decentralised by Design

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

Community Acknowledgement

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

Our Commitment

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

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

XDC Innovation Lab
Building a Secure and Decentralised Future

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

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

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

XDC Network at a Glance

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

Key Milestones

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

Network at a Glance (as of early 2026)

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

1. Network Overview

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

2. Staking Requirements

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

3. Node Types Under XDC 2.0

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

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

4. Hardware & Infrastructure Specs

Minimum Requirements

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

5. Uptime & Availability

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

6. Security Best Practices

Key Management

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

Infrastructure Security

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

Firewall & Port Configuration

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

Port Reference:

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

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

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

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

Additional hardening notes:

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

Operational Security

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

7. Monitoring & Maintenance

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

8. Reward Economics (Indicative)

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

Reward Split by Node Tier

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

9. Deployment Quick-Start

Docker (recommended)

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

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

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

Network Snapshots

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

XDC Network Mainnet Snapshots:

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

Apothem Testnet Snapshots:

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

Applying a Snapshot

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

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

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

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

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

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

Important notes:

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

10. Compliance & Governance

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

11. Frequently Asked Questions (FAQs)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12. Key Ecosystem Partners & Integrations

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

Key References

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

EVM Compatible XDC Network’s Upgraded Security and Memory features on Apothem Platform.

Omkar Mestry — Wed, 21 Dec 2022 08:17:51 +0000

EVM Compatible XDC Network’s Upgraded Security and Memory features on Apothem Platform.

Upgrading the feasibility of XinFin(XDC) network which covers Security issues and Memory leak issues.

Introduction to XDC Network and Apothem Network.

The XDC Network is a global, open-source, delegated proof of stake consensus network (XDPoS), which enables hybrid relay bridges, instant block finality and interoperability with ISO 20022 financial messaging standards. The network’s hybrid (private/public) architecture is designed to support institutional use in trade finance and asset tokenization. Featuring interoperable smart contracts, 2,000 transactions per-second, and Ethereum Virtual Machine compatibility, the XDC Network provides a scalable infrastructure for enterprises and independent community contributors.

Apothem Network (Testnet) is the network used by smart contract developers to test smart contracts and protocol upgrades before deployment to the mainnet. Any upgrade to the XinFin XDC Network blockchain is first implemented on the Apothem Test Network, a simulation of the XinFin XDC Network, giving developers and other community members a chance to test the system before real assets are involved.

Now Let’s discuss what issues the team has fixed, which will be on the Apothem Network.

https://github.com/XinFinOrg/XDPoSChain/pull/200
https://github.com/XinFinOrg/XDPoSChain/pull/212

internal/ethapi: EstimateGas and Call handle revert error

Mentioned first issue was, XDC blockchain didn’t show the revert error before sending the tx with no one wallet/interface(metamask, XDCpay, Remix…). There is no way to see the error before sending the transaction.

In the current version XDPoSChain, it always returns the message: “gas required exceeds allowance or always failing transaction”. If solidity contract function reverts when metamask or other client calls method eth.estimateGas. Therefore, neither the user nor the wallet programme can predict when a revert will occur or get a revert message when one does. This is the main problem in the complaint by xcantera. The latest Pull Request parses and returns the revert message/reason for both of eth.call and eth.estimateGas. This PR is tested on a private network and now it will be tested on Apothem testnet.

test with apothem RPC

Code:

https://explorer.apothem.network/address/xdc41cfa4c7c764c39237a765788eb0596c4b7a05ba#readContract

Request:

curl -X POST -H “Content-Type: application/json” https://rpc.apothem.network -d ‘

{

“jsonrpc”:”2.0",

“method”:”eth_estimateGas”,

“params”:[

{

“from”:”0xD4CE02705041F04135f1949Bc835c1Fe0885513c”,

“to”:”0x41cfa4c7c764c39237a765788eb0596c4b7a05ba”,

“data”: “0x55241077000000000000000000000000000000000000000000000000000000000000000a”,

“value”:”0x0"

}

],

“id”:1

}’

Response

{

“jsonrpc”: “2.0”,

“id”: 1,

“error”: {

“code”: -32000,

“message”: “gas required exceeds allowance or always failing transaction”

}

}

Now, Users can see that this fix will be live on the XDC Apothem Network first.

Merged link: https://github.com/XinFinOrg/XDPoSChain/pull/200

Fixed memory leak when sending tx, vote, block etc to peers.
A memory leak reduces the performance of the peer by reducing the amount of available memory. Eventually, in the worst case, too much of the available memory may become allocated and all or part of the system or device stops working correctly, the application fails, or the system slows down vastly due to thrashing.

The memory leak issue is based on original v1/eth code that has been Merged and it will be live on XDC Apothem Network with the Latest Merge.

Both the issues will be live on XDC Apothem Network in the first week of January 2023.

Discuss any technical developments on the XDC Network Technical forum XDC.Dev

How To Use Your Ledger Nano S Plus Device With The XDC Web Wallet

Omkar Mestry — Thu, 18 Aug 2022 15:53:12 +0000

Introduction

A Ledger Device is a hardware wallet considered one of the most secure ways to store digital assets. Ledger uses an offline, or cold storage, method of generating private keys, making it a preferred method for many crypto users. This guide will help you to connect your Ledger Nano S Plus device to the XDC Web Wallet. The XDC Web Wallet enables you to Send and Receive XDC with the Ledger Device.

Before You Start, Make Sure:

You've initialized your Ledger Device.
The latest firmware is installed (Ledger Nano S Plus).
Ledger Live is ready to use.
Access the XDC Web Wallet and choose your Network.

Install The XDC Network App

Step 1: Open the Manager in Ledger Live.
Step 2: Connect and unlock your Ledger Device.
Step 3: If asked, follow the onscreen instructions and Allow Ledger Manager.
Step 4: Find XDC Network in the app catalog. (Here, we have already installed it.)

Step 5: Click the Install button.

a. An installation window will appear.

b. Your device will display Processing…

c. Once the app installation is confirmed, XDC Network app will
appear on the Ledger device screen.

Step 6: Now, Close the Ledger Live.

Connecting to the XDC Web Wallet

Step 1: First, connect and unlock your Ledger Device.

Step 2: Open the XDC Network App on your Ledger Device.

Step 3: Ledger Nano S Plus will show "Application is ready."

Step 4: Open the XDC Web Wallet Application and choose "Hardware Wallets".

Step 5: Choose the Hardware "Ledger" and select the "XDC Network" from the dropdown.

Step 6: Confirm the Network details and Click on "Connect ledger" button to connect your Ledger Device with the XDC Web Wallet.

Step 7: Select your Device, “Nano S Plus,” and click on Connect button.

Once you connected to the Ledger device, you will be able to see the message “Ledger Connected.”

Step 8: Now connect your Ledger device by selecting any ONE address and Network i.e., “XDC Network” (Mainnet/Apothem Network), and click on the “Access my Wallet” button.

Step 9: Once you access the wallet, the dashboard looks like this:

If you are using Testnet i.e.,. Apothem network, then you can get the tXDC from the XDC faucet

Step 10: Before sending any transaction, Visit the “Settings” tab on your Ledger device, and Please enable Blind signing or Contract data in the XDC Network app Settings.

Step 11: For sending the XDC, Enter the XDC Amount, Address of the destination wallet address, and click on the Next button.

If “Blind signing or Contract data” in the XDC Network app settings is “Not enabled” then you will be notified like this:

Step 12: Confirm the transaction details and click on the “Confirm & Send” button.

Step 13: Once you confirm the transaction, Review and sign the transaction on your Ledger Device.

Press the right button on your Ledger Device to review the transaction details (Amount, Address, Nonce, and Max Fees) until you see “Accept and Send.”

a. Amount Screen

b. Address Screen

c. Nonce Screen

d. Max Fees Screen

e. Accept & Send Screen

Step 14: Once you “Accept & Send” the transaction, you will see that the transaction has been initiated.

Step 15: You can check the transactions in the “Tx History” on the right corner of the XDC Web Wallet.

By clicking on the Transaction Hash, you can check the transaction details on XDC BlocksScan Explorer.

This is how we can Store and Send the XDC tokens to Ledger. In case of any technical queries on XDC Network, feel free to drop your queries on XDC.Dev forum.

Quick links:

XinFin.org

XDC Chain Network Tools and Documents

XDC Network Explorer

XDC Network — BlocksScan Explorer

XDC Dev Forum

XDC Web Wallet

XDC faucet

How to Deploy a smart contract with XinFin Remix IDE by connecting Metamask through D'CENT Wallet Software App.

Omkar Mestry — Tue, 02 Aug 2022 12:32:58 +0000

The MetaMask is a wallet that supports EVM blockchains and is utilised on numerous DApp websites. The MetaMask includes a QR-based mechanism for connecting with accounts in hardware wallets in addition to its own account.

The D’CENT App offers a feature that uses the QR-based protocol to connect D’CENT accounts (EVM) with Metamask. Users can create Solidity smart contracts using XinFin Remix, a web browser-based Integrated Development Environment (IDE), and then compile, deploy, and execute those smart contracts on the XinFin Blockchain Network.

The steps to deploy a smart contract with the XinFin Remix IDE by connecting Metamask via the DCENT wallet software app will now be covered.

Let’s start with Metamask.

Once you have unlocked your Metamask wallet, click on the Network button and select XDC Apothem Network.

Note: If you have not added the Apothem Network, you can add it through the ‘Add Network’ button below the network list.

Here are the details that need to be entered while adding the network:

Network Name: XDC Apothem Network
New RPC URL: https://rpc.apothem.network
Chain ID: 51
Currency Symbol: TXDC
Block Explorer URL: https://apothem.blocksscan.io/

After adding the network, you will be notified that “XDC Apothem Network” was successfully added.

How to connect D’CENT Wallet with MetaMask

Note:

This function is supported only in Biometric Wallet and App Wallet(Software) mode. Minimum supported version.
Biometric Wallet firmware version: 2.19.7 or higher
D’CENT App version: Android (5.16.1 or higher) / iOS (5.16.2 or higher)
The QR-based protocol supported by the MetaMask can only be used when a camera is installed on the computer.

After running the D’CENT App, enter the Discovery tab and Select MetaMask Integration from the list or type.

Click on the Go button. On the MetaMask integration screen, click on Connect Metamask account button.

Select the account to be linked from the account selection list and click on Connect button. Once the QR code gets generated, Proceed to further steps.

Click on the Account icon at the top right of the MetaMask main page. Now, Click on Connect Hardware Wallet button.

After selecting QR-based, click the Continue button at the bottom. It switches to the QR code scanning page. (Place the QR code in front of your Camera, The screen will be blurred, but it will not affect the reading.)

When the QR code scan is completed normally, it will be converted to the account selection page, Now, select the First account and click Unlock.

You can check the page where the account of the D’CENT wallet and the MetaMask are linked.

Let’s deploy a smart contract using XinFin Remix:

Step 1: Access the XinFin Remix and enter the smart contract to compile it.

Used Contract code:

// My First Smart Contract

pragma solidity >=0.5.0 <0.7.0;

contract HelloWorld {

function get()public pure returns (string memory){

return ‘Hello World’;

}

}

Step 2: Select the respective compiler version and Compile it.

Step 3: After successful compilation, Go to the Deploy & Run Transaction screen.

Now, Select the environment as ‘Injected Web3’ to connect with Metamask.

On the Metamask screen, select ‘Connected DCENT wallet’ account and click on the Next button.

Step 4: Confirm the address and account balance, and Click on the Connect button.

Once the connected DCENT wallet is connected to the Remix successfully then, it will fetch the address of the DCENT wallet through Metamask like this:

Step 5: Now click on the Deploy button; Metamask will ask to Confirm the transaction. Click on Confirm button to complete the transaction.

Step 6: After checking the transaction details, click the Confirm button. It switches to the signature request page in QR code format.

Step 7: Now, open the DCENT wallet and access the Metamask link (https://qrbase.dcentwallet.com).

Scan the Metamask QR code through DCENT App.

(There are two ways to scan the signature request QR.)

i. From D’CENT App, go to the Discovery tab and Click on the Metamask QR Scan button.

ii. Or, click the QR Scan button at the top left of the Discovery tab.

Step 8: Scan the signature request QR code generated in Step 6. After scanning, check the from address and click on the Continue button.

Step 9: Now, check the Network and other details and click on the Signing button to complete the transaction.

After signing, you can check the signature in QR code format.

Step 10: Now you need to send signed data to MetaMask, for that Click the Get Signature button on the signature request page completed in Step 6.

Step 11: Once you click the Get Signatures button, you must scan the QR code prepared in Step 9.

This is how you can Deploy your smart contract with XinFin Remix IDE by connecting Metamask through DCENT Software App

Deploy your smart contract using DCENT Wallet with XinFin Remix and Metamask, and share your feedback.

Relatable links:

How to update node name in XinFin Masternode?

Omkar Mestry — Fri, 01 Jul 2022 09:14:26 +0000

What is XinFin - XDC Masernode?

A Masternode validates each transaction and is also responsible for writing the transaction onto the truth ledger: the blockchain. As a consequence, this makes decentralized governance of the network possible. Restrictions on nodes that aspire to become Masternodes.

Here you can check the XDC Staking Information; Total Masternode Count, Total Staked amount, and Current Epoch/Block number.

Let’s learn, How to update your XinFin - XDC Masternode name and other info.
(Used Network: Apothem)

Masternode owners can Log in to the Masternode app using the XDCPay, Private Key, Ledger Wallet, or Trezor Wallet.

Now, Logged into your Masternode and visit the Home page and click on your Masternode.

Once you are on your Masternode screen, the Edit option will be shown next to your Masternode name.

Here you can edit your Masternode Name, and also update the other information such as Hardware name, Data Center Name, Data Center Location, Website, and Telegram link.

Once you confirmed all the information, click on the Next button.

Now you will be redirected to the Confirmation screen, Confirm the information and click on Submit button.

You will be notified that “Your Masternode information has been updated successfully!”

And you can check the updated name of your Masternode on Home Screen.

Check out the Important link regarding XinFin - XDC Masternode:

XinFin - XDC Mainnet Masternode

XinFin - XDC Apothem Masternode

XDC Network Masternode App with Improved Features.

Watch here, How to Setup XinFin Blockchain Node Masternode with just One Click.

Guide To Set Up XinFin Master Node.