Farcaster PoW Tokenomics Proposal — Commitment-Weighted Emission with Activity Density Score

[CryptoExplor]

I've created a comprehensive Proof of Work tokenomics proposal designed to complement FIP #19 (PoW Tokenization) and FIP #21 (Snap Compute) with a phased rollout that prioritizes commitment-weighted rewards over raw hash power. The document includes the Activity Density Score framework, builder tier distribution, hyper mode integration, anti-sybil defense, and success metrics. Research properly references FIP #19, FIP #21, FIP #17, and my previous PoS Proposal (#12 v2).

---

Farcaster Proof of Work Tokenomics Proposal

Version 1.0 — April 2026

Prepared by: @CryptoExplor | FID 612066 | dare1.eth

Status: Draft for Community Discussion

---

Executive Summary

This proposal outlines a Commitment-Weighted Proof of Work (PoW) tokenomics framework for the Farcaster protocol that rewards verifiable, protocol-native work — not passive token holding or arbitrary hash computation. It is designed to complement FIP #19 (Proof of Work Tokenization) and FIP #21 (Snap Compute) with a phased rollout that prioritizes decentralization, anti-sybil robustness, and genuine contribution over speculation.

Core Innovation: An Activity Density Score (ADS) that weights token emissions by the quality and consistency of work performed — not just raw output volume. Small contributors earn meaningfully. Whales cannot linearly multiply rewards through scale alone.

Key Objectives:

• Reward verifiable protocol-native work across Data Availability, Growth, and Application markets
• Prevent hash-power plutocracy through reputation-gated credibility scalars
• Phase rollout safely: canonical behavior never disrupted, hyper mode unlocks PoW benefits progressively
• Align incentives for node operators, mini-app builders, and content contributors simultaneously
• Integrate natively with Snapchain's StateContext::Hyper unbounded retention model

---

1. Introduction

1.1 Context and Motivation

Farcaster's transition to a community-governed protocol creates a once-in-a-generation opportunity to design incentive systems from first principles. FIP #19 correctly identifies that "work" in a social protocol is fundamentally different from hashcash-style computation — it is the production of data availability, social graph growth, and application engagement that sustains the network.

However, the current tokenomics landscape has three unsolved problems:

• Linear scaling abuse — Large operators can multiply work output proportionally through infrastructure scale without diminishing returns, concentrating rewards
• Cold-start inequality — New contributors cannot compete with entrenched participants on raw output volume alone, chilling ecosystem entry
• Snap Compute blindspot — Mini-app interactions executed through Snap Compute (FIP FIP: Snap Compute #21) produce verifiable on-chain SnapExecutionBundle records that are currently not treated as first-class work receipts in emission calculations

This proposal addresses all three through the Activity Density Score model, reputation-gated credibility scalars, and explicit Snap Compute receipt recognition.

1.2 Design Principles

All decisions in this proposal flow from five foundational principles:

Principle 1: Work Must Be Verifiable
Emissions flow only to work that is cryptographically attestable on-chain. Self-reported metrics are inadmissible. AppUsageReceipt, SnapExecutionBundle, and FID-anchored Optimism transfer events are the canonical evidence layer.

Principle 2: Quality Over Quantity
Raw output volume alone should not determine reward magnitude. Consistency, retention, and cross-community diversity weight every work unit through the Activity Density Score.

Principle 3: Phased Safety
The canonical Snapchain pipeline is never disrupted. Hyper mode provides the unbounded historical store that PoW accounting requires — but legacy peers remain unaffected throughout all phases.

Principle 4: Anti-Sybil by Architecture
Identity verification, stake requirements, and behavioral pattern detection are built into Phase 0, not retrofitted. The ordering problem is real: an airdrop without sybil detection creates permanent farming damage.

Principle 5: Composable with Existing FIPs
This proposal is additive, not competitive, with FIP #19 and FIP #21. It specifies the credibility scalar methodology, phased rollout timeline, and Snap Compute alignment that FIP #19 leaves as implementation details.

---

2. The Activity Density Score (ADS)

2.1 What It Measures

The Activity Density Score (ADS) is a per-FID scalar in the range [0.0, 2.0] that multiplies raw work output to compute adjusted emissions weight. It captures three dimensions:

Dimension	Weight	Signal
Consistency	40%	Active days / total days in epoch (streaks rewarded)
Retention Quality	35%	Ratio of content that generated genuine cross-user engagement
Diversity	25%	Number of distinct channels / communities interacted with

Formula:

ADS = (0.40 × consistency_score) + (0.35 × retention_score) + (0.25 × diversity_score)

ADS is computed per epoch (7 days) and decays with inactivity. It cannot exceed 2.0, preventing unbounded amplification.

2.2 Why This Beats Raw Volume

Under a raw-volume PoW model, an operator running 50 nodes earns 50× a single-node operator with identical per-node quality. Under ADS weighting:

• The 50-node operator's ADS is computed at the FID level, not the node count level
• Per-node output is averaged and normalized before the credibility scalar applies
• A high-quality single contributor with ADS 1.8 can out-earn a low-quality 10× scale operator with ADS 0.4

2.3 ADS and the Credibility Scalar

FIP #19 defines a credibility scalar derived from unforgeable FID age (anchored to Optimism transfer events), social graph position, and interaction diversity. ADS is the dynamic component of that scalar — it is the per-epoch measurement layer that FIP #19's static identity signals cannot capture.

Combined scalar:

credibility = (fid_age_weight × 0.30) + (social_graph_weight × 0.30) + (ADS × 0.40)

This means a new FID can earn a competitive credibility scalar within 3–6 epochs by demonstrating high-quality consistent work, even without years of FID age.

---

3. Token Emission Model

3.1 Three Work Markets (Aligned with FIP #19)

Total epoch emissions are distributed across three work markets:

Market	Emission Share	Work Definition
Data Availability (DA)	50%	Hub operation, block validation, snapchain participation
Application Usage (App)	30%	Mini-app interactions, AppUsageReceipt production, Snap Compute bundles
Growth	20%	New FID acquisition, cross-community expansion, content retention

3.2 Snap Compute as First-Class App PoW

This is the critical alignment with FIP #21 that is missing from current FIP #19 implementation details.

Every SnapExecutionBundle produced by a mini-app through Snap Compute constitutes a verifiable App PoW receipt automatically, without requiring a separate AppUsageReceipt submission.

Rationale:

• Snap Compute bundles are more verifiable than server-side receipts — execution is on-chain, not self-reported
• Requiring a separate receipt submission disadvantages snap-native apps versus server-side apps
• The hyper_state_root in HyperEnvelope confirms the retained execution context, providing a second verification layer

Rule: Any SnapExecutionBundle referencing a registered app FID counts as 1.0 App PoW unit. Snap Compute apps should never be penalized for using the more verifiable execution path.

3.3 Emission Schedule

Total supply: 2,000,000,000 tokens (compatible with the analysis in Discussion #20)

Bitcoin-style halving every 4 years:

Year	Annual Emission	Notes
1–4	100M tokens/year	Bootstrap phase, full three-market distribution
5–8	50M tokens/year	Post-halving, ecosystem self-sustaining expected
9–12	25M tokens/year	Maturity phase
13+	12.5M tokens/year	Long tail, approaching terminal supply

Epoch length: 7 days. Emissions computed and claimable weekly.

Caps per epoch:

• MAX_DA_REWARD_PER_NODE: 5,000 tokens/epoch (prevents single-operator DA capture)
• MAX_APP_REWARD_PER_EPOCH: 8,000 tokens/epoch per registered app (prevents single-app capture)
• MAX_GROWTH_REWARD_PER_FID: 500 tokens/epoch (prevents referral farming)

3.4 Token Allocation

Category	Allocation	Vesting
PoW Emission Pool (ongoing rewards)	40%	Continuous, epoch-by-epoch
Community & Initial Airdrop	20%	Retroactive, trust score ≥ 40 required
Developers & Builder Grants	15%	12-month vest, quarterly unlock
Treasury & Public Goods	15%	DAO-controlled, 20%/year max spend
Core Contributors	10%	4-year vest, 1-year cliff

---

4. Anti-Sybil Framework

4.1 Three-Layer Defense (ships with Phase 0)

The anti-sybil framework must ship with the airdrop, not after. The ordering problem is irreversible: farming damage done before sybil detection is permanent.

Layer 1: Identity Signals (40% weight)

• FID age anchored to Optimism transfer events (unforgeable)
• Verified Ethereum address with transaction history
• ERC-8004 agent registry check (flags agent FIDs from human FIDs)
• Minimum trust score: 40 for full eligibility, 20–39 for 50% multiplier, < 20 ineligible

Layer 2: On-Chain Activity (35% weight)

• Minimum 30 days of verifiable Farcaster activity in trailing 90 days
• At least 3 distinct on-chain interactions (casts, reactions, recasts) per active week
• AppUsageReceipt or SnapExecutionBundle production (for app PoW claimants)
• Validator registration with staked collateral (for DA PoW claimants)

Layer 3: Behavioral Analysis (25% weight)

• Temporal pattern detection: bot-like posting regularity flagged
• Network graph analysis: isolated FIDs with no organic social connections penalized
• Cross-correlation: FIDs sharing IP ranges, wallet derivation paths, or timing signatures clustered and capped

4.2 Eligibility Thresholds

Trust Score	Airdrop Eligibility	Ongoing Emission Multiplier
≥ 70	Full allocation	1.5× (high-trust bonus)
40–69	Full allocation	1.0× (standard)
20–39	50% allocation	0.5×
< 20	Ineligible	0×

4.3 Agent FID Handling

Autonomous agents are a significant share of Farcaster activity today. The framework must address them from day one, not retrofit later.

Core principle: Agents are extensions of their operators, not independent economic actors.

• Agent FIDs identified via ERC-8004 registry OR behavioral anti-sybil flagging
• Agent FIDs are ineligible for direct PoW rewards
• Operator/builder FIDs receive builder rewards based on their agent's contribution metrics — but capped at 1 operator identity regardless of agent count deployed
• Agents cannot stake, vote, or claim independently
• Operator must stake proportionally to number of deployed agents (anti-spam, creates skin-in-game)
• Agent signals (non-binding) can inform governance through a separate advisory channel without creating a voting attack surface

---

5. Phased Rollout

5.1 Phase 0: Foundation (Weeks 1–4, Ships First)

Nothing else needs to go live before this phase is complete.

• Fixed supply ERC-20 on Optimism (2B total supply)
• Retroactive airdrop to existing FIDs (trust score ≥ 40, age + activity weighted)
• Anti-sybil scoring active before airdrop snapshot — no exceptions
• Validator staking with minimum threshold to register
• DA PoW market operational (hub operators can begin earning)
• DAO treasury multi-sig (5/7) operational
• ERC-8004 agent registry integrated for FID classification
• First 90 days: 5% of builder allocation reserved for early app deployers, declining bonus

5.2 Phase 1: Work Markets (Months 1–3)

• App PoW market operational (AppUsageReceipt and SnapExecutionBundle both accepted)
• Growth PoW market operational
• Full three-market emission distribution active
• ADS scoring engine deployed on-chain
• StateContext::Hyper enabled for nodes that opt into hyper mode (unbounded history for PoW accounting)
• HyperConfig::with_retention_cap() soft alerting operational for disk management

5.3 Phase 2: Governance & Refinement (Months 4–6)

• First governance vote on emission parameters
• Dynamic emission adjustment based on network health metrics
• Builder reward tiers active (Tier 3 emerging apps get proportionally higher share)
• Hyper audit tooling (snapchain hyper audit) live for PoW history verification
• SyncReport::diverged() and summary() integrated into epoch settlement checks
• Cross-FIP alignment audit: reconcile SnapExecutionBundle ↔ AppUsageReceipt equivalence formally

5.4 Phase 3: Scaling (Months 7–12)

• Cross-chain bridge deployments
• Expanded validator network (target: 100+ hub operators across 5+ continents)
• Retroactive public goods funding round from treasury
• Developer grants program launch
• First quarterly transparency report with Gini coefficient and distribution equity metrics

5.5 Phase 4: Decentralization (Year 2+)

• Multi-sig signer rotation (community members join)
• Core contributor vesting begins unlocking
• Subcommittee formation: Technical, Economic, Grants
• Protocol ossification for stable emission parameters
• Progressive reduction of founding team influence (target: < 5% of active development)

---

6. Hyper Mode Integration

6.1 Why PoW Needs Hyper Mode

The canonical Snapchain pipeline prunes message history. PoW accounting requires verifiable historical records to compute ADS, validate AppUsageReceipt sequences, and audit epoch-over-epoch consistency claims.

Hyper mode (StateContext::Hyper) is a prerequisite for full PoW accounting — it stores every historical message without pruning, giving the emission settlement layer access to complete, unforgeable work history.

Key integration points:

• StateContext::is_hyper() — Emission settlement contracts query this to confirm a node is participating in full history retention
• HyperConfig::with_retention_cap() — Operators set soft disk alerts without truncating data (PoW history must never be pruned)
• SyncReport::diverged() — Epoch settlement rejects PoW claims from nodes showing hyper state divergence
• snapchain hyper audit --latest 500 — Standard verification step before any epoch settlement

6.2 Operator Incentive for Hyper Mode

Nodes that enable hyper.enabled = true and maintain verified non-divergent hyper state receive a DA PoW bonus multiplier of 1.2× on their epoch rewards.

This creates an economic incentive for operators to invest in the storage and compute required for unbounded retention, growing the hyper network without mandating it.

---

7. Builder Reward Tiers

7.1 Tier Structure

The flat reward curve is the most underappreciated design decision in this proposal. Under standard power-law distribution, the top 10% of apps capture 90% of rewards. The tiered structure below inverts that — an app with 50 retained users earns meaningfully, not as a rounding error.

Tier	Criteria	App Pool Share	Notes
Tier 1 — Established	> 1,000 monthly active users, > 6 months live	15%	Capped to prevent monopolization
Tier 2 — Growing	100–1,000 monthly active users	35%	Core mid-market incentive
Tier 3 — Emerging	< 100 monthly active users, < 6 months live	50%	Maximum support for new entrants

Why Tier 3 gets 50%: Cold-start is the hardest problem in ecosystem development. A new mini-app builder competing against established apps on raw volume will always lose. Giving emerging apps the largest pool share creates a genuine economic reason to build on Farcaster — not just a theoretical one.

7.2 Snap Compute Builder Bonus

Mini-apps that use Snap Compute (FIP #21) as their primary execution environment receive an additional 1.15× multiplier on their App PoW emissions above the base tier allocation.

Rationale: Snap Compute execution is more verifiable than server-side receipt submission. Apps that use the more accountable path should be rewarded for it, not penalized by being required to submit a redundant AppUsageReceipt on top.

7.3 Builder Registration

All apps must register a builder FID to participate in App PoW rewards:

• Stake 500 tokens minimum (refundable on deregistration, anti-spam)
• Submit verifiable app identity (FID, Ethereum address, ERC-8004 agent registry link if applicable)
• Agree to AppUsageReceipt submission standards or use Snap Compute native execution
• Agent-operated apps: operator must stake an additional 100 tokens per deployed agent FID

---

8. Governance Model

8.1 Hybrid Voting Weights

Pure token-weighted voting concentrates governance power too quickly. The builder and validator weights exist specifically to prevent a new form of plutocracy where the earliest large token holders control all protocol parameters.

Stakeholder	Governance Weight	Rationale
Token Holders	40%	Economic alignment, capital at risk
Builders (registered apps)	35%	Day-to-day protocol users, most affected by parameter changes
Validators (hub operators)	25%	Infrastructure providers, security guarantors

8.2 Voting Mechanics

• Proposal threshold: 10,000 tokens staked OR builder/validator registration
• Approval threshold: 60% supermajority on major parameter changes (emission rates, tier boundaries, credibility scalar weights)
• Simple majority: 51% for operational decisions (treasury spending below 5% of pool, security patches)
• Quorum: 30% of eligible voting weight must participate for a vote to be valid
• Discussion period: 14 days minimum before any formal vote

8.3 Governable vs Non-Governable

Governable (community vote required):

• Emission rates per work market
• ADS dimension weights
• Tier boundary thresholds
• Credibility scalar formula weights
• Treasury spending above 5% of annual allocation

Non-governable (hardcoded, requires fork):

• Total supply cap (2B)
• Halving schedule
• Anti-sybil eligibility minimum (trust score floor of 20)
• Agent FID exclusion from direct voting

---

9. Success Metrics

9.1 Protocol Health Indicators

Year 1 Targets:

• Active FIDs earning PoW rewards: 10,000+ monthly
• Registered Apps: 150+ mini-apps with verified builder FIDs
• Hub Operators: 75+ independent validators across 3+ continents
• Hyper mode adoption: 30%+ of DA PoW participants running hyper.enabled = true
• Governance: 8+ proposals submitted, 50%+ eligible weight participating

Year 3 Targets:

• Active FIDs earning PoW rewards: 75,000+ monthly
• Registered Apps: 500+ with diverse use case coverage
• Hub Operators: 150+ validators, full geographic distribution
• Hyper mode adoption: 70%+ of DA PoW participants

Year 5 Targets:

• Active FIDs earning PoW rewards: 300,000+ monthly
• Registered Apps: 1,500+
• Protocol Revenue: $5M+ annual via fee capture and burn
• Governance Maturity: Subcommittees operational
• Ecosystem Independence: Core contributors < 5% of active development

9.2 Fairness Metrics

Distribution equity:

• Gini coefficient < 0.68 for PoW reward distribution (vs. 0.85+ typical for crypto)
• Top 10 recipients control < 12% of epoch rewards
• Tier 3 emerging apps receive ≥ 45% of App PoW pool in every epoch

Anti-sybil effectiveness:

• < 5% false positive rate on legitimate FIDs
• < 2% confirmed sybil penetration in epoch reward distributions
• Community confidence score > 75% in quarterly surveys

---

10. Alignment with Existing FIPs

FIP	Relationship	Key Integration Point
FIP #19 (PoW Tokenization)	Complementary — this proposal specifies the ADS credibility scalar methodology and phased timeline FIP #19 leaves open	ADS is the dynamic layer of the FIP #19 credibility scalar
FIP #21 (Snap Compute)	Extends — adds first-class SnapExecutionBundle recognition as App PoW receipts	Snap Compute apps receive 1.15× builder bonus and automatic receipt credit
FIP #17 (Proof of Quality)	Compatible — trust scores from PoQ feed Layer 1 identity signals in the anti-sybil framework	PoQ trust score ≥ 40 is the Phase 0 airdrop eligibility threshold
Proposal #12 (This author's PoS proposal)	Complementary — the allocation percentages, vesting schedules, flat reward curve, and hybrid governance model from Proposal #12 v2 apply directly to this PoW emission system	Builder Tier distribution maps to App PoW pool

Critical reconciliation needed before launch: The SnapExecutionBundle ↔ AppUsageReceipt equivalence must be formally ratified across FIP #19 and FIP #21 before Phase 1 emission settlement goes live. Without this, Snap Compute apps are structurally disadvantaged versus server-side apps even though their work is more verifiable.

---

11. Conclusion

This PoW tokenomics proposal represents a commitment-weighted alternative to hash-power plutocracy. It rewards protocol-native work — data availability, application usage, and ecosystem growth — through verifiable on-chain receipts and reputation-gated credibility scalars.

Key Innovations:

1. Activity Density Score — Quality and consistency weight every work unit, preventing linear scaling abuse
2. Snap Compute First-Class Receipts — SnapExecutionBundle accepted as native App PoW without redundant submissions
3. Hyper Mode Integration — Unbounded history retention creates the verification layer PoW accounting requires
4. Flat Builder Tiers — Tier 3 emerging apps get 50% of pool, cold-start solved
5. Hybrid Governance — Token holders capped at 40%, builders and validators structurally embedded

This model prioritizes:

• Genuine contribution over passive token holding
• New entrants over entrenched monopolies
• Verifiable on-chain work over self-reported metrics
• Long-term ecosystem health over short-term speculation

The proposal is intentionally designed to evolve. Initial parameters will be refined through governance as the community observes real-world outcomes. Success requires active participation from builders, validators, and contributors — not passive accumulation.

Next Steps:

1. Community discussion on GitHub (30 days)
2. Refinement based on feedback and economic modeling
3. Cross-FIP alignment audit with FIP FIP: Proof of Work Tokenization #19 and FIP FIP: Snap Compute #21 maintainers
4. Formal governance proposal with implementation timeline
5. Security audits and testnet deployment
6. Mainnet launch with Phase 0 MVP

We invite all ecosystem participants to contribute ideas, challenge assumptions, and help refine this model. The goal is not perfection at launch, but a fair, adaptable foundation that serves the protocol for decades to come.

---

Document Version: 1.0 Draft
Last Updated: April 17, 2026
Author: @CryptoExplor | FID 612066 | dare1.eth
License: Creative Commons Attribution 4.0 International
Contact: GitHub Discussion #25 — https://github.com/orgs/farcasterorg/discussions/25

---

Related Discussions:

• FIP FIP: Proof of Work Tokenization #19 (PoW Tokenization): https://github.com/orgs/farcasterorg/discussions/19
• FIP FIP: Snap Compute #21 (Snap Compute): https://github.com/orgs/farcasterorg/discussions/21
• FIP FIP: Proof of Quality #17 (Proof of Quality): https://github.com/orgs/farcasterorg/discussions/17
• Proposal Farcaster tokenomics proposal #12 (PoS Tokenomics v2): https://github.com/orgs/farcasterorg/discussions/12
• Hypersnap PR FIP: Open Consensus for Hypersnap Validators #13 (Hyper Mode + Operator Runbook): feat(hyper): add StateContext helpers, SyncReport, tokenomics docs — FIP-19/21 alignment hypersnap#13