Developers Forum for XinFin XDC Network

XDC Masternode Backup and Migration Procedure for v2.6.8 and Later

PXI_Nl — Wed, 16 Sep 2026 05:11:42 +0000

Hi everyone,

I would like to confirm the backup and migration procedure for an XDC Masternode running v2.6.8 or later.

Previously, I personally backed up coinbase.txt as well. However, since v2.6.8, the contents of coinbase.txt have been empty, so I understand that there is no longer any need to back up this file.

At the moment, I believe the important files to back up for an XDC Masternode are:

the UTC--... file inside the keystore directory
.env, if necessary

My understanding of the migration procedure to a new server is as follows:

Set up XinFin-Node on the new server.
Wait until synchronization is complete.
Replace the UTC--... file in the new server's keystore directory with the one from the original Masternode.
Update the .env file if necessary.
Confirm that Docker has been stopped on the original server.
Restart the Docker container on the new server.

Is this procedure correct?

Also, since coinbase.txt is empty in v2.6.8 and later, is my understanding correct that there is no need to migrate or back up the empty coinbase.txt?

In particular, I would like to confirm the following three points:

Since v2.6.8, there is no need to back up the empty coinbase.txt.
When migrating an XDC Masternode to another server, the UTC--... file inside the keystore directory is the important file that needs to be backed up and restored.
.env should be backed up if necessary.

Could you please confirm whether my understanding is correct?

From token creation to liquidity rewards on XDC: a practical BBBFi guide

Galaxy — Sun, 13 Sep 2026 21:43:26 +0000

Disclosure: I am sharing this as part of the BBBFi team. This guide explains the current workflow and its boundaries so XDC builders can evaluate it before connecting a wallet. The interface also supports BNB Smart Chain, but each operation is chain-specific.

1. Create a fixed-supply token

Open Create a token on XDC, select the network, and enter a name, symbol and total supply. Advanced settings expose decimals from 0 to 18; the default is 18. Review the parameters before approving deployment in your wallet: they cannot be changed afterwards.

BBBFi charges zero platform creation fees. The creator still pays network gas in XDC or BNB and receives the entire supply. The template is a non-upgradeable ERC-20 with fixed supply, no additional minting, no token tax, no administrator, no blacklist and no pause control. The compiler input/source is publicly available.

Creating a token does not create liquidity or automatically add it to the public token list. In particular, a freshly created BSC token is not automatically enabled in the trading interface; the applicable listing checks still matter.

2. Understand the token-and-logo listing threshold

In the swap or liquidity token selector, open Add my token, check the selected network, enter the contract address and attach a PNG, JPEG or WebP logo. Images must be at most 256 KB and 1024 by 1024 pixels. Name, symbol and decimals are read from the contract rather than supplied as marketing text.

Anyone can submit for automatic checks. Qualification requires strictly more than USD 1,000 of independently valued XDC/BNB-side liquidity in BBBFi pools on the selected chain. Liquidity on unrelated DEXs does not count. The new token's self-quoted value is excluded; the native side is not doubled into an assumed total TVL.

For example, a pool with USD 600 of verifiable native-side value does not qualify merely because its displayed two-sided value is USD 1,200. Exactly USD 1,000 does not pass the strict threshold either. Existing logos cannot be anonymously overwritten. Listing is a discovery feature, not an audit, ownership certificate or endorsement.

3. Create a BBB liquidity reward campaign

Open Community reward pools on XDC and select Create reward pool.

Choose two tokens and the eligible BBBFi V2/V3 pool, including the V3 fee tier when relevant.
Set a positive BBB reward budget and a UTC start/end schedule.
Review the pool, network, funding amount and dates before wallet approval and creation.

The creator pre-funds the BBB budget. Campaign creation is permissionless: there is no owner-only creation gate. Start time must be at least 10 minutes and at most 30 days ahead; duration must be between 1 and 365 days.

No upfront liquidity deposit is required just to create the reward campaign. Missing pools can be prepared empty, but an empty pool is not automatically tradeable: price initialization and usable liquidity are still needed where applicable. The reward token is BBB; this is not an arbitrary-token or unconditional wallet airdrop.

Participants stake eligible liquidity. V3 direct staking requires the selected pool's full usable tick range. Scheduled campaigns do not accept entry before the start; ended campaigns stop new entry while retaining withdrawal and earned-reward claim paths.

4. Manage liquidity and review the swap route

The liquidity workspace brings V2/V3 positions and sortable pool information together. Smart DEX routing supports qualified split and mixed V2/V3 routes across BBBFi pools on the same chain, with a direct-route fallback.

This is bounded routing, not a promise to search every DEX or guarantee the best net-of-gas execution. Review the selected route, each pool's fee, price impact, minimum output and gas before signing. There is no additional platform swap fee; underlying pool fees and gas remain.

Supported reward campaigns also offer single-token Easy entry. This can swap within the selected pool, add liquidity and stake through a user/campaign vault. Native XDC/BNB entry is available when the pool contains the corresponding wrapped-native asset. Initial approvals may be required. Reward claims are separate from principal withdrawal, and LP/NFT withdrawal is available without requiring conversion back into a chosen token.

Before using real funds

Verify the network, contract addresses and token behavior. Fixed supply and public source do not make a token or protocol risk-free, and source verification is not an independent security audit. Liquidity providers face price changes, impermanent loss, smart-contract risk, slippage and gas costs. APR is variable and returns are not guaranteed. Permissionless campaign creation is not platform endorsement.

