Security Subsidy

A security subsidy directly pays users from a protocol's treasury or token emissions to offset specific risks they undertake. This is distinct from yield farming, which often rewards general participation. Examples include:

• Compensating liquidity providers for impermanent loss in a volatile pool.
• Paying stakers for the slashing risk associated with validating a new network.
• Reimbursing users for smart contract risk when interacting with unaudited protocols.

A common application where a protocol uses its treasury to provide its own liquidity on decentralized exchanges (DEXs). Instead of relying on mercenary capital from yield farmers, the protocol:

• Uses a bonding mechanism to acquire LP tokens.
• Earns trading fees and controls the liquidity depth.
• Reduces reliance on inflationary token emissions to attract external LPs. Projects like OlympusDAO pioneered this model with their "(3,3)" game theory.

Used in overcollateralized lending protocols (e.g., those similar to MakerDAO) to ensure system solvency. A subsidy is paid to participants who deposit assets into a stability pool, which acts as a first-loss capital reserve. These users are compensated for the risk that their deposits will be automatically liquidated to cover undercollateralized loans, stabilizing the protocol's native stablecoin.

Subsidies are often distributed with a vesting schedule or lock-up period to align long-term incentives. This prevents recipients from immediately selling the subsidizing token, which would depress its price and undermine the security goal. Common structures include:

• Linear vesting over months or years.
• Cliff periods before any tokens are claimable.
• Escrowed tokens (e.g., ve-tokens) that grant governance rights and boosted rewards.

A well-designed subsidy transitions from inflationary funding (printing new tokens) to revenue-funded rewards. The goal is for protocol-generated fees (e.g., trading fees, loan interest) to eventually cover the subsidy costs. This shifts the model from pure token emissions to a sustainable business model, reducing sell pressure on the native token.

The core security premise: subsidies raise the economic cost of attacking the network. By making honest participation more profitable, they disincentivize malicious acts like:

• Short-term price manipulation (pump-and-dumps).
• Governance attacks to drain treasuries.
• Liquidity raids on DEX pools. The subsidy must be calibrated so that the profit from attacking is less than the ongoing reward for behaving honestly.

The challenge period in Optimistic Rollups (e.g., Arbitrum, Optimism) is secured by a subsidy model. Verifiers are incentivized with a bounty to submit fraud proofs, while a bond is slashed from faulty actors. The potential bounty subsidizes the cost of monitoring the chain.

• Security Model: Economic incentives for decentralized watchdogs.
• Result: Users benefit from lower fees without sacrificing security.

A direct user-paid subsidy for network security. Users attach a priority fee to their transactions, which is paid directly to validators. This compensates validators for the computational resources (CPU/GPU) required to process transactions during high congestion, ensuring liveness and performance.

• Function: Real-time, market-based resource pricing.
• Impact: Aligns user demand with validator compensation.

Many Proof-of-Stake networks (e.g., early Ethereum 2.0, Cosmos) use protocol-issued token inflation to fund block rewards. This is a blanket security subsidy paid to all active validators, designed to offset operational costs and secure the chain until transaction fee revenue becomes sufficient.

• Purpose: Bootstrap network security and participation.
• Trade-off: Dilutes token holders to pay for security.

Proposed systems where the right to sequence transactions on a rollup is auctioned. The winning sequencer pays a fee (subsidy) to the L1 or a security council, which acts as a backstop for liveness and censorship resistance. This turns sequencing revenue into a fund for decentralized security services.

• Concept: Monetize sequencing rights for shared security.
• Example: Proposals in the Espresso and Astria ecosystems.

A security subsidy occurs when a primary blockchain's native token (e.g., ETH, ATOM) is staked or delegated to validate and secure a separate, often application-specific, network. This allows the secondary chain to leverage the established economic security and validator set of the primary chain without bootstrapping its own. Key implementations include restaking (EigenLayer) and interchain security (Cosmos).

The primary risk for stakers is slashing, where a portion of their staked tokens can be forfeited due to malicious or faulty behavior by the operator of the subsidized service (e.g., an Actively Validated Service (AVS)). This creates correlated risk: a single operator fault can trigger slashing events across multiple services simultaneously, potentially leading to significant, uncorrelated losses for stakers who diversified.

Security subsidies introduce complex economic dependencies.

• Yield Compression: As more services compete for the same staked capital, yields may decrease, reducing the incentive to secure the primary chain itself.
• Liquidity Fragmentation: Capital locked in subsidized services is less available for the base layer's DeFi ecosystem.
• Cascading Failures: A major slashing event or a collapse in the value of the staked token could destabilize all dependent services in a systemic risk scenario.

The model can inadvertently encourage validator centralization. Operators with the largest stakes and best reputations are likely to be selected by multiple services, concentrating trust and technical responsibility. This creates single points of failure and reduces the censorship resistance of the overall network, as a small set of entities gains disproportionate influence over many services.

Stakers bear operator risk, as they must perform due diligence on every service they support. This includes auditing the service's code, its governance, and the operator's technical competence. The principal-agent problem is acute: stakers (principals) delegate security to operators (agents) whose incentives may not be perfectly aligned, especially with complex reward-sharing models.

Unlike traditional Proof-of-Stake staking, which secures a single protocol with clear consensus rules, security subsidy staking involves securing arbitrary, external services with diverse and potentially buggy logic. This shifts risk from consensus-layer faults (e.g., double-signing) to application-layer faults (e.g., incorrect data attestation, oracle failure), which are harder to model and insure against.