Oracle Session Security: Staking for Continuous State Protection

TL;DR

Oracle Session Security is a new framework that mathematically defines security across continuous time intervals rather than discrete transactions. In this research, we extend the threshold formula from the previous security study into a time-integral form to derive the actual staking requirements needed for state synchronization. The network establishes fixed minimum staking requirements per node, with security scaling achieved through node count expansion and the Security Reserve Pool rather than dynamic parameter changes. Block rewards are reinterpreted as the baseline insurance premium for continuous security, with Phase 1 establishing an annual reward distribution rate of 5-7%. In the Normal Case scenario, Phase 1 expected APY ranges from 15-22%, with the survival threshold analyzed at approximately 6% APY.

---

Introduction: The Temporal Dimension of Security

In our previous research, we quantified the security requirements of the state synchronization economy. The Security Threshold Formula established in the Economic Security Requirements study was as follows:

$$\beta \cdot S_{total} \cdot p \cdot \theta > V_{protected} \cdot \gamma + C_{operational}$$

Where β is the stake ratio required for an attack (0.33), S_total is total staking amount, p is token price, θ is slashing ratio, V_protected is protected value, and γ is the extractable ratio.

However, this formula contains an implicit assumption: security is evaluated at discrete points in time. For typical blockchains, this assumption is sufficient. Each block is independent, and security breaches occur at specific blocks.

But oracle state synchronization is fundamentally different. What we must protect is not individual transactions but state consistency across continuous time intervals. When an Oracle Session starts at t₀ and ends at t₁, security must be maintained at every moment in between.

This is the background that led us to define Oracle Session Security: the economic and cryptographic framework ensuring state integrity throughout the entire synchronization lifecycle.

Part I: Session Security Framework

1.1 Mathematical Definition of Session Security

Let the existing security function s(t) represent the instantaneous security level at time t. In typical blockchains, it is sufficient for s(t_bi) > s_threshold at each block b_i.

However, Oracle Sessions require a different condition:

$$\mathcal{S}_{session}(t_0, t_1) = \int_{t_0}^{t_1} s(t) \, dt$$

Here, session security S_session is the integral of security over the entire time interval.

More importantly, the minimum condition is:

$$\min_{t \in [t_0, t_1]} s(t) \geq s_{threshold}$$

The implication of this condition is clear: a session’s security is determined by its most vulnerable moment. Even if perfect security is maintained 99% of the time, the entire session is at risk if a 1% vulnerability window exists.

1.2 The Meaning of Continuous Security

Why does this matter? Traditional oracles (e.g., Chainlink) provide discrete price feeds. Attackers can target specific update moments for frontrunning or exploit the gaps between updates.

Oraclizer’s state synchronization is fundamentally different. RWA states change continuously, and the integrity of these changes must be guaranteed throughout the entire session. Bond interest accrual, real estate rental attribution, game item attribute changes—all of these don’t occur at specific “blocks” but happen continuously through the flow of time.

Therefore, our staking economics is not simply about “locking up enough capital to prevent attacks” but about economically guaranteeing trust across continuous time.

1.3 Time Extension of Security Threshold

Extending the Security Threshold Formula from previous research to the time dimension:

$$\forall t \in [t_0, t_1]: \beta \cdot S(t) \cdot p(t) \cdot \theta > V_{protected}(t) \cdot \gamma$$

Here, all variables become functions of time. Specifically:

• S(t): Total staking amount at time t
• p(t): Token price at time t
• V_protected(t): Protected RWA value at time t

To practically satisfy this continuous condition, we apply conservative estimation:

$$\beta \cdot S_{min} \cdot p_{min} \cdot \theta > V_{max} \cdot \gamma$$

The principle is that even with the minimum staking and minimum token price expected during a session, we must be able to secure the maximum protected value.

Part II: Staking Requirements Design

2.1 Design Philosophy: Fixed Minimums with Flexible Scaling

Rather than implementing complex dynamic staking formulas that would be difficult to manage in smart contracts, Oraclizer adopts a more practical approach: fixed minimum requirements per node with security scaling through node count expansion.

This design philosophy addresses several operational realities:

