FIP: Proof of Work Tokenization — Multi-Market Token Emission for Protocol Sustainability

Overview

Farcaster uses a token emission model based on three "work markets" — Data Availability, Growth, and Application Usage — where tokens are minted and distributed to participants who perform verifiable, valuable work for the network. Work is weighted by a credibility scalar derived from unforgeable FID age (anchored to Optimism transfer events), social graph position, and interaction diversity. Nodes must be associated with FIDs via attestation, creating accountability. The system avoids hashcash-style proof of work in favor of protocol-native work definitions that align incentives with network health.

Depends on: Hyper Validator Selection (epoch system, validator registration), Proof of Quality (trust scores, identity weighting).

1. Motivation

Why Tokenize

Farcaster currently relies on storage rent (payments on optimism) to prevent spam. This model has limitations:

• No ongoing incentive: Storage rent is a recurring cost, but only funds the developers of Farcaster Classic, not node operators. Node operators bear continuous infrastructure costs with no continuous revenue stream. As the network scales, the gap between operating cost and revenue widens, which has lead to the corporate ownership of the previous snapchain architecture (Farcaster Classic).
• No growth incentive: Nobody is directly rewarded for growing the network's user base or application ecosystem. Growth could happen despite the protocol, not because of it, but in either case, has been on a downward trajectory since the end of 2025.
• Validator concentration: Without economic incentives or permissionless validator membership, validator operation is philanthropic or strategic. This concentrates validators among well-funded entities and limits decentralization.
• No application incentive: Miniapp and client developers build on Farcaster for distribution, not protocol rewards. A token could directly incentivize ecosystem development.

Why Proof of Work (Non-Hashcash)

Traditional PoW (SHA256 grinding) wastes energy to demonstrate a commitment of hardware to participating in consensus. We have greater flexibility to define work. "Work" means actions that directly benefit the network:

1. Data Availability work: Keeping the chain's data accessible and serving it reliably
2. Growth work: Bringing genuinely valuable new participants into the network
3. Application work: Building applications that generate credible, sustained usage

Each work type produces verifiable proofs that validators can check deterministically.

Why FID-Anchored Identity

Every mechanism depends on a credibility scalar per participant. Without it, sybil attacks trivially drain emission. FIDs — registered on Optimism via IdRegister events — provide an unforgeable identity anchor already in place, which we can use as a launch point:

• Registration timestamp: The block_timestamp on the IdRegister event is immutable on L2
• Transfer events: ID_REGISTER_EVENT_TYPE_TRANSFER records custody changes. Using the last transfer timestamp as effective account birthday prevents gaming via purchasing old FIDs
• On-chain anchoring: FID age cannot be forged without rewriting Optimism history

2. FID Age Calculation

Effective Age

effective_age(fid) = now - last_custody_change_timestamp(fid)

Where:

last_custody_change_timestamp(fid) =
    if has_transfer_events(fid):
        max(block_timestamp for all ID_REGISTER_EVENT_TYPE_TRANSFER events for fid)
    else:
        block_timestamp of ID_REGISTER_EVENT_TYPE_REGISTER event for fid

Implementation

The on-chain event store already indexes IdRegisterEventBody per FID. Computing effective age requires scanning the FID's IdRegister events (typically 1-3 events) and taking the most recent transfer timestamp, falling back to the registration timestamp if no transfers exist.

fn effective_age(fid: u64, onchain_store: &OnchainEventStore, now: u64) -> u64 {
    let events = onchain_store.get_id_register_events_by_fid(fid);
    let last_transfer = events.iter()
        .filter(|e| e.id_register_event_body.event_type == IdRegisterEventType::Transfer)
        .map(|e| e.block_timestamp)
        .max();

    let base_timestamp = last_transfer.unwrap_or_else(|| {
        events.iter()
            .filter(|e| e.id_register_event_body.event_type == IdRegisterEventType::Register)
            .map(|e| e.block_timestamp)
            .next()
            .unwrap_or(now) // No registration found → age 0
    });

    now.saturating_sub(base_timestamp)
}

Age Factor

age_factor(fid) = min(1.0, effective_age(fid) / AGE_MATURITY_SECONDS)

Where AGE_MATURITY_SECONDS = 15,552,000 (180 days). Accounts younger than 6 months receive proportionally reduced weight in all reward calculations.

Anti-Gaming Properties

3. Node-FID Attestation

Requirement

Every node participating in work markets must be associated with exactly one FID. This creates accountability: if a node misbehaves, the FID's credibility and rewards are affected.

Attestation Mechanism

A new HyperMessage type for node-FID binding:

enum HyperMessageType {
  // ... existing types ...
  HYPER_MESSAGE_TYPE_NODE_ATTESTATION = 130;
  HYPER_MESSAGE_TYPE_NODE_ATTESTATION_REVOKE = 131;
}

message NodeAttestationBody {
  bytes node_public_key = 1;    // Ed25519 public key of the node (same as validator key)
  bytes node_signature = 2;     // Node signs the FID to prove key possession
}

Validation:

• The HyperMessage is signed by the FID's signer (proving FID ownership)
• node_signature is verified against node_public_key over the FID bytes (proving node key possession)
• One FID can attest to at most MAX_NODES_PER_FID nodes (default: 3)
• One node key can be attested by at most 1 FID

Storage:

[RootPrefix::NodeAttestation] ++ [node_public_key] -> NodeAttestationState { fid, attested_at }
[RootPrefix::NodeAttestationByFid] ++ [fid_bytes] ++ [node_public_key] -> 1

4. Epoch-Based Consensus Membership

Current State

Validator sets are currently static and config-based. StoredValidatorSets holds a list of StoredValidatorSet entries, each with an effective_at height and a list of validator public keys. The get_validator_set(height) method returns the most recent set where effective_at <= height. Transitions are pre-planned in TOML config — there is no runtime mechanism for validators to join, leave, or for the network to react to membership changes.

This is insufficient for a tokenized protocol because:

1. No dynamic entry: New validators can't join without a coordinated config push to all existing validators
2. No graceful exit: A validator that goes offline causes consensus degradation with no advance warning
3. No DA awareness: When a node leaves, the data it was responsible for serving becomes less available. Other nodes need advance notice to replicate and rebalance
4. No accountability: Without on-chain registration, there's nothing to slash or reward

Migration: Activating Epoch-Based Membership on a Live Network

The existing consensus set is live and producing blocks using config-based ValidatorSetConfig entries with effective_at heights. The migration to epoch-based membership must be a coordinated cutover that all validators agree on.

Activation Mechanism

Two coordinated gates, one for each domain:

1. EngineVersion gate (ProtocolFeature::EpochBasedMembership): A new EngineVersion (e.g., V16) activated at a specific FarcasterTime timestamp via the existing VersionSchedule. This gates the code path — nodes running the new binary know to use epoch-based logic after this timestamp. Nodes running old binaries ignore epoch registration messages.

2. Block height anchor (EPOCH_GENESIS_HEIGHT): The block height at which epoch 0 begins. This must be a height that will occur after the EngineVersion activation timestamp, giving all validators time to upgrade. Epoch numbers are computed relative to this anchor:

epoch(height) = if height < EPOCH_GENESIS_HEIGHT: BOOTSTRAP_EPOCH
                else: (height - EPOCH_GENESIS_HEIGHT) / EPOCH_LENGTH

Where BOOTSTRAP_EPOCH is a sentinel value meaning "use config-based validator sets."

Cutover Timeline

The cutover window is compressed to ~48 hours. The current network is small enough that coordinated validator upgrade, engine-version activation, and the genesis block can all land within two days. The expensive retroactive scoring computation runs once at EPOCH_GENESIS_HEIGHT as part of normal epoch-boundary processing.

T = 0     Binary release. Validators begin upgrading.
          Binary contains:
            - EpochBasedMembership feature gated by EngineVersion V16
            - EngineVersion V16 timestamp ≈ T + 24h
            - EPOCH_GENESIS_HEIGHT baked in, expected ≈ T + 36-48h
          Epoch logic is dormant in all running binaries until V16 fires.

