Oraclizer Core

Dec 12, 2025

Economy

Economic Security Requirements: Quantifying Protection Needs

Oraclizer Core

Dec 12, 2025

TL;DR

Economic security is an incentive structure designed so that attack costs exceed potential profits—the core security mechanism of POS networks. Analysis of Ethereum, Cosmos, and Polkadot security models reveals that each network makes attacks economically irrational through 33-66% stake thresholds and differentiated slashing mechanisms. State Synchronization Economy must protect continuous state flows and bidirectional information transfer unlike conventional POS, generating additional security requirements. The Security Threshold Formula derived in this research, incorporating BFT threshold β, forms the foundation for calculating actual staking quantities in subsequent research.

The Fundamental Question

When discussing blockchain network security, we often focus on technical mechanisms. Mathematical proofs of consensus algorithms, cryptographic signature safety, network latency tolerance ranges. However, the most fundamental question posed by the Proof of Stake paradigm is different:

“Why would an attacker choose not to attack the network?”

The answer to this question is the essence of economic security. Even if an attack is technically possible, rational actors will not attempt it if the cost exceeds potential profits. This is the core principle by which POS networks secure themselves through economic collateral rather than physical computational power.

For those of us designing the State Subscription economy, this question takes a more specific form: How much economic collateral is needed to protect continuous state synchronization?

This research is the first step toward finding that answer. We analyze existing POS network security models and derive formulas to quantify economic security requirements reflecting the oracle state machine’s unique characteristics.

Economic Security in POS Networks: A Comparative Analysis

The Cost-of-Corruption Framework

The clearest framework for understanding POS network security is the Cost-of-Corruption vs Profit-from-Corruption analysis. For a system to be secure, the following condition must hold:

$$C_{attack} > P_{attack}$$

Here, $C_{attack}$ is the total cost required to execute an attack, and $P_{attack}$ is the maximum profit obtainable from a successful attack.

This simple inequality governs all decisions in POS network design. Staking requirements, slashing ratios, and reward structures are all parameters designed to satisfy this inequality.

However, the critical point often overlooked is that the attacker loses only their own stake, not the entire network’s stake. Therefore, the precise formulation requires reflecting what proportion of total stake the attacker must control—the BFT threshold β.

Ethereum 2.0: The Three Thresholds

Ethereum 2.0 provides the most systematically documented economic security model. Three threat levels exist depending on the attacker’s stake proportion:

33% Threshold (Finality Delay)

If an attacker holds more than 33% of total stake, they can delay finality
Since Casper FFG requires 2/3 majority (66%) attestation, 33% or more offline or opposing votes can prevent finality
However, the inactivity leak mechanism gradually drains offline validators’ stakes, allowing the online majority to recover 66%

51% Threshold (Chain Reorganization)

With 51% or more stake, attestation weights can be manipulated to make the preferred fork the canonical chain
Similar to traditional 51% attacks but far more costly due to slashing

66% Threshold (Double Finality)

With 66% or more stake, finality can be granted to two conflicting chains
The most severe attack, but slashing destroys the attacker’s entire stake

Note: According to Ethereum Foundation analysis, with approximately 35 million ETH currently staked and assuming an ETH price of $1,000, the minimum cost of a 33% attack is approximately $46.2 billion. The attacker loses this amount through slashing and is expelled from the network, requiring the same amount to be accumulated again for re-attack[2].

Cosmos: Binary Penalties and Tombstoning

Cosmos is based on Tendermint BFT consensus and adopts a simpler, clearer slashing model:

Violation Type	Slashing Ratio	Additional Sanction
Double-signing	5%	Tombstoning (permanent expulsion)
Downtime	0.01%	Jailing (temporary expulsion)

Tombstoning is Cosmos’s unique mechanism. Validators slashed for double-signing are permanently removed from the network and cannot become validators again with the same key. This fundamentally blocks repeat attacks.

Notably, there have been only 5 double-signing incidents in Cosmos Hub’s entire history. This represents less than 0.002% of total blocks, demonstrating that slashing mechanisms work as a deterrent rather than being frequently executed.

Polkadot: Correlation Penalty

Polkadot’s Nominated Proof of Stake (NPoS) implements the most sophisticated slashing system:

$$S_{slash} = \min(k \cdot x^2, 1) \cdot S_{total}$$

