Research

Economy

Cost Structure Analysis: The Economics of Continuous State Flow in State Synchronization Economy

11 Oct 2025 · 6 min read

Continuous state synchronization exhibits fundamentally different cost structures than discrete API calls, and we mathematically prove that a single pricing model cannot fairly handle all usage frequencies. By introducing the Oracle Session concept, we clearly distinguish between fixed costs (initial connection) and variable costs (intra-session synchronization), deriving boundary values for three distinct frequency bands.

A toll plaza seen through a windshield: light, standard and heavy lanes, with a loaded truck in the heavy lane.

TL;DR

  • Continuous state synchronization exhibits fundamentally different cost structures than discrete API calls, and we mathematically prove that a single pricing model cannot fairly handle all usage frequencies.
  • By introducing the Oracle Session concept, we clearly distinguish between fixed costs (initial connection) and variable costs (intra-session synchronization), deriving boundary values for three distinct frequency bands.
  • While the Pay-per-sync model proves efficient in Light-frequency and Medium-frequency bands, we quantitatively demonstrate structural losses occurring in the Heavy-frequency band.
  • Mathematical modeling of node operators’ tail risk and unpredictable revenue volatility establishes the necessity for multi-tier economic models and cushioning mechanisms.

In our previous research, we explored the economic potential that the revolutionary paradigm of state synchronization could bring. Technical efficiency through L3 architecture and zkVerify integration was clearly an achievable goal. But we came to realize that technical success alone isn’t enough.

When actually operating a state synchronization system through Oracle Sessions, the economic reality that node operators would face was far more complex than we initially anticipated. There exists a fundamental difference in cost structure between “calling a new API each time” and “synchronizing continuous states.”

Oracle Session: The Basic Unit of State Synchronization

To understand the economics of state synchronization, we must first define a new concept: Oracle Session. An Oracle Session represents the state synchronization contract period between a single owner of a specific Real World Asset (RWA) and the Oraclizer network.

Oracle Session lifecycle and cost One fixed cost opens the session and each sync then adds a small marginal cost, so the fixed cost spreads over every sync that follows.
One Oracle Session: lifecycle and cumulative cost A session timeline over a cumulative cost chart on one shared progress axis. The session starts with a new tokenization or an ownership transfer, runs through five continuous synchronizations in the same owner context at low marginal cost, and ends with asset expiry or a regulatory action that triggers settlement; the session duration is variable. The chart plots cumulative cost in USD against session progress with illustrative values: a one-time fixed cost of about USD 90 is paid at the start, five synchronizations then add marginal costs that raise the total to about USD 150 at settlement, so total cost equals fixed cost plus the sum of marginal costs. The fixed cost amortizes over the session, so more synchronizations give a lower unit cost. Session start New tokenizationOwnership transfer Continuous sync Low marginal costSame owner context Session end Asset expiryRegulatory action Time Session duration, variable Cumulative cost, USD (illustrative values) Fixed (one-time): USD 90 Marginal (per sync) Total = Fixed + Σ(Marginal) Settlement: USD 150 050100150 Start25%50%75%End Session progress Fixed cost amortizes over the sessionmore syncs, lower unit cost One Oracle Session: lifecycle and cumulative cost A session timeline over a cumulative cost chart on one shared progress axis. The session starts with a new tokenization or an ownership transfer, runs through five continuous synchronizations in the same owner context at low marginal cost, and ends with asset expiry or a regulatory action that triggers settlement; the session duration is variable. The chart plots cumulative cost in USD against session progress with illustrative values: a one-time fixed cost of about USD 90 is paid at the start, five synchronizations then add marginal costs that raise the total to about USD 150 at settlement, so total cost equals fixed cost plus the sum of marginal costs. The fixed cost amortizes over the session, so more synchronizations give a lower unit cost. Start Continuous sync End Time Session duration, variable Cumulative cost, USD (illustrative) 050100150 Start25%50%75%End Session progress Fixed (one-time): USD 90 Marginal (per sync) Settlement: USD 150 Total = Fixed + Σ(Marginal) Session startNew tokenization, ownership transfer Continuous syncLow marginal cost, same owner context Session endAsset expiry, regulatory action Fixed cost amortizesover the sessionmore syncs, lower unit cost
Figure 1Oracle Session Lifecycle and Cost Structure

