FIP: Ungate Message Variants from Farcaster Pro Subscriptions

[CassOnMars]

FIP: Ungate Message Variants from Farcaster Pro Subscriptions

Overview

Remove the protocol-level gates that condition specific CastAdd and UserDataAdd message variants on an active Farcaster Pro tier subscription. After this FIP, the following message variants are accepted from any FID with sufficient storage, regardless of subscription state:

• CastType::TenKCast (the 10,000-byte cast variant)
• UserDataType::Banner (profile banner field)
• The extended 4-embed cap on CastAddBody.embeds
• The MAX_DATA_BYTES_FOR_10K_CAST (16 KiB) per-message size ceiling, applied to any CastAdd regardless of subscription state

The Pro subscription itself, its on-chain tier-purchase event, and its surfaced tier metadata on user/profile endpoints all remain intact — the change is strictly to remove subscription as a consensus-level admission gate on specific message variants. Subscription becomes a client-side / application-level signal rather than a protocol-level capability.

---

1. Motivation

The current rules treat a small set of message variants as paywall-gated capabilities. A node validating a block at height N checks the proposer's claim that the sender has an active Pro subscription at block_timestamp and rejects the message if not. The subscription fees accrue to a single entity, and does not provide economic security or benefit to the protocol or other clients – indeed, other clients using only snapchain have to require users pay an entirely separate company to use these features.

---

2. Current Gates Being Removed

To reduce scope, the minimal changeset is suggested:

#	Site	Today	After this FIP
1	CastType::TenKCast	Rejected with ProUserFeature when is_pro_user == false.	Accepted; subject to the standard MAX_DATA_BYTES_FOR_10K_CAST size ceiling and the same text_bytes.len() ∈ (1024, 10_000] range.
2	UserDataType::Banner	Rejected with ProUserFeature when is_pro_user == false.	Accepted; subject to the standard 256-byte value ceiling already enforced on the variant.
3	CastAddBody.embeds count	4 max when is_pro_user == true, 2 max otherwise.	Uniformly 4 max.
4	validate_message data-size selector	MAX_DATA_BYTES_FOR_10K_CAST (16 KiB) only when is_pro_user && type == CastAdd.	MAX_DATA_BYTES_FOR_10K_CAST applied to every CastAdd, regardless of subscription.
5	validate_message/validate_cast_add_body/validate_user_data_add_body is_pro_user: bool parameter	Threaded from the engine via Stores::is_pro_user(fid, timestamp).	Parameter removed.
6	Stores::is_pro_user	Read by the validation path.	Retained as a read-only RPC accessor; no consensus path consults it.
7	Tier-purchase event ingestion (EventTypeTierPurchase)	Gated on ProtocolFeature::FarcasterPro.	Unchanged on ingestion — still recorded for clients/indexers to consume.

What is not removed:

• proto::TierType::Pro and the rest of the tier type enumeration.
• On-chain tier-purchase event ingestion via EventTypeTierPurchase.
• OnchainEventStore::tier_subscription_expires_at / is_tier_subscription_active_at.
• The HTTP/gRPC tier endpoints that surface (fid, tier_type, expires_at) to clients.
• The ProtocolFeature::FarcasterPro engine-version gate. Activation is by a new feature flag, not by repealing the existing one.

---

3. Activation and Compatibility

3.1 New protocol feature

Introduce a new ProtocolFeature::UngateMessageVariants activated at a coordinated EngineVersion boundary. The pattern mirrors prior consensus-affecting upgrades:

pub enum ProtocolFeature {
    // ... existing features ...
    UngateMessageVariants,
}

impl EngineVersion {
    fn is_enabled(&self, feature: ProtocolFeature) -> bool {
        match feature {
            ProtocolFeature::UngateMessageVariants => self >= &UNGATE_MIN_VERSION,
            // ...
        }
    }
}

UNGATE_MIN_VERSION is the next free EngineVersion.

3.2 Gate behaviour pre/post activation

Each validator computes the effective is_pro_user value at the block's EngineVersion:

let is_pro_user_effective = if version.is_enabled(ProtocolFeature::UngateMessageVariants) {
    true  // every FID is treated as Pro for capability purposes
} else {
    stores.is_pro_user(fid, block_timestamp)?
};

This shape preserves byte-identical replay of historical blocks (pre-activation messages still validate the way they originally did) while producing a single uniform admission policy after activation. The validate_cast_add_body and validate_user_data_add_body functions are not re-shaped to drop the parameter until a second cleanup pass several versions later, when the historical-replay window is well behind us.

3.3 Replay safety

StorageSlot-style retroactive recomputation does not apply here: cast and user-data validity is checked at admission and the result is reflected in trie state. Once a message is in the trie, no future validation pass re-checks it. The only consensus-visible effect of activation is that new admissions stop being filtered by the gate.

This means:

• Existing blocks replay identically pre- and post-activation. No re-derivation of trie roots.
• Pre-activation admissions that were rejected for being non-Pro stay rejected — they were never in the trie. There is no migration step that retroactively admits them.
• Post-activation admissions of the previously-gated variants flow through validation, into the trie, and into block state-roots exactly the way any other message does.

3.4 Client compatibility

Clients today read:

• The UserDataAdd(Banner) field to render banners. The field is identical post-FIP — only the admission gate is removed. Existing clients continue to work; new clients can render banners for any FID rather than only Pro subscribers.
• The CastAdd(TenKCast) text via the cast endpoints. Identical post-FIP — only the admission gate is removed.
• The additional embeds are rendered however a given client renders them. Identical post-FIP.
• The Pro tier endpoint to badge subscribers in the UI. Unchanged.