Here, $x$ is the proportion of validators committing violations simultaneously, and $k$ is a scaling constant.

This correlation penalty reflects a unique design philosophy:

Isolated mistakes (e.g., infrastructure failures) incur minor penalties (~0.01%)
Large-scale simultaneous violations (intentional or not) result in maximum 100% slashing

Slashed DOT is not burned but transferred to the Treasury, providing flexibility to recover from erroneous slashing through governance.

Cross-Network Comparison

Comparing the security models of the three networks:

Characteristic	Ethereum 2.0	Cosmos	Polkadot
Consensus Mechanism	Casper FFG	Tendermint BFT	GRANDPA + BABE
BFT Tolerance	1/3	1/3	1/3
Minimum Attack Cost	33% stake	34% stake	34% stake
Slashing Method	Correlation-based	Fixed ratio	Correlation-based
Slashed Fund Handling	Burned	Burned	Treasury

POS Network Security Model Comparison

🔷 Ethereum 2.0

Consensus Casper FFG

BFT Tolerance 1/3 (33%)

Slashing Correlation-based

Slashed Funds Burned

Attack Thresholds:

33%

Finality Delay

66%

Double Finality (100% slash)

⚛️ Cosmos

Consensus Tendermint BFT

BFT Tolerance 1/3 (33%)

Slashing Fixed Rate

Slashed Funds Burned

Slashing Rates:

Double-signing 5% + Tombstone

Downtime 0.01% + Jail

⬡ Polkadot

Consensus GRANDPA + BABE

BFT Tolerance 1/3 (33%)

Slashing Correlation Penalty

Slashed Funds Treasury

Correlation Formula:

          S = min(k × x², 1) × S_total
        

Isolated: ~0.01% → Coordinated: up to 100%

Figure 1: POS Network Security Model Comparison

The Oracle State Machine: Unique Security Requirements

Beyond Simple Consensus

The security requirements of an oracle state machine differ fundamentally from general POS networks. While general blockchains reach consensus on transaction ordering and validity, oracle state machines must reach consensus on state synchronization with the external world.

This difference generates three additional security requirements:

1. Continuity Protection

Existing oracles provide discrete price updates. Attackers can front-run using time gaps between updates. In contrast, oracle state machines provide continuous state flows, requiring protection of this flow’s integrity.

Attack Vector: State flow interruption or delay
Defense Requirement: Continuous liveness guarantee

2. Bidirectional Integrity

Oracle state machines synchronize state bidirectionally: on-chain→off-chain and off-chain→on-chain. This provides a wider attack surface than unidirectional data feeds.

Attack Vector: State manipulation in one direction propagating to the other
Defense Requirement: Bidirectional verification mechanism

3. Cross-chain Consistency

When the RWA Registry is referenced across multiple chains, consistent state must be maintained across all chains. Differences in inter-chain latency can cause temporary inconsistencies.

Attack Vector: Double-spending exploiting state inconsistencies between chains
Defense Requirement: Atomic cross-chain updates

The State Synchronization Security Model

Reflecting these special requirements, we propose the State Synchronization Security Model. We add an adjustment coefficient reflecting state synchronization specifics to the basic POS security formula:

$$C_{sync} = C_{base} \cdot \alpha$$

Where:

$C_{sync}$: State synchronization attack cost
$C_{base}$: Basic POS attack cost (stake acquisition cost)
$\alpha$: State synchronization adjustment coefficient ($\alpha \geq 1$)

The adjustment coefficient α is a function of the following factors:

$$\alpha = f(F_{continuity}, F_{bidirectional}, F_{crosschain})$$

$F_{continuity}$: Continuity requirement intensity (proportional to state update frequency)
$F_{bidirectional}$: Bidirectional verification complexity
$F_{crosschain}$: Complexity related to number of supported chains

Important Note: The specific calculation of α values will be determined in future research based on testnet operational data and simulation results. We are currently at the stage of establishing the theoretical framework, with an initial design target considering the range $\alpha \in [1.2, 1.8]$.

Quantifying Security Requirements

The Security Threshold Formula

Let us derive the core formula for quantifying POS network security requirements. The critical insight is that an attacker must control at least β (BFT threshold, typically 33%) of total stake to execute an attack, and loses only their own stake through slashing.

For a system to be secure:

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