1. Contract Stability: Fixed parameters are easier to audit, understand, and implement in immutable smart contracts
2. Predictable Entry: Node operators can make investment decisions with clear, unchanging requirements
3. Flexible Security: As TVL grows, security scales through more nodes rather than parameter changes
4. Reserve Buffer: The Security Reserve Pool provides additional flexibility during growth phases

2.2 Per-Node Staking Parameters

The following fixed parameters govern node staking:

Parameter	Value	Rationale
Minimum Staking per Node (Smin)	10M OZ	Ensures meaningful economic commitment and slashing deterrence
Maximum Staking per Node (Smax)	30~50M OZ	Prevents excessive concentration while allowing growth
Total Token Supply	10B OZ	Design parameter
Initial Node Target	20 nodes	Phase 1 network size
Mature Node Target	100 nodes	Full decentralization goal

Security Threshold Analysis Tool

While staking requirements are fixed, the Security Threshold Formula remains valuable as an analytical tool to assess whether current network configuration provides adequate security for given TVL levels:

$$S_{required} = \frac{V_{protected} \cdot \gamma \cdot \alpha}{\beta \cdot p \cdot \theta \cdot (1 + \delta)}$$

Using baseline parameters:

Parameter	Value	Notes
Token Price (p)	$0.01	Conservative initial assumption
Extractable Ratio (γ)	0.1	Reduced by protocol design (preemptive locking, zk verification)
Attack Threshold (β)	0.33	BFT standard
Slashing Ratio (θ)	0.10	Base rate, to be refined in slashing research
State Sync Adjustment (α)	1.5	Initial assumption for Session Security; to be validated on testnet
Deterrence Effect (δ)	0.3	Reputation/slashing effect; conservative scenario (δ=0) also analyzed

Conservative Scenario Analysis (δ = 0)

The deterrence effect coefficient δ = 0.3 assumes that reputation damage provides 30% additional attack deterrence beyond direct slashing. However, given blockchain’s pseudonymous nature, this may be optimistic. Under the conservative assumption of δ = 0:

$$S_{required}^{conservative} = \frac{V_{protected} \cdot \gamma \cdot \alpha}{\beta \cdot p \cdot \theta} = 1.3 \times S_{required}^{base}$$

This represents a 30% increase in security requirements, which informs our Security Reserve Pool sizing.

2.3 Security Scaling Mechanism

As TVL grows, Oraclizer maintains security through three mechanisms rather than changing per-node requirements:

1. Node Count Expansion

Phase	Target Nodes	Total Minimum Staking	Supported TVL Range
Phase 1	20	200M OZ	Up to $6M
Phase 2	50	500M OZ	Up to $15M
Phase 3	100	1B OZ	Up to $30M

2. Voluntary Additional Staking

Existing nodes can stake beyond S_min up to S_max. As network value increases, higher staking becomes economically rational due to increased fee revenue.

3. Security Reserve Pool

In Phase 1, the team operates a portion of nodes for network security. Adding a buffer to the minimum for 51% attack defense (51%), we set the team operation ratio at 55%.

• Team-operated nodes out of 20 total: 11 (55%)
• Team staking volume: 11 × 10M = 110M OZ minimum
• Percentage of total supply: 1.1%

Management Approach:

• Managed in locked/reserved addresses
• Governance voting rights restricted
• Gradual reduction during decentralization (not converted to treasury)

Decentralization Path:

• Phase 1: 55% → Phase 2: 40% → Phase 3: ≤33%
• Phasing out team-operated nodes in favor of community node expansion
• Phase 3 target: Minimum Nakamoto Coefficient of 10-20

2.4 Staking Participation Models

The minimum staking requirement of 10M OZ may exceed what individual participants can provide independently. Oraclizer supports multiple participation models to ensure broad access while maintaining security:

Solo Staking

Participants with sufficient capital operate their own nodes directly. This provides maximum control and full reward capture but requires technical expertise and significant capital commitment.

Delegated Staking

Token holders delegate their stake to professional node operators (validators) who manage the technical infrastructure. Rewards are distributed proportionally after the operator’s commission (typically 5-15%). This model mirrors successful implementations in Cosmos and Polkadot ecosystems.

Staking Pools

Multiple participants pool their tokens to collectively meet the minimum requirement. A pool operator manages node operations on behalf of all contributors. This approach is similar to Liquid Staking protocols in Ethereum (e.g., Lido, Rocket Pool) but adapted for Oraclizer’s requirements.