3.5 Indexer / external store compatibility

External indexers (Neynar and other client backends, Snapchain replicas, Hypersnap, GraphQL gateways) follow the same path: tier metadata stays surfaced; admission semantics relax. Indexers do not need to re-process historical blocks — pre-activation rejections were never recorded, so there is nothing to backfill.

---

4. Migration Strategy

4.1 Pre-activation (current state)

Both is_pro_user_effective = stores.is_pro_user(...) and the rejection paths run as today. Operators run the upgraded binary in a no-op mode keyed off the engine version.

4.2 Activation timestamp

At the EngineVersion::Vn boundary, the validation paths flip:

• validate_cast_add_body: pass is_pro_user = true unconditionally
• validate_user_data_add_body: pass is_pro_user = true unconditionally
• validate_message's data-size selector: drop the && is_pro_user qualifier from the CastAdd arm

4.3 Post-activation cleanup (deferrable, optional)

In a follow-up release once the historical replay window has comfortably moved past activation:

• Drop the is_pro_user: bool parameter from validate_message, validate_cast_add_body, validate_user_data_add_body.
• Drop the Stores::is_pro_user(...) lookup from the engine's per-message preamble.
• Remove or repurpose the ValidationError::ProUserFeature variant.

These are pure refactors — no consensus change, no engine-version gate needed — and can ship at any tagged release whose activation timestamp lies beyond the network's earliest-known peer's chain start.

---

5. Code Changes Required

File	Change
src/version/version.rs	Add UngateMessageVariants to ProtocolFeature; add is_enabled arm; add Vn schedule entries per network; bump LATEST_PROTOCOL_VERSION.
src/storage/store/engine.rs	At the is_pro_user lookup site that feeds validate_message, replace the lookup with the engine-version-conditional expression in §3.2.
src/storage/store/block_engine.rs	Same change as engine.rs.
src/core/validations/message.rs	No signature change in the activation release (parameter stays). The cleanup pass in §5.3 drops the parameter later.
src/core/validations/cast.rs	Same — no immediate signature change; parameter stays.

Concrete diff at the engine call site

// Today
let is_pro_user = self.stores.is_pro_user(message.fid(), timestamp)?;

// After this FIP (activation release)
let is_pro_user = if version.is_enabled(ProtocolFeature::UngateMessageVariants) {
    true
} else {
    self.stores.is_pro_user(message.fid(), timestamp)?
};

A symmetric change lands at the block_engine.rs site.

---

6. Testing Plan

6.1 Unit tests

Each existing test that asserts ValidationError::ProUserFeature is rejection-positive must be split into:

• Pre-activation case (EngineVersion < Vn): still rejects with ProUserFeature.
• Post-activation case (EngineVersion >= Vn): accepts.

This includes:

• validate_cast_add_body with CastType::TenKCast and is_pro_user = false.
• validate_user_data_add_body with UserDataType::Banner and is_pro_user = false.
• The 4-embed cap test (currently asserts rejection at embed Move documentation to Github #3 for non-Pro).
• The MAX_DATA_BYTES_FOR_10K_CAST size-selector test.

6.2 Engine integration tests

• A non-Pro FID emits a TenKCast at a block timestamp just before activation: rejected. The same FID emits the same message at the next block-cadence boundary, with activation in effect: accepted.
• A non-Pro FID emits a UserDataAdd(Banner) across the activation boundary: same pattern.

6.3 Block-replay determinism

A node started cold against a chain that crosses the activation boundary must produce byte-identical trie roots at every height as a node that has been running across the activation. This is the standard replay guarantee for any version-gated change.

6.4 Stress / capacity

MAX_DATA_BYTES_FOR_10K_CAST is 16 KiB. Once it applies to every FID's CastAdd, a network with N% of FIDs emitting 10k-character casts increases per-block average byte size by N% * (16 KiB - 2 KiB). The block-time and mempool sizing analysis is the same as in FIP: 3-Second Block Time — no new headroom is needed at the current cap, but operators should watch sustained block-size distributions in the weeks after activation.

---

7. Out of Scope (Explicitly)

This FIP does not:

• Remove the Pro tier itself.
• Remove tier-purchase event ingestion.
• Remove tier RPC endpoints, tier expiry computation, or tier metadata in user-data responses.
• Repeal ProtocolFeature::FarcasterPro (which gates event ingestion; this FIP only ungates message variants).
• Change cast text-length limits, embed counts, banner size, or 10k-cast size beyond merging the gated and ungated paths into a single uniform path.

If a future FIP proposes removing the Pro tier or restructuring tier semantics, this FIP is a strict prerequisite: tier semantics cannot be cleanly restructured while consensus admission depends on tier state.

---

8. Summary

Aspect	Before	After
CastType::TenKCast admission	Pro-only	Universal
UserDataType::Banner admission	Pro-only	Universal
CastAddBody.embeds cap	2 (4 if Pro)	4
CastAdd data-size cap	2 KiB (16 KiB if Pro)	16 KiB
is_pro_user consulted on admission	Yes, every message	No (after activation)
Tier purchase events	Ingested	Ingested
Tier metadata RPCs	Surfaced	Surfaced
Pro subscription product surface	Protocol-enforced capability gate	Client-level signal
Migration	EngineVersion-gated cutover, byte-identical replay of history	—
Rollback	Push activation timestamp forward; no on-disk state to undo	—

The protocol stops carrying the gate. The subscription stays.

[felirami]

Yes yes yes I like it