Each Oracle Session has clear boundaries:

Session Start Conditions:

  • New RWA tokenization and initial issuance
  • Ownership transfer of existing RWA (on-chain transfer)
  • Initial state registration from off-chain to on-chain

Session End Conditions:

This session structure demands a completely different cost model from traditional oracle one-time calls. While initial connection costs (Fixed Cost) occur at the start of an Oracle Session, each state synchronization within the session requires only relatively low variable costs (Marginal Cost).

Modeling the Oracle Session Cost Function

To analyze the economic characteristics of Oracle Sessions, we defined the total cost function based on synchronization frequency as follows:

\(\displaystyle C_{total}(f) = C_{fixed} + c_{marginal}(f) \cdot f + R_{overhead}(f)\)

Where:

  • \(C_{fixed}\): Fixed cost at session start (initial state setup, oracle contract creation)
  • \(c_{marginal}(f)\): Unit synchronization cost based on frequency \(f\)
  • \(R_{overhead}(f)\): Additional resource overhead at high frequencies

Importantly, \(c_{marginal}(f)\) is not a simple constant. As synchronization frequency increases, it exhibits the following band-specific characteristics:

$$c_{marginal}(f) = \begin{cases} c_0 & \text{if } f \leq f_1 \text{ (Light-frequency)} \\ c_0 \cdot (1 + \alpha \log(f/f_1)) & \text{if } f_1 < f \leq f_2 \text{ (Medium-frequency)} \\ c_0 \cdot (1 + \beta \sqrt{f/f_2}) & \text{if } f > f_2 \text{ (Heavy-frequency)} \end{cases}$$

Unit Cost Analysis and Discovery of Frequency Bands

More importantly, the behavior of unit cost \(U(f) = C_{total}(f)/f\) reveals interesting patterns when analyzed:

Unit cost by synchronization frequency Unit cost falls steeply in the Light band, plateaus in the Medium band and turns up again in the Heavy band.
Unit cost across the three synchronization frequency bands A line chart of normalized unit cost against annual synchronization frequency from 0 to 400 and beyond, divided at f1 = 50 and f2 = 200 into the Light, Medium and Heavy bands. In the Light band unit cost falls steeply as fixed cost amortization spreads the initial connection cost over more synchronizations, and it crosses the efficiency threshold on the way down at about 27 a year. In the Medium band it stays on a low plateau just under the threshold, where fixed and variable costs balance. In the Heavy band resource overhead increases and unit cost turns up again, crossing the threshold at about 260 a year and reaching about 1.7 times the base marginal cost at 400. The curve is drawn from the three-band cost model with illustrative parameters. Normalized unit cost Light Medium Heavy Efficiency threshold Fixed cost amortization Resource overhead increases 00.51.01.52.0 0100150250300350400+ f1 = 50 f2 = 200 Annual synchronization frequency, times per year U(f) = Cfixed / f + cmarginal(f) + Roverhead(f) / f Illustrative parameters; units of the base marginal cost c0 = 1 Unit cost across the three synchronization frequency bands A line chart of normalized unit cost against annual synchronization frequency from 0 to 400 and beyond, divided at f1 = 50 and f2 = 200 into the Light, Medium and Heavy bands. In the Light band unit cost falls steeply as fixed cost amortization spreads the initial connection cost over more synchronizations, and it crosses the efficiency threshold on the way down at about 27 a year. In the Medium band it stays on a low plateau just under the threshold, where fixed and variable costs balance. In the Heavy band resource overhead increases and unit cost turns up again, crossing the threshold at about 260 a year and reaching about 1.7 times the base marginal cost at 400. The curve is drawn from the three-band cost model with illustrative parameters. Normalized unit cost Light Medium Heavy Efficiencythreshold Fixed costamortization Resourceoverheadincreases 01.02.0 050100200300400+ Annual syncs per year f1 = 50, f2 = 200 U(f) = Cfixed / f + cmarginal(f) + Roverhead(f) / f Illustrative parameters; units of the basemarginal cost c0 = 1
Figure 2Unit Cost Analysis by Synchronization Frequency