T + ~24h  EngineVersion V16 activates (timestamp-based).
          Validators that are still on the old binary stop participating
          in consensus correctly; they MUST upgrade before this point.
          Nodes begin accepting VALIDATOR_REGISTER / VALIDATOR_DEREGISTER
          HyperMessages. Epoch logic is armed but not yet anchored.

T + ~36-48h  Block reaches EPOCH_GENESIS_HEIGHT. Epoch 0 begins.
          As part of epoch-0 boundary processing, the proposer:
            1. Snapshots the active config-based validator set as the
               epoch-0 bootstrap set (Section "Bootstrap Set Seeding").
            2. Runs PoQ (Section 8): trust scores, eligibility, credibility.
            3. Runs the retroactive distribution computation (Section 10).
            4. Commits the per-FID retroactive allocation records to the trie.
            5. Distributes the first tranche of each FID's allocation
               directly to their token balance (Section 10.5). Subsequent
               tranches vest at each epoch boundary thereafter.
          Dynamic registration/deregistration becomes possible.

T + ~36-48h + 2 epochs
          First epoch where dynamically registered validators can activate.

This timeline assumes coordinated validator upgrade. Validators must subscribe to the binary release ahead of T, run the upgraded binary on or before T, and stay online through the genesis epoch. With the active validator set in the low-double-digits at the time of writing, this is operationally feasible within two days; later networks with larger validator sets may need a longer window.

Bootstrap Set Seeding

At EPOCH_GENESIS_HEIGHT, the system must seed the hyper trie with the currently active config-based validator set:

fn seed_bootstrap_validators(
    &mut self,
    height: u64,
    config_validators: &SnapchainValidatorSet,
) {
    // Write each config validator as a "registration" event at epoch 0
    for validator in config_validators.validators() {
        let event = HyperValidatorEventBody {
            validator_key: validator.public_key.to_bytes(),
            registration_epoch: 0,
            ..Default::default()
        };
        self.hyper_trie.insert(
            &validator_event_key(&validator.public_key, 0),
            &event.encode_to_vec(),
        );
    }

    // Compute and store the epoch 0 validator set
    self.store_epoch_validator_set(0, config_validators);
}

This is a one-time operation that runs exactly once when height == EPOCH_GENESIS_HEIGHT. After this, the config-based validator_sets entries in TOML are no longer used for consensus — the hyper trie is the source of truth.

Validator Set Resolution After Cutover

The get_validator_set(height) call path changes:

pub fn get_validator_set(&self, height: u64) -> SnapchainValidatorSet {
    if height < EPOCH_GENESIS_HEIGHT {
        // Pre-cutover: use static config (existing behavior)
        self.config_validator_sets.get_validator_set(height)
    } else {
        // Post-cutover: use epoch-based set from hyper trie
        let epoch = (height - EPOCH_GENESIS_HEIGHT) / EPOCH_LENGTH;
        self.get_validator_set_for_epoch(epoch)
    }
}

This preserves backward compatibility: historical blocks before the cutover still validate against the config-based sets. New blocks use the dynamic epoch system.

Rollback Safety

If the cutover causes consensus issues:

• A new binary can be shipped with EPOCH_GENESIS_HEIGHT pushed further into the future
• All validators revert to config-based sets automatically (the height < EPOCH_GENESIS_HEIGHT branch)
• Any epoch registrations submitted between the old and new genesis heights become orphaned (harmless — they'll be re-submitted after the new genesis)

Configuration

[consensus]
# Existing config-based validator sets remain (used pre-cutover and as bootstrap)
validator_sets = [...]

# New: epoch activation height (must be coordinated across all validators)
epoch_genesis_height = 30_000_000   # Example — set to a future height

# New: epoch length (36,000 blocks × 12s = ~5 days)
epoch_length = 36_000

The epoch_genesis_height value is baked into the binary release, not truly configurable per-node — all nodes must agree. It appears in config for transparency and for testnet overrides.

Design: Three-Phase Epoch Transitions

Replace config-based validator sets with a dynamic, epoch-based system where membership changes are announced, buffered, and applied with enough lead time for DA rebalancing.

4.1 Block Time Change: 12-Second Blocks

The epoch activation at EPOCH_GENESIS_HEIGHT also increases the block time from the current cadence to 12 seconds. This is a deliberate coupling — the epoch system and the block time change activate atomically at the same height because:

• Epoch math depends on stable block time: EPOCH_LENGTH in blocks must map to a predictable wall-clock duration. Changing block time after epoch activation would invalidate all epoch timing assumptions.
• Consensus parameter changes must be coordinated: The same binary upgrade that introduces epoch logic also ships the new consensus timeouts. Activating both at the same height avoids a second coordinated upgrade.
• Validator economics improve: 12-second blocks reduce consensus overhead by 4x (vs 3s) or 12x (vs 1s), making it more economically viable to run a validator — critical if we're tokenizing validator rewards.

Consensus parameters at activation:

These parameters switch when height >= EPOCH_GENESIS_HEIGHT, using the same EngineVersion gate that activates epoch logic. The next_height_delay() method already computes wait time dynamically — it will naturally target the new 12-second cadence once the parameters change.

Finality: Happy-path finality at 12-second blocks is ~4-5 seconds (propose + vote rounds complete well before the block interval). For a social protocol, this is imperceptible, and clients running hypersnap nodes can surface mempool data as it appears since it is validated prior to block inclusion.

Throughput: max_messages_per_block = 12,000 at 1 block per 12 seconds = 1,000 messages/second/shard — same throughput ceiling as 1,000 messages/block at 1 block/second.

4.2 Epoch Constants

EPOCH_LENGTH = 36,000 blocks (~5 days at 12s block time)
ANNOUNCEMENT_BUFFER = 1 epoch  — changes announced in epoch N take effect at epoch N+2
REBALANCE_WINDOW = 3,600 blocks (~12 hours) — time before epoch boundary for DA rebalancing

Note: epoch constants are calibrated for 12-second blocks. 36,000 blocks × 12 seconds = 432,000 seconds ≈ 5 days.

The two-epoch buffer (announce in N, prepare in N+1, activate in N+2) gives the network a full epoch to observe, replicate, and prepare.

4.3 Transition Phases

Epoch N          Epoch N+1               Epoch N+2
|----------------|------------------------|------------------
 Validator V     ANNOUNCED: V leaving     V REMOVED
 announces       at epoch N+2.            from active set.
 departure.
                 REBALANCE_WINDOW starts  All peers have
                 12h before N+2 boundary. V's data replicated.
                 Peers begin replicating
                 V's shard data.

For a validator joining:

Epoch N          Epoch N+1               Epoch N+2
|----------------|------------------------|------------------
 New validator W  W's registration is      W ADDED to active
 submits          known. Peers expect W    set. W begins
 registration.    at N+2.                  participating in
                                           consensus.
                  W syncs shard data
                  during N+1 (standard
                  bootstrap/replication).

4.4 Registration and Deregistration Messages

Reuses the HyperMessage types from the Hyper Validator Selection FIP:

enum HyperMessageType {
  HYPER_MESSAGE_TYPE_VALIDATOR_REGISTER = 102;
  HYPER_MESSAGE_TYPE_VALIDATOR_DEREGISTER = 103;
}

message HyperValidatorEventBody {
  bytes validator_key = 1;        // Ed25519 public key (32 bytes)
  uint64 registration_epoch = 2;  // Must match current epoch
  bytes operator_address = 3;     // Optional operator
  uint64 fid = 4;                 // FID associated with this node (from Node-FID Attestation)
}

Validation rules:

• validator_key must have a valid NodeAttestation binding to a FID (Section 3)
• The FID must meet minimum credibility requirements: age_factor >= 0.5 (90+ days old)
• registration_epoch must equal the current epoch (prevents replay)
• For registration: must not already be in active or pending set
• For deregistration: must currently be in active set
• Submitter must prove key possession (sign the message with the validator key)

4.5 DA Rebalancing on Membership Change

When a node announces departure (or fails to respond and is auto-deregistered), its shard data must remain available.

Current architecture context: All validators store all shards (gossip is global, not shard-partitioned). So "rebalancing" doesn't mean moving shard ownership — it means ensuring the departing node's data has been fully replicated before it leaves.

For the current global-gossip architecture:

The concern is simpler than in a sharded-storage model. Since all nodes receive all decided values via gossip, a node leaving doesn't create a DA gap for validators — they already have the data. The gap is for read nodes that may have been relying on the departing node for sync/replication.

The rebalancing protocol:

1. Departure announced (epoch N): VALIDATOR_DEREGISTER message is included in a hyper block. All nodes learn that validator V is leaving at epoch N+2.

2. Rebalance window opens (REBALANCE_WINDOW blocks before epoch N+2 boundary):

   • The departing validator is flagged as DEPARTING in the validator set state
   • Read nodes that were syncing from V should discover alternative sync sources
   • A new gossip message type announces the transition:

   message ValidatorTransitionAlert {
     bytes validator_key = 1;
     uint64 effective_epoch = 2;     // When this takes effect
     TransitionType transition = 3;
     uint64 alert_block = 4;         // Block at which this alert was generated
   }
   
   enum TransitionType {
     TRANSITION_NONE = 0;
     TRANSITION_DEPARTING = 1;
     TRANSITION_JOINING = 2;
   }

3. Epoch N+2 boundary: V is removed from the active validator set. Consensus continues with the remaining validators. If V was a read node sync source, peers have had ~12 hours to switch.

For a future shard-partitioned architecture (where nodes only store assigned shards):

Rebalancing becomes much more involved:

1. Shard reassignment computed at epoch N+1: Given the new validator set (minus V, plus any new joiners), recompute shard-to-validator assignments using consistent hashing:

   shard_assignment(shard_id, validator_set) =
       validators sorted by SHA256(validator_key ++ shard_id)
       take first REPLICATION_FACTOR validators
   

2. Data migration during rebalance window: Validators newly assigned to a shard they don't currently hold must sync that shard's data from existing holders. This uses the existing replication RPC (SyncService).

3. Migration completeness proof: Before the epoch boundary, each validator must confirm it holds all assigned shard data by publishing a signed attestation:

   message ShardReadyAttestation {
     bytes validator_key = 1;
     uint32 shard_id = 2;
     uint64 epoch = 3;
     bytes state_root = 4;           // Trie root hash of the shard data
     bytes signature = 5;
   }

4. Fallback: If migration is incomplete at the epoch boundary, the old assignment persists for that shard until the next epoch. The departing validator's data responsibility extends by one epoch. This is announced via ValidatorTransitionAlert with a TRANSITION_DELAYED type.

4.6 Auto-Deregistration (Involuntary Departure)

A validator that misses AUTO_DEREGISTER_THRESHOLD consecutive proposals (default: 100) is automatically deregistered. This triggers the same rebalancing flow as voluntary departure, but with compressed timing:

• Auto-deregistration is recorded in the hyper block that detects the threshold breach
• The standard 2-epoch buffer still applies (the node might recover)
• If the node recovers and re-registers within the buffer, the deregistration is cancelled

For sudden failures (node crashes without deregistering):

• The node stops voting. Other validators notice via missed commit signatures.
• After AUTO_DEREGISTER_THRESHOLD missed proposals, auto-deregistration fires
• BFT consensus tolerates f < n/3 failures. As long as the failure doesn't breach this threshold, consensus continues normally during the buffer period
• The 2-epoch buffer gives the operator time to recover the node. If they don't, the node is removed and the set contracts.

4.7 Minimum Validator Set Size

The active validator set must never drop below MIN_VALIDATORS (default: 3). If a deregistration would breach this:

• The deregistration is rejected (for voluntary departures)
• For auto-deregistration: the validator is flagged as INACTIVE but remains in the set. An alert is broadcast urging new validators to register.

4.8 Integration with StoredValidatorSets

The existing StoredValidatorSets / get_validator_set(height) interface remains, but the backing data changes from config to hyper trie state:

impl StoredValidatorSets {
    /// Static config-based lookup (current behavior, used for bootstrap epochs 0-1)
    pub fn get_validator_set(&self, height: u64) -> SnapchainValidatorSet { ... }

    /// Dynamic epoch-based lookup (new, used for epoch >= 2)
    pub fn get_validator_set_for_epoch(&self, epoch: u64) -> SnapchainValidatorSet {
        // Read from hyper trie: [RootPrefix::HyperValidatorSet] ++ [epoch]
        // Falls back to bootstrap set for epoch 0-1
    }
}

The ShardValidator calls get_validator_set(height) on every start_round(). This method would compute the epoch from the height and delegate to get_validator_set_for_epoch():

pub fn get_validator_set(&self, height: u64) -> SnapchainValidatorSet {
    let epoch = height / EPOCH_LENGTH;
    if epoch < 2 {
        // Bootstrap: use static config
        self.validator_sets.get_validator_set(height)
    } else {
        // Dynamic: use epoch-computed set from hyper trie
        self.validator_sets.get_validator_set_for_epoch(epoch)
    }
}

4.9 Gossip Implications

Current gossip is global (all topics go to all peers). With epoch-based membership:

• New membership gossip topic: Carries ValidatorTransitionAlert messages so all peers (including read nodes) learn about impending changes
• Peer scoring: Validators in DEPARTING state should not be penalized for reduced participation during the rebalance window (they're winding down gracefully)
• Peer discovery: The contact-info topic should include the validator's epoch registration info so new peers can verify membership

4.10 New Proto Additions for Epoch Membership

4.11 New RootPrefix Values for Epoch Membership

pub enum RootPrefix {
    // ... existing values ...
    HyperValidatorEvent = 25,      // From Hyper Validator Selection FIP
    HyperValidatorSet = 26,        // Per-epoch computed validator sets
    HyperValidatorScore = 27,      // From Hyper Validator Selection FIP
    ValidatorTransition = 28,      // Pending transitions (join/leave) per epoch
}

5. Work Market 1: Data Availability (DA-PoW)

Purpose

Reward nodes for keeping the chain's data accessible and serving it reliably. This is the anchor of the token's value — without DA, the protocol is useless.

Mechanism

5.1 Challenge-Response Proofs

Each epoch, the hyper block proposer generates data availability challenges for participating nodes using on-chain randomness:

challenge_seed = SHA256(block_hash(epoch_boundary) ++ epoch_number ++ challenge_index)

From the seed, derive:

• Target shard: shard_id = seed[0..2] % num_shards
• Target message: message_key = seed[2..18] (used to select a message by trie key prefix)
• Response deadline: deadline = current_block + CHALLENGE_RESPONSE_WINDOW (default: 25 blocks ≈ 5 minutes at 12s blocks)

5.2 Proof Structure

A valid DA proof contains:

• Verkle inclusion proof for the challenged message in the shard's trie
• The message bytes themselves
• Timestamp of proof submission

5.3 Continuous vs. Epoch-Based

Challenges must prevent precomputation and outsourcing to cold storage. Two approaches exist, with different overhead profiles:

Continuous challenges interact in real-time but create significant overhead:

• Each challenge requires gossip of the challenge, gossip of the proof, and validation by all nodes
• At N participating nodes with C challenges per epoch, this is N×C additional gossip messages
• Challenge-response requires nodes to be online with hot storage — but this is already required by the existing gossip protocol. A node that's offline misses blocks regardless.

Epoch-based challenges use short response windows and achieve the same guarantees with far less overhead. All challenges are generated at epoch start from the epoch boundary block hash (unpredictable beforehand), with responses required within a tight window (5 minutes):

• Challenges are unpredictable (derived from future block hash)
• Response window is short enough that cold-storage retrieval is impractical
• One batch of challenges per epoch vs. continuous challenge generation

5.4 Reward Signal

da_score(node, epoch) = (challenges_answered / challenges_issued)
                        × latency_factor
                        × uptime_factor

Where:

• latency_factor = 1.0 - (avg_response_blocks / CHALLENGE_RESPONSE_WINDOW) — faster responses score higher
• uptime_factor = blocks_participated / total_blocks_in_epoch — measured by commit signatures (for validators) or heartbeat messages (for read nodes)

6. Work Market 2: Growth (Social PoW)

Purpose

Reward participants who increase the valuable social graph — measured by sustained mutual engagement with credible counterparties. Growth is structural, not referral-based: the reward flows to FIDs whose ongoing reciprocal interactions with high-trust users contribute to graph health, regardless of when those interactions occurred.

6.1 Algorithm

Each epoch, the Growth pool is distributed in proportion to a per-FID composite score computed from the post-transfer engagement graph. The score is the same one used by retroactive distribution (Section 10) — there is no separate "first-30-days" or "onboarding-window" model.

growth_score(f) =
    Σ over u where:
        - u and f have reciprocal post-transfer engagement, AND
        - trust(u) ≥ CREDITER_TRUST_FLOOR
    of:
        ln(1 + mutuality(count(f → u), count(u → f))) · credibility(u)

Where:

• count(a → b) is the count of post-transfer events (replies / mentions / reactions to b's casts; follows of b) where the timestamp is post-transfer for both a and b. See Section 8.1.
• mutuality(a, b) is the protocol's reciprocity-aggregating function. The protocol-default is sum: a + b, gated on both > 0. (Alternative shapes — min(a,b), √(a · b), 2ab/(a+b) — were evaluated empirically; see MUTUALITY_FUNCTION in Section 15. sum was chosen as the most prolific-friendly option that still requires reciprocity, since the per-pair contribution is then capped by ln(1 + a + b) saturation rather than by an asymmetry-penalty term.)
• ln(1 + …) saturates per-pair contribution. A pair with 1000 interactions contributes ~ln(1001) = 6.9, not 1000. Volume spam cannot dominate sustained genuine relationships.
• CREDITER_TRUST_FLOOR is a hard threshold: only crediters with trust_score ≥ floor contribute. Calibrated as the THRESHOLD_PERCENTILE of trust over the calibration cohort (Section 8.3). Sybil-ring sockpuppets at the EigenTrust noise floor sit below this threshold and contribute zero, regardless of their volume.
• credibility(u) is per Section 8.4.

6.2 Composite Score and Pool Allocation

composite(f) = credibility(f) · growth_score(f)

Each epoch, the Growth pool is distributed proportional to composite over eligible FIDs (Section 8.3 filters):

emission(f, epoch) = composite(f) / Σ composite(eligible f') · GROWTH_EMISSION_POOL(epoch)

Where GROWTH_EMISSION_POOL(epoch) is the per-epoch share of total emission allocated to Growth PoW (Section 9).

6.3 Why This Algorithm

Three failure modes drove every design choice:

1. Volume-spam dominates linear scoring. A bot replying 1000 times to a popular cast accumulates 100× a real conversation's count. ln(1+x) saturation makes this 2.9× instead of 100×, removing the volume advantage.
2. Sybil rings can self-bootstrap entropy and activity metrics. Coordinated sockpuppets interact with each other and accumulate signals that look "diverse." The CREDITER_TRUST_FLOOR requires non-trivial trust on the crediter side, and trust comes from EigenTrust seeded outside the ring — sockpuppets land below the floor.
3. First-30-days windows are gameable by accounts placed in onboarding flows. The previous formulation gave outsized weight to interactions during a new user's first 30 days, which auto-follow lists and reply-to-popular-account patterns trivially exploited. The current formulation counts all post-transfer time symmetrically: sustained relationships and dormant-then-reactivated patterns both contribute proportionally to their actual engagement.

6.4 Anti-Farm: Reward Maintenance, Not Referral

Growth PoW does not reward "who invited the user." It rewards "who maintains a reciprocal, high-credibility relationship with credible users." Mutuality encodes the reciprocity requirement; credibility(u) and CREDITER_TRUST_FLOOR together encode quality.

This is a structural departure from the original first-30-days maintenance model. That model rewarded "interactions during the invitee's onboarding" and was systematically gameable: any account positioned to be auto-followed by new users (default-follow lists, reply-to-popular-accounts visibility) accumulated rewards from onboarding-window interactions regardless of whether those interactions reflected real value-add. The current model:

• Counts all post-transfer time symmetrically.
• An account that maintained quality relationships across years contributes proportionally to one that's done so for months.
• A dormant-then-reactivated account contributes again when re-engaged; its previous-life graph position is filtered out by the post-transfer clause if a transfer occurred, otherwise carries forward naturally.

6.5 Eligibility Gate

A FID receives zero Growth emission in an epoch where they fail any of the eligibility filters in Section 8.3. The filters apply to the FID themselves, not to their crediters; crediter quality is handled inside the growth_score formula by CREDITER_TRUST_FLOOR.

6.6 Risks and Mitigations

7. Work Market 3: Application / Usage PoW

Purpose

Reward miniapp developers whose applications generate credible, sustained usage by real users.

7.1 Work Definition

Work = generating credible usage, defined as:

app_work(app, epoch) = sum over all interactions(w_user × action_weight)

Where:

• w_user = credibility score of the interacting user (from Proof of Quality trust score × FID age factor)
• action_weight = weight for the action type (see below)

7.2 Proof Model

Each miniapp interaction that occurs through the protocol produces a verifiable record:

The protocol can only reward actions it can verify. Off-protocol app usage (clicks, sessions, time-on-page) is not verifiable by consensus and must be excluded.

7.3 Signed Receipt Model

For in-app actions beyond casts and adds, apps can submit signed receipts:

message AppUsageReceipt {
  bytes miniapp_id = 1;       // 16-byte miniapp ID
  uint64 user_fid = 2;        // FID of the user
  string action_type = 3;     // App-defined action label
  uint64 timestamp = 4;       // Farcaster timestamp
  bytes user_signature = 5;   // User's signer signs the receipt
}

The user's signature prevents apps from fabricating usage. The user must have actually interacted for the receipt to be valid.

7.4 Reward Function

reward(app, epoch) = min(
    app_work(app, epoch) / total_app_work(epoch) × APP_EMISSION_POOL,
    MAX_APP_REWARD_PER_EPOCH
)

The cap prevents a single dominant app from capturing the entire pool.

7.5 Cross-Validation

Apps must NOT self-report freely. All usage claims are validated:

1. Protocol-level actions (casts, adds): Verified by checking message existence in the trie. Deterministic — all validators agree.
2. Signed receipts: Verified by checking user signature validity and FID existence. The receipt must be submitted as a HyperMessage and included in a hyper block.
3. Rate limiting: A single user can generate at most MAX_RECEIPTS_PER_APP_PER_EPOCH (default: 100) receipts per app per epoch. Prevents click-farming.

7.6 Risks

8. Proof of Quality and Identity Weighting

This section defines two foundational primitives used by every work market in this FIP:

1. Trust score — a per-FID number in [0, 1] derived from the protocol-native social graph by Proof of Quality (PoQ).
2. Credibility scalar — a weighted combination of trust score, age, and activity-diversity metrics that multiplies per-user contributions throughout reward and fee computations.

This section supersedes the trust-score algorithm specified in the proof of quality FIP. References to "PoQ" anywhere else in this FIP refer to the definitions below.

8.1 Effective Age and the Post-Transfer Filter

effective_age is defined in Section 2: time since the most recent ID_REGISTER_EVENT_TYPE_TRANSFER event, falling back to the original Register event timestamp. Transfers reset effective age to zero. age_factor = min(1.0, effective_age / 180 days).

Every protocol event used by PoQ — casts, replies, mentions, reactions, follows — is filtered at use time by:

event with timestamp ts attributed between FIDs (a, b) is counted only if
    ts > max(a.effective_ts, b.effective_ts)

For one-sided metrics (e.g. an FID's own cast count), only that FID's effective_ts applies. This makes every PoQ input custody-aware: a newly-transferred FID neither inherits nor counts engagement attributable to the previous custodian.

8.2 Trust Score (PoQ)

Trust score is computed by EigenTrust over the post-transfer follow graph, seeded on a fixed cohort of early users.

8.2.1 Seed Cohort

The seed set is the set of FIDs with fid ≤ SEED_MAX_FID, where SEED_MAX_FID = 50_000 is a fixed protocol constant, not a configurable parameter. This corresponds to the cohort of users hand-onboarded during the protocol's bootstrap phase.

The constant is fixed because it encodes a historical fact about who the trusted bootstrap users were. Tuning it later would alter the trust foundation of the network. The 50_000 figure was chosen because:

• It captures the empirical hand-onboarded user base.
• Aggregating trust across enough seeds bounds the influence of any single seed (including any individual seed that may have been transferred or compromised).
• It is independent of any timestamp, so the OP Mainnet contract migration — which reset effective-age signals for older FIDs — does not affect seed selection.

Seed status alone does not grant high trust score; a seed contributes the seed weight 1 / SEED_MAX_FID as its EigenTrust starting mass. A seed with no incoming follows propagates no further trust than that.

8.2.2 EigenTrust Propagation

seed(i)        = 1 / SEED_MAX_FID  if  i ≤ SEED_MAX_FID
                 0                  otherwise

t₀(i)          = seed(i)

t_{n+1}(i)     = (1 − d) · seed(i)
               + d · Σⱼ ( t_n(j) · 1_{j follows i (post-transfer)}
                          / out_degree_post_transfer(j) )

where d = EIGENTRUST_DAMPING (default 0.85)

Iterate until L1 change Σ |t_{n+1}(i) − t_n(i)| < EIGENTRUST_CONVERGENCE_TOLERANCE (default 1e-6) or EIGENTRUST_MAX_ITERATIONS (default 50) is reached.

The follow graph is filtered per Section 8.1: a follow edge j → i contributes only when its followed_at is post-transfer for both j and i.

8.2.3 Normalization

The raw EigenTrust mass distribution is power-law: a small number of heavily-followed accounts hold most of the mass, while most non-zero values are at the noise floor. Normalizing by a percentile such as p99 lands at the long tail, saturating any FID above that to 1.0 — including spammers with barely-above-noise EigenTrust mass.

Instead, normalize by the average of the top EIGENTRUST_NORM_TOP_N raw values (default 100):

trust_norm     = average of top N raw EigenTrust values

trust_score(i) = clamp(
                     raw_eigentrust(i) / trust_norm × age_factor(i),
                     0,
                     1
                 )

This anchors trust_score = 1.0 to the actually-trusted top of the distribution. A spammer at the noise floor lands at trust_score ≈ raw / top_avg ≈ 0.001 × age_factor, near zero. Real top-tier users saturate to 1.0. Mid-tier users land at meaningful intermediate values.

The age_factor multiplier ensures young accounts cannot leverage incoming-follow gaming alone — they must also have age.

8.3 Eligibility Classifier

PoQ provides a binary eligibility signal — "is this FID an authentic active user?" — used by reward distribution mechanisms to gate allocation. Eligibility is determined by algorithmic filters on protocol-native data:

"Data-derived" thresholds (F3, F4, F5, F6) are computed at the THRESHOLD_PERCENTILE (default 0.10, or 1 − 0.10 = 0.90 for the upper-tail F5) of the metric's distribution over the calibration cohort:

calibration cohort = { fid : total_casts ≥ CALIBRATION_MIN_CASTS  (default 10)
                       AND active_days ≥ CALIBRATION_MIN_ACTIVE_DAYS (default 5) }

The calibration cohort is distinct from the seed cohort: the seed is the trust foundation (small, top-tier); calibration is "typical active user" (broader, representative). Calibrating filter thresholds against the seed alone is too strict — top-1% behavior excludes most legitimate users. Calibrating over all FIDs is too permissive — the bulk of the graph is bots. The two-cohort split serves both ends.

Eligibility = passes all enabled filters. F4 is optional, off by default.

8.4 Credibility Scalar

The credibility scalar combines PoQ outputs with activity-diversity signals:

credibility(fid) = 0.25 · age_factor
                 + 0.35 · trust_score
                 + 0.20 · interaction_entropy
                 + 0.10 · stake_factor
                 + 0.10 · client_diversity

Components:

8.5 Compute Cadence

PoQ trust scores and eligibility flags are recomputed once per epoch under consensus. The proposer of the first hyper block of each epoch executes PoQ, produces per-FID trust scores and eligibility, and commits them to the hyper trie:

[RootPrefix::TrustScore]   ++ [fid_be_bytes] → u16  (0–10000 representing 0.0–1.0000)
[RootPrefix::Eligibility]  ++ [fid_be_bytes] → u8   (bit-packed F0–F6 flags)

Other validators verify by re-running PoQ against the same trie state (deterministic).

8.6 Supersession of FIP-proof-of-quality.md

This section supersedes the trust-score algorithm specified in FIP-proof-of-quality.md. The earlier specification:

• Used a small seed of "verified Ethereum address holders," introducing an external-chain dependency the protocol cannot verify under consensus.
• Used 99th-percentile normalization, which saturated everyone above the long tail to trust_score = 1.0 — including spammers with noise-floor EigenTrust mass.
• Specified a spectral-clustering sybil-ring penalty that, in practice, is unnecessary: the structural sybil signal is already captured by the EigenTrust distribution itself when normalization correctly anchors to the top of the distribution. Sybil rings have no inbound seed-traceable trust and land at the noise floor.

This revision uses only protocol-native data (FID number for the seed, post-transfer follow graph for propagation, top-N average for normalization) and is robust against the failure modes that motivated the earlier specification.

8.7 Design Principles

• Custody-aware everywhere. Every input excludes activity attributable to a previous custodian. There is no path to inheriting a previous owner's score by acquiring an FID.
• No external chain reads. PoQ uses only IdRegister events that the on-chain event watcher already commits to protocol state. No live RPC dependencies.
• No labels. PoQ's trust signal is structural — derived from the seed cohort and graph topology, not from any human or organization labeling FIDs.
• Trust dominates within credibility. With weight 0.35, trust is the largest single contributor. Real-user trust spans roughly 0.3–1.0; ring members sit at < 0.05. Trust alone produces ~10× credibility gap.
• No single factor dominates. Even a maximally old account with perfect trust but zero interaction entropy scores at most 0.70. Multi-factor composition prevents single-vector gaming.

9. Emission Schedule

Total Supply

Fixed total supply: TOTAL_SUPPLY tokens, minted over a multi-year schedule.

Emission Curve

Halving every 2 years (matching Bitcoin's proven model for predictable supply):

emission_per_epoch(epoch) = INITIAL_EPOCH_EMISSION × 0.5^(epoch / EPOCHS_PER_HALVING)

Where:

• INITIAL_EPOCH_EMISSION: Calibrated such that Year 1 mints 25% of total supply
• EPOCHS_PER_HALVING: Number of epochs in 2 years

Distribution Split

10. Retroactive Genesis Distribution

Principle

The protocol does not begin at token genesis — the network has been running, and participants have been performing real work, since before any token existed. FIDs were registered. Casts were posted. Replies were written. Social graphs were built. Applications were developed and used. Nodes served data.

The retroactive genesis distribution recognizes this prior work by applying the same algorithm as forward Growth PoW (Section 6) to the full historical interaction graph. There is no separate retroactive scoring function and no per-pattern "retroactive corrections" — what would have been earned epoch-by-epoch had Section 6 been live since the protocol's first cast is what gets paid out at genesis. There is no special allocation, no team carve-out, no preference. The computation is deterministic, runs under consensus, and produces the same result on every validator.

10.1 Scope

At EPOCH_GENESIS_HEIGHT, validators execute a one-time retroactive scoring pass over all historical data using the same algorithm as forward Growth PoW (Section 6). There is no separate retroactive scoring function and no "retroactive corrections" — the algorithm is the same. The retroactive distribution is what would have been earned had Section 6 been running per-epoch since the protocol's first cast.

Retroactive distribution rewards user growth contribution only. Other work markets are excluded:

• DA-PoW is excluded because Farcaster Classic did not have the DA challenge infrastructure; there is no historical DA work to measure.
• Application PoW is excluded because the historical distribution of app-side work is firmly disproportionate. A small number of clients and channels captured the overwhelming majority of protocol-verifiable usage — not because of comparative merit, but because of default custodial signer arrangements, first-mover bundling, and onboarding-funnel placement. Rewarding that distribution would codify an outcome that later entrants could not have earned under the same rules. Forward-looking Application PoW (Section 7) continues to exist; it simply does not apply retroactively.

10.2 Algorithm

The retroactive computation is a direct application of Section 6 over the full history. For each FID:

1. Compute trust_score per Section 8.2 (EigenTrust seeded on fid ≤ SEED_MAX_FID = 50_000, propagated through the post-transfer follow graph, normalized by top-N average, age-multiplied, clamped to [0, 1]).
2. Determine eligibility per Section 8.3 (the algorithmic filters F0–F6, calibrated against the calibration cohort).
3. Compute credibility per Section 8.4. Note that stake_factor = 0 for all FIDs at retroactive evaluation because no tokens existed yet, so the maximum retroactive credibility is 0.90.
4. Compute growth_score per Section 6.1 over the entire post-transfer history.
5. Compute composite = credibility × growth_score.

Pool allocation:

allocation(fid) = composite(fid) / Σ composite(eligible f)
                · RETROACTIVE_POOL

Where RETROACTIVE_POOL = TOTAL_SUPPLY · RETROACTIVE_SHARE. Ineligible FIDs receive zero.

The retroactive computation is not adjusted, dampened, or filtered beyond the Section 6 + Section 8 rules. Earlier drafts of this FIP described per-cohort structural-follow detection, SimHash near-duplicate collapse, cohort-concentration dampening, and other "retroactive adjustments." Those have all been removed in favor of the unified algorithm. The structural-distortion problems they were designed to address are handled directly by:

• The post-transfer engagement filter (Section 8.1) — invalidates auto-follow-list edges from accounts that have changed custody, and provides custody-aware bookkeeping throughout.
• EigenTrust seeded on FID number (Section 8.2) — sybil rings and onboarding-list-recipients land at the noise floor because trust does not propagate to them through follow chains rooted in the seed cohort.
• Log-saturated mutuality (Section 6.1) — volume spam in any window cannot dominate.
• The crediter trust floor (Section 6.1) — low-trust crediters contribute zero, so ring sockpuppets can't prop up each other.

Together these structural rules subsume the earlier per-pattern adjustments without requiring custom corrections per attack type.

10.3 Distribution Pool

The retroactive distribution is funded from a fixed fraction of total supply, not ongoing emission:

RETROACTIVE_POOL = TOTAL_SUPPLY × RETROACTIVE_SHARE

Where RETROACTIVE_SHARE is a protocol parameter (see Section 15). This pool is allocated once, at genesis, and never replenished.

Individual allocations are pro-rata:

allocation(fid) = retro_score(fid) / sum(retro_score(all_fids)) × RETROACTIVE_POOL

10.4 Deterministic Execution Under Consensus

The retroactive computation must produce identical results on all validators. This requires:

1. Fixed evaluation snapshot: All scoring uses state as of EPOCH_GENESIS_HEIGHT - 1. No data from the genesis block or later is included.
2. Integer arithmetic: All intermediate computations use fixed-point integer arithmetic (e.g., scores as u64 with 6 decimal places of precision) to avoid floating-point non-determinism across architectures.
3. Ordered iteration: FIDs are processed in ascending order. Trie iteration is key-ordered; aggregation loops use FID-ascending ordering with deterministic tiebreakers.
4. No external state: Every input is read from the trie. No external chain queries, no labels, no hardcoded FID lists.

The retroactive computation is expensive — it touches every FID and every interaction. On a network with millions of FIDs and billions of messages, this is a significant computation. But it executes exactly once, at genesis, and validators have the full epoch-boundary processing window to complete it.

fn compute_retroactive_distribution(
    &self,
    genesis_height: u64,
) -> HashMap<u64, u64> {
    // Phase 1: Trust scores via EigenTrust seeded on fid ≤ SEED_MAX_FID
    //          (Section 8.2).
    let trust = self.compute_trust_scores(genesis_height);

    // Phase 2: Eligibility flags F0–F6 via algorithmic filters
    //          calibrated against the calibration cohort (Section 8.3).
    let eligibility = self.compute_eligibility(genesis_height, &trust);

    // Phase 3: Credibility weights (Section 8.4).
    let credibility = self.compute_credibility(genesis_height, &trust);

    // Phase 4: Growth scores via mutual post-transfer engagement
    //          (Section 6.1). Same algorithm as forward emission.
    let growth = self.compute_growth_scores(genesis_height, &credibility, &trust);

    // Phase 5: Composite + pool normalization
    let mut scores: HashMap<u64, u64> = HashMap::new();
    for fid in self.all_fids_ordered() {
        if !eligibility.is_eligible(fid) { continue; }
        let composite = (credibility.get(fid) as u128
                       * growth.get(fid) as u128
                       / PRECISION as u128) as u64;
        if composite > 0 {
            scores.insert(fid, composite);
        }
    }

    let total: u64 = scores.values().sum();
    if total == 0 { return scores; }
    for score in scores.values_mut() {
        *score = (*score as u128 * RETROACTIVE_POOL as u128 / total as u128) as u64;
    }
    scores
}

The reference implementation is src/bin/retro_rewards_finalize.rs, which produces an off-chain preview of the distribution from the current hub state. The on-chain implementation runs the same algorithm under consensus at genesis.

10.5 Distribution and Vesting

Retroactive allocations are computed at genesis, committed to the trie, and distributed automatically at each epoch boundary:

[RootPrefix::RetroactiveScore] ++ [fid_be_bytes] → RetroactiveScoreRecord {
    score:                u64,
    allocation:           u64,   // total entitlement, fixed at genesis
    epochs_distributed:   u32,   // number of tranches paid out so far
}

The allocation vests linearly over RETROACTIVE_VESTING_EPOCHS (default: 36 epochs, ~6 months). The per-tranche size is tranche = allocation / RETROACTIVE_VESTING_EPOCHS.

At EPOCH_GENESIS_HEIGHT (epoch 0), the first tranche is credited directly to each eligible FID's token balance as part of epoch-boundary processing — no claim action required. epochs_distributed is set to 1.

At each subsequent epoch boundary n (for n = 1, 2, ..., RETROACTIVE_VESTING_EPOCHS - 1), a single bulk-distribution pass runs in epoch-boundary processing:

fn distribute_tranche(epoch: u32) {
    if epoch >= RETROACTIVE_VESTING_EPOCHS { return; }
    for fid in self.all_retroactive_fids_ordered() {
        let rec = self.get_retroactive_record(fid);
        if rec.epochs_distributed > epoch { continue; }
        let tranche = rec.allocation / RETROACTIVE_VESTING_EPOCHS;
        self.credit_balance(fid, tranche);
        self.set_epochs_distributed(fid, epoch + 1);
    }
}

Push, not pull. Every eligible FID receives the same number of tranches at the same epochs, regardless of whether they are actively transacting. Unallocated rounding remainders stay in the pool.

Why push instead of claimable: the original draft used a claimable model with on-demand vesting checks, motivated by avoiding bulk processing for dormant FIDs. With the eligibility filters in Section 8.3 — particularly F1 (total_casts > 0) — dormant accounts are filtered out before they receive any allocation. The remaining set of eligible FIDs is bounded and well-defined; a bulk push at each epoch boundary is tractable, and produces a cleaner property: "your retroactive allocation arrives at the same cadence regardless of your post-genesis behavior, as long as you were eligible at genesis."

Why vest rather than full distribution at genesis: Linear vesting aligns retroactive recipients with forward-looking protocol health. A recipient whose FID is transferred mid-vesting forfeits the unvested remainder back to the pool: per Section 8.1, the new custodian's effective age (and therefore eligibility position) starts fresh, and the prior custodian's retroactive entitlement does not transfer with the FID.

10.6 Transparency and Verifiability

Because the retroactive computation is deterministic and runs under consensus:

• Any node can independently verify the result. Run the same computation on the same snapshot, get the same scores.
• Scores are queryable before claiming. GET /v1/hyper/retroactive/score?fid=12345 returns the FID's retroactive score, allocation, vesting schedule, and claimed amount.
• The rules are public and immutable. Sections 6, 8, and 10 define the formulas and parameters; they behave the same way on every validator. There is no subjective judgment, no committee, no vote. The protocol applies its own rules to its own history.

10.7 What This Is Not

• Not an airdrop. Airdrops are discretionary. This is a deterministic computation.
• Not a team allocation. If the founding team's FIDs scored high under the Section 6 growth function, they receive proportional allocation — same rules as everyone else. If they scored low (because their prior interactions were not reciprocal with high-trust counterparties, or they failed any eligibility filter), they receive less.
• Not an investor allocation. There is no investor category. There is no pre-mine. There are no investors. There is only the retroactive computation.
• Not retroactive public goods funding. RPGF requires human judgment about impact, and is rife with politics. This is fully algorithmic — the protocol cannot and does not distinguish between "impactful" and "not impactful" beyond what the scoring metrics capture.
• Not an app-usage allocation. Application PoW is excluded from retroactive scoring for the structural reasons in Section 10.1. Developers and app-side contributors earn forward-looking Application PoW (Section 7) on equal terms going forward.

11. Proof of Conversation Health (Experimental)

We adopt the Proof of Quality metrics defined in Section 8 to constitute proof of conversation health.

12. Token Mechanics

Denomination

The token is denominated in micro-units internally (u64). 1 token = 1,000,000 micro-units.

Fee Integration

The fee mechanism from the Proof of Quality FIP defines per-message fees adjusted by trust and uniqueness. The token system defines where those fees go and how new tokens are minted.

Collected message fees are distributed:

There is no protocol treasury. Fees are burned or paid to the block proposer; nothing is routed to a development fund or any other protocol-controlled account.

Emission (new minting) is separate from fee redistribution. Both exist simultaneously:

• Emission decreases over time (halving schedule)
• Fee revenue increases over time (more users = more messages)
• The crossover point where fee revenue exceeds emission is the protocol's sustainability milestone

Staking

Users can stake tokens for three purposes:

1. Validator staking: Required to register as a hyper validator (minimum: MIN_VALIDATOR_STAKE)
2. Vouch staking: Optional, used to vouch for new users (Growth PoW)
3. Credibility staking: Optional, contributes to stake_factor in identity weighting

Staked tokens are locked for UNSTAKING_PERIOD epochs after unstaking is initiated.

13. Protocol-Native Token Operations & Trustless Bridging

The token is not an external ERC-20 contract that the protocol references — it is a first-class protocol primitive. Balances, transfers, minting, and burning are all HyperMessage operations processed by consensus, stored in the verkle trie, and subject to the same finality guarantees as any other protocol state. This co-location with identity (FIDs), social graph, and work proofs is the entire point: the token exists where the work happens, not on a separate ledger that requires oracles to connect.

The migration to verkle proofs makes this practical beyond Farcaster's own consensus boundary. A verkle proof for a single key-value pair is ~150-200 bytes regardless of trie depth — small enough to verify inside an EVM STATICCALL. This means any state claim about Farcaster ("FID 12345 has 500 tokens locked at epoch 47") can be proven on Ethereum, Optimism, or any EVM chain with a single compact proof against an anchored state root.

13.1 Token Operations as HyperMessages

All token operations are expressed as HyperMessage types processed during block proposal:

enum HyperMessageType {
  // ... existing types ...
  HYPER_MESSAGE_TYPE_TOKEN_TRANSFER = 140;
  HYPER_MESSAGE_TYPE_TOKEN_LOCK = 141;       // Lock for outbound bridge
  HYPER_MESSAGE_TYPE_TOKEN_UNLOCK = 142;     // Unlock from inbound bridge proof
  HYPER_MESSAGE_TYPE_TOKEN_STAKE = 143;
  HYPER_MESSAGE_TYPE_TOKEN_UNSTAKE = 144;
}

message TokenTransferBody {
  uint64 recipient_fid = 1;     // Destination FID
  uint64 amount = 2;            // In micro-units (1 token = 1,000,000)
  uint64 nonce = 3;             // Replay protection, monotonically increasing per FID
  bytes memo = 4;               // Optional, max 256 bytes
}

message TokenLockBody {
  uint64 amount = 1;
  uint64 nonce = 2;
  uint64 destination_chain_id = 3;    // EIP-155 chain ID (1 = Ethereum, 10 = Optimism, etc.)
  bytes destination_address = 4;       // 20-byte EVM address to receive wrapped tokens
  uint64 lock_id = 5;                 // Unique lock identifier, derived from FID + nonce
}

message TokenUnlockBody {
  uint64 amount = 1;
  uint64 source_chain_id = 2;
  bytes source_tx_hash = 3;           // Transaction hash of the lock/burn on the source chain
  bytes event_proof = 4;              // Proof of the lock event on the source chain
  uint64 source_block_number = 5;
}

message TokenStakeBody {
  uint64 amount = 1;
  uint64 nonce = 2;
  StakeType stake_type = 3;
}

enum StakeType {
  STAKE_TYPE_NONE = 0;
  STAKE_TYPE_VALIDATOR = 1;
  STAKE_TYPE_VOUCH = 2;
  STAKE_TYPE_CREDIBILITY = 3;
}

Validation rules for transfers:

• Sender FID is derived from the HyperMessage signer (same pattern as all HyperMessages)
• amount <= available_balance(sender_fid) (balance minus staked minus locked)
• nonce == current_nonce(sender_fid) + 1
• recipient_fid must exist (registered on-chain)
• Self-transfers are allowed (FID sends to itself — useful for nonce advancement)

Minting is not a user-facing operation. Tokens are minted by the protocol during epoch boundary processing based on work market scores. The EmissionRecord (already defined in Section 14) records each mint. There is no HYPER_MESSAGE_TYPE_TOKEN_MINT — minting is a validator-executed consensus operation, not a user-submitted message.

13.2 Account Model

The account model is FID-native, not address-native. Every FID has an implicit account with the following state stored in the verkle trie:

[RootPrefix::TokenBalance]   ++ [fid_be_bytes] → u64 (available balance)
[RootPrefix::TokenStaked]    ++ [fid_be_bytes] ++ [stake_type] → u64 (staked amount)
[RootPrefix::TokenLocked]    ++ [fid_be_bytes] ++ [lock_id_be_bytes] → TokenLockState
[RootPrefix::TokenNonce]     ++ [fid_be_bytes] → u64 (current nonce)

Where TokenLockState contains the lock details (amount, destination chain, destination address, block height of lock) needed for bridge proof generation.

The account model is FID-keyed rather than address-keyed:

• The credibility/identity system is FID-based. Balances attached to FIDs inherit all identity properties (age, trust score, interaction history) without a join.
• Token operations use FID signers (Ed25519 keys registered via SignerAdd), the same keys used for all other protocol operations. No separate signing scheme required.
• FID custody transfer on L2 moves the token balance to an escrow owned by the previous custody address (see Section 13.9). Tokens are earned by the operator, not inherent to the FID.

13.3 Verkle Proofs as the Bridging Primitive

The migration from Merkle to Verkle tries gives us a property that Merkle tries cannot provide at practical cost: constant-size proofs verifiable in EVM.

A Merkle proof for a key in a trie of depth D requires O(D) hashes — for the current trie with branching factor 16, this is 6-12 hashes plus sibling nodes, totaling 500-2000+ bytes. Each hash verification in Solidity costs ~200 gas. Verkle proofs using polynomial commitments (IPA or KZG) compress the entire proof to a single opening, verifiable in ~100-200 bytes and a single pairing check (KZG) or a multi-scalar multiplication (IPA).

This size difference is the enabling property for trustless bridging. A bridge contract on Ethereum can verify a Farcaster state proof within a single transaction's gas limit, without batching or recursive verification.

13.4 State Root Anchoring

For any external chain to verify Farcaster state, it needs to know the current verkle root. This is the trust anchor — the root that proofs are verified against.

Anchoring Mechanism

At each epoch boundary, the block proposer computes the verkle root of the full hyper trie state and includes it in the epoch boundary block:

message EpochBoundaryRecord {
  uint64 epoch = 1;
  bytes verkle_state_root = 2;       // 32-byte commitment
  uint64 block_height = 3;           // Height at which root was computed
  bytes proposer_signature = 4;      // Proposer signs the root
  repeated ValidatorRootAttestation attestations = 5;
}

message ValidatorRootAttestation {
  bytes validator_key = 1;
  bytes signature = 2;               // Validator signs (epoch, root, height)
}

During the commit phase, validators verify the state root matches their local trie state and include their attestation. This is a natural extension of the existing commit signature — validators already sign the block hash, which implicitly commits to state. The epoch boundary record makes this commitment explicit and extractable.

Posting to External Chains

The signed epoch boundary record is posted to an anchor contract on the destination chain:

AnchorContract.postRoot(epoch, stateRoot, blockHeight, signatures[])

The anchor contract verifies that signatures represent a 2/3+ supermajority of the registered validator set. The validator set itself is bootstrapped into the anchor contract at deployment and updated at each epoch boundary (the epoch boundary record also contains the next epoch's validator set commitment).

Who posts: Any participant can post. There's no privileged relayer. The first valid post for each epoch wins. Incentive to post comes from the bridge fee (a small fee on each bridge operation, paid to the root poster).

Posting frequency: Once per epoch (~5 days) is sufficient. Users bridging between epoch boundaries wait for the next anchor. For faster bridging, roots can be posted more frequently (e.g., every 100 blocks) at higher gas cost — this is a gas/latency tradeoff controlled by the poster, not the protocol.

13.5 Outbound Bridge: Farcaster → External Chain

A user wants to move tokens from their FID balance to an EVM address on Ethereum or Optimism.

1. User submits TokenLock HyperMessage:
   { amount: 100_000_000, destination_chain_id: 10, destination_address: 0xABC..., nonce: 7 }

2. Consensus includes the lock in a block. The user's available balance decreases,
   and a TokenLockState is written to the trie at:
   [RootPrefix::TokenLocked] ++ [fid] ++ [lock_id]

3. User waits for the next epoch boundary (or more frequent root anchor).
   The verkle root containing the lock is posted to the anchor contract.

4. User (or any relayer) generates a verkle proof of the lock:
   prove(key: [RootPrefix::TokenLocked ++ fid ++ lock_id], root: anchored_root)
   → proof bytes (~150-200 bytes)

5. User submits proof to the bridge contract on the destination chain:
   BridgeContract.claim(lockId, amount, fid, destinationAddress, proof, epochRoot)

6. Bridge contract:
   a. Verifies epochRoot matches the anchored root for the claimed epoch
   b. Verifies the verkle proof against epochRoot
   c. Verifies the lock details match the proof
   d. Checks lockId hasn't been claimed before (replay protection)
   e. Mints wrapped tokens to destinationAddress

Trustless properties:

• No relayer trust required — anyone can generate the proof and submit the claim
• No oracle — the anchor contract's root is attested by 2/3+ validators
• No timelock/challenge period for individual claims — the root is already finalized by consensus. The only trust assumption is the same one underlying all Farcaster state: 2/3+ validators are honest
• Lock is irreversible on Farcaster once included in a committed block

13.6 Inbound Bridge: External Chain → Farcaster

A user wants to move wrapped tokens from an EVM chain back to their FID.

1. User calls BridgeContract.lock(amount, recipientFid) on the source chain.
   The bridge contract burns (or locks) the wrapped tokens and emits a BridgeLockEvent.

2. The BridgeLockEvent is observed by Farcaster's existing on-chain event watcher.
   (Same infrastructure that watches IdRegister events on Optimism.)

3. After sufficient confirmations (BRIDGE_FINALITY_CONFIRMATIONS, default: 64 blocks
   on Optimism, ~2 minutes), the event is processed:
   a. Verify the event comes from the known bridge contract address
   b. Verify the event hasn't been processed before (tx hash uniqueness)
   c. Credit the recipient FID's balance

4. No user-submitted HyperMessage needed — the inbound bridge is fully automatic,
   driven by the on-chain event watcher that already exists.

The bridge is asymmetric by design:

• Outbound requires a user-submitted proof because the external chain can't watch Farcaster natively — it needs the proof.
• Inbound is automatic because Farcaster already watches L1/L2 events (this is how FID registration works). The OnChainEventStore pattern is reused directly.

Alternative (manual inbound): If the on-chain event watcher doesn't cover the source chain, a user or relayer can submit a TokenUnlock HyperMessage with an event proof. The proof is verified against a known L1/L2 block hash (Farcaster can track L1 block hashes via the existing event watcher or a dedicated block hash oracle). This is the fallback for chains not directly watched.

13.7 Bridge Security Model

13.8 Bridge Parameters

13.9 Relationship to FID Custody

Token balances are keyed by FID, but FID custody transfer on L2 does not transfer the token balance to the new custodian. Tokens are earned by the operator behind the FID, not by the FID itself. A custody transfer changes who controls the identity — it does not transfer economic value that the previous operator accumulated through work.

When a ID_REGISTER_EVENT_TYPE_TRANSFER event is observed for a FID, the protocol:

1. Moves the FID's entire available balance to an escrow keyed by the previous custody address:

   [RootPrefix::TokenEscrow] ++ [old_custody_address] → u64 (escrowed balance)
   

2. Unstakes any staked tokens and moves them to the same escrow.
3. Locked tokens (pending bridge operations) are unaffected — the destination address was set by the original custodian and the bridge completes normally.

The previous custodian retains full ownership of their earned tokens and can claim them via either route:

• Claim to another FID: Submit a TokenEscrowClaim HyperMessage signed by the old custody address (EIP-712), specifying a destination FID. The escrowed balance is credited to that FID.
• Bridge out: Submit a TokenEscrowBridge HyperMessage signed by the old custody address, specifying a destination chain and address. This creates a TokenLockState and follows the standard outbound bridge flow (Section 13.5).

message TokenEscrowClaimBody {
  bytes custody_address = 1;       // 20-byte EVM address (the old custodian)
  uint64 destination_fid = 2;      // FID to credit
  bytes eip712_signature = 3;      // Old custodian signs (custody_address, destination_fid, nonce)
  uint64 nonce = 4;
}

Escrow balances do not expire. The old custody address can claim at any time.

Implications:

• FID recovery: The recovery address (set via CHANGE_RECOVERY on Optimism) can transfer the FID, which triggers the same escrow flow. Recovery is the backstop for lost keys, not a mechanism for inheriting token balances.
• Key rotation is unaffected: Rotating signers (adding new Ed25519 keys, removing old ones) does not trigger a custody transfer event and does not affect balances. Only L2 ID_REGISTER_EVENT_TYPE_TRANSFER events move the balance to escrow.

14. New Proto Additions Summary

New RootPrefix Values

pub enum RootPrefix {
    // ... existing values ...
    NodeAttestation = 40,
    NodeAttestationByFid = 41,
    DAChallenge = 42,
    DAScore = 43,
    GrowthReward = 44,
    AppWork = 45,
    EmissionLedger = 46,
    TokenBalance = 48,
    TokenStaked = 49,
    TokenLocked = 50,
    TokenNonce = 51,
    TokenEscrow = 52,
    RetroactiveScore = 53,
}

15. Parameter Summary

FID Age Parameters

DA-PoW Parameters

Epoch Membership Parameters

Proof of Quality Parameters (Section 8)

Growth PoW Parameters (Section 6)

App PoW Parameters

Emission Parameters

Retroactive Distribution Parameters (Section 10)

The retroactive computation uses the Section 6 + Section 8 parameters above; it has no parameters of its own beyond the pool size and vesting schedule.

Bridge Parameters