Withdrawal and Unbonding Mechanics

To maintain node stability while providing reasonable liquidity, the following withdrawal framework applies:

Parameter	Value	Rationale
Unbonding Period	21 days	Aligns with Cosmos standard; allows slashing verification
Withdrawal Request Window	Monthly (Epoch-based)	Balances liquidity with node stability
Withdrawal Execution	Next Epoch start	Enables predictable node state management

Pool Withdrawal Logic:

1. Delegator submits withdrawal request during current Epoch
2. Request queued until next Epoch transition
3. At Epoch boundary, total withdrawal requests aggregated
4. If remaining stake ≥ S_min: withdrawals processed, 21-day unbonding begins
5. If remaining stake < S_min: entire node enters dissolution procedure (all stakes enter 21-day unbonding)

This design prevents sudden node deactivation from individual withdrawals while ensuring all participants can eventually exit.

Part III: Block Rewards as Continuous Insurance

3.1 Reinterpreting Block Rewards

In traditional PoS, block rewards are understood as “compensation for block production.” However, from a Session Security perspective, block rewards carry a different meaning.

Reinterpreted in the language of actuarial science:

Block rewards are the baseline insurance premium for continuous security services.

Node operators provide “security insurance” to the network by locking up capital and operating infrastructure. This insurance works preventively to prevent specific events (attacks) from occurring, and the premium (block rewards) is paid continuously while the insurance contract is maintained.

This reinterpretation carries two important implications:

1. Session Security Alignment: Continuous premium payments align with the requirement for uninterrupted security across Oracle Sessions
2. Sustainability Transition: Initial reliance on block rewards can shift toward fee-based revenue as the network matures, reducing long-term inflation

3.2 Reward Distribution Schedule Design

The phase-based reward distribution schedule follows these principles:

Phase 1 (Network Bootstrapping):

• Goal: Initial node attraction and security establishment
• Demand-side revenue (oracle fees) is limited, so high dependence on block rewards
• Annual reward distribution rate: 5-7%

Phase 2 (Growth Stage):

• Goal: Demand-supply balance transition
• Increased oracle fee revenue reduces dependence on block rewards
• Annual reward distribution rate: 3-4%

Phase 3 (Maturity Stage):

• Goal: Long-term sustainability
• Fee revenue becomes the primary source of node rewards
• Annual reward distribution rate: 1-2%

This schedule is set more conservatively than industry averages (Solana initial 8%, Near 5%). Since Oraclizer is an L3 solution rather than L1, we only need to secure state synchronization service security rather than entire chain security, allowing sufficient node incentives with relatively lower distribution rates.

3.3 Block Reward Calculation

We calculate per-block rewards based on Phase 1 parameters.

Assumptions:

• Total token supply: 10 billion OZ
• Annual distribution rate: 6% (midpoint of 5-7%)
• Block generation interval: 2 seconds (Polygon CDK-based)
• Annual blocks: 15,768,000

Annual Block Reward Distribution:

$$10B \times 0.06 = 600M \text{ OZ/year}$$

Per-Block Distribution:

$$\frac{600M}{15,768,000} \approx 38.0 \text{ OZ/block}$$

Per-Node Annual Block Rewards (20 nodes, assuming equal distribution):

$$\frac{600M}{20} = 30M \text{ OZ}$$

Dollar value (token price $0.01):

$$30M \times \$0.01 = \$300,000$$

Reward Pool Structure: Block rewards are distributed from a pre-allocated Reward Pool rather than newly minted. The initial size of the Reward Pool and policies for pool depletion will be addressed in subsequent revenue-to-reward conversion research.

3.4 Evolution of Revenue Structure

Node revenue consists of two sources:

1. Block Rewards (Supply-side): Distribution from Reward Pool
2. Oracle Fees (Demand-side): Compensation for state synchronization services

Expected revenue composition ratio by Phase:

Phase	Block Rewards	Oracle Fees
Phase 1	80-85%	15-20%
Phase 2	50-60%	40-50%
Phase 3	20-30%	70-80%

The key risk in this transition is synchronization failure. If the rate of block reward decrease exceeds the rate of oracle fee increase, node operators’ total revenue could fall below the survival threshold. Countermeasures for this will be addressed in insurance and crisis response research.

