# Revolution Node Network
### Three-Tier Participant Architecture
Revolution's topology implements a **hard two-level delegation cap**: Fan -> Creator -> Node. This
constraint prevents deep delegation trees that would make gas costs unpredictable and
accounting complex. When a node earns a batch reward, the payout cascades automatically
through the delegation hierarchy with deterministic, bounded execution costs. The design
ensures that even in worst-case scenarios with maximum participation (250 nodes × 200
creators), distribution loops remain computationally tractable at L2 gas prices.
The system enforces several **critical guardrails** to maintain scalability and economic
soundness. These include a 10-minute unstake cooldown to prevent gaming, bounded creator
sets per node (max 200), and transparent commission structures that create competitive
market dynamics. Each Reward Pool can only delegate to one node at a time, eliminating
dilution conflicts and simplifying the accounting model. This rigid topology might seem
restrictive, but it's precisely what enables Revolution to offer on-chain reward distribution at
scale - a feature that would be economically prohibitive with unbounded delegation trees.
####
**Key Network Constraints**
* Maximum 250 active validator nodes
* Maximum 200 creators per node
* 10-minute unstake cooldown period
* Single delegation path per creator
* Bounded distribution loops
####
**Economic Parameters**
* Node cut: 20% default (max 50%)
* Creator cut: 0-100% (fully flexible)
* 40-epoch emission decay curve
* Stake-weighted reward selection
* On-chain priority mechanism
### On-Chain Reward Selection
Revolution implements a novel approach to reward distribution that operates independently
from transaction sequencing. While distributed sequencing across the zkStack ecosystem
continues to evolve, Revolution's "soft consensus" mechanism enables **immediate
deployment of sovereign staking economics** without waiting for mature cross-chain
sequencer coordination. This separation of concerns represents a pragmatic engineering
choice that unlocks programmable rewards today while remaining compatible with future
sequencing infrastructure.
The reward selection mechanism operates as a **stake-weighted priority counter system**. Each
validator node maintains a priority value that increases by its stake weight on every round. The
node with the highest accumulated priority wins the reward for that batch, after which its
\
priority decreases by the total network stake. This algorithm converges to proportional fairness
over time - nodes with more delegated stake win proportionally more rewards, but the roundrobin nature prevents any single node from dominating consecutive blocks.
1. **Priority Accumulation**
1. Each node's priority counter increases by its
current stake weight every round
2. **Winner Selection**
1. The node with highest priority wins the batch
reward for that round
3. **Priority Reset**
1. Winning node's priority decreases by total
network stake
4. **Adaptive Smoothing**
1. If priority spreads grow too large, dampening
mechanisms reduce variance
The entire selection and distribution process executes fully on-chain. This stands in stark contrast to most L2s where reward distribution happens off-chain or through trusted aggregators. Revolution's approach trades some flexibility for transparency and programmability4every reward allocation is verifiable, every commission is enforceable by code, and the entire economic history lives on-chain for analysis and auditing.
Adaptive smoothing mechanisms prevent edge cases where priority spreads might grow excessively large due to stake distribution changes or extended runs of particular nodes winning. These safety rails ensure the system remains stable and fair even under adversarial conditions or unexpected stake dynamics. The priority-based approach also gracefully handles node additions and removals, with new entrants starting at zero priority and gradually accumulating selection weight proportional to their stake.
### Distribution Mechanics & Economic Flows
When a validator node wins a batch reward, the funds flow through a **deterministic cascade**
with no central accumulation pool. Rewards land directly at the NodeContract, where the node
immediately claims its commission (the "node cut"). The remaining balance distributes prorata acros all Reward Pools that have delegated stake to that node. Each Reward Pool then
applies its own commission (the "take rate") before indexing the residual to fan accruals.
This multi-tier split happens **atomically on-chain** with bounded computational costs.
Distribution loops iterate only across the pools delegated to the winning node (max 200). Fan
balances update through indexed accrual accounting rather than direct transfers, making
claims cheap and enabling fans to accumulate rewards over time before withdrawing.
The protocol includes sophisticated **failure handling** to prevent distribution blockage. If any
transfer fails during the cascade - due to gas limits, receiver contract issues, or other edge
cases - those funds automatically queue as pending claimable rewards rather than reverting
the entire distribution. This fail-safe design ensures that one problematic creator or node
configuration cannot halt reward flows for the entire network.
Performance management includes **eviction logic** that allows nodes to rotate out their
lowest-delegated creator when approaching the 200-creator cap. This mechanism maintains
distribution efficiency under load while preserving the economic rights of existing participants.
Evicted creators can re-delegate to other nodes, and their fans' principal and accrued rewards
remain fully accessible throughout the transition.
The competitive dynamics this creates are powerful: nodes optimize for creator quality and
aggregate stake rather than just raw numbers, while creators compete on utility offering,
commission rates, and community engagement. **Every economic parameter is visible onchain**, enabling fans to make informed decisions and market forces to reward value creation.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://revolution-network.gitbook.io/whitepaper/network-architecture/revolution-node-network.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.