Docs
Overview

Philosophy & Overview

Buzzer is a fully on-chain, permissionless social network: one identity, one social graph, and every app built on top is just a kind of post. It is a single immutable contract with no owner, no settings, and no governance — deployed to an EVM chain where money already lives (target: Robinhood Chain).

Two priorities drive every design decision: gas cost and UX above everything. Validation lives in the client unless it protects funds. The chain records; clients interpret.

Use the tools people already have

There is nothing new to install and no new key to manage. Buzzer is plain EVM: any wallet signs in, identity is an address, and gasless actions use standard EIP-712 typed-data signatures. Indexing is standard event-log reading. If you can build on Ethereum, you can build on Buzzer today — no bespoke node software, no separate data network, no custom cryptography.

Composable with the chain where value lives

Because Buzzer is an ordinary contract on a general EVM chain, a social graph sits in the same execution environment as everything else on that chain — balances, tokens, stablecoins, tokenized stocks, gold and other real-world assets, credit primitives, game items, and memecoins. Another contract can read a profile, gate a drop on a relationship, tip in any ERC-20, or settle value against a handle in the same transaction. Social identity stops being a walled-off silo and becomes a building block other contracts compose with directly.

Content is an event log — cheap and flexible

Posts (buzzes), reactions, community activity, and messages are emitted as events, not stored in contract state. A post is a single counter increment plus a log entry; there is no per-post storage slot, no bidOwner, no reaction counters on-chain. This is what makes posting cheap enough to be practical, and it keeps the data model open: the event payload is opaque bytes32[] content plus a self-describing settings word, so new post types and encodings are a client convention, never a contract upgrade.

Only identity, profile data, and graphs are stored

The contract's persistent state is deliberately small — the things that must be authoritative and queryable:

  • Identity — the uid, its custody address, optional recovery, linked keys and their permissions, and the unique handle.
  • Profile data — an open key → value map (name, bio, pfp, …), interpreted by clients.
  • Graphs — the user-to-user relationship bitmap and community membership standing.

Everything else (who posted what, reactions, tips, messages, media) is reconstructed by an indexer from the event stream.

One immutable contract, zero governance

There is no admin, no pause switch, no upgrade path, and no parameter that anyone can change after deployment. Fees, intervals, and permission bits are fixed at deploy time. This is a constraint, not a limitation: it means the network cannot be quietly re-keyed, censored at the contract level, or governed into a different product. The only optional, self-expiring exception is the genesis invite gate, which can only ever open, never re-close.

The trade-off is intentional: the contract does the smallest possible set of things that must be trustless, and pushes everything interpretive out to an open convention layer that anyone can read and extend.