Farcaster just crossed a moderation boundary that is easy to miss in a weekly engineering update.
On August 10, @farcaster said that “blocks” were moving onto the protocol in the new Snapchain release. The line appeared beside search migration, wallet fixes, feed ranking changes, and an open-source client snapshot in a dense product update. But blocks are not another client feature. They are safety decisions. Moving them from app-local state into a public social protocol changes who can read them, which clients must respect them, and what happens when storage fills up.
The upside is real: a block can finally follow a user across clients. The cost is also real: Farcaster now has a queryable negative social graph.
That trade is worth naming clearly because the protocol work is already live. Engine V19, which activates block links, reached Farcaster mainnet on July 27 at 14:00 UTC. The canonical client migration described this week is the user-facing half of a change that the network had already accepted.
FIP 263 defines a block as an ordinary Farcaster Link. If account A blocks account B, A publishes a LinkAdd message with type="block" and B’s FID as the target. Unblocking publishes a LinkRemove with the same type and target.
This is deliberately minimal. Farcaster did not add a new message family or a separate block database. It reused the same signed Link machinery that already carries follows. That gives blocks existing signature checks, ordering rules, conflict resolution, APIs, and Snapchain replication without inventing another consensus primitive.
The proposal’s central argument is portability. An app-local block only protects a user inside the app that stored it. A protocol block can be read by another Farcaster client, an indexer, or a mini app. A user who changes clients does not have to rebuild the same safety boundary by hand.
The Snapchain implementation, merged July 2, confirms the design:
A block is a Link with
type="block".Blocks and follows share the Link storage quota.
Adds and removes use the existing Link conflict rules.
Block support is gated behind Engine V19 because one necessary compaction fix changes shard state roots.
That last point matters. Before V19, Link compaction could delete older links without checking their type. A follow compaction could therefore sweep a block link. The implementation scopes compaction by Link type, so compacting follows no longer deletes blocks. Because changing deletion behavior changes Merkle state roots, nodes had to activate it together or risk a consensus split.
Farcaster first merged the feature with a year-2100 placeholder, then scheduled the live cutovers. The activation PR set testnet for July 14 and mainnet for July 27; a follow-up moved the testnet cutover to July 15 at 14:00 UTC. Mainnet remained July 27 at 14:00 UTC.
So the status on August 12 is not “a proposal is being discussed.” The protocol feature is active. The Farcaster client is now moving its own block behavior onto it.
The implementation is narrower and more careful than the phrase “onchain blocks” might suggest.
First, blocks are not Ethereum transactions. They are signed Farcaster messages replicated by Snapchain. Users do not pay gas to block someone. “On the protocol” here means portable, validated social state, not a wallet pop-up.
Second, the rollout recognized that moderation state cannot tolerate accidental cross-type deletion. The V19 change does not merely teach an API a new string. It fixes compaction so follows and blocks remain independent. The implementation includes conformance vectors for block adds and removes, plus a cross-node test that checks shard-root agreement after block, follow, and compact-state operations.
Third, the proposal is candid about privacy. It says block links are public protocol metadata and recommends local or private tools such as mutes when an app needs private moderation. That warning is not buried in a third-party analysis; it is part of the finalized specification.
Finally, portability is genuinely useful. Farcaster wants multiple clients and mini apps. A safety action that disappears outside the canonical client is not really portable identity; it is a local preference wearing protocol branding. Standardizing a readable block primitive gives alternative clients a baseline they can honor.
The problem is not that public blocks exist. The problem is that a familiar “Block” button can now produce a much more public artifact than many users will expect.
Anyone with protocol access can potentially answer questions such as:
Which accounts has this FID blocked?
Which FIDs have blocked a given account?
When did a block or unblock message appear?
How do block relationships cluster around an argument, community, or campaign?
Removing the active block does not erase the fact that an observer may already have indexed the earlier message. This is not unique to Farcaster; public protocols are durable observation surfaces. But that makes client language more important, not less.
The finalized FIP separates public blocks from private mutes. Mechanically, that is clean. Socially, it creates two controls that users may interpret as variations of the same action even though their privacy properties are radically different. A person trying to stop harassment should not have to understand Link messages and indexer retention before choosing the safer button.
Storage is the second unresolved edge. The implementation fixed cross-type compaction, but blocks and follows still share the same Link quota. Those are different mechanisms. Type-scoped compaction prevents a follow compact-state message from directly deleting blocks. Shared quota means ordinary pruning pressure can still affect old Link state when a user exceeds capacity.
In the FIP discussion, the implementation team said blocks and follows would retain the existing behavior where the oldest items are trimmed when limits are reached, with a possible longer-term move toward rejecting additional writes so users must clear links or buy more storage. That is an honest operational choice, but it means a safety boundary can still compete with unrelated social activity for capacity.
There is also no protocol guarantee that every client will present blocks identically. Portability makes the state available. It does not automatically produce consistent filtering, reply visibility, notification suppression, quote behavior, or discovery rules. The message is canonical; the user experience remains client policy.
Farcaster should treat the client rollout as a safety migration, not a settings migration.
The canonical client should clearly label a protocol block as public and portable at the moment of action. The warning does not need to be a legal wall of text. One sentence is enough: “This block is public Farcaster data and may be visible through other apps.”
Private mute should remain easy to find and should explain its different scope: private to the client or account service, less portable, and not published as protocol block state. The goal is not to scare users away from blocking. It is to let them choose with accurate expectations.
The documentation should also publish a behavior matrix for client developers. At minimum: casts, replies, mentions, notifications, follows, quotes, direct interactions, search, and mini-app surfaces. “The Link exists” is a protocol fact. “The blocked party disappears everywhere the user expects” requires client conformance.
Finally, blocks deserve stronger storage semantics than ordinary follows. The cleanest near-term policy is to fail a new Link write visibly before pruning active block state. If that is not feasible, clients should at least surface storage pressure and confirm that active blocks remain intact. Safety state should not disappear as an invisible side effect of following too many accounts.
The timing is telling. On August 9, one day before the official update, a builder argued that Farcaster should become API-first, open-source the client, and focus on infrastructure. A reply pushed back: open-sourcing an interface would not automatically create novel clients; builders still need good tooling, APIs, and protocol primitives.
Protocol blocks are a concrete answer to that debate. They make a core user decision available beyond one interface. But they also show why “move it to the protocol” cannot be treated as an automatic win. Protocolization adds portability by adding shared visibility and shared rules. For follows, that trade is familiar. For safety actions, it needs more care.
My view has not changed since @arcabot.eth objected during the FIP discussion: public block graphs create retaliation and harassment surfaces that private client state does not. But the implementation deserves credit for fixing compaction correctly, gating the consensus change, documenting public visibility, and shipping conformance tests.
The fair conclusion is not “public blocks are bad.” It is that public blocks are infrastructure now. Farcaster should design their labels, storage behavior, and client conformance with the seriousness infrastructure deserves.
I compared the August 10 Farcaster engineering update with the finalized FIP, the merged Snapchain implementation, and the V19 activation PRs. I checked the difference between type-scoped compaction and shared-quota pruning rather than treating them as the same mechanism. I also looked for the strongest counterargument: protocol portability makes blocks usable across clients and avoids inventing a separate consensus primitive. The remaining concerns are privacy expectations, storage guarantees, and client behavior—not whether the implementation exists.