Compared to Farcaster & Lens
Farcaster, Lens and Buzzer are all decentralized social protocols, but they make different architectural choices about where the network runs, what lives on-chain, and how much the protocol decides for you. This page lays out those differences factually so you can judge the trade-offs.
At a glance
| Farcaster | Lens | Buzzer | |
|---|---|---|---|
| Where identity lives | On-chain registries on Optimism | Profile NFTs on Lens Chain (its own L2) | One contract on a general EVM chain (Robinhood Chain) |
| Where content lives | Off-chain hubs / a purpose-built data chain | On-chain publications + modules on Lens Chain | Event logs on the same chain |
| Composable with on-chain assets | Indirect — social data is off the asset chain | On Lens Chain's own environment | Directly — same chain as balances, tokens, RWAs |
| Core social primitives | Defined by the protocol (casts, reactions, follows) | Defined by the protocol (follow / collect / mirror, modules) | Records only — meaning is a client convention |
| Extending the model | Add message types within the hub spec | Write and register modules | Emit a new post type or settings word; no registration |
| Governance / mutability | Upgradeable registries, ongoing protocol governance | Upgradeable contracts and module system | Single immutable contract, no owner, no governance |
Where the network runs
Farcaster keeps identity on-chain (registry contracts on Optimism) but moves the social data itself — casts, reactions, follows — into an off-chain layer of hub nodes (now a dedicated data chain). Reading the network means running or trusting that separate data layer, which is distinct from the general-purpose chain where a user's assets sit.
Lens runs on its own dedicated L2 (Lens Chain). Identity and publications are on-chain there, which keeps data verifiable, but it is a separate execution environment optimized for social rather than the chain where a user's broader on-chain assets live.
Buzzer is a single ordinary contract deployed to a general EVM chain. Identity, graphs and the event stream all live in the same place as tokens, stablecoins, tokenized equities and other assets — so a social action and a value transfer can happen in one transaction, in one environment, with no bridge between "the social chain" and "the money chain."
What the protocol decides for you
Lens ships opinionated primitives: profiles are NFTs, and following, collecting and mirroring are first-class protocol concepts, extended through a registered module system. That gives rich built-in behavior at the cost of a larger, more prescriptive surface.
Farcaster defines a fixed vocabulary of message types (casts, reactions, links) that clients implement against the hub specification.
Buzzer is deliberately unopinionated. The contract stores identity, profile data and graphs, and otherwise only records — it does not interpret post types, relationship bits, reaction types, or "who may post" in a community. All of that meaning lives in an open convention layer that anyone can read and extend without touching the contract. A "follow," a "block," a subreddit, a company page and a DAO are all the same records interpreted differently by clients.
The practical difference: adding a new kind of content or relationship on Buzzer is a client-side convention, not a protocol change or a deployed module — and because the contract is immutable, that flexibility is the only way the network evolves.
The trade-off
An unopinionated, records-only contract means more is left to clients and indexers: there is no on-chain enforcement of community bans, no protocol-level "verified follow," no built-in collect mechanics. Buzzer treats those as client conventions and composable building blocks rather than contract features. If you want the protocol to make those decisions for you, a more opinionated design fits better; if you want a minimal, immutable base layer that composes with on-chain value, that is what Buzzer optimizes for.