Where:

$S_{attacker}$: Attacker’s stake amount
$p$: Token price
$\theta$: Slashing ratio (proportion of stake lost in attack)
$V_{protected}$: Protected value (total assets the system protects)
$\gamma$: Extractable ratio upon successful attack
$C_{operational}$: Operational costs required to execute attack

Since an attack requires $S_{attacker} \geq \beta \cdot S_{total}$:

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

Rearranging this formula:

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

This is the Security Threshold Formula. The minimum total stake required by the network is determined by protected value, BFT threshold, token price, and slashing ratio.

Understanding γ: Attack Profit Scenarios

The parameter γ (extractable ratio upon successful attack) varies by attack type in oracle state machines:

Price Manipulation Attack: γ ≈ Liquidation profits from specific DeFi positions. If a lending protocol holds $100M in collateral and 30% can be liquidated through price manipulation, γ = 0.3.

Double-Spend Attack: γ ≈ Value of double-spent assets. In worst case where the same asset is spent twice, γ could approach 1.0.

State Delay Attack: γ ≈ MEV-style profits. Generally lower than other attacks but easier to execute repeatedly.

For security design, we must assume worst-case γ while actual attacks may target lower γ with higher success probability.

The Deterrence Effect

An interesting paradox exists. In many POS networks, total staking is much smaller than protected value (TVL), yet systems operate securely[1]. Why is this possible?

Slashing’s Deterrent Effect: Actual slashing is rare, but its existence itself deters attacks
Social Consensus: Communities can isolate attackers through forks in case of severe attacks
Increased Cost of Repeat Attacks: After slashing, stake must be accumulated again for re-attack
Reputation Cost: Loss of delegated stake leads to reputation damage

In State Subscription economy, we reflect these factors as follows:

$$S_{required} = \frac{V_{protected} \cdot \gamma + C_{operational}}{\beta \cdot p \cdot \theta \cdot (1 + \delta_{deterrence})}$$

Here, $\delta_{deterrence}$ quantifies slashing’s deterrent effect. Research on traditional crime economics suggests deterrent effects of 0.2-0.5 range depending on penalty certainty and severity. We adopt a similar range for blockchain contexts.

Applying the State Synchronization Adjustment

For oracle state machines, the base formula must be adjusted by α:

$$S_{required}^{sync} = \frac{V_{protected} \cdot \gamma \cdot \alpha + C_{operational}}{\beta \cdot p \cdot \theta \cdot (1 + \delta_{deterrence})}$$

The α factor increases required stake proportionally to the additional attack surfaces presented by state synchronization. When α = 1.5, 50% more stake is required compared to a simple POS network protecting the same value.

Node Distribution Requirements

Economic security depends not only on total staking but also on distribution. If stake is concentrated in a few nodes, collusion attacks become easier.

Distribution requirements using the Nakamoto Coefficient:

$$N_c \geq N_{min}$$

Where:

$N_c$: Minimum number of entities needed to control the network
$N_{min}$: System design target (e.g., 10-20)

The 10-100 node range presented in the Oraclizer whitepaper reflects the balance between this distribution requirement and operational efficiency. The analysis finding optimal efficiency indices at 37-52 nodes suggests both security and performance can be optimized within this range.

Security-Decentralization-Efficiency Tradeoff

⚠️ Insufficient Security Zone

Nodes: <10
High collusion risk. Too few validators make coordinated attacks economically viable.

Security Index Low (<50)

Efficiency Index High (95+)

✓ Optimal Zone

Nodes: 37-52
Best balance between security guarantees and operational efficiency. Peak combined optimality index.

Security Index High (85-95)

Efficiency Index Good (75-85)

Combined Optimality Maximum

📐 Design Range

Nodes: 10-100
Acceptable operational range per whitepaper specification. Security minimum (10) to practical maximum (100).

Minimum (10 nodes) Security threshold met

Maximum (100 nodes) Efficiency threshold met

📉 Diminishing Returns Zone

Nodes: >100
Additional nodes provide marginal security gains while significantly increasing coordination overhead.

Security Index Plateau (~95)

Efficiency Index Declining

💡 Key Insight

The optimal efficiency index discovered at 37-52 nodes represents the sweet spot where Nakamoto coefficient (N_c) requirements are satisfied while maintaining BFT consensus performance.

Figure 2: Security-Decentralization Tradeoff in Node Distribution

Slashing Framework Preview

Detailed slashing mechanism design will be covered in subsequent research, but we present framework-level principles to complete the security requirements.

Design Principles

1. Proportionality Principle

Penalties proportional to violation severity
Distinction between simple mistakes and malicious attacks

2. Correlation Awareness

Weighted penalties for simultaneous violations, referencing the Polkadot model
Prevention of cascading slashing due to infrastructure failures

3. Deterrence First

Focus on deterrent effect rather than actual slashing
Clear and predictable penalty structure

4. Recovery Path

Return mechanism for minor violations
Reference to Cosmos’s jailing concept

Integration with Economic Structure

Funds recovered through slashing connect with other economic elements of the system. How they integrate with the 4-way distribution structure presented in earlier research (nodes 45%, operations 25%, insurance 15%, development 15%) will be detailed in the insurance and recovery economics research.

Parameters for Future Research

We summarize the core parameters and formulas derived from this research. These form the foundation for calculating actual staking quantities and designing slashing mechanisms in future research.

Security Threshold Variables

Variable	Definition	Initial Consideration Range
β	BFT threshold (minimum stake ratio for attack)	0.33 (33%)
θ	Base slashing ratio	5-15% (differentiated by violation type)
α	State synchronization adjustment coefficient	1.2-1.8
δ_deterrence	Deterrence effect coefficient	0.2-0.5
γ	Extractable ratio upon successful attack	0.1-1.0 (varies by attack type)
N_min	Minimum Nakamoto coefficient	10-20

Core Formulas

Security Condition (Basic):

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

Required Total Stake:

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

Required Stake with Deterrence Effect:

$$S_{required} = \frac{V_{protected} \cdot \gamma + C_{operational}}{\beta \cdot p \cdot \theta \cdot (1 + \delta_{deterrence})}$$

State Synchronization Adjusted Stake:

$$S_{required}^{sync} = \frac{V_{protected} \cdot \gamma \cdot \alpha + C_{operational}}{\beta \cdot p \cdot \theta \cdot (1 + \delta_{deterrence})}$$

Security Parameter Interdependency

Security Condition

S_total · p · θ > V_protected · γ + C_op

Input Parameters

S_total

Total Stake

Aggregate value locked by all validators. Determined by node count × stake per node.

Depends on N_c × Individual Stake

Slashing Rate

Percentage of stake burned upon protocol violation. Higher θ increases attack cost.

Initial Range 5-15%

→ Detailed design in slashing research (EC008)

V_sync

Protected Value

Total value secured by state synchronization. RWA TVL + oracle service value.

Dynamic Market Determined

Adjustment Factors

State Sync Adjustment

Multiplier reflecting unique security requirements of continuous state synchronization.

Initial Range 1.2-1.8

→ Refined based on testnet data

δ_det

Deterrence Effect

Coefficient quantifying the preventive impact of slashing beyond direct economic loss.

Initial Range 0.2-0.5

N_c

Nakamoto Coefficient

Minimum entities required for network control. Measures decentralization level.

Minimum Required 10-20

Required Stake Formula

S_req = V_sync · γ / [θ · (1 + δ_det)]

Figure 3: Security Parameter Interdependency

Conclusion

Economic security is the core of POS networks and the fundamental element determining State Subscription economy sustainability. Through this research, we achieved the following:

First, by analyzing security models of Ethereum, Cosmos, and Polkadot, we understood how the Cost-of-Corruption > Profit-from-Corruption framework is implemented, with particular attention to the role of BFT threshold β.

Second, we defined additional security requirements demanded by oracle state machine specifics—continuity, bidirectionality, and cross-chain consistency—and reflected these in the α adjustment coefficient.

Third, we derived basic formulas and variables quantifying security requirements, establishing the foundation for future research. The Security Threshold Formula now correctly reflects that attackers lose only their own stake (not total network stake) and must control at least β proportion to attack.

The next research will utilize these formulas to differentiate staking requirements for light nodes and full nodes, and calculate actual staking quantities. Detailed slashing mechanism design will follow in subsequent research.

Quantifying economic security is not merely a mathematical exercise. It is the work of implementing trust between network participants in code, creating the foundation for State Synchronization Economy to actually function.