Farcaster Protocol
Farcaster is a protocol for building “sufficiently decentralized” social networks, created by Dan Romero and Varun Srinivasan (ex-Coinbase) in 2021. Its design premise: social networks began as open platforms that courted third-party developers, then progressively restricted APIs and revoked access without recourse — so a durable network needs credible neutrality enforced by architecture rather than policy. The best-known client is Warpcast.
Architecture: on-chain identity, off-chain data
The split is the whole design:
| Layer | Where | What |
|---|---|---|
| Identity | On-chain (Ethereum, later OP Mainnet) | Farcaster ID Registry (FIR) issues numeric FIDs to Ethereum addresses; Farcaster Name Registry (FNR) maps FIDs to human fnames |
| Keys | Off-chain | Users authorize per-app signers (Ed25519 key pairs) that sign messages on the account’s behalf; revocable without touching the custody key |
| Data | Off-chain | Casts (posts), reactions, follows are signed messages replicated across a peer network of Hubs (later superseded by Snapchain, a Rust p2p data layer targeting ≥10k TPS) |
| Rent | On-chain | Storage units are purchased on-chain, bounding spam while keeping messages off the L1 |
An FID is tied to an Ethereum address (derived as in hd-wallet-derivation-paths), is transferable, and has a separate recovery address — a middle path between “key loss is forever” (pure self-custody) and “the platform can unban you” (Web2).
Message semantics: CRDT replication
Each account’s data forms a per-type set (casts, reactions, verifications, signers) with merge rules — last-write-wins by timestamp/hash tiebreak, removes as tombstones, adds idempotent. Hubs gossip deltas and converge without a global order or consensus over content: classic CRDT (conflict-free replicated data type) behavior. Messages are validated per-account against the signers authorized on-chain.
- Casts — ≤320-byte public posts with optional embeds and parent references (reply graph).
- Actions / reactions — likes and recasts as their own set type.
- Verifications — EIP-191
0x45signed proofs linking an FID to an external Ethereum address (so clients can show, e.g., NFT avatars — see erc721-nft-deployment). - Signer authorizations — adding/revoking app keys is itself a signed, replicated message type anchored to the on-chain key registry.
Threat model (per the spec’s security considerations)
- Signer compromise — bounded blast radius: revoke the signer on-chain; the custody key stays cold.
- Eclipse attacks — a hub isolated by malicious peers can be fed a divergent view; mitigated by diverse peering and periodic full-sync.
- Flooding / DDoS — on-chain storage rent makes unbounded message injection expensive; hubs rate-limit per-FID by storage entitlement.
- Replay — timestamps + per-FID sequence and hash-chained references bound replay windows.
The documented security posture is honest about the tradeoff: liveness and permissionless replication in exchange for weaker global consistency than a blockchain.
Position in the decentralized-social landscape
Farcaster’s identity layer is exactly the model described in web3-identity — authentication as key-signing, with an on-chain registry instead of a CA. Compared to its peers: Nostr maximizes self-issued identity (no registry at all, no recovery); AT Protocol/Bluesky keeps identity on a server-signed ledger with real recoverability; ActivityPub/Mastodon trusts per-instance admins entirely. Farcaster sits at “immutable on-chain ID + revocable app keys + off-chain CRDT data,” making it the closest working analogue of Gemini-style client-certificate thinking scaled to a social graph.
Sources
Related
- web3-identity — the wallet-as-identity model Farcaster builds on
- hd-wallet-derivation-paths — how the custody addresses are derived
- erc721-nft-deployment — NFT avatars linked via Farcaster verifications
- uniform-resource-locators — FIDs, fnames, and on-chain pointers as naming layers
- cooperation-and-defection — credible neutrality as an institutional commitment device