\(\displaystyle U(f) = \frac{C_{fixed}}{f} + c_{marginal}(f) + \frac{R_{overhead}(f)}{f}\)

Through simulation, we identified three distinct bands:

Light-frequency band (\(f \leq 50\) times/year):

  • Fixed cost amortization effect dominates
  • Unit cost decreases sharply with increasing frequency
  • Pay-per-sync model most efficient

Medium-frequency band (\(50 < f \leq 200\) times/year):

  • Balance point between fixed and variable costs
  • Unit cost decreases gently or plateaus
  • Pay-per-sync model still efficient

Heavy-frequency band (\(f > 200\) times/year):

  • Resource overhead increases dramatically
  • Unit cost begins to rise again
  • Structural losses occur in Pay-per-sync model

Risk-Revenue Analysis from Node Operators’ Perspective

From a node operator’s perspective, the most serious issue is unpredictable revenue volatility. Under the Pay-per-sync model, a node operator’s expected revenue is modeled as:

Pay-per-sync margin by frequency band Pay-per-sync earns a margin in the Light and Medium bands and loses money in the Heavy band, which carries most of the network load.
Node margin under pay-per-sync by frequency band, with session shares and tail risk A bar chart of the node operator profit or loss margin under the pay-per-sync model across five annual synchronization frequency bands, with a dashed break-even line at 0 percent and one value axis from minus 30 to plus 20 percent. The Light band of 0 to 50 syncs a year earns plus 12 percent and carries 65 percent of sessions; 50 to 100 earns plus 8 percent with 20 percent of sessions; 100 to 200 earns plus 3 percent with 7 percent of sessions. These first three bands are profitable and make up 92 to 95 percent of sessions. The Heavy bands lose money: 200 to 300 loses 15 percent with 5 percent of sessions and 300 and above loses 25 percent with 3 percent of sessions. Heavy-frequency sessions are 5 to 8 percent of sessions but 60 to 70 percent of network load. Their tail risk at 95 percent value at risk is 12 to 18 percent of monthly revenue. Profitable Loss-making Tail riskVaR 95%12 to 18% of monthly revenue +12% +8% +3% −15% −25% Break-even −30%−20%−10%0%+10%+20% 0 to 5050 to 100100 to 200200 to 300300+ Annual synchronization frequency per session Share of sessions 65% 20% 7% 5% 3% 92 to 95% of sessions 5 to 8% of sessions60 to 70% of network load Node margin under pay-per-sync by frequency band, with session shares and tail risk A bar chart of the node operator profit or loss margin under the pay-per-sync model across five annual synchronization frequency bands, with a dashed break-even line at 0 percent and one value axis from minus 30 to plus 20 percent. The Light band of 0 to 50 syncs a year earns plus 12 percent and carries 65 percent of sessions; 50 to 100 earns plus 8 percent with 20 percent of sessions; 100 to 200 earns plus 3 percent with 7 percent of sessions. These first three bands are profitable and make up 92 to 95 percent of sessions. The Heavy bands lose money: 200 to 300 loses 15 percent with 5 percent of sessions and 300 and above loses 25 percent with 3 percent of sessions. Heavy-frequency sessions are 5 to 8 percent of sessions but 60 to 70 percent of network load. Their tail risk at 95 percent value at risk is 12 to 18 percent of monthly revenue. Annual synchronization frequencyper session −30−20−100+10+20 Profit or loss margin, % 0 to 5065% of sessions +12% 50 to 10020% of sessions +8% 100 to 2007% of sessions +3% 200 to 3005% of sessions −15% 300+3% of sessions −25% Break-even Profitable92 to 95% of sessions Loss-making5 to 8% of sessions60 to 70% of network load Tail riskVaR 95%12 to 18% of monthly revenue
Figure 3Node Operator Risk-Revenue Analysis under Pay-per-sync Model

