FIP: Hypersnap Commitment-Weighted Proof-of-Work Tokenomics

[CryptoExplor]

Hypersnap Commitment-Weighted Proof-of-Work Tokenomics (Draft FIP)

Preamble

• FIP: Hypersnap Commitment-Weighted Proof-of-Work Tokenomics
• Title: Hypersnap Commitment-Weighted Proof-of-Work Tokenomics
• Author: dare1.eth (@CryptoExplor, FID 612066)
• Status: Draft – For Community Discussion
• Type: Economic / Tokenomics
• Created: 2026-04-17
• Requires: PoQ (FIP-17), Proof-of-Work Tokenization (FIP-19), Snapchain / Snap Compute (FIP-21 / Snapchain FIP), Hypersnap base protocol

Scope note: Canonical Farcaster (maintained under farcasterxyz/protocol) does not define or issue a protocol token; its FIP process covers protocol behavior, not tokenomics. This proposal specifies a token and incentive system for Hypersnap, a fork of Farcaster maintained under farcasterorg, which is independently exploring Proof of Quality and Proof of Work tokenization.[^1][^2][^3][^4]

Abstract

This proposal introduces a Commitment-Weighted Proof-of-Work (PoW) tokenomics framework for the Hypersnap fork of the Farcaster protocol. The framework rewards verifiable, protocol-native work across three markets—Data Availability (DA), Application Usage, and Growth—while explicitly rejecting hashcash-style, purely computational mining.

The core innovation is an Activity Density Score (ADS), a per-FID scalar that weights raw work output by consistency, retention quality, and cross-community diversity. ADS feeds into a credibility scalar together with identity and graph signals, ensuring that small, high-quality contributors can earn meaningfully while large operators cannot linearly multiply rewards purely through scale.

The proposal is designed to be additive to Hypersnap’s PoQ and PoW Tokenization discussions: it instantiates the dynamic credibility scalar, formalizes SnapExecutionBundle as a first-class Application PoW receipt, and defines a phased rollout that ships anti-sybil defenses and trust-score gating in Phase 0.

Motivation

Background

Farcaster is a decentralized social protocol that exposes FIDs, hubs, Snapchain, and other primitives which Hypersnap reuses while experimenting with alternative incentive, fee, and quality systems. Hypersnap’s PoQ (Proof of Quality) proposal defines a trust score derived from verifiable behavioral signals and positions that score as a general-purpose input for fee and reward systems.[^2][^3][^4]

In parallel, Hypersnap’s Proof-of-Work Tokenization discussion outlines three “work markets” (DA, Application Usage, Growth) but leaves open the implementation details of the credibility scalar, how mini-app work is attested, and how to prevent farming and hash-power plutocracy.[^3]

Problems to Solve

This proposal addresses three primary problems:

1. Linear scaling abuse – Large operators can multiply work output linearly by adding infrastructure, concentrating rewards without corresponding quality improvements.
2. Cold-start inequality – New contributors cannot compete on raw volume against incumbents with years of history and infrastructure, which chills ecosystem entry.
3. Snap Compute blind spot – Mini-app interactions executed via Snap Compute generate verifiable SnapExecutionBundle records, but today these are not specified as first-class work receipts alongside server-side AppUsageReceipts.

Design Goals

The tokenomics are designed to:

• Reward verifiable protocol-native work across DA, Growth, and Application usage.
• Weight rewards by quality and commitment via ADS and trust scores, not by raw volume alone.
• Ship anti-sybil defenses and trust-score gating in Phase 0 to avoid irreversible airdrop farming damage.
• Integrate tightly with Snapchain and hyper mode (StateContext::Hyper) to leverage unbounded history for PoW accounting and audits.[^5][^6]
• Align incentives for hub operators, builders (apps and agents), and content contributors without privileging any single category.

Specification

1. Token and Supply

• Name/Symbol: TBA (by Hypersnap governance)
• Network: Optimism (L2)
• Total supply: 2,000,000,000 tokens (fixed cap)
• Token standard: ERC-20

