Skip to content

feat: XDC Network Protocol Upgrade Proposal - Reward Mechanism & Node Tiers #36

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AnilChinchawale wants to merge 3 commits into
base: main
Choose a base branch
from
Open

feat: XDC Network Protocol Upgrade Proposal - Reward Mechanism & Node Tiers #36

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bb13aec
feat: Add XDC Network Protocol Upgrade Proposal
AnilChinchawale Feb 19, 2026
5c502ca
feat: Add reward mechanism upgrade proposal to navigation
AnilChinchawale Feb 19, 2026
9859fc2
docs: Add proposal reference to governance overview
AnilChinchawale Feb 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions docs/xdcchain/governance/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,16 @@ title: Overview - XDCDAO

The DAO Treasury within the [XDCDAO](https://www.xdcdao.org/) framework plays a critical role in the XDC Network's decentralized governance system. It is meticulously designed to manage the community's collective resources efficiently, securely, and transparently. This section provides a structured overview of the DAO Treasury, highlighting its purpose, operation, funding sources, and significance within the DAOFIN ecosystem.

## Upcoming Protocol Upgrades

> 🔔 **New Proposal**: [XDC Network Reward Mechanism Upgrade (XDC 2.0)](./proposal-reward-mechanism-upgrade.md)
>
> This proposal introduces:
> - Three-tier node system (Master, Protector, Observer)
> - Unlimited staking with fixed rewards
> - Fee burning mechanism
> - Enhanced gas model

## Purpose of the DAO Treasury

The DAO Treasury's primary objective is to support the sustainable growth and development of the XDC Network by financing projects and initiatives that align with the community's goals. It acts as the financial hub for:
Expand Down
193 changes: 193 additions & 0 deletions docs/xdcchain/governance/proposal-reward-mechanism-upgrade.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,193 @@
---
title: XDC Network Protocol Upgrade Proposal - Reward Mechanism & Node Tiers
description: Proposal for XDC 2.0 Network Reward Mechanism Upgrade including Protector & Observer nodes, unlimited staking, and fee burning
---

# XDC Network Protocol Upgrade Proposal

## Reward Mechanism Upgrade & Node Tier System

**Author:** Community Proposal
**Date:** February 2026
**Status:** Draft

---

## Executive Summary

This proposal outlines a comprehensive upgrade to the XDC Network's reward mechanism, introducing a multi-tiered node system and enhanced economic model. The upgrade includes:

- **Three-tier node system**: Master Nodes, Protector Nodes, and Observer Nodes
- **Unlimited staking** with fixed per-node rewards
- **Enhanced fee burning mechanism**
- **Gas fee redistribution**

---

## 1. Background: How Rewards Work Today

In the current XDC Network's consensus model:

- Rewards are distributed every epoch (900 blocks)
- Total reward per epoch: 5000 XDC (defined by `XDPoSConfig.Reward`)
- 90% to block signers (Master Nodes)
- 10% to Foundation Wallet (`xdc92a289fe95a85c53b8d0d113cbaef0c1ec98ac65`)

### Current Reward Flow (3 Steps)

1. **Count Contributions**: Only block signers who were Master Nodes are counted
2. **Calculate Reward**: Fixed reward per epoch (5000 XDC)
3. **Distribute Rewards**:
- 90% to the owner of each contributing signer
- 10% to the Foundation Wallet

---

## 2. Proposed Changes

### 2.1 Three-Tier Node System

| Role | Rank | Total Nodes | Min Stake |
|------|------|-------------|-----------|
| Master Nodes | 1 – 108 | 108 | 10,000,000 XDC |
| Protector Nodes | 109 – 324 | 216 | 10,000,000 XDC |
| Observer Nodes | 325 – 1324 | 1000 | 10,000,000 XDC |

### 2.2 Proposed Per-Epoch Rewards

| Role | XDC Contribution | Annual Rewards | 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 |

> **Note:** Higher stake increases probability of being selected as Master Node. New selection criteria includes:
> - XDC Contribution amount
> - Node longevity (timestamp)
> - Hardware/Network resources allocated

### 2.3 Unlimited Staking

- No maximum stake limit
- Per-epoch rewards remain fixed regardless of stake amount
- Higher stake = higher probability of being selected as validator
- Voting mechanism allows community delegation

### 2.4 Fee Burning & Gas Enhancement

#### Base Fee Burning (EIP-1559 Style)

- A portion of gas fees is burned from each transaction
- Base fee varies based on network congestion
- Burn rate: 30% of base fee

#### Priority Fee Redistribution

- 70% of priority fees go to the block proposer
- 30% distributed to Protector and Observer nodes

Comment on lines +76 to +88
Copy link

@coderabbitai coderabbitai bot Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Fee model is internally inconsistent between Section 2.4 and Section 4.1.

Two separate issues:

  1. Disposition of the non-burned base fee is never specified. Section 2.4 states 30% of the base fee is burned. Section 4.1's table echoes this. Neither explains what happens to the remaining 70% of the base fee (burned entirely? returned to validators? added to the network fee pool?).

  2. "Network Fee" in the Section 4.1 table appears to be a third, distinct fee component, but Section 2.4 describes only two fee types (base fee + priority fee). The 30% figure in the "Network Fee" row matches the 30% priority-fee redistribution from Section 2.4, but presenting it as a separate row in a table alongside "Base Fee" and "Priority Fee" implies it is an additional charge, inflating the perceived total fee burden and misleading implementers.

The table should be restructured to clearly show that the 30% "Network Fee" is a subset of the priority fee, not an additive component, and the fate of the 70% of base fee that is not burned must be specified.

🔧 Suggested restructured fee table for Section 4.1 
-| Component | Description |
-|-----------|-------------|
-| Base Fee | Dynamic, burned (30%) |
-| Priority Fee | Goes to validator (70%) |
-| Network Fee | Distributed to Protector/Observer nodes (30%) |
+| Component      | Split           | Destination                                  |
+|----------------|-----------------|----------------------------------------------|
+| Base Fee (30%) | Burned          | Deflationary burn                            |
+| Base Fee (70%) | [TBD]           | [Specify: e.g., burned, treasury, validator] |
+| Priority Fee   | 70% / 30%       | Block proposer / Protector + Observer nodes  |

Also applies to: 128-132

---

## 3. Technical Implementation

### 3.1 V2Config Structure

```go
type V2Config struct {
MasternodeReward float64 `json:"masternodeReward"`
ProtectorReward float64 `json:"protectorReward"`
ObserverReward float64 `json:"observerReward"`
MaxProtectorNodes int `json:"maxProtectorNodes"`
MaxObserverNodes int `json:"maxObserverNodes"`
FeeBurnRate float64 `json:"feeBurnRate"`
MinStakeAmount uint64 `json:"minStakeAmount"`
}
Comment on lines +95 to +104
Copy link

@coderabbitai coderabbitai bot Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

float64 is unsafe for token reward amounts — use integer/fixed-point types.

Blockchain financial values must be represented with exact arithmetic. float64 fields for MasternodeReward, ProtectorReward, ObserverReward, and FeeBurnRate introduce floating-point rounding errors that will produce non-deterministic results across nodes, causing consensus failures. The XDC codebase already uses *big.Int (via the Go math/big package) for all token denominations. Additionally, there is no MaxMasternodeNodes field for the 108-node cap, while MaxProtectorNodes and MaxObserverNodes are both present.

🔧 Proposed fix for 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"`
-    FeeBurnRate      float64 `json:"feeBurnRate"`
-    MinStakeAmount   uint64  `json:"minStakeAmount"`
+    MasternodeReward   *big.Int `json:"masternodeReward"`
+    ProtectorReward    *big.Int `json:"protectorReward"`
+    ObserverReward     *big.Int `json:"observerReward"`
+    MaxMasternodeNodes int      `json:"maxMasternodeNodes"`
+    MaxProtectorNodes  int      `json:"maxProtectorNodes"`
+    MaxObserverNodes   int      `json:"maxObserverNodes"`
+    // FeeBurnRate stored as basis points (e.g., 3000 = 30%)
+    FeeBurnRate        uint64   `json:"feeBurnRate"`
+    MinStakeAmount     *big.Int `json:"minStakeAmount"`
 }
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@docs/xdcchain/governance/proposal-reward-mechanism-upgrade.md` around lines
95 - 104, The V2Config struct uses float64 for monetary fields which is unsafe;
change MasternodeReward, ProtectorReward, ObserverReward, FeeBurnRate (and
MinStakeAmount if representing token amounts) to integer/fixed-point types used
elsewhere (e.g., *big.Int for token amounts via math/big, and an integer scaled
unit for FeeBurnRate such as parts-per-billion or basis points) to ensure exact
arithmetic and consensus safety; also add the missing MaxMasternodeNodes int
field (to represent the 108-node cap) alongside MaxProtectorNodes and
MaxObserverNodes. Ensure constructors/JSON (un)marshalling logic and any code
using V2Config (references to V2Config, MasternodeReward, ProtectorReward,
ObserverReward, FeeBurnRate, MinStakeAmount, MaxProtectorNodes,
MaxObserverNodes) are updated to handle the new types and scaling convention.

```

### 3.2 Implementation Steps

1. Pull candidates from parent state of epoch switch block
2. Rank by Candidate Cap (stake from owner + voters)
3. Assign roles (Master, Protector, Observer)
4. Calculate fixed rewards per contributing node
5. Distribute rewards to node owners
6. Apply 90/10 split with Foundation Wallet
Comment on lines +107 to +114
Copy link

@coderabbitai coderabbitai bot Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Step 6 ("Apply 90/10 split with Foundation Wallet") contradicts the proposed new reward model.

The new model replaces the flat 90/10 split with fixed per-node rewards across three tiers. Retaining Step 6 verbatim implies the Foundation Wallet split is applied on top of the three-tier distribution, which conflicts with the reward table in Section 2.2. This needs to either be removed or replaced with an explicit statement of what — if anything — the Foundation Wallet receives under the new scheme.

🔧 Suggested replacement for Step 6 
-6. Apply 90/10 split with Foundation Wallet
+6. Distribute remaining epoch emissions: [specify Foundation Wallet allocation under new model,
+   e.g., fixed allocation, percentage of total, or zero]
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@docs/xdcchain/governance/proposal-reward-mechanism-upgrade.md` around lines
107 - 114, Step 6 in the "Implementation Steps" list contradicts the three-tier
fixed per-node reward model described in Section 2.2; update the "Apply 90/10
split with Foundation Wallet" line in the Implementation Steps (the numbered
list under "3.2 Implementation Steps") to either remove it entirely or replace
it with an explicit statement of the Foundation Wallet treatment under the new
scheme (e.g., "No additional Foundation Wallet split; rewards are fixed per-node
across Master/Protector/Observer tiers as defined in Section 2.2" or an explicit
percent if intended), and ensure the revised line clearly references the
three-tier distribution so readers see it does not stack with the per-node
rewards.


### 3.3 Penalty & Inactivity

- Inactive nodes (no contribution during epoch) receive no rewards
- Penalty provision: Serve few epochs before starting rewards
- Slashing mechanism for malicious behavior
Comment on lines +116 to +120
Copy link

@coderabbitai coderabbitai bot Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Penalty mechanism lacks quantitative specifics.

"Serve few epochs before starting rewards" is not actionable for implementation — "few" is undefined. Similarly, the slashing mechanism has no stated criteria (what constitutes malicious behavior?), no slashing percentage, and no appeal/recovery process. For a governance proposal that will drive a hard-fork implementation, these must be precisely specified.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@docs/xdcchain/governance/proposal-reward-mechanism-upgrade.md` around lines
116 - 120, The "3.3 Penalty & Inactivity" section uses vague terms ("Serve few
epochs before starting rewards") and lacks concrete slashing rules; replace that
text with precise, implementable parameters: specify an exact number of warm-up
epochs (e.g., N epochs) before rewards begin for a node, define "inactive"
quantitatively (e.g., contribution threshold T per epoch), enumerate clear
malicious-behavior criteria for slashing (e.g., double-signing, equivocation,
prolonged downtime > M consecutive epochs, or incorrect state submissions),
state exact slashing percentages for each offense category (e.g., X% bond for
minor offenses, Y% + temporary ban for major offenses), define recovery/appeal
mechanics (how to submit appeals, evidence window in epochs, conditions for
partial/full bond restoration and unstaking delay), and include the
authoritative labels used in the implementation (reference the section header
"3.3 Penalty & Inactivity", the phrase "Serve few epochs before starting
rewards", and "Slashing mechanism") so authors can replace placeholders with
these concrete thresholds, percentages, and procedural steps for the hard-fork
spec.


---

## 4. Gas Fee Structure

### 4.1 New Fee Model

| Component | Description |
|-----------|-------------|
| Base Fee | Dynamic, burned (30%) |
| Priority Fee | Goes to validator (70%) |
| Network Fee | Distributed to Protector/Observer nodes (30%) |

### 4.2 Gas Limit Changes

- Current gas limit: Dynamic
- Proposed increase: 2x for smart contract execution
- Special provisions for XDPoS system transactions (free)

---

## 5. Security & Activation

### Requirements

- Full security audit
- Rigorous testnet simulations
- Clearly defined activation block (`TIPUpgradeReward = big.NewInt(XXXX)`)
- Community approval via governance process

### Risk Assessment

| Risk | Mitigation |
|------|------------|
| Unprecedented model | Extensive testing |
| Edge case behaviors | Monitoring & emergency response |
| Network congestion | Dynamic fee mechanism |

---

## 6. Timeline

| Phase | Timeline | Milestone |
|-------|----------|-----------|
| Testnet | Month 1-2 | Protocol simulation |
| Security Audit | Month 3 | Audit completion |
| Community Vote | Month 4 | Governance approval |
| Mainnet Upgrade | Month 5 | Hard fork activation |

---

## 7. Conclusion

This proposal represents a major step forward for the XDC Network:

- ✅ Recognizes contribution from all node tiers
- ✅ Encourages decentralization
- ✅ Provides sustainable reward model
- ✅ Implements fee burning for deflationary mechanics
- ✅ Positions XDC for long-term growth

---

## References

- [Original Proposal](https://www.xdc.dev/gary/proposal-xdc-network-reward-mechanism-upgrade-3kkc)
- [XDC Whitepaper](../whitepaper.md)
- [XDPoS Documentation](xdpos.md)
- [XDC Architecture](../learn/xdc-architecture.md)
Comment on lines +185 to +189
Copy link

@coderabbitai coderabbitai bot Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, locate the proposal file to confirm its directory
echo "=== Locating proposal file ==="
fd -t f "proposal-reward-mechanism-upgrade.md"

echo ""
echo "=== Checking for whitepaper.md ==="
fd -t f "whitepaper.md"

echo ""
echo "=== Checking for xdpos.md ==="
fd -t f "xdpos.md"

echo ""
echo "=== Checking for xdc-architecture.md ==="
fd -t f "xdc-architecture.md"

echo ""
echo "=== Listing docs/xdcchain directory structure ==="
tree -L 2 docs/xdcchain/ 2>/dev/null || find docs/xdcchain -type f -name "*.md" | head -20

Repository: XinFinOrg/Docs

Length of output: 1439

🌐 Web query:

site:xdc.dev proposal-xdc-network-reward-mechanism-upgrade

💡 Result:

The query matches this XDC Developers Forum post:

  • “Proposal: XDC Network Reward Mechanism Upgrade” (Gary) — posted Apr 21, 2025; updated Apr 25, 2025. It proposes changing XDC’s epoch-based rewards (epoch = 900 blocks/rounds; fixed 5000 XDC/epoch in the current config) into a tiered, fixed per-node reward model across Master (1–108), Protector (109–324), and Observer (325–1324) nodes, with distribution still described as 90% to contributing node owners / 10% to the Foundation wallet, and notes the upgrade would require a hard fork and an activation block parameter. [1]

Fix broken internal documentation links.

All three internal links have incorrect relative paths and will not resolve:

  • ../whitepaper.md should be ../../whitepaper.md (file is at docs/whitepaper.md, not docs/xdcchain/whitepaper.md)
  • xdpos.md should be ../xdpos.md (file is at docs/xdcchain/xdpos.md, not docs/xdcchain/governance/xdpos.md)
  • ../learn/xdc-architecture.md should be ../../learn/xdc-architecture.md (file is at docs/learn/xdc-architecture.md, not docs/xdcchain/learn/xdc-architecture.md)

The external link to the XDC Developers Forum post is live and accessible.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@docs/xdcchain/governance/proposal-reward-mechanism-upgrade.md` around lines
185 - 189, Update the three broken internal markdown links in the listed bullet
items: change "../whitepaper.md" to "../../whitepaper.md", change "xdpos.md" to
"../xdpos.md", and change "../learn/xdc-architecture.md" to
"../../learn/xdc-architecture.md" so the links in the block containing "[XDC
Whitepaper]", "[XDPoS Documentation]", and "[XDC Architecture]" resolve to the
correct files.


---

*This is a community-driven proposal. Questions and feedback are welcome.*
1 change: 1 addition & 0 deletions mkdocs.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -112,6 +112,7 @@ nav:

- Governance:
- Overview of XDCDAO: ./xdcchain/governance/overview.md
- Proposal: Reward Mechanism Upgrade (XDC 2.0): ./xdcchain/governance/proposal-reward-mechanism-upgrade.md
- User Guide: https://www.xdc.dev/0xbeny/xdcdao-understanding-the-proposal-window-39f8

- FAQ:
Expand Down
Loading