\(\displaystyle E[R_{node}] = \sum_{s} P(s) \cdot R_{session}(s)\)

Where \(P(s)\) is the probability of session \(s\) occurring, and \(R_{session}(s)\) is the revenue from that session.

The problem arises with Heavy-frequency sessions. These sessions:

  • Comprise only 5-8% of all sessions
  • Account for 60-70% of total network load
  • Cause unpredictable losses for individual nodes

Specifically, nodes handling Heavy-frequency sessions experience the following losses:

\(\displaystyle Loss_{heavy}(f) = \left(c_{marginal}(f) + \frac{R_{overhead}(f)}{f}\right) \cdot f - Revenue_{pps}(f)\)

Where \(Revenue_{pps}(f) = p_{sync} \cdot f\) and \(p_{sync}\) is the fixed fee per synchronization.

According to our simulations, node loss rates reach 15-25% for sessions where \(f > 300\) times/year.

Tail Risk and the Need for Cushioning Mechanisms

The tail risk faced by node operators within each Oracle Session can be quantified as:

\(\displaystyle VaR_{95\%} = \inf\{x : P(Loss \leq x) \geq 0.95\}\)

Monte Carlo simulation results show that node operators are exposed to potential losses equivalent to 12-18% of monthly revenue at the 95% confidence interval. This isn’t just a profitability issue; it’s a matter of network stability.

This risk structure clearly demonstrates the need for economic cushioning mechanisms:

  • Risk Pooling: Network-wide absorption of Heavy-frequency session losses
  • Predictable Revenue: Minimum revenue guarantee for node operators
  • Fair Burden Distribution: High-frequency users bear additional costs

Economic Justification for Multi-Tier Economic Models

Our analysis clearly reveals structural limitations that cannot be resolved with a single Pay-per-sync model:

Efficient Range: Light + Medium frequency sessions (92-95% of total)

  • Pay-per-sync model achieves optimal efficiency
  • Fair value provided to both nodes and users

Problem Range: Heavy-frequency sessions (5-8% of total)

  • Structural losses occur in Pay-per-sync model
  • Account for 60-70% of total network load
  • Alternative economic model needed

This provides economic justification for a multi-tier Oracle Session pricing system:

  • Entry Level: Pay-per-sync (targeting Light-frequency sessions)
  • Growth Level: Prepaid credits (targeting Medium-frequency sessions)
  • Enterprise Level: Flat-rate subscription (targeting Heavy-frequency sessions)

Future Oracle Session Research Directions

This analysis has established the following key parameters:

  • Frequency band boundaries: Light (≤50 times/year), Medium (50-200 times/year), Heavy (>200 times/year)
  • Pay-per-sync efficiency range: 92-95% of all sessions
  • Heavy-frequency loss rate: 15-25%
  • Node tail risk: 12-18% of monthly revenue

Our next research will explore service revenue structure design and node compensation mechanisms based on these findings. Key challenges will be how to economically hedge structural losses in the Heavy-frequency band and how to achieve fair value distribution for all stakeholders through a multi-tier pricing system.

Disclaimer: This analysis is a research study that models the economic sustainability of state synchronization mechanisms. All parameters, formulas and APY figures are theoretical estimates under stated assumptions and may be revised as the research progresses. It is not investment advice, a guarantee of returns, or an offer to buy or sell any token or other asset.

References

[1]. Cong, L. W., Fox, L., Li, S., & Zhou, L. (2025). A primer on oracle economics. Journal of Corporate Finance, 94, 102800.

[2]. Caldarelli, G. (2022). Overview of blockchain oracle research. Future Internet, 14(6), 175.

[3]. Fitzgerald, J. (2023). With subscription fatigue setting in, companies need to think hard about fees. Harvard Business School Working Knowledge.

Subscribe

New research, by email.

  • One email when a new article is published
  • Confirm once, leave with one click
  • Privacy