Part IV: APY Simulation and Survival Analysis

4.1 APY Calculation Framework

From a node operator’s perspective, APY (Annual Percentage Yield) is a key decision-making metric. The APY calculation formula:

$$APY = \frac{R_{block} + R_{fee} – C_{operational}}{S_{staked}} \times 100\%$$

Where:

• R_block: Annual block reward revenue
• R_fee: Annual oracle fee revenue
• C_operational: Annual operational costs
• S_staked: Value of staked capital

4.2 Scenario Definitions

Worst Case:

• Low network utilization
• Token price decline
• High competition (node count increase)

Normal Case:

• Expected level of network growth
• Stable token price
• Planned node expansion

Best Case:

• High network utilization
• Token price appreciation
• Fee revenue exceeds targets

4.3 Phase 1 APY Calculation (Normal Case)

Revenue Calculation:

Block Rewards:

• Per-node annual: 30M OZ
• Dollar value: $300,000

Oracle Fees:

• Assumed network annual fee revenue: $500K (early stage)
• Per-node allocation (20 nodes): $25,000
• Node reward ratio 45%: $11,250

Operational Costs:

• Server/infrastructure: $500/month = $6,000/year
• Monitoring/maintenance: $2,000/year
• Total operational costs: $8,000/year

Staking Value (at S_min):

• Staking amount: 10M OZ
• Dollar value: $100,000

Token-Basis APY:

$$APY_{token} = \frac{30M \text{ OZ}}{10M \text{ OZ}} \times 100\% = 300\%$$

With Dilution Effect:

$$APY_{nominal} = 300\% – 6\% = 294\%$$

However, this figure is based on several idealized assumptions:

• All nodes produce blocks perfectly equally
• No slashing occurs
• 100% uptime
• All nodes stake exactly S_min

Realistic Adjustment Factors:

1. Block production inequality due to VRF variance: -15~20% (estimate, to be validated on testnet)
2. Slashing/downtime risk reflection: -5~10%
3. Token price volatility premium: -10~15%
4. Competition from higher-staking nodes: Variable

Given these factors and assuming average staking levels exceed minimum requirements in competitive environments:

Phase 1 Normal Case adjusted APY estimate: 15-22%

4.4 APY Summary by Scenario

The APY projections across phases and scenarios reveal critical insights for network sustainability. The color coding reflects operational viability: green (>15%) indicates strong incentive for new node operators, blue (7-15%) represents sustainable but not highly attractive returns, and red (<7%) signals danger zones approaching the survival threshold.

Key observations from the matrix:

• Phase 1 provides adequate buffer: Even in the Worst Case (5-9%), APY remains near the ~6% survival threshold, giving the network time to establish demand-side revenue
• Phase 2-3 Worst Cases present systemic risk: Returns of 3-6% and 2-4% fall below the survival threshold, meaning rational node operators would exit under sustained adverse conditions
• The gap between Best and Normal Cases narrows over time: As the network matures, return volatility decreases—a sign of stabilization but also reduced upside potential

The Survival Threshold of ~6% APY is derived from opportunity cost analysis: DeFi stablecoin yields (3-5%) plus ETH staking yields (3-4%) plus operational risk premium (2-3%). Below this level, capital allocation to Oraclizer nodes becomes economically irrational.

Mitigation strategies for Worst Case scenarios—including insurance pool deployment and emergency reward adjustments—will be addressed in the Insurance and Recovery Economics research.

4.5 Survival and Incentive Thresholds

We distinguish between two critical APY thresholds:

Survival Threshold (~6% APY)

The minimum APY for a node operator to remain on the network, derived from opportunity cost analysis:

• DeFi stablecoin yields: 3-5%
• ETH staking yields: 3-4%
• Operational risk premium: 2-3%

Below this threshold, rational operators would allocate capital elsewhere.

Incentive Threshold (~12-15% APY)

The APY level required to actively attract new node operators and grow the network. Operating Oraclizer nodes requires more technical expertise than simple ETH staking, justifying a premium above basic opportunity cost.

Risk Assessment:

• Worst Case Phase 1 APY (5-9%) approaches the survival threshold
• Phase 2-3 Worst Case may fall below survival threshold
• This represents a systemic risk requiring mitigation

