TL;DR
The previous research designed a Node Incentive Pool structure guaranteeing 7.6 years of pool survival, and the one before that defined the security threshold over continuous time intervals through the Oracle Session Security framework. These two studies answered “how long does the pool last” and “what security must be guaranteed,” but how rewards from that pool should be distributed to individual nodes remained unaddressed. This research fills that gap. Node reward distribution is a balancing problem among three pressures (pool stability, inflation-free loop, and early-phase adoption), and no single-mode distribution can satisfy all three. This study resolves the balance with a three-layer compensation framework (Activity, Throughput, Session Continuity) and phase-evolving weights. It also closes out the VRF variance compensation and node expansion triggers explicitly handed off by the Oracle Session Security research, as well as the delegated staking slashing allocation handed off by the Slashing Mathematics research.
Introduction: From Pool to Pocket
The two rivers of state synchronization economics have met and converged into the Node Incentive Pool. The previous research, the Reward Pool Sustainability Engine, verified what flows at that confluence and whether that flow can remain unbroken for 7.6 years. Yet the merged river must reach the pockets of individual node operators before the system actually works. The fact that the pool is large enough alone does not guarantee each node’s survival. This is the core question of node reward distribution.
The question looks simple at first. Just divide the pool by the number of nodes. But equal distribution immediately raises two problems. First, if nodes that do no work receive the same reward, the inflation-free loop becomes impossible. Second, because of the inherent variance in VRF-based leader selection, the actual block production count between nodes over the same period differs by -15 to -20 percent (as estimated in the previous Oracle Session Security research). Equal distribution ignores this variance, but from the node’s perspective, rewards then depend on luck.
What about purely performance-based distribution then? A method where rewards are proportional to the number of syncs processed. This approach also has two problems. First, in the early Phase 1, the network’s overall sync demand is so small that new nodes have no incentive to enter. Second, Oracle Session continuity, which is the unique characteristic of state synchronization oracles, is not reflected in the reward structure. The Session Security defined by the Oracle Session Security research is “maintaining the security threshold throughout the session,” yet if a node abandons its assigned session midway, another node must take over and this handoff cost is ultimately covered by the pool. An action that directly affects pool stability cannot be ignored in the reward structure.
This research faces these three pressures honestly. No single-mode distribution provides an answer, and we need a structure that explicitly separates a distribution layer for each pressure and then evolves their weights by phase.
Part I: The Three-Pressure Framework
1.1 Separating the Three Pressures
Node reward distribution in a state synchronization oracle is shaped by three pressures pulling in different directions.
Pressure A. Pool Stability: The Node Incentive Pool designed in the previous research distributes a fixed amount each year following the decay function R(y) = 600M · e^(-0.12y). The premise that this pool survives 7.6 years is that distribution occurs in a predictable form. If the distribution method varied the rate of pool depletion based on some external fluctuation, the 7.6-year survival guarantee would break.
Pressure B. Inflation-Free Loop: The Node Incentive Pool is distributed from a pre-allocated pool, not newly minted. However, even within pool distribution, if the same reward is given to nodes that do no work, this effectively functions as token value dilution. The essence of inflation avoidance is not “not minting” but “tokens issued being linked to actual value creation.”
Pressure C. Early Adoption: Phase 1 is a small network with 20 nodes and TVL up to $6M. When Oracle Fees are insufficient, the incentive for new node operators to enter comes from the stability of block rewards itself. Distribution that leans too heavily on performance blocks new entry.
These three pressures cannot be satisfied simultaneously by any single-mode distribution.
| Pressure | Distribution Direction Required | Conflict When Applied Alone |
|---|---|---|
| A: Pool Stability | Predictable → favors equal split | Pool drains regardless of performance |
| B: Inflation-Free Loop | Performance-proportional → favors throughput split | Blocks new node entry |
| C: Early Adoption | Activity-based reward → favors uptime split | Inefficient at Phase 3 |
1.2 Why Single-Mode Distribution Fails
Let us look concretely at how each of the three single-mode distributions fails.
Pure equal distribution (\(C_i = R(y) / N\)): All active nodes receive the same reward. Entry is easy, but since rewards are the same whether one works or not, pool depletion accelerates. Pressure B fails.
Pure performance distribution (\(C_i = R(y) \cdot T_i / \sum T_j\)): Rewards are exactly proportional to the number of syncs processed. Rational at Phase 3, but in early Phase 1 the sync demand itself is small, so only the distribution gap becomes extreme and new node entry is blocked. Pressure C fails.
Pure stake-proportional (\(C_i = R(y) \cdot S_i / \sum S_j\)): Nodes with more staking receive more. Induces capital concentration and lowers the Nakamoto Coefficient. Both Pressures B and C fail, with negative consequences for security as well.
If three pressures point in different directions, the distribution structure itself must be separated into layers corresponding to each pressure.
1.3 The Gas Cost Sanity Check
Before introducing the three-layer structure, let us first verify whether the rewards from the pool can cover the actual operating costs of a node. According to the previous Oracle Session Security research, the annual operating cost of a single node is as follows:
- Server/infrastructure: $6,000/year
- Monitoring/maintenance: $2,000/year
- Total operating cost: \(C_{op} \approx \$8,000\)/year/node
Using this value, we check whether Phase-specific rewards cover operating costs (at the token price of $0.045, the public R2 baseline from the Economy design document).
| Phase | Nodes | Annual Block Reward (M OZ) | Per Node (M OZ) | USD Value/Node | vs Operating Cost |
|---|---|---|---|---|---|
| Phase 1 (Y1) | 20 | 565 | 28.3 | $1,273,500 | ~159x |
| Phase 2 (Y3) | 50 | 445 | 8.9 | $400,500 | ~50x |
| Phase 3 (Y5) | 100 | 350 | 3.5 | $157,500 | ~20x |
Block rewards alone guarantee more than 20 times the operating cost. The entry incentive issue of Pressure C is therefore not a question of covering operating costs but of covering capital opportunity cost. APY-based analysis is covered in Part VI.
Let us also verify the conservative price scenario where the token price drops to $0.01:
| Phase | Nodes | USD/Node (Conservative) | vs Operating Cost |
|---|---|---|---|
| Phase 1 (Y1) | 20 | $283,000 | ~35x |
| Phase 2 (Y3) | 50 | $89,000 | ~11x |
| Phase 3 (Y5) | 100 | $35,000 | ~4.4x |
Operating cost coverage remains possible at Phase 3 even under the conservative price scenario, but the margin shrinks significantly. At that point Oracle Fee should account for 70 to 80 percent, consistent with the Phase-specific composition predictions from the prior research.
Part II: Three-Layer Compensation Architecture
2.1 The Distribution Function
Our node reward distribution function takes block reward \(R(y)\) and allocates it to node \(i\) as follows:
The distribution function as it first appeared, before it became Equation (1).
$$C_i(y) = R(y) \cdot \sum_{\ell \in \{A, T, S\}} w_\ell(y) \cdot \frac{\phi_\ell(i)}{\sum_j \phi_\ell(j)} \tag{1}$$
where \(w_\ell(y)\) is the phase-specific weight of layer \(\ell\), and \(\phi_\ell(i)\) is node \(i\)‘s score in layer \(\ell\). The three layers correspond to the three pressures:
- Layer A (Activity): Addresses Pressure C. Guarantees entry incentive through active state maintenance.
- Layer T (Throughput): Addresses Pressure B. Removes idle nodes through sync processing count.
- Layer S (Session Continuity): Addresses Pressure A. Preserves pool stability by minimizing Oracle Session handoff cost.
Figure 1: Three Pressures Framework
2.2 Layer A. Activity (Heartbeat for Early Phase)
The score is the proportion of time node \(i\) participates in consensus while online during an Epoch:
$$\phi_A(i) = u_i \cdot \mathbb{1}[S_i \geq S_{\min}] \cdot \mathbb{1}[\text{epoch participation}]$$
- \(u_i\): Uptime ratio within Epoch (0 to 1)
- \(S_i \geq S_{\min}\): Whether the minimum staking of 10M OZ is maintained
epoch participation: Whether the node participated in D-quencer consensus (BLS signature submitted)
Measurement cost: This information is already tracked by the D-quencer consensus engine. Uptime is automatically aggregated at the Epoch boundary, requiring no additional infrastructure. The development complexity of this layer is very low.
Why Activity (necessity check): For a BFT consensus system to function, nodes must be online and exchange consensus messages. This is a fundamental requirement of all PoS systems, and the same applies to state synchronization oracles. Compensating activity itself is not a “benefit” but covering the consensus system’s operating cost.
2.3 Layer T. Throughput (Anti-Free-Rider Mechanism)
Proportional to the number of syncs node \(i\) processed during an Epoch:
$$\phi_T(i) = T_i$$
- \(T_i\): Number of BVC cycles node \(i\) completed within the Epoch
Measurement cost: Since OSS emits an event upon every sync completion, only counting is needed. Maintaining a per-node sync counter in the State DB is sufficient. Development complexity is low.
Why Throughput (necessity check): If a node receives rewards from the pool while not actually performing sync processing, this means pool value operates decoupled from actual value creation. That is, inflation within the pool. Throughput distribution forces tokens from the pool to be linked to sync service provision. This is the core mechanism of the inflation-free loop.
Important correction: VRF-based leader selection inherently has variance. If Throughput is measured by simple count, per-node rewards vary by luck. This variance is addressed separately in Part III.
2.4 Layer S. Session Continuity (Unique to State Sync Oracle)
The ratio of Oracle Sessions that node \(i\) completed without handoff among those assigned:
$$\phi_S(i) = \frac{N_{completed}^{(i)}}{N_{assigned}^{(i)}}$$
- \(N_{assigned}^{(i)}\): Number of Oracle Sessions assigned to node \(i\) within the Epoch
- \(N_{completed}^{(i)}\): Among those, the count that expired or terminated without handoff
Sessions terminate normally through two paths: asset ownership transfer or maturity, or forced termination by regulatory action (CONFISCATE, etc.). The latter is not attributable to the node, so it is included in \(N_{completed}\). Only cases where another node took over due to node downtime or voluntary departure are excluded from \(N_{completed}\).
Measurement cost: OSS already tracks state based on session IDs (see the Oracle Session definition in the Thesis). Only the session assignment and termination times need additional recording. Development complexity is medium.
Why Session Continuity (necessity check): This is the most important necessity judgment in this research. The Session Security defined by the previous research is “maintaining the security threshold throughout the session,” yet when a node departs midway, a state restoration cost is incurred for another node to take over. This cost is not covered by Oracle Fees and is ultimately compensated from the pool. Therefore the session handoff ratio is a variable that directly affects pool stability.
Let us clarify how this layer differs from the so-called “Longevity Reward” (a bonus for nodes operating for a long time).
| Item | Longevity Reward (Convenience Design) | Session Continuity (Essential Design) |
|---|---|---|
| Measurement Unit | Time (operation duration) | Session (completed without handoff) |
| Reward Basis | “Lasting longer is good” | “Session handoff cost damages pool stability” |
| Received Without Working | Yes (time alone is enough) | No (if no session assigned, denominator is also 0) |
| Contribution to Pool Stability | Indirect | Direct |
Longevity Reward is rejected, Session Continuity is adopted. This distinction is the explicit application of the “necessity vs. convenience” principle in our guidelines.
2.5 Phase-Aligned Weight Evolution
The weights of the three layers evolve with network maturity.
| Phase | \(w_A\) (Activity) | \(w_T\) (Throughput) | \(w_S\) (Session Continuity) |
|---|---|---|---|
| Phase 1 (Y1-2) | 0.50 | 0.30 | 0.20 |
| Phase 2 (Y3-4) | 0.30 | 0.45 | 0.25 |
| Phase 3 (Y5+) | 0.20 | 0.50 | 0.30 |
Rationale for each weight change:
Decrease in \(w_A\) (0.50 → 0.20): In Phase 1, sync demand is so small that Throughput alone cannot induce new node entry. Placing significant weight on activity itself lowers the entry barrier. In Phase 3, activity becomes a baseline assumption, so its weight is reduced.
Increase in \(w_T\) (0.30 → 0.50): As the network matures, the penalty against idle nodes grows stronger. In Phase 3, throughput becomes the primary reward indicator, and a natural node attrition mechanism operates.
Increase in \(w_S\) (0.20 → 0.30): As TVL grows, the value per session increases and so does the absolute handoff cost. Since Session Continuity has the greatest impact on pool stability in Phase 3, its weight is gradually increased.
The sum of weights is always kept at 1. This means the total amount distributed is determined by \(R(y)\) and the layer weights only determine the form of that distribution. Pressure A (pool stability) is not broken.
| Phase | w_A | w_T | w_S |
|---|---|---|---|
| Phase 1 Y1-2 | 0.50 | 0.30 | 0.20 |
| Phase 2 Y3-4 | 0.30 | 0.45 | 0.25 |
| Phase 3 Y5+ | 0.20 | 0.50 | 0.30 |
Figure 2: Three-Layer Compensation Architecture with Phase Evolution
2.6 Explicit Exclusions: Quality Reward and Longevity Reward
Longevity was explicitly excluded above. How is Quality Reward (SLA-based latency, accuracy evaluation) handled?
The answer is avoiding double punishment. The slashing framework from the prior Slashing Mathematics research already imposes penalties for SLA-violating behavior: Sync Integrity Faults at 1 to 5 percent and Regulatory Compliance Faults at 5 to 15 percent. If the reward structure also evaluates SLA, the same behavior is punished twice. More importantly, Session Continuity measurement itself naturally reflects abnormal termination (node-attributable) as a score drop. If a session is interrupted due to SLA non-fulfillment, \(\phi_S(i)\) drops. Placing a separate Quality Reward layer is equivalent to measuring the same variable twice.
Therefore this research does not place Quality Reward as a separate layer, and any mechanism for clients to prefer higher-quality nodes and price differently is beyond the scope of this research. It is examined separately in subsequent research dealing with pricing models.
Part III: VRF Variance Compensation
3.1 The VRF Inequality Problem
The previous Oracle Session Security research explicitly left the following open to this research:
“Block production inequality due to VRF variance: ±15-20% (estimate, to be validated on testnet)”
VRF (Verifiable Random Function) is the mechanism by which D-quencer randomly selects Active Asserters. By the nature of randomness, the selection count over short periods is not even. If there are 20 nodes and 1000 selections occurred, the expected value is 50 per node, but in practice the standard deviation of about 7 (the standard deviation of binomial distribution \(\sqrt{np(1-p)}\)) occurs.
If left as is, the Throughput score of Layer T fluctuates by ±15 to ±20 percent based on luck. Having rewards determined by luck for the same effort imposes irrational risk on node operators.
3.2 The Averaging Mechanism
The simplest way to reduce variance is time-window averaging. We calculate node \(i\)‘s Throughput score as the average over multiple Epochs rather than a single one:
The √7 reduction stayed on the whiteboard after the discussion ended.
$$\tilde{\phi}_T(i, y) = (1 – \rho) \cdot \phi_T(i, y) + \rho \cdot \bar{\phi}_T^{(w)}(i, y) \tag{2}$$
where:
- \(\phi_T(i, y)\): Throughput score of the current Epoch
- \(\bar{\phi}_T^{(w)}(i, y)\): Average Throughput score over the previous \(w\) Epochs
- \(\rho\): Averaging weight (0 to 1)
Recommended values of \(w\) and \(\rho\):
\(w = 7\) Epochs (a roughly one-week window). Since binomial variance decreases as \(1/w\), a 7-Epoch average yields about \(\sqrt{7} \approx 2.65\) times variance reduction compared to a single Epoch. The ±15-20 percent variance shrinks to ±5.7-7.5 percent.
\(\rho = 0.5\). A balance between current and past performance. Too high makes new nodes hard to evaluate quickly, too low weakens the variance compensation effect.
3.3 The Compensation Effect Seen Through the Gini Coefficient
Let us measure the effect of VRF variance on reward gaps between nodes using the Gini coefficient. Under the idealized assumption that 20 nodes each have an even 1 percent throughput:
- Gini before compensation, single Epoch: about 0.09 (gap as large as variance)
- Gini after compensation, 7-Epoch average: about 0.034 (theoretically \(0.09 / \sqrt{7}\))
A Gini of 0.034 is practically equivalent to equal distribution. The impact of VRF variance on rewards is reduced to an academically negligible level. At the same time, the system still responds to actual performance differences (per-node processing capability differences), since these differences do not disappear in the time average.
Let us also note the relation to the \(\alpha\) coefficient. The State Sync Adjustment Coefficient \(\alpha = 1.5\) introduced by the prior Economic Security Requirements research is an adjustment on the security requirement side, whereas the VRF variance compensation in this research is an adjustment on the reward distribution side. The two variables address different aspects and therefore do not directly combine. Still, both share the common goal of “mitigating the impact of variance on the system,” which is worth comprehensive review in a future integrated simulation.
with w = 7 Epoch, ρ = 0.5
Figure 3: VRF Variance Compensation Effect
Part IV: Delegated Staking and Node Onboarding
4.1 Validator-Delegator Distribution
In delegated staking, Delegators delegate tokens to Validators and share rewards in return. Validators take commission as compensation for infrastructure operation and node management.
The prior Oracle Session Security research proposed a commission range of 5 to 15 percent, and this research fixes the recommended value at 10 percent. Rationale:
- Below 5 percent: Recovery of the Validator’s infrastructure operating cost ($8,000/year) becomes difficult. In particular, this acts as a barrier to entry for new Validators in Phase 1 who have received little delegated stake.
- Above 15 percent: Higher than the Cosmos ecosystem average (5-10 percent), making Delegator acquisition difficult.
- 10 percent: The de facto standard level for Cosmos Hub, Polkadot, and others, capable of recovering the $8,000/year operating cost at around the point of 80,000 OZ in delegated stake.
We distribute the total reward \(C_v\) received by Validator \(v\) with Delegators as follows:
$$C_{val}(v) = c \cdot C_v + (1 – c) \cdot \frac{S_v^{own}}{S_v^{total}} \cdot C_v \tag{3}$$
$$C_{del}(j, v) = (1 – c) \cdot \frac{S_j^{del}}{S_v^{total}} \cdot C_v \tag{4}$$
where:
- \(c\): Commission ratio (recommended 0.10)
- \(S_v^{own}\): Validator’s own stake
- \(S_j^{del}\): Amount Delegator \(j\) delegated to \(v\)
- \(S_v^{total} = S_v^{own} + \sum_j S_j^{del}\): Validator \(v\)‘s total stake
This structure is reasonable in that the Validator also receives, without commission, the portion of rewards arising from their own stake.
4.2 Slashing Allocation
The prior Slashing Mathematics research left the question of slashing allocation in delegated staking open to this research. The answer here is stake-proportional allocation.
When Validator \(v\) is slashed by ratio \(\theta\):
$$L_{val}(v) = \theta \cdot S_v^{own} \tag{5}$$
$$L_{del}(j, v) = \theta \cdot S_j^{del} \tag{6}$$
Rationale: Delegation is a voluntary choice, and the Delegator delegates with knowledge of the Validator’s operational risk. If only the Validator bears slashing, an asymmetry arises where the Validator takes only commission and avoids all risk. This is the Cosmos Hub standard model, structurally validated by the market.
Exception: For L5 (Collusion + Tombstoning), since Delegators have no substantive responsibility, Delegator slashing is capped at the general L4 level (15 to 50 percent). That is:
$$\theta_{del}(L5) = \min(\theta_{val}(L5), \theta_{L4,max})$$
This reflects the social agreement that Delegators should not bear unlimited liability for the Validator’s malicious actions.
4.3 New Node Onboarding Weight
A weight of 1.2x is applied to the Activity score for the first 6 Epochs after a new node enters:
$$\phi_A^{onboard}(i) = 1.2 \cdot \phi_A(i) \quad \text{for first 6 epochs}$$
Rationale: New nodes naturally have low Throughput scores in the first few Epochs because sync assignment is small (VRF does not quickly recognize new nodes). If the reward is low while bearing the same operating cost, entry incentive weakens. A 1.2x weight is roughly at the level of covering the entry cost for the first week, and it automatically releases after 6 Epochs without significantly affecting existing nodes’ rewards.
This mechanism improves new nodes’ first-week APY by approximately +20 percent and encourages new node inflow during the Phase 1-2 transition.
Part V: Node Expansion Triggers
5.1 The Question Inherited from the Previous Research
The prior Oracle Session Security research left the following question open to this research:
“Optimal node expansion: At what pace should we expand from 20 to 100 nodes? What triggers expansion?”
This research answers the question. The refinement of the efficiency index \(E(n)\) and the network effects analysis, however, fall outside the scope of this research and are deferred to separate subsequent research.
5.2 Principles of Expansion Trigger Conditions
Node count expansion is decided by governance vote when the following three conditions are simultaneously met. The specific thresholds of each condition are governance decisions adjusted based on operational data, so only the principles are placed in the main text.
Condition 1: TVL Threshold
The review for expansion to the next Phase begins when the TVL approaches the current Phase ceiling. The threshold is set at a point before the ceiling rather than at the ceiling itself, because expanding only after the TVL reaches the ceiling risks a temporary breach of the security threshold. The advance point provides sufficient buffer for governance decision-making and onboarding of new nodes.
Condition 2: APY Stability
The average APY over a preceding fixed window must comfortably exceed the Survival Threshold (6 percent). Since per-node rewards split as the node count grows, average APY decreases, and an advance safety margin must be set so APY does not fall below the Survival Threshold after expansion.
Condition 3: Pool Balance Threshold
The remaining balance of the Node Incentive Pool must be at or above the Yellow Alert threshold defined in the prior research. Below that, additional node entry accelerates pool depletion, so expansion is suspended.
5.3 Expansion Pace Principles
Even when all three conditions are met, an abrupt expansion of node count brings operational risk. This research recommends gradual expansion. The monthly count of new nodes should guarantee sufficient validation time for the D-quencer slashing mechanism, and should accumulate data verifying the intended effect of the new node onboarding weight (Section 4.3). The specific monthly expansion count is a governance decision.
Scope note: This research covers the principles of expansion trigger conditions and pace. Quantitative refinement of the efficiency index \(E(n)\) and detailed analysis of the node-count-to-throughput relationship require network effects analysis and are deferred to separate subsequent research. The impact of node count increase on client pricing is also examined in subsequent research dealing with pricing models.
Part VI: Sustainability Verification
6.1 Inflation-Free Loop Verification
Let us verify whether the three-layer structure truly guarantees the inflation-free loop. Assume the following scenario:
- Among 20 nodes, 5 are “stake-only” nodes (no sync processing, but Activity maintained)
- The remaining 15 process all syncs evenly
Distributing with Phase 1 weights (0.50, 0.30, 0.20):
- Idle nodes (5): \(\phi_A = 1\), \(\phi_T = 0\), \(\phi_S = N/A\) (denominator 0)
- Active nodes (15): \(\phi_A = 1\), \(\phi_T = T_{total}/15\), \(\phi_S = 1\)
The reward received by idle nodes:
$$C_{idle} = R(y) \cdot \left[0.50 \cdot \frac{1}{20} + 0.30 \cdot 0 + 0.20 \cdot 0\right] = 0.025 \cdot R(y)$$
The reward received by active nodes:
$$C_{active} = R(y) \cdot \left[0.50 \cdot \frac{1}{20} + 0.30 \cdot \frac{1}{15} + 0.20 \cdot \frac{1}{15}\right] = 0.0583 \cdot R(y)$$
Ratio: \(C_{active} / C_{idle} \approx 2.33\). Idle nodes receive only about 43 percent of what active nodes receive.
Applying the same calculation with Phase 3 weights (0.20, 0.50, 0.30):
- \(C_{idle} = R(y) \cdot 0.20/100 = 0.002 \cdot R(y)\) (based on 100 nodes)
- \(C_{active} = R(y) \cdot [0.20/100 + 0.50/95 + 0.30/95] = 0.0104 \cdot R(y)\)
At Phase 3, idle nodes receive only about 19 percent of what active nodes receive. This is a level where neither operating cost ($8,000/year) nor capital opportunity cost can be recovered, and rational nodes voluntarily exit.
The structure where weight evolution strengthens the inflation-free loop over time is verified.
6.2 Token Price Sensitivity
The effect of token price changes on the distribution. The annual reward of a Phase 1 active node in USD:
| Token Price | \(C_{active}\) (M OZ) | USD Value | APY (S_min basis) |
|---|---|---|---|
| $0.045 (base) | 33.0 | $1,485,000 | 330% |
| $0.01 (conservative) | 33.0 | $330,000 | 73% |
| $0.005 (extreme) | 33.0 | $165,000 | 37% |
Compared with the Worst Case adjusted Phase 1 APY of 15 to 22 percent derived in the previous research, the system substantially exceeds the Survival Threshold (6 percent) even under extreme price scenarios. The distribution structure is robust to price fluctuations.
What if the price falls further? At the $0.001 level (-98 percent) scenario, APY becomes 7 percent, near the Survival lower bound. At that point, rather than the pool itself, a token price recovery mechanism or emergency protocol is needed, and this falls beyond the scope of this research. It is examined separately in subsequent research dealing with insurance and crisis recovery.
6.3 Impact on Pool Stability
Let us verify that the three-layer structure does not undermine the 7.6-year pool survival validated in the previous research. The key point:
Distribution function (1) does not alter the total amount. \(R(y)\) is the annual amount withdrawn from the pool, and since the weights \(w_\ell(y)\) always sum to 1, only the form of inter-node distribution is determined. The pool depletion speed remains exactly as the exponential decay function from the previous research.
One subtle effect: when nodes with low Session Continuity scores voluntarily exit, the remaining nodes process more syncs, leading to improved individual operating-cost efficiency. This effect is unrelated to pool depletion and rather raises the value efficiency of the pool. The net impact on pool stability is positive.
Part VII: Synthesis and Open Questions
7.1 Confirmed Node Reward Distribution Parameters
| Parameter | Value | Basis |
|---|---|---|
| Distribution function | Equation (1) | Three-layer structure |
| Phase 1 weights \((w_A, w_T, w_S)\) | (0.50, 0.30, 0.20) | Entry incentive priority |
| Phase 2 weights | (0.30, 0.45, 0.25) | Performance transition |
| Phase 3 weights | (0.20, 0.50, 0.30) | Performance + stability |
| VRF averaging window \(w\) | 7 Epochs | \(\sqrt{7}\) variance reduction |
| VRF averaging weight \(\rho\) | 0.5 | Current/past balance |
| Validator commission recommended | 10% | Cosmos/Polkadot standard |
| Slashing allocation | Stake-proportional | Cosmos Hub model |
| L5 Delegator slashing cap | L4 max (50%) | Delegator liability limit |
| New node onboarding weight | 1.2x for 6 Epochs | First-week entry cost coverage |
The specific operational thresholds for node expansion timing and pace were derived from this research, but as they fall under governance decision-making, only qualitative principles are placed in the main text. Specific values are governed by governance procedures.
7.2 Questions Deferred to Future Research
This research has resolved everything it can resolve within its scope as a Single Source of Truth. The following items are beyond the scope of this research and will be addressed in future research. Specific scheduling and prioritization of subsequent work are determined separately.
- Emergency compensation mechanisms and the role of the insurance pool under crisis conditions such as extreme token price drops or mass node departures
- Price differentiation mechanisms where clients pay different prices based on node quality levels
- Quantitative refinement of the efficiency index \(E(n)\) and its interaction with network effects
- Comprehensive sensitivity analysis between the distribution weights in this research and other parameters such as the security adjustment coefficient
Conclusion
If the previous two research efforts answered “how long does the pool last” and “what security must be guaranteed,” this research answered how node reward distribution from that pool should work.
There are three core results.
First, no single-mode distribution can simultaneously satisfy the three pressures (pool stability, inflation-free loop, and early-phase entry incentive). The three-layer compensation framework (Activity, Throughput, Session Continuity) corresponds exactly to each pressure.
Second, the Session Continuity layer is an essential mechanism unique to state synchronization oracles. “Bonus for long operation” is rejected as a convenience design, but “weight for nodes that complete assigned sessions without handoff” is essential as it directly contributes to pool stability. The distinction between necessity and convenience is the core design principle of this research.
Third, the phase-based weight evolution reflects network maturity over time. Phase 1 emphasizes entry incentive, Phase 3 emphasizes performance-based attrition, and since the weight sum is kept at 1, the pool depletion speed does not change.
This research resolved the VRF variance compensation and node expansion triggers explicitly handed off by the Oracle Session Security research, and the delegated staking slashing allocation handed off by the Slashing Mathematics research. Some remaining questions are deferred to future research.
References
[1] Cosmos SDK. (2024). Slashing Module Documentation. GitHub. https://github.com/cosmos/cosmos-sdk/blob/main/x/slashing/README.md
[2] Polkadot Wiki. (2024). NPoS and Validator Selection. https://wiki.polkadot.network/docs/learn-validator
[3] Buterin, V. (2017). On Inflation, Transaction Fees and Cryptocurrency Monetary Policy. Ethereum Foundation Blog. https://blog.ethereum.org/2016/07/27/inflation-transaction-fees-cryptocurrency-monetary-policy/
[4] Cosmos Hub Documentation. (2023). Validator Rewards and Commissions. https://hub.cosmos.network/main/validators/validator-faq.html
[5] Daian, P., et al. (2020). Flash Boys 2.0: Frontrunning in Decentralized Exchanges. IEEE S&P. https://ieeexplore.ieee.org/document/9152675