1.1 Emission Schedule

The emission schedule follows a Bitcoin-style halving with 7-day epochs:

• Years 1–4: 100M tokens per year
• Years 5–8: 50M tokens per year
• Years 9–12: 25M tokens per year
• Years 13+: 12.5M tokens per year (long tail, approaching terminal supply)

Emission is computed per 7-day epoch and becomes claimable at the end of each epoch. Unused emissions rules (e.g., under-subscribed markets) are governed in Section 5.

1.2 Allocation

Initial and ongoing allocation is as follows:

Category	Allocation	Vesting / Notes
PoW Emission Pool	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, max 20% of treasury spent per year
Core Contributors	10%	4-year vest, 1-year cliff

2. Work Markets and Reward Surfaces

Each epoch’s PoW emission pool is split across three work markets, aligned with Hypersnap’s PoW Tokenization concept:[^3]

Market	Share of Epoch Emissions	Work Definition
Data Availability	50%	Hub operation, block validation, hyper participation
Application Usage	30%	Mini-app interactions, AppUsageReceipts, SnapExecutionBundles
Growth	20%	New FID acquisition, cross-community expansion, retention

2.1 Per-Epoch Caps

To limit single-operator or single-app capture, the following caps apply per epoch:

• MAX_DA_REWARD_PER_NODE: 5,000 tokens per registered DA validator
• MAX_APP_REWARD_PER_APP: 8,000 tokens per registered app
• MAX_GROWTH_REWARD_PER_FID: 500 tokens per FID

All caps are evaluated per operator identity (see Agent and Operator Handling) to prevent circumvention via sybil-splitting.

3. Activity Density Score (ADS)

3.1 Definition

The Activity Density Score (ADS) is a per-FID scalar in \[0.0, 2.0] that weights raw work units to compute their adjusted emission weight in a given epoch. ADS is recomputed every epoch (7 days) and decays with inactivity.

ADS aggregates three dimensions:

• Consistency (40% weight): How regularly a FID is active within and across epochs.
• Retention Quality (35% weight): How much of a FID’s content or activity generates genuine cross-user engagement (unique counterparties, not self or sybil ring).
• Diversity (25% weight): The breadth of distinct channels / communities / counterparties interacted with.

Formally:

\[
ADS = 0.40 \cdot consistency_score + 0.35 \cdot retention_score + 0.25 \cdot diversity_score \quad (1)
\]

Each sub-score is normalized into \[0, 2], and ADS is capped at 2.0.

3.2 Inputs and Data Sources

ADS is computed exclusively from verifiable protocol-native events, including but not limited to:

• Snapchain messages (casts, reactions, recasts, links) associated with a given FID in hyper history.[^6][^5]
• Growth-related events (new FIDs referred/linked via a FID, cross-channel engagement).
• AppUsageReceipts or SnapExecutionBundles for application usage.

No self-reported off-chain metrics are used. Indexers can compute ADS off-chain as long as all inputs are provably derivable from on-chain or Snapchain data.

3.3 Intuition

Under a raw-volume model, an operator running 50 nodes can earn roughly 50× a smaller operator at the same per-node quality. With ADS:

• ADS is computed per FID, not per node.
• Per-node output is normalized before ADS and credibility scalars apply.
• A high-quality single operator (ADS ≈ 1.8) can out-earn a low-quality, high-scale operator (ADS ≈ 0.4) when rewards are weighted by credibility.

4. Credibility Scalar

4.1 Components

Hypersnap’s PoW Tokenization discussion introduces a credibility scalar that should combine static identity and graph signals with dynamic quality signals. This proposal instantiates that scalar as:[^3]

• FID Age Weight: Derived from age of FID, anchored to Optimism transfer events or other unforgeable registration proofs.
• Social Graph Weight: A function of the FID’s position in the network graph (e.g., follower/following structure, link centrality).
• ADS: The dynamic, per-epoch quality and commitment measure defined in Section 3.

4.2 Formula

Let each component be normalized into \[0, 2]. Then define:

\[
credibility = 0.30 \cdot fid_age_weight + 0.30 \cdot social_graph_weight + 0.40 \cdot ADS \quad (2)
\]

This weighting allows a new FID to reach competitive credibility within 3–6 epochs by demonstrating high-quality, consistent work, even without long-standing age or central graph position.

5. Reward Computation

Each work market computes rewards in three steps per epoch:

1. Measure raw work units per eligible FID/operator/app.
2. Compute adjusted weight as (adjusted_work = raw_work \times credibility), incorporating ADS.
3. Distribute emissions for the market pro-rata on adjusted work, subject to per-epoch caps.

Market-specific definitions of raw work units:

• DA: Validated chunks or snaps, uptime, and hyper participation for a given validator.
• App: Count of valid AppUsageReceipts and/or SnapExecutionBundles for a registered app.
• Growth: Number of newly-activated FIDs and cross-community retained users attributable to a FID.

Unused emissions in a market for a given epoch are rolled into a “market reserve” for that category and can be reallocated by governance (e.g., to future epochs in the same market or burned) as defined in governance parameters.

6. Application PoW and Snap Compute

6.1 Work Receipts

Application PoW is measured using two equivalent classes of work receipts:

• AppUsageReceipt: A signed, verifiable record of application usage produced by server-side infrastructure associated with a registered app FID.
• SnapExecutionBundle: A Snap Compute execution record produced on-chain by the Snapchain/Snap Compute stack for snap-native mini-apps.[][]

6.2 Equivalence Rule

To avoid penalizing snap-native apps for choosing a more verifiable execution path, the following equivalence is defined:

• Each valid SnapExecutionBundle referencing a registered app FID counts as exactly one App PoW unit, equivalent to a valid AppUsageReceipt for the purposes of Application market reward computation.

Conditions for validity include:

• The bundle is included in a finalized snap in hyper history.
• The bundle references a currently registered app FID.
• No double-counting: a single logical interaction must not generate both a server-side receipt and a SnapExecutionBundle eligible for reward.

6.3 Snap Compute Builder Bonus

Apps that use Snap Compute as their primary execution environment receive an additional 1.15× multiplier on their Application PoW emissions after tier-based allocation (see Builder Reward Tiers). The rationale is that Snap Compute execution is more accountable and verifiable than server-side logging and should be economically favored.

7. Hyper Mode Requirements

7.1 Rationale

Snapchain’s canonical pipeline can prune history, while PoW accounting requires access to complete historical records for ADS computation, AppUsageReceipt and SnapExecutionBundle sequences, and auditability.[][] Hyper mode provides unbounded retention of historical messages and execution bundles.

7.2 Integration Points

Emission settlement contracts and indexers must be able to query:

• StateContext::is_hyper() – to confirm a node participates in full history retention.
• HyperConfig::with_retention_cap() – for operator-side soft alerts (disk usage) without truncating history.
• SyncReport::diverged() – to detect and invalidate PoW claims from nodes whose hyper state has diverged.

A standard operator runbook includes running snapchain hyper audit --latest N (for a configurable N) before each epoch settlement to prove non-divergent hyper state.

7.3 Hyper Mode DA Bonus

Nodes with hyper.enabled = true that maintain verified non-divergent hyper state receive a 1.2× multiplier on their DA market rewards for the epoch. Divergence detected via SyncReport::diverged() invalidates DA PoW claims for that epoch and may trigger additional penalties as approved by governance.

8. Anti-Sybil Framework

The anti-sybil framework ships in Phase 0 and gates both the initial airdrop and ongoing emissions.

8.1 Trust Score and Layers

A unified trust score is derived from three layers, building on PoQ’s approach:[]

1. Identity Signals (≈ 40% weight)

   • FID age anchored to Optimism transfer or registration events.
   • Verified Ethereum address with non-trivial transaction history.
   • ERC-8004 agent registry flag distinguishing human FIDs from agent FIDs.

2. On-Chain Activity (≈ 35% weight)

   • ≥ 30 days of verifiable activity in trailing 90 days.
   • At least 3 distinct interactions (casts/reactions/recasts) per active week.
   • AppUsageReceipt or SnapExecutionBundle production for App PoW claimants.
   • Validator registration with staked collateral for DA PoW claimants.

3. Behavioral Analysis (≈ 25% weight)

   • Temporal patterns (highly regular, bot-like posting).
   • Network graph analysis (isolated FIDs with no organic connections).
   • Cross-correlation of shared IP ranges, wallet derivation paths, or timing signatures.

The exact mapping from signals to trust score is left to an upgradable scoring contract and/or oracle, with parameters governed by Hypersnap governance.

8.2 Eligibility Thresholds

Trust score determines eligibility and multipliers:

Trust Score	Airdrop Eligibility	Ongoing Emission Multiplier
≥ 70	Full allocation	1.5×
40–69	Full allocation	1.0×
20–39	50% allocation	0.5×
< 20	Ineligible	0×

The initial airdrop requires trust score ≥ 40. PoW emissions continue to apply multipliers each epoch as trust scores evolve.

8.3 Appeals and Updates

Trust scores are recomputed at least once per epoch. Users can submit appeals via a governance-defined process; successful appeals apply to subsequent epochs and, where feasible, are retroactively considered for airdrop eligibility within a defined dispute window.

9. Agent and Operator Handling

9.1 Core Principle

Autonomous agents constitute a significant share of activity but are considered extensions of human operators, not independent economic entities.

9.2 Operator–Agent Mapping

• A single Operator FID controls zero or more Agent FIDs.
• An ERC-8004 registry and/or protocol-level tagging is used to classify FIDs as agents.[]

Rules:

• Agent FIDs are ineligible for direct PoW rewards and governance voting.
• Emissions attributable to agent activity are aggregated at the Operator FID.
• Emission caps and trust-score multipliers apply per operator, not per agent.

9.3 Staking and Penalties

• Operators must stake a baseline amount to register as builders or validators.
• Agent-operated apps require an additional per-agent stake (e.g., 100 tokens per Agent FID) to discourage spam.
• Proved misbehavior (spam, sybil ring activity) can trigger partial or full slashing of operator and per-agent stakes.

An optional agent advisory channel can be created to collect non-binding sentiment from agents that is visible to governance but carries zero voting weight.

10. Builder Reward Tiers

10.1 Tier Structure

The Application market is split into builder tiers to improve fairness and reduce power-law concentration:

Tier	Criteria	Share of App PoW Pool	Notes
Tier 1 – Established	> 1,000 MAU, > 6 months live	15%	Capped to avoid monopolization
Tier 2 – Growing	100–1,000 MAU	35%	Core mid-market incentive
Tier 3 – Emerging	< 100 MAU and/or < 6 months live	50%	Maximum support for new entrants

Within each tier, apps share their tier’s pool pro-rata by adjusted work (raw App PoW units × credibility scalar). Snap Compute apps then receive an additional 1.15× multiplier.

10.2 Builder Registration

To participate in App PoW rewards, apps must:

• Register an app FID and associated builder FID.
• Stake a minimum of 500 tokens (refundable on clean deregistration).
• Provide verifiable metadata (FID, Ethereum address, ERC-8004 link if applicable).
• Commit to either:
  • Submitting AppUsageReceipts meeting protocol-defined standards, or
  • Executing via Snap Compute and relying on SnapExecutionBundles.

Agent-operated apps require an additional per-agent stake as in Section 9.

11. Governance

11.1 Voting Weights

To avoid pure token plutocracy, governance weight is split across three stakeholder classes:

Stakeholder Class	Governance Weight	Rationale
Token Holders	40%	Economic alignment and capital at risk
Builders	35%	Most affected by protocol parameter changes
Validators	25%	Infrastructure providers and security guarantors

Builders and validators must be registered and in good standing to exercise voting weight.

11.2 Voting Rules

• Proposal threshold: 10,000 tokens staked or registered builder/validator status.
• Approval thresholds:
  • 60% supermajority for major changes (emission shares, ADS weights, tier boundaries).
  • Simple majority (51%) for operational matters (treasury spends < 5% of annual budget).
• Quorum: At least 30% of total eligible governance weight must participate.
• Discussion period: Minimum 14 days prior to any formal vote.

11.3 Governable vs Non-Governable Parameters

Governable via normal process:

• Emission rates per work market (within defined bounds).
• ADS dimension weights and normalization functions.
• Tier boundaries and shares.
• Credibility scalar weights.
• Treasury spending within yearly caps.

Non-governable (requires hard fork / new token):

• Total supply cap (2B).
• Halving schedule.
• Minimum trust score for basic eligibility (floor at 20).
• Exclusion of agent FIDs from direct voting and rewards.

12. Treasury and Fee Mechanics

12.1 Fee Capture and Burn

Fee sources and default burn splits:

Fee Source	Burn Percentage	Notes
Storage unit fees	50%	Core deflationary pressure
Snap Compute execution fees	40%	Rewards verifiable on-chain work
Validator slashing	100%	Full burn, no redistribution
Builder registration slashes	100%	For provable fraud or misbehavior

Long-term target is net annual inflation of ≈ 2%, balancing emissions with fee burns once protocol usage scales.

12.2 Treasury Management

The 15% treasury allocation is managed by a DAO multi-sig (e.g., 5/7) under these constraints:

• Spending caps: Max 20% of treasury per year.
• Categories (targets):
  • 40% ecosystem grants and public goods.
  • 30% core protocol development and audits.
  • 20% marketing and ecosystem awareness.
  • 10% emergency reserve.
• Assets (targets):
  • 40% stablecoins.
  • 30% blue-chip crypto (ETH/BTC).
  • 20% protocol-owned liquidity.
  • 10% strategic ecosystem investments.

All treasury operations are executed on-chain with a public dashboard.

13. Implementation Roadmap

Phase 0 – Foundation (Weeks 1–4)

• Deploy ERC-20 token contract on Optimism (2B supply).
• Deploy airdrop contract with trust-score gating.
• Deploy validator staking contract and DA PoW reward router.
• Stand up DAO treasury multi-sig.
• Implement and deploy PoQ-based trust score computation pipeline.
• Integrate ERC-8004 agent registry.
• Enable StateContext::is_hyper() and SyncReport::diverged() in node software.
• Open builder/app FID registry.

Phase 1 – Work Markets Live (Months 1–3)

• Activate three work markets (DA 50%, App 30%, Growth 20%).
• Deploy ADS scoring engine and credibility scalar logic.
• Activate hyper mode DA bonus (1.2×) for verified non-divergent nodes.
• Activate Snap Compute builder bonus (1.15×) for qualifying apps.
• Settle first epoch and enable reward claims.

Phase 2 – Governance Active (Months 4–6)

• Hold first community vote on emission parameters.
• Enable dynamic emission adjustment via governance.
• Activate builder tier system.
• Integrate snapchain hyper audit into epoch settlement validation.
• Ratify SnapExecutionBundle ↔ AppUsageReceipt equivalence formally across FIPs.

Phase 3 – Scaling (Months 7–12)

• Deploy cross-chain bridges (if approved).
• Expand validator network (target: ≥ 100 hubs across ≥ 5 continents).
• Conduct first retroactive public goods funding round.
• Launch developer grants program.
• Finalize and implement a dedicated Agent Economics FIP building on this framework.

Phase 4 – Decentralization (Year 2+)

• Rotate multi-sig signers to include community members.
• Begin core contributor vest unlocks.
• Form Technical, Economic, and Grants subcommittees.
• Ossify key emission parameters.
• Reduce founding team influence to < 5% of active development.

14. Security Considerations

Key risks and mitigations:

• Smart contract vulnerabilities – Mitigate via multiple independent audits, formal verification of emission and treasury contracts, and emergency pause mechanisms.
• ADS manipulation – Mitigate by sourcing ADS inputs exclusively from verifiable on-chain/Snapchain events and by providing a 48-hour per-epoch dispute window.
• Hyper mode failures – Mitigate via SyncReport::diverged() checks, mandatory hyper audit runs before settlement, and operator alert metrics.
• Token price volatility – Mitigate by allowing storage payments in stablecoins, defining validator bonds in token amounts rather than dollar equivalents, and maintaining a stablecoin-heavy treasury buffer.
• Tier 3 spam – Mitigate by requiring builder stakes, enforcing MAX_APP_REWARD_PER_APP, and using ADS to down-weight low-retention apps.
• Governance capture – Mitigate via multi-stakeholder voting weights, supermajority requirements for major changes, and hardcoded non-governable fairness guarantees.

15. Backwards Compatibility

This proposal does not modify canonical Farcaster protocol semantics and is compatible with existing Hypersnap PoQ and PoW Tokenization proposals, which it extends with concrete definitions and parameters.[][] Legacy Farcaster hubs and clients are unaffected; Hypersnap-specific nodes and contracts implement the described behavior.

16. Open Questions

• Exact functional forms and normalization for consistency, retention, and diversity sub-scores.
• Detailed dispute-resolution mechanism and appeal rights for trust-score and ADS computations.
• Long-term role and specific voting weight formulas for builders and validators in governance.
• Parameter bounds for governance (e.g., min/max emission shares, ADS weight ranges) to avoid governance-induced instability.

---

References

1. FIPs - Farcaster Docs - An FIP, or Farcaster Improvement Proposal, is a process for building consensus around protocol chang...

2. farcasterxyz/protocol: Specification of the Farcaster Protocol - GitHub - Farcaster is a protocol for building decentralized social apps. This repository contains the technic...

3. FIP: Proof of Work Tokenization · farcasterorg · Discussion #19 - Farcaster uses a token emission model based on three "work markets" — Data Availability, Growth, and...

4. FIP: Proof of Quality · farcasterorg · Discussion #17 · GitHub - This proposal defines a fee mechanism for Hypersnap that dynamically adjusts per-message fees based ...

5. FIP: Snapchain · farcasterxyz protocol · Discussion #207 - Snapchain is a blockchain-like network for storing and syncing Farcaster's social data. It has stron...

6. farcasterxyz/snapchain: The open-source, canonical ... - Snapchain is a data storage layer for the Farcaster social protocol. It is a blockchain-like decentr...

Hypersnap Commitment-Weighted Proof-of-Work Tokenomics (Draft FIP).pdf
Hypersnap Commitment-Weighted Proof-of-Work Tokenomics (Draft FIP).docx
Hypersnap Commitment-Weighted Proof-of-Work Tokenomics (Draft FIP).md

[arcabotai]

I’d avoid treating this as a competing mechanism to FIP-19. The useful parts here should probably be folded into FIP-19 as bounded modifiers and receipt rules.

Three pieces seem worth carrying over:

1. activity_density should be a capped modifier, not a dominant score. Something like credibility * clamp(activity_density_modifier, 0.8, 1.2) keeps consistent contributors from being underweighted without reopening volume farming.

2. Snap Compute should produce first-class App-PoW receipts. If SnapExecutionBundle is verifiable under consensus, it should map deterministically into AppWorkRecord; otherwise snap-native apps are structurally disadvantaged versus server-side apps submitting signed receipts.

3. Market activation should be phased. DA first, App second, Growth last. Growth is the most adversarial market and should not be activated until PoQ/eligibility outputs have survived real epochs.

The main risk is double-counting commitment. Age, trust, interaction entropy, stake, client diversity, and ADS are all correlated in places. If ADS becomes another full-weight top-level term, it may reward the same behavior twice. Keep it bounded and inspectable.