Mitigation Mechanisms (to be designed in subsequent research):

1. Insurance pool construction
2. Dynamic distribution rate adjustment
3. Emergency block reward increase protocol

Part V: Synthesis and Open Questions

5.1 Parameter Interdependencies

The parameters established in this research form an interconnected system where changes propagate throughout:

Key dependency chains:

TVL Growth Chain:

$$TVL \uparrow \Rightarrow \text{Security requirement} \uparrow \Rightarrow \text{Node count target} \uparrow$$

Distribution Rate Chain:

$$\text{Distribution rate} \downarrow \Rightarrow \text{Block rewards} \downarrow \Rightarrow APY \downarrow$$

Fee Revenue Chain:

$$\text{Fee revenue} \uparrow \Rightarrow \text{Block reward dependence} \downarrow \Rightarrow \text{Sustainable reduction of distribution rate}$$

Staking Competition Chain:

$$\text{Average stake per node} \uparrow \Rightarrow \text{Per-token APY} \downarrow \Rightarrow \text{Natural staking equilibrium}$$

Future research will analyze this interdependency matrix more precisely, particularly the feedback loops that could amplify or dampen systemic risks.

5.2 Decision Framework for Node Operators

Based on this research, potential node operators can evaluate participation using these metrics:

1. Entry Cost: Minimum 10M OZ per node (currently equivalent to $100,000 at $0.01/OZ)
2. Expected Revenue: Normal Case Phase 1 APY of 15-22%
3. Key Risks: Token price decline, low network utilization, transition timing mismatch
4. Exit Signal: When APY persists below 6%
5. Participation Options: Solo staking, delegated staking, or staking pools

5.3 Open Questions for Future Research

This research raises several questions that will be systematically addressed:

1. Slashing Differentiation: What differentiated slashing ratios should apply by violation type? (Liveness vs Safety vs Collusion) → Next: Slashing research
2. Reward Pool Parameters: What should be the initial Reward Pool size, and what policies govern depletion scenarios? → Revenue-to-Reward research
3. Optimal Node Expansion: At what pace should we expand from 20 to 100 nodes? What triggers expansion? → Node Compensation research
4. Insurance Pool Sizing: How much is needed to compensate for node losses in Worst Case scenarios? → Insurance research
5. Dynamic Adjustment Mechanisms: At what ranges and intervals should distribution rates and fee allocation ratios be adjusted? → Dynamic Pricing research

---

Conclusion

Through the conceptual framework of Oracle Session Security, we explored the essence of economic security required for continuous state synchronization. Beyond simply “how much should be staked,” we presented the rationale for “why that amount is needed” and “how security scales with network growth.”

The key findings are as follows:

First, Oraclizer adopts fixed minimum staking requirements (10M OZ per node) with security scaling achieved through node count expansion and the Security Reserve Pool. This provides operational predictability while maintaining flexibility for growth.

Second, block rewards should be understood not as “compensation for block production” but as insurance premiums for continuous security services. This framing aligns with Session Security requirements and supports the transition from inflation-based to fee-based sustainability.

Third, two distinct APY thresholds define network health: the survival threshold (~6%) below which nodes exit, and the incentive threshold (~12-15%) required to attract new operators. Maintaining APY above these levels is essential for network stability.

Fourth, multiple participation models—solo staking, delegated staking, and staking pools—ensure broad access while maintaining security requirements through structured withdrawal mechanics.

The following research will design the slashing mechanism that enforces service quality and maintains the security guarantees established here.

---

References

1. Buterin, V. (2020). “Why Proof of Stake.” Ethereum Foundation Blog. https://vitalik.eth.limo/general/2020/11/06/pos2020.html
2. Daian, P., et al. (2020). “Flash Boys 2.0: Frontrunning in Decentralized Exchanges.” IEEE S&P. https://ieeexplore.ieee.org/document/9152675
3. Solana Foundation. (2024). “Staking on Solana.” Solana Documentation. https://solana.com/staking
4. L2Beat. (2024). “Layer 2 Risk Analysis.” https://l2beat.com/scaling/risk
5. Polygon Labs. (2024). “Polygon CDK Documentation.” https://docs.polygon.technology/cdk/