The Farcaster fork token discussion, explained without the fog.
The token people are checking is best understood as a Hypersnap retroactive genesis allocation: a draft, deterministic reward calculation for an independent Farcaster fork โ not an official Farcaster or Neynar token.
Retro pool
10%
of total supply, per FIP-19 default
Vesting
36 epochs
roughly 6 months, linearly
Forward markets
3
DA, Growth, Application work
Not official
Separate
not a Farcaster / Neynar token
Short version
What is actually happening?
Hypersnap is an independent fork / extension path around Farcaster's Snapchain data layer. The project is exploring a network where validators, read nodes, growth, and app usage can be rewarded by protocol-native token emissions. The current controversy is about the retroactive genesis allocation: a one-time calculation that tries to reward historical contribution before the new token system exists.
The important distinction: this is not an official token from Farcaster's main team, not a Neynar token, and not something where raw cast count automatically equals rewards. It is a draft tokenomics model for a fork, with previews circulating before final launch details are locked.
Mental model
Farcaster, Snapchain, Hypersnap, token โ how the pieces fit
Farcaster Classic / Snapchain
The existing Farcaster data layer stores FID activity, casts, reactions, follows, signers, and related protocol messages.
Hypersnap fork
Hypersnap is an independently maintained fork / extension path that keeps Farcaster compatibility while experimenting with a hyper execution context, fuller retention, validators, and incentive rules.
Token discussion
The current token docs propose protocol-native work rewards: not hash mining, not an official Farcaster token, and not a discretionary giveaway.
Retro preview
The reward checker circulating on Farcaster shows estimated retroactive genesis allocations based on the draft algorithm. Numbers can change until the root and launch parameters are final.
Token model
The draft rewards protocol-native work, not hash mining
๐๏ธ
Data Availability
Validators and read nodes earn for keeping network data available and serving it reliably. Draft share: 50% of forward emissions.
๐ฑ
Growth PoW
FIDs earn for credible, reciprocal relationships with other credible users. Draft share: 20% of forward emissions.
๐งฉ
Application PoW
Apps and clients earn for verifiable, sustained usage through signed receipts / Snap Compute-style work. Draft share: 30% of forward emissions.
Calculation
How the retro reward preview is calculated
1. Effective FID age
Age is based on registration unless the FID changed custody; transferred FIDs use the latest custody-transfer timestamp so old accounts cannot simply be bought for age weight.
2. Trust score
A graph-based EigenTrust-style score is computed from the follow graph, seeded by older / verified / established accounts, then dampened for sybil-like clusters.
3. Eligibility filters
Accounts pass or fail protocol-native filters: minimum post-transfer activity, received engagement, engager diversity, reply/activity quality, and app/farm detection.
4. Credibility scalar
The draft combines age factor, trust score, interaction entropy, stake factor, and client diversity. For retro, stake factor is zero because no token existed yet.
5. Growth score
Historical reciprocal relationships with credible users matter more than raw cast volume. Low-trust crediters contribute zero, and mutuality is log-saturated to reduce spam volume advantages.
6. Pro-rata allocation
Each eligible FID gets composite score / total eligible composite score ร retroactive pool. Ineligible FIDs receive zero in the draft model.
Formula, simplified
allocation(fid) = composite(fid) / ฮฃ composite(eligible FIDs) ร retroactive_pool
In the draft, retroactive_pool = total_supply ร 10%. The retro pool is one-time; future rewards come from ongoing work markets.
Why people see weird numbers
Why active users can get very different allocations
- A newer but productive builder may be underweighted if most of their work happened recently or inside a smaller subgraph.
- An older FID does not automatically win if it lacks credible reciprocal engagement or fails eligibility filters.
- App/client contribution is mostly forward-looking in FIP-19; historical app usage is intentionally excluded from retro.
- The algorithm favors graph credibility and mutuality, so social structure matters more than screenshots of cast count.
- Preview tools can drift from final results if parameters, snapshots, eligibility filters, or launch roots change.
FAQ
Common claims, corrected
Is this the official Farcaster token?+
No. The public discussion points to Hypersnap, an independent fork / experiment under farcasterorg. Treat it separately from the official Farcaster and Neynar accounts.
Is it just an airdrop?+
The FIP explicitly frames retro rewards as a deterministic genesis computation, not a discretionary airdrop. In practice, people are calling the preview an airdrop because it feels like one.
Do more casts always mean more tokens?+
No. The draft is weighted toward credible reciprocal growth, eligibility, trust, and diversity. Raw volume alone can be weak or even filtered if it looks farmed.
Are builders rewarded retroactively?+
Not through historical app usage in FIP-19. Retro is Growth PoW only. App builders are intended to earn through forward-looking Application PoW after launch.
Are numbers final?+
No public preview should be treated as final until the launch parameters, snapshot, root, and claim / distribution mechanics are finalized by the project.
Should I connect my wallet to random claim links?+
Absolutely not. Verify official sources. A reward preview is not a reason to sign messages, approve contracts, or connect wallets to unknown sites.
Safety
Before you touch any checker or claim site
- Do not sign approvals just to view an allocation.
- Do not trust copied links from random casts, replies, or DMs.
- Verify official sources and read the transaction/message before signing anything.
- Assume previews are mutable until final parameters and distribution mechanics are published.
Sources
Primary docs I used
FIP-19: Proof of Work Tokenization
Main draft for work markets, retro calculation, eligibility, emissions, and vesting.
FIP-17: Proof of Quality
Trust / uniqueness / sybil-resistance model that feeds credibility and fees.
FIP-13: Hyper Validator Selection
Dynamic validator / epoch direction for the hyper path.
Hypersnap repository
Rust node implementation and hyper-mode architecture docs.
Hypersnap API docs
Developer API reference, including the public node at haatz.quilibrium.com.
The cast that kicked this off
mvr's cast showing a Snap reward preview and the circulating checker link.