For builders reviewing the workflow: are the native-side listing threshold and the distinction between campaign creation, liquidity provision and reward eligibility clear? Specific feedback on those boundaries would be useful.

Where XDC actually swaps: comparing routes across 30+ sources

slaenov — Thu, 10 Sep 2026 13:39:06 +0000

Short post about something that kept annoying me while working with XDC.
When you want to move XDC in or out, the rate you get depends a lot on which venue you go through, and there is no single place showing that side by side. Some instant exchangers quote XDC and some
don't. Bridges quote it sometimes. The spread between the best and the worst route on the same pair is not small.
So we built a screener for it. It queries 30+ sources - DEX aggregators, bridges, instant exchangers - for one pair and sorts them by how much you actually receive after fees, gas and the provider's spread. There is no account and no registration, and it never takes your funds: you pick a route and the swap happens on that provider's site.
XDC pairs are live: https://eidex.io/screener/xdc-xdc-to-btc-btc
A few things worth knowing if you try it:
Coverage moves. Not every provider quotes XDC every day, so a route that was there yesterday can be missing today. We show what is actually quoted at that moment rather than a static list, which is
less pretty but more honest.
Quotes are indicative. The number you see is what the provider returns to the quote endpoint - the final amount is whatever they execute at.
Happy to hear what is missing. If there is a venue that quotes XDC and we are not pulling it, tell me and I will look at wiring it in.
One unrelated thing while I am here: we opened a PR to the xinfin.org site repo back in August adding EIDEX to the get-xdc exchange cards (PR #49 in XinFinOrg/Official-XinFinOrg). It has no conflicts and follows the existing markup. If someone knows who looks after that repo, a nudge would be appreciated.

veXDC is live on Apothem testnet — come try it

Beny — Thu, 10 Sep 2026 10:35:40 +0000

veXDC is a real-yield vote-escrow for XDC Network. You lock tXDC for 1–104 weeks, receive a soulbound veNFT whose weight decays linearly toward unlock, and earn a pro-rata share of participating dApp revenue each week.

There is no emissions token. Yield is whatever dApps actually commit on-chain. Principal sits in an immutable vault; the only two exits are mature withdraw and early exit at a penalty snapshotted at lock time.

App (Apothem): https://ve.xdcai.tech

Whitepaper & Architecture

https://github.com/0xbeny/xdc-staking-revshare-dapp/blob/main/docs/WHITEPAPER.md

How to sign in

You don’t need a wallet installed. On the app, hit Sign in and either:

Enter your email — you’ll get a one-time code (OTP). We create an embedded wallet for you, or
Connect MetaMask, Rabby, OKX, or WalletConnect (mobile)

If you use email, you still get an XDC address and can lock / claim like everyone else.

Add Apothem if your wallet doesn’t have it

Skip this if you signed in with email — the embedded wallet is already on Apothem.

Easiest: https://chainlist.org/chain/51 → Add to MetaMask (works with Rabby / OKX too if they’re the active injected wallet).

Or add it manually:

Field	Value
Network name	XDC Apothem
RPC URL	`https://rpc.apothem.network`
Chain ID	`51` (hex `0x33`)
Currency symbol	`TXDC`
Block explorer	`https://testnet.xdcscan.com`

MetaMask / Rabby / OKX: Settings → Networks → Add network → Add a network manually → paste the row above → Save. Then switch the wallet to XDC Apothem before opening the app.

Fallback RPC if the first one is slow: https://erpc.apothem.network

tXDC faucet

≤ 1,000 tXDC: public faucet → https://faucet.apothem.network Paste the address from the app (email users: copy it after Sign in).
Need more than 1,000 tXDC for load / multi-position tests: DM me here on xdc.dev (or @zeroxbeny on X) with your Apothem address and I’ll send it.

What to test

Lock native tXDC (1 week → max 104 weeks)
Extend / keep-at-max, claim, auto-compound if you opt in
Mature withdraw and emergency exit (24h cooldown)
Email OTP login vs wallet login
Anything that feels broken, confusing, or missing

Reply in this thread with bugs, tx hashes, and how you signed in (email / MetaMask / Rabby / OKX / mobile).

Integrating a dApp

If you run a protocol and want to commit a share of fees to lockers, pick a mode and follow the guide:

Mode	When to use
A — Push	You already know the amount to push
B — FeeSplitter	Your fee receiver can be a contract (default)
B2 — Pull	Dedicated fee Safe + ERC-20 allowance
B3 — Zodiac	Dedicated fee Safe + Safe module
C — Attestor	Off-chain / cross-chain revenue

Index: https://github.com/0xbeny/xdc-staking-revshare-dapp/tree/main/docs/adapters

How it works (simple)

You lock XDC for a time. Longer lock = stronger claim on that week’s dApp fees.

Think of it like a tip jar that dApps fill. Every week the jar is split among lockers. People who locked more and longer get a bigger slice.

Example 1 — same money, different lock

Three people each put in 1,000,000 XDC. This week the tip jar has $100,000.

Person	Lock length	Rough share of the jar	They get
Alice	1 week	tiny (~0.6%)	~$640
Bob	1 year	about 1/3	~$33,000
Carol	2 years (max)	about 2/3	~$66,000

Same deposit. Carol earns more because she locked longer.

Example 2 — you join a big crowd

Lots of people are already locked. You add 100,000 XDC. This week the jar is $1,000,000.

Your lock	About what you get
1 week	~$10
1 year	~$500
2 years (max)	~$1,000

Longer lock helps, but if many others are locked too, your slice stays small.

Example 3 — where the money comes from

A dApp (like a DEX) sends some fees into veXDC.
Those fees go into this week’s pot.
After the week, lockers can claim their share.

Important: there is no “print money” token.

If dApps put $0 in the pot that week, everyone earns $0 — even max lockers.

On Apothem you can try a fake fee run from the app (Admin → Simulate revenue), then claim from your position.

More detail: https://github.com/0xbeny/xdc-staking-revshare-dapp/blob/main/docs/PROJECTIONS.md

DM me if you want help wiring an adapter on Apothem.

This is testnet only. tXDC has no value. Contracts are pre-audit — treat it as a public dry run, not production.

— Beny (@zeroxbeny)

Official x402 Batch-Settlement Contracts Deployed on XDC Mainnet

Tarun Sharma — Wed, 09 Sep 2026 12:39:16 +0000

The official x402 EVM batch-settlement contract stack has been deployed on XDC mainnet, enabling the next phase of x402 payment infrastructure experimentation on XDC.

This deployment uses the upstream x402 reference contracts with canonical CREATE2 addresses, giving builders a public, verifiable foundation for testing batch-settlement flows, escrow-backed vouchers, and higher-throughput x402 facilitator designs.

Deployment
Network: XDC Mainnet Chain ID: 50 Public repo: https://github.com/Tarunshrma/xdc-x402-batch-settlement-contracts Deployment record: https://github.com/Tarunshrma/xdc-x402-batch-settlement-contracts/blob/main/docs/deployment-record.md
Contract Addresses

x402BatchSettlement
https://xdcscan.com/address/0x4020074e9dF2ce1deE5A9C1b5c3f541D02a10003

ERC3009DepositCollector
https://xdcscan.com/address/0x4020806089470a89826cB9fB1f4059150b550004

Permit2DepositCollector
https://xdcscan.com/address/0x4020425FAf3B746C082C2f942b4E5159887B0005

This deployment is intended as a public compatibility and validation milestone for x402 batch settlement on XDC. Source verification and further audit review remain important next steps before meaningful production TVL.

Single-token LP staking on XDC: approvals, exits and risk-aware UX

Galaxy — Tue, 08 Sep 2026 03:33:52 +0000

I'm part of the BBBFiSwap team. We have added a single-token entry path for the BBB/XDC liquidity pool, and this write-up explains the transaction model and the UX decisions. We would welcome developer feedback, especially on communicating LP exposure and withdrawal choices.

A simpler input does not change the underlying position

The new default, Easy stake, accepts BBB or native XDC. It swaps part of the input, supplies both assets to the BBB/XDC pool and stakes the resulting liquidity-provider tokens. This is an LP position, not XDC validator staking or a principal-protected single-asset deposit.

The original LP staking / Advanced entry remains available for people who already have LP. Existing positions do not need to migrate just to continue using that path.

Approval and execution are different states

For a first BBB deposit, the wallet may need to approve token spending before submitting the deposit transaction. Approval alone does not create LP or start earning rewards. Native XDC input still requires a transaction and enough XDC left for gas.

A useful mental model is:

Select the input asset and amount.
Review the current quote, price impact, slippage and minimum output.
Approve BBB if the current allowance is insufficient.
Submit the deposit and wait for confirmation before treating the position as created.

Quotes are estimates, not executed results. Direct transfers to a contract are not a substitute for calling the entry function and may be unrecoverable. The interface keeps high-price-impact warnings visible; a warning should not be interpreted as an assurance that proceeding is economical.

Why exits have three output choices

The default withdrawal asset follows the original deposit bucket, but the user can choose BBB, XDC or LP. Partial withdrawals are supported.

Returning the original token type does not guarantee returning the original amount. Pool price changes, impermanent loss, swap costs and transaction ordering can affect the result. Users should inspect the exit quote rather than assuming that an input of N tokens implies an exit of N tokens.

LP-only withdrawal avoids converting the LP into a single token. It does not claim rewards: BBB rewards remain separately claimable. For other exit routes, the interface offers a separate reward-claim option, and claimed rewards are paid in BBB regardless of the selected withdrawal asset. Receiving LP is also different from removing liquidity into its underlying tokens.

Rates, fees and verification boundaries

The convenience feature adds no reward allocation and does not restart the existing 90-day season. The deposit preview estimates APR using the post-deposit state. Participation, valuations and prices change that estimate; an annualized rate is neither a guaranteed return nor the return over the remaining season.

There is no additional Easy stake service fee. DEX swap fees and network gas still apply. LP price risk, impermanent loss, price impact, smart-contract risk and execution risk remain.

The deployed XDC entry contract is 0x2737D88a098Ec597F5eFE96f3d6F46CC3Bc766a6. Its implementation is 0x685f96614792a898080A62D5EF93970cF4D76377. Explorer source verification and our automated tests are not an independent security audit or a guarantee of safety.

Reference interface and discussion

The walkthrough uses real production-interface screenshots with English captions; it does not demonstrate completed mainnet transactions.

For builders: how would you distinguish the selected exit asset from the underlying LP exposure? Should the input-token bucket, LP amount, minimum output and separately claimable BBB be shown together before confirmation? We'd appreciate concrete feedback on these choices. This is a team-authored implementation note, not an XDC Foundation endorsement or investment recommendation.

gas2500x test plan

Daniel Liu — Sat, 05 Sep 2026 11:02:50 +0000

Field test for the Gas2500x tier (625 gwei) shipped by three XDPoSChain
commits on dev-upgrade (baseline 5501a1f1e5, all three included):

7823fc7f (#2516) — Gas2500xBlock fork: the pool floor, the chain default gas price and the EIP-1559 base fee move 12.5 gwei → 625 gwei, and --gasprice can no longer move the floor.
68695806 (#2532) — on a floor rise the pool sweeps every non-special tx below the new floor from pending and queue; swept txs never come back.
06582401 (#2541) — the local tracker holds back below-floor local txs and revives them when the floor drops; below-floor rejects never enter the tracker.

A test result: https://github.com/gzliudan/Local_DPoS_Setup/blob/gas2500x/results/gas2500x-20260905-182603.log

Test environment

OS: Ubuntu 24.04.4 LTS (Linux 7.0.0, x86_64)
bash: GNU bash 5.2.21
jq: jq 1.7
cast: foundry cast 1.8.1
curl: curl 8.5.0
Go: go 1.25.14 (builds the XDC binaries)

Quick start

cd ~/XDPoSChain
git use dev-upgrade
make all                            # once: XDC binaries

cd ~
git clone https://github.com/gzliudan/Local_DPoS_Setup/
cd Local_DPoS_Setup/
git use gas2500x
cp .env.sample .env                 # once: sender/node keys (S1–S5, P3)
# Fill the real keys in `.env`
./gas2500x-run.sh                   # reset → start network → 53 cases → stop
./stop-network.sh                   # only after an interrupted run

Fill the real keys in .env — the three masternode keys
(PRIVATE_KEY_0/1/2) are bound to genesis.json: their addresses are the
masternodes baked into the genesis extraData (and funded in alloc),
so they must stay exactly as shipped; generating fresh keys here yields
a node that can never sign. PRIVATE_KEY_3 (observer pn3) and
TXGEN_KEY_1..5 (senders S1–S5) may be any funded-able raw hex keys.

The runner does the whole lifecycle itself — wipes the datadirs, starts the
network, runs every case, stops the network.

Topology

Node	Role	RPC	Metrics
pn0	masternode, genesis signer	8545	6060
pn1	masternode, genesis signer	8546	6061
pn2	masternode, genesis signer	8547	6062
pn3	observer, non-signer	8548	6063

Masternodes keep sealing the whole run — 2/3 quorum is intact. All pool
cases submit via pn3, so tracker/journal state lands there and the rewind
experiment touches pn3 only.

Key numbers

Gas50x floor: 12.5 gwei
Gas2500x floor: 625 gwei
gas2500xBlock: 120
Tracker recheck: 10s after start, then every 60 s (locals.recheckInterval)

Test scripts

Local_DPoS_Setup/
├── gas2500x-run.sh          # the only entry point
├── gas2500x-test.md         # this document
├── results/
│   └── gas2500x-<ts>.log    # runner transcript (start/end tally inside)
└── tests/
    ├── gas2500x-lib.sh      # shared helpers
    ├── t01.sh … t23.sh      # pre-fork
    ├── t24.sh … t34.sh      # fork sweep
    ├── t35.sh … t42.sh      # post-fork probes
    ├── t43.sh … t45.sh      # rewind saga
    └── t46.sh … t53.sh      # creation matrix

Test cases

53 cases, one verifiable result each. The fork (block 120) splits them into
mirrored pairs, one case per side (T02/T27 reject, T09/T29 at-floor seal,
T13/T32 replace, T21 parks / T30 seals the survivor, T15/T42 default price);
observation-only cases add no submissions (T10, T22, T24–T26, T34, T44,
T45); the survivor chain T21→T24→T30 and the rewind saga T43→T44→T45 are
fixed state chains (via /tmp markers); the creation matrix t46–t53 cases
are mutually independent. Missed the pre-fork window? Just re-run the runner
— it resets the chain.

One benign interference: every ~30 s each masternode broadcasts a consensus
signing tx (gasPrice 0) that transiently enters every pool as
executable-special for ~2 s. The pending-side assertions (T11, T12, T34,
T45) therefore count only non-signing txs (shape-based filter).

Out of scope (unit-test covered): TRC21/XDCx tier pricing, concurrent
TrackAll races, Osaka gas-cap discard, Gas2500xBlock == nil, special txs.

Case names are verb-object and paren-free. The table below is generated
from the scripts' begin_case args — regenerate it after renaming a case.

Case	Name
T01	fund the senders
T02	reject a tx 1 wei below the pre-fork floor
T03	verify eth_gasPrice on the pre-fork tier
T04	verify eth_maxPriorityFeePerGas on the pre-fork tier
T05	verify the block baseFeePerGas on the pre-fork tier
T06	verify eth_estimateGas on the pre-fork tier
T07	reject a legacy creation below the pre-fork floor
T08	reject a 1559 creation below the pre-fork floor
T09	seal a tx at the pre-fork floor of 12.5 gwei
T10	verify the below-floor reject is not tracked
T11	seed 10 queued txs from S1
T12	seed 8 queued txs from S2
T13	replace a pre-fork queued tx at the same nonce
T14	verify txpool_contentFrom mirrors the pre-fork queue
T15	seal a tx at the pre-fork default gas price
T16	seal a legacy creation at the pre-fork floor
T17	seal a legacy creation above the pre-fork floor
T18	seal a 1559 creation at the pre-fork floor
T19	seal a tip-0 creation at the pre-fork base fee
T20	verify the journal load keeps the pre-fork replacement
T21	park a 700 gwei tx from S4 for the sweep
T22	verify the queued batch is not sealed
T23	verify sealing continuity across the fork
T24	verify the fork sweep empties the queue
T25	verify the sweep meter and drop log on pn3
T26	verify the sweep leaves a hold-back gauge
T27	reject a tx 1 wei below the post-fork floor
T28	reject a swept tx re-entering at the old price
T29	seal a tx at the post-fork floor of 625 gwei
T30	seal the parked 700 gwei tx above the new floor
T31	verify the post-fork reject is not tracked
T32	replace a post-fork queued tx at the same nonce
T33	verify the journal load keeps the new-tier replacement
T34	verify no tracker revival within the recheck
T35	verify effectiveGasPrice matches the block base fee on both tiers
T36	verify the --gasprice 1 knob is inert
T37	verify eth_gasPrice on the post-fork tier
T38	verify eth_maxPriorityFeePerGas on the post-fork tier
T39	verify the block baseFeePerGas on the post-fork tier
T40	verify txpool_contentFrom mirrors the post-fork queue
T41	verify eth_estimateGas on the post-fork tier
T42	seal a tx at the post-fork default gas price
T43	revive the held-back txs when the floor drops
T44	verify the re-cross sweep fires again
T45	verify the hold-back survives a restart
T46	reject a 1559 tx 1 wei below the post-fork floor
T47	reject a legacy creation below the post-fork floor
T48	reject a 1559 creation below the post-fork floor
T49	seal a legacy creation at the post-fork floor
T50	seal a legacy creation above the post-fork floor
T51	seal a 1559 creation at the post-fork floor
T52	seal a tip-0 creation at the post-fork base fee
T53	seal a 1559 tx at the post-fork floor

Can't access xdcdomains.xyz with XDCPay wallet?

Ben Volker — Mon, 31 Aug 2026 09:56:52 +0000

Hello,
After a long time i tried to check my xdc domains but when i opened the xdcdomains.xyz site, the message appears everytime: You are not logged in or your wallet is locked. Please open the XDCPay wallet and enter the password to unlock, then try again..

Hope someone knows how to fix that problem.
Thank you

XDC Masternode, Protector & Observer Nodes Explained: The Complete XDC 3.0 Staking & Rewards Guide (2026)

Rushabh Parmar — Tue, 25 Aug 2026 11:02:27 +0000

A complete community guide to XDC Network's node architecture — what masternodes are, the upcoming Staking, Rewards & Burning upgrade (now live on Apothem), the new three-tier node structure, and rewards.

The XDC Network is entering one of the most significant phases in its history. The XDC 3.0 Staking, Rewards & Burning upgrade introduces a new three-tier node architecture — Core Validator (Masternode), Protector Node, and Observer Node — along with a redesigned reward mechanism and a token-burning model to control inflation.

The upgrade is currently live on the Apothem Test Network, and a security audit is in progress before the mainnet rollout which is scheduled in October. This is the right time for every community member, node operator, and prospective staker to understand what's changing, why it matters, and how to prepare.

This article covers everything: what a masternode is, the current node structure, the upcoming node roles and their rewards, KYC requirements, node setup, and infrastructure options.

What Is a Masternode?

A masternode is a full node on the XDC Network that does far more than simply store a copy of the blockchain. Masternodes are the backbone of the network — they:

Validate transactions and produce (mine) blocks
Participate in consensus via XDC's Proof of Stake mechanism
Guarantee uptime, security, and decentralization for the entire ecosystem

To operate a masternode, an operator must lock 10,000,000 XDC as self-bond collateral. This economic stake ensures that every validator has real skin in the game.

In return, masternode operators earn block rewards and participation incentives, making it both a service to the network and a yield-generating activity.

Key requirements at a glance:

Requirement	Detail
Stake	10,000,000 XDC
Uptime expectation	100% — dedicated or cloud server infrastructure
KYC/KYB	Mandatory for all node operators
Rewards	Block rewards + incentives, distributed per epoch

The Current Node Structure: Masternodes and Standby Nodes

Today, the XDC Network operates with two node categories:

Masternodes (Validators)

The active set of 108 validator nodes that take turns producing and validating blocks. These nodes participate directly in consensus and earn the highest rewards.

Standby Nodes

Nodes that have staked the full 10M XDC and meet all requirements, but are outside the active 108 validator set. They remain synced and ready to step into the validator set when a slot opens, and earn a slightly lower reward rate for maintaining readiness.

This two-tier model has served the network well — but XDC 3.0 takes it much further.

What's Changing: The XDC 3.0 Three-Tier Node Architecture

Under the Staking, Rewards & Burning upgrade, the network moves from the Masternode/Standby model to a layered, three-role consensus architecture. Every role still requires the same 10M XDC stake — what changes is the function each node performs and the reward it earns.

1. Core Validator (Masternode)

The most critical node type on the network.

Contributes 10,000,000 XDC
Validates transactions and produces blocks
Ensures network uptime, security, and decentralization
Earns block rewards and incentives for active participation
Must maintain 100% uptime on dedicated or cloud server infrastructure
Capped at 108 Core Validator slots

2. Protector Node (New in XDC 3.0)

A brand-new role designed for fault tolerance.

Contributes 10,000,000 XDC
Acts as a backup for Core Validators — from the next update, the architecture targets 4 Protector Nodes for every Core Validator (432 Protector slots)
Enables seamless block production during disruptions — if a Core Validator fails, Protectors keep the network producing blocks without downtime
Earns proportional rewards from the reward pool based on the number of associated Protector Nodes
Adds a redundancy layer that meaningfully strengthens network resilience

3. Observer Node (New in XDC 3.0)

The entry point into the validator ecosystem.

Contributes 10,000,000 XDC
Non-block-producing — observes consensus and broadcasts transactions
Ideal for individuals and organizations that want to contribute to decentralization today and move up to Protector or Core Validator roles as slots open
Receives 50% of the Protector Node reward — passive earning without active consensus duties
No cap on the number of Observer Nodes

How role assignment works: The 108 Core Validator slots fill first, then the 432 Protector slots. Once Protector capacity is full, new qualifying nodes automatically become Observer Nodes.

Reward Structure Under XDC 3.0

Rewards are calculated from fixed protocol emissions relative to the 10,000,000 XDC self-bond. Reward pools are allocated per epoch and shared among the nodes in each tier — Core Validators earn the highest rate for producing blocks, Protector Nodes earn proportional rewards from their pool, and Observer Nodes receive 50% of the Protector reward rate.

Per-Epoch Reward Distribution

Based on the current configuration, each node role earns a fixed reward every epoch. A Core Validator (Masternode) earns 63.4196 XDC per epoch, a Protector Node earns 50.7357 XDC, and an Observer Node earns 25.3678 XDC — exactly half the Protector rate, as designed. From each reward, a 10% foundation cut is deducted to support ongoing ecosystem development, which means the net per-epoch reward received by operators comes to 57.07764 XDC for a Core Validator, 45.66213 XDC for a Protector Node, and 22.83102 XDC for an Observer Node. Since rewards are distributed every epoch, earnings accumulate continuously throughout the day rather than in monthly or quarterly payouts.

Node Role	Gross Reward / Epoch	Foundation (10%)	Net Reward / Epoch
Core Validator (Masternode)	63.4196 XDC	6.34196 XDC	57.07764 XDC
Protector Node	50.7357 XDC	5.07357 XDC	45.66213 XDC
Observer Node	25.3678 XDC	2.53678 XDC	22.83102 XDC

Want the exact percentage-based calculations? Ask an AI assistant like Claude or ChatGPT to calculate the approximate APR for each node role based on the fixed protocol emissions and the 10,000,000 XDC self-bond — they can walk you through the per-epoch and annualized math step by step.

Per-epoch view: An epoch is 900 blocks/rounds. Reward pools are allocated per epoch and shared among the nodes in each tier — for example, 108 Core Validators sharing the validator pool and the Protector Nodes sharing the protector pool.

How rewards are paid today: Until the next network update — planned around October 2026 — node rewards are distributed from the XDC ecosystem wallet. Once the upgrade goes live on mainnet, reward distribution moves to the new on-protocol mechanism described above.

The Burning Mechanism

Alongside restructured rewards, XDC 3.0 introduces token burning to reduce inflation. A portion of network fees/emissions is permanently removed from circulation, making the reward model economically sustainable long-term rather than purely inflationary.

⚠️ Important: Reward parameters reflect the current proposal and testnet configuration. Final mainnet values are subject to governance approval and may be refined based on audit findings and Apothem results. Always verify against official XDC announcements before making staking decisions.

KYC / KYB Requirements (New Format Drafts)

All new node operators must complete identity verification. New draft formats have been published for both individuals and organizations:

Individual (KYC) — new format draft: KYC Document Format — Individual
Organization (KYB) — new format draft: KYB Document Format — Organization

Complete the applicable document before (or alongside) your node registration. Each masternode requires its own separate KYC.

How to Set Up a Masternode

Setting up an XDC masternode is straightforward with the official tooling. Provision a reliable dedicated server or cloud VM, then clone the official node repository from github.com/XinFinOrg/XinFin-Node and follow the Docker-based setup guide at xinfin.org/docker-setup — the recommended path for most operators. Once your node is synced, lock your 10,000,000 XDC via the official masternode DApp, submit your KYC/KYB documents, and register your node's coinbase address. From there, keep the node updated and monitored to meet the 100% uptime expectation.

Prefer to test first? Spin up a node on the Apothem Test Network (Chain ID 51) to get familiar with the flow before committing on mainnet (Chain ID 50).

Infrastructure Operators & Trusted Institutions

The network is currently secured by leading infrastructure operators and trusted institutions including: SBI VC Trade (SBI VC Japan), Cumberland (a DRW company), Deutsche Telekom, GSR Markets, HashKey Cloud, Republic, UOB Venture Management, Animoca Brands, Clearpool, RedStone, stakeFi, BCW Group, SettleMint, Bitrue, InvestaX, IXS, Hivemind Capital, Blueprint, CertiK, StorX, NTT DOCOMO GLOBAL, DSRV, and Bridge (a Stripe company).

Third-Party Masternode Services

If you don't have the resources to maintain a masternode yourself, a number of third-party services and community providers offer managed node infrastructure, including: IndSoft, Node Forge, Zeeve, Blockdaemon, Tatum, NOWNodes, Asternodes, Ankr, thirdweb, and Goldsky.

Disclaimer: XDC Network does not officially endorse third-party services. Please perform due diligence before proceeding.

Conclusion

The XDC 3.0 Staking, Rewards & Burning upgrade is more than a reward reshuffle — it's a structural evolution of how the network achieves security, resilience, and decentralization:

Core Validators keep producing blocks with the strongest incentives
Protector Nodes add a fault-tolerance layer the network has never had before
Observer Nodes open a passive on-ramp into the validator ecosystem
Token burning keeps the economics sustainable

With the upgrade live on Apothem and the audit progressing, mainnet is on the horizon. Whether you're a current masternode operator, an institution evaluating XDC infrastructure, or a community member preparing to participate — now is the time to understand the architecture and get ready.

Questions about node setup, role assignment, or rewards? Drop them in the comments or post on xdc.dev — happy to help.

XDCE To XDC

James Williams — Fri, 21 Aug 2026 16:47:41 +0000

Hello Developers,

I'm interested in information on how to redeem my XDCE which I purchased years ago on metamask as XDC. I couldn't see it in my wallet for a long time and now it has apparently been changed to XDCE. I googled information concerning they change from one to another. Please let me know if it's possible to change it on metamask. I don't want to lose money invested and I didn't receive any information concerning a change deadline confirmation concerning my XDC to XDCE. Please help me with a solution. I also use willj1968@outlook.com as contact
information. Thank you in advance!!

How to Generate a Seed Phrase Using Dice: A Complete BIP39 Guide

Rushabh Parmar — Tue, 04 Aug 2026 07:12:49 +0000

If you've ever created a crypto wallet, you've seen it happen: 12 or 24 words appear on your screen in a couple of seconds, and you're told to "write them down safely." That phrase is the master key to everything in that wallet — every coin, every token, every transaction history, forever. And yet almost nobody who uses one knows exactly how those words were chosen, or whether the process that chose them can be trusted.

This guide shows a different way to generate that phrase: using ordinary six-sided dice, offline, with a free open-source tool you can inspect line by line. No app store download, no account, no server involved at generation time.

Tool used in this guide: dice-to-seed — a free, open-source, single-file HTML generator.

Why Trust Dice Over Your Wallet's Built-In Generator?

Every crypto wallet app generates your seed phrase using a random number generator (RNG) running on your phone or computer. That RNG needs to produce numbers that are truly unpredictable — because if anyone could guess or reproduce them, they could reconstruct your seed phrase and steal everything the wallet holds.

The problem is that you can't see or verify that RNG. You're trusting:

That the wallet app's code has no bugs affecting randomness
That the device's operating system hasn't been compromised by malware
That no one tampered with the app before you downloaded it
That the hardware itself has no hidden flaws

Software RNG failures aren't theoretical. There is a well-documented history of wallets, apps, and cryptographic libraries shipping with weakened or predictable random number generation — sometimes by accident, sometimes not. Once a weakness like that is found, every wallet ever created with that flawed generator is retroactively at risk.

Physical dice sidestep this entire category of risk. A die sitting on your desk isn't running software. It can't be hacked, backdoored, or silently weakened by an update. Its randomness comes from physics — the chaotic, unpredictable way it tumbles and bounces — not from code you have to trust blindly.

This is the same principle used by high-security systems like Cloudflare's LavaRand which uses a wall of physical lava lamps as an entropy source specifically because physical, real-world randomness is harder to manipulate than anything purely computational.

What Problem Are We Actually Solving?

Three things, specifically:

1. Verifiable randomness. With dice, you watch the entropy get created. There's no black box between "the random event" and "the number you wrote down."

2. Air-gapped generation. The seed phrase never has to exist on a device connected to the internet at the moment of creation, closing off remote attack vectors entirely.

3. Auditable software. The tool that converts your rolls into words is a single open-source HTML file — anyone can read the code, verify it does exactly what it claims, and confirm nothing is sent anywhere.

What we are not solving: safe storage of the phrase afterward, protection against someone watching you roll, or protection against a compromised device that's used to display the words later. Dice generation is one link in the security chain — a strong one, but not the only one that matters.

The Standard Behind It: BIP39

The 12–24 word phrase format itself follows a specification called BIP39, used by virtually every major crypto wallet (Bitcoin, Ethereum, XDC, and most EVM-compatible chains included). BIP39 defines:

A standardized list of 2048 English words
How raw randomness (called "entropy") is mapped to those words
A built-in checksum so a typo during recovery gets caught instead of silently creating the wrong wallet

Because it's a shared standard, a phrase generated by our dice tool restores correctly in any BIP39-compatible wallet — hardware wallets, MetaMask, Trust Wallet, and XDC-native wallets alike.

Step-by-Step: Generating Your Seed Phrase With Dice

What you need

A fair six-sided die (a casino-grade die with sharp edges is ideal — avoid rounded "fun" dice, which can be subtly biased)
A computer you can safely disconnect from the internet for a few minutes, or one that's genuinely air-gapped
Pen and paper to record the final phrase
The dice-to-seed tool: github.com/RushabhParmar12/dice-to-seed

Step 1 — Download the tool

Go to the dice-to-seed GitHub repository and download dice-to-seed.html. Because the tool is fully open-source, you (or anyone) can read through the code before running it — there's nothing hidden.

Step 2 — Move to an offline environment

Transfer the file to the computer you'll actually use to generate the phrase, then disconnect Wi-Fi and any Ethernet cable. This step matters: it guarantees the phrase can't leave the machine even if something unexpected happens.

Step 3 — Open the file in your browser

No installation needed — double-click dice-to-seed.html and it opens directly. The page will show a warning if it detects you're still online, as a reminder to disconnect first.

Step 4 — Choose your phrase length

The tool supports both:

24 words (256 dice rolls) — the maximum security level
12 words (128 dice rolls) — still fully secure and BIP39-standard, just a shorter phrase

Step 5 — Roll the die and enter each result

Roll your die and type the number (1–6) into the page as you go. Do this for all 256 rolls (or 128, for a 12-word phrase). As you type, a live grid on the page fills in — this is your entropy being generated in real time, so you can visually confirm the process is working correctly.

Behind the scenes, each roll becomes a single bit: odd numbers (1, 3, 5) become 0, even numbers (2, 4, 6) become 1. Since a die has exactly three odd and three even faces, this gives a perfectly balanced 50/50 result every roll — no bias toward any outcome.

Step 6 — Let the tool calculate your phrase

Once all rolls are entered, the tool automatically:

Runs a standard checksum calculation over your entropy (this step uses your browser's built-in cryptographic function, not randomness — it's the same every time for the same rolls)
Looks up each 11-bit group in the official BIP39 word list
Displays your full recovery phrase

Step 7 — Write it down by hand

Copy the words onto paper — never a screenshot, never a note app, never a password manager during this step. There is no copy button in the tool, deliberately, to keep the phrase off the clipboard.

Step 8 — Verify independently before funding a wallet

This step is not optional if real funds are involved. Restore the same phrase on a hardware wallet, or a second independent BIP39 tool, and confirm both produce identical wallet addresses. Only fund the wallet after two independent methods agree.

Step 9 — Close the browser

The tool stores nothing — no history, no cache, no saved state. Closing the tab clears everything from that session.

Frequently Asked Questions

Is dice-generated randomness actually better than my wallet app's randomness?
It's not necessarily "better" in a mathematical sense — a properly implemented software RNG can also produce excellent randomness. The advantage of dice is verifiability: you don't have to trust code you can't see. For high-value wallets, treasury keys, or long-term cold storage, that verifiability is worth the extra effort.

Does this work for Bitcoin, Ethereum, and XDC Network?
Yes. BIP39 is a shared standard across virtually all major chains, including EVM-compatible networks like XDC. The resulting phrase restores identically wherever BIP39 is supported.

What if I make a mistake typing a roll?
The tool only accepts digits 1–6 and shows your progress live, so mistakes are easy to catch before finishing. If you do notice an error after generating the phrase, simply start over — dice are free and the process only takes a few minutes.

Is a 12-word or 24-word phrase better?
Both are considered cryptographically secure by current standards. 24 words offer a larger security margin and are generally preferred for high-value or long-term storage; 12 words are still standard and widely used.

Can I trust an HTML file I downloaded from the internet?
That's exactly why the project is open source — the code is fully readable on GitHub, so you (or someone you trust) can review exactly what it does before running it, instead of taking a claim on faith.

Try It Yourself

The full tool, source code, and technical documentation are available on GitHub:

👉 github.com/RushabhParmar12/dice-to-seed

It's free, open-source, and designed to be read before it's trusted.

[Insights] July Edition: Key Highlights and Developments from Plugin’s Journey

Pooja Balaji — Mon, 03 Aug 2026 17:33:55 +0000

Plugin just got faster, wider, and more connected all in the same month. Data feeds now speak across chains, a cross-chain bridge that took weeks to earn our trust finally proved itself end-to-end, and Automation just got faster under the hood...here's the story behind the progress!

📰 News

⛓️ Plugin Data Feeds Step Into a Multi-Chain World

Plugin has taken its next step toward expanding its presence across multiple blockchain networks. Plugin Data Feeds are now live on testnet across multiple blockchains: XDC Apothem, Ethereum Sepolia, and BNB Smart Chain Testnet with each network reporting independently.

For developers, this means the same Plugin infrastructure that powers lending platforms, DEXs, stablecoins, derivatives, and RWAs on one chain can now be built with across ecosystems, using the same Plugin infrastructure across supported networks.

Supporting this expansion is PLI SWAP, a bridge connecting XDC and EVM-compatible chains, which has completed development and is now deployment-ready on testnet. With multi-chain data feeds live and the bridge ready to go, mainnet rollout is the next milestone on the horizon.

🔓 Major Milestone Unlocked

The Plugin CCIP bridge, providing a single communication lane between XDC and Base, is now fully operational end-to-end. Following extensive debugging across consensus logic, gas mechanics, RPC stability, and on-chain configurations, the team successfully validated the complete cross-chain flow from commit to execute, fully automated and verified on-chain.

Key milestones achieved include reliable message commitment from XDC to Base, automatic detection and execution by the Plugin oracle network without manual intervention, and successful completion of multiple full round-trip test messages. The team also identified and resolved infrastructure challenges, including message batching at scale and consensus edge cases, with every improvement verified across the full validator set. This milestone reflects the extensive protocol-level work to build more reliable cross-chain infrastructure.

🎙️ Weekly X Spaces with the Web3 Community

Plugin hosts an X Space featuring leaders and contributors from across the Web3 ecosystem to discuss emerging trends, share perspectives, and exchange insights on the latest developments in blockchain. These sessions provide an opportunity to showcase Plugin's decentralized infrastructure, engage with the broader Web3 community, and foster meaningful industry connections and potential collaborations.

Whether you're a developer, builder, or blockchain enthusiast, join us at 6 pm GST every Friday for new discussions, fresh perspectives, and the latest updates from the Plugin ecosystem.

Get latest updates: https://x.com/GoPlugin

🤖 Automation Gets Its Speed Fixed

Plugin has enhanced the performance of Smart Contract Automation network by optimizing coordination between nodes and reducing execution delays. These improvements ensure automated tasks are executed more quickly once on-chain conditions are met.

With faster transaction execution, improved monitoring, and more consistent performance, developers can build more responsive decentralized applications while users benefit from a smoother experience across DeFi protocols and other automated services.

🍽️ Food for Thought :

The most important infrastructure work rarely announces itself. Nobody notices a bridge until it fails, or a delay until it's gone. This month was a reminder that real trust in decentralized systems isn't built through big reveals it's built through the unglamorous work of finding the edge case, fixing the few extra seconds, and verifying it across every validator before calling it done.

🧠 Plugin Quiz :

Which token standard is commonly used for governance?

👉 Reply with your answer in the comments!