The XDC Network is evolving β and so is its reward mechanism.
This article outlines a detailed proposal to upgrade how rewards are calculated and distributed in the XDC Networkβs XDC 2.0βs Consensus. This builds on our earlier discussion and introduces new logic to better recognize node contributions while preparing the network for future security and scalability.
π§ Background: How Rewards Work Today
In the current XDC Networkβs consensus model:
- Rewards are distributed every epoch, not every block.
- An epoch equals 900 blocks (XDC 1.0) or 900 rounds (XDC 2.0).
- At the start of each epoch, a total reward (currently 5000 XDC) is allocated, defined by the parameter
XDPoSConfig.Reward
.
π§ Current Reward Flow (3 Steps):
- Count Contributions: Only block signers who were Master Nodes are counted.
- Calculate Reward: The protocol uses a fixed reward per epoch (e.g., 5000 XDC).
- Distribute Rewards:
- 90% to the owner of each contributing signer
- 10% to the Foundation Wallet (xdc92a289fe95a85c53b8d0d113cbaef0c1ec98ac65)
π Whatβs Changing: Introducing Protector & Observer Nodes
We're proposing a multi-tiered node reward system, where three types of nodes will now receive fixed, per-node rewards based on their rank and contribution:
Role | Rank by Stake Cap | Total Nodes |
---|---|---|
Master Nodes | 1 β 108 | 108 |
Protector Nodes | 109 β 324 | 216 |
Observer Nodes | 325 β 1324 | 1000 |
Each role will have a predefined per-epoch reward β but only if they actively contribute to network health.
π° Proposed Per-Epoch Rewards
Role | XDC Contribution | Annual Rewards | Approx. Per Epoch Reward |
---|---|---|---|
Master Node | 10,000,000 XDC | 1,000,000 XDC | β 57 XDC |
Protector Node | 10,000,000 XDC | 800,000 XDC | β 45 XDC |
Observer Node | 10,000,000 XDC | 400,000 XDC | β 23 XDC |
This is a major shift β rewards are now fixed per contributing node, rather than dynamically split.
Technically, no restriction to Contribute more XDC compared to 10,000,000 XDC to become a Masternode or protector node but Per EPoch Rewards will remain the same. Higher XDC contribution increases probability to be masternode as timestamp based validation will be replaced with new updates which includes XDC Contribution, Timestamp (to check longevity of node), Hardware/ Network resources allocated to the Masternode/Protector Node/Observer Node.
β οΈ Inactive nodes (no contribution during epoch) will receive no rewards also provision of penalty to serve few epoch before start getting rewards.
π Technical Enhancements
The new configuration will be managed via the upgraded V2Config struct:
type V2Config struct {
MasternodeReward float64 `json:"masternodeReward"`
ProtectorReward float64 `json:"protectorReward"`
ObserverReward float64 `json:"observerReward"`
MaxProtectorNodes int `json:"maxProtectorNodes"`
MaxObserverNodes int `json:"maxObserverNodes"`
}
Implementation Steps:
- Pull candidates from the parent state of the epoch switch block.
- Rank by Candidate Cap (stake from owner + voters).
- Assign roles (Master, Protector, Observer).
- Distribute fixed rewards to the owner of each contributing node. Also distribute rewards to the Foundation Wallet according to the 90/10 split.
π Future-Proofing the Network
While the reward values proposed are grounded in staking math and real-world logic, they are subject to change based on:
- Transaction volume
- Network activity
- Validator participation
- New edge cases that emerge in production
π Why This Is Unique
This model introduces a first-of-its-kind, tiered validator reward system in the blockchain space.
To our knowledge, no other blockchain has implemented a structure that:
- Recognizes not just core validators, but mid-tier and observer nodes
- Distributes fixed per-node rewards based on participation
- Provides room for adaptive scalability via upgradable node caps and reward values
But with innovation comes risk:
β οΈ As this model is unprecedented, no guarantee exists that it will work flawlessly in all conditions.
High network traffic, edge-case validator behaviors, and real-world operations may necessitate future refinements.
π§ͺ Security & Activation
This upgrade will be rolled out as a hard fork, requiring:
- A full security audit
- Rigorous testnet simulations
- A clearly defined activation block (e.g.,
TIPUpgradeReward \= big.NewInt(XXXX)
)
π§© Final Thoughts
The XDC Network is on a journey of rapid technical innovation. This reward upgrade is a big leap forward β one that honors contribution, encourages decentralization, and positions XDC for long-term sustainability.
We welcome feedback from developers, node operators, and community members to refine this proposal before implementation.
Letβs build the future of contribute-based reward systems β together.
Please note: There is nothing new in this proposal β it simply reinforces the original vision that has been in place since day one. We are not changing anything, only aligning the implementation more closely with XDCβs core principles.
βοΈ Questions or thoughts? Comment below.
Discussion (3)
Hi Gary,
Thank you for putting forward this proposal β I support the direction with updating the reward mechanism. Not sure how I feel about the tiered approach as I feel this might bring issues when a node advances through each tier. Keeping it more simple might be the best approach for success with just the 8% and 10%. Itβs a strong move toward greater decentralization, reliability, and long-term engagement across the network.
As part of this upgrade, Iβd like to propose a few additional enhancements that could further strengthen the security and flexibility of validator participation:
1.Smart Contract Ownership of Validator Nodes
Allowing smart contracts to act as the registered owners of validator nodes would enable decentralized staking protocols, DAOs, and community pools to participate directly in network consensus. This adds an important layer of programmability and trustlessness for participants, especially in pooled environments.
2.Enhanced Security via Multisig and Protocol-Controlled Wallets
Smart contract validator ownership would also allow for multisig authorization and layered access controls, which can significantly reduce risk for users and protocols. This added security is especially important as institutional and community-scale participation grows.
3.Ability to Update Reward Wallets If Compromised
In the unfortunate case of a compromised validator reward wallet or lost private keys, having a mechanism in place to securely rotate or update the wallet address would help ensure validator continuity and protect long-term stakers. This could involve a governance process or pre-approved ownership structure that enables this change without disrupting validator performance.
These features would further enhance the resilience, security, and flexibility of the XDC Networkβs infrastructure layer
All three points are very valid and very much needed. Currently there is no way to change a wallet in the case it is compromised. This forces the node operator to having to unstake their node, wait 30 das (cooling off period) to receive their collateral (10m XDC) and then hope that you are faster than the scammers to move the funds when withdrawing the assets from the compromised wallet to a new one (hopefully a hardware wallet). As node operators, we need this feature ASAP.
I also agree that we should maintain the simplicity of validators and standby's vs adding 2 layers of nodes (Protector and Observer), that will serve the same function they serve now. To be quite honest, I still dont see the reason of implementing Protectors and Observers if they are going to do what the rest of the nodes are doing. They're not going to do anything special or different than the rest of the nodes.