Archive Node Incentives
The Storage Challenge
High message throughput creates a storage scaling challenge. At maximum capacity, yearly data growth can reach ~84 TB—far beyond what traditional "store everything" archive nodes can handle.
Traditional answer: "Full nodes store everything out of altruism."
Obsidian's answer: Sharded archives and dedicated incentives.
Incentivizing Archives
Message data grows forever, so archival storage needs durable incentives.
The chain configuration includes fee share parameters for future distribution:
proposerFeeShare
30%
Block proposer's share of PM fees
laneLeaderFeeShare
20%
Lane leader's share of PM fees
archiveFeeShare
50%
Archive pool's share of PM fees
archivePoolAddr
Set
Well-known archive pool address
Current status: PM bids are burned in the current implementation. Fee distribution to proposers and archive pools will be enabled in a future upgrade.
Why Dedicated Archive Incentives?
Archives are essential because:
Storage costs scale with usage
Serving historical queries consumes bandwidth and CPU
Operators need predictable incentives to provide high-availability data
Economics (Conceptual)
Any long-term archive incentive mechanism should:
Scale with message volume
Reward storage and query-serving reliability
Avoid centralizing data availability
Archive Incentive Mechanism
The specific mechanism (e.g. an on-chain pool, direct payouts, or other designs) is implementation-defined and may change.
Registration Requirements
To earn archive rewards, nodes must:
Stake deposit
Skin in the game, slashing collateral
Store assigned data
Actually have the messages
Serve queries
Respond to historical requests
Maintain uptime
Be available when needed
Slashing Conditions
Archive nodes can lose stake for:
Failing to serve data they're responsible for
Extended downtime
Serving incorrect/corrupted data
This ensures the pool rewards go to nodes that actually provide value.
Full vs Sharded Archives
Obsidian solves storage scaling with sharded archives: instead of every archive storing all history, nodes store specific epoch ranges:
Full Archive
All history
Full share
High (TB+)
Sharded Archive
Epoch range
Proportional
Lower
How it works:
Epoch ranges: History is divided into epoch ranges (e.g., 1000 epochs per shard)
Shard groups: Multiple nodes store the same range for redundancy
Node assignment: Archive operators are programmatically assigned based on current network needs
Proportional rewards: Nodes earn rewards proportional to their coverage, uptime, etc.
This architecture enables:
Accessible participation: Run an archive with consumer hardware by storing a subset of history
Horizontal scaling: More epoch ranges served by adding shard groups
Redundancy: Multiple nodes per shard group ensures availability
See Sharded Archive Nodes for the sharding model.
Flywheel Effect
The economics create a positive feedback loop:
Why This Matters
Most blockchains treat archival as an afterthought. "Someone will run a full node."
Obsidian treats it as essential infrastructure with proper economic incentives:
Predictable revenue for operators
Sustainable model as usage grows
Aligned incentives between users and infrastructure
The goal is that message activity ultimately funds the permanent storage that makes Obsidian's promise real.
Next: Sharded Archive Nodes - Scaling storage across many operators
Last updated