overlay.social
A federated read+sync layer for sovereign social applications on Bitcoin SV. Chain as truth-anchor, overlays as the read layer, BRC-100 wallets as the identity primitive.
Four properties, simultaneously
Every existing decentralized-social protocol gives up exactly one of these. The overlay.social profile family targets all four — the substrate (BSV with restored opcodes + Teranode), the wallet abstraction (BRC-100), and the federation model (BRC-22 with formally-grounded convergence) make the combination feasible for the first time.
Identity sovereignty
Users own their cryptographic identity. No server-administered registry. BRC-100 wallets, BRC-43 namespaced keys.
Content verifiability
Every assertion — post, like, follow, profile update — is signed and verifiable against the signing key. Canonical AIP, BRC-77 signed messages.
State enforceability
Ownership-bearing entities live as stateful UTXOs whose update rules are enforced by Bitcoin Script, not application code. OP_PUSH_TX, restored Satoshi-era opcodes, sCrypt and Rúnar.
Read availability
Federated overlays with formally-grounded convergence semantics serve queries with bounded latency and bounded divergence even under partition. BRC-22 + GASP, per-topic Merkle roots.
Three write channels
Real social applications have three distinct kinds of state change. They are not alternatives — they are complements. Implementations choose per entity which channel fits.
Token-state
stateful 1Sat-style UTXO
Profile, Post, Reply, IdentityClaim, BRC-52 cert. The locking script encodes data plus the rules for its mutation. Updates are spends; ownership is the spend authority. Sovereign and mutable.
Read the spec →Input-script-data
the unlocking script of a normal P2PKH spend
Tip + comment, paid follow, paywall receipt, anointing. Data ride along in the spend that pays. Payment and record are one event. Zero new outputs, zero burn.
Read the spec →OP_RETURN
the legacy / high-volume attribution channel
Likes, follows, tags, channel messages. Cheap, fast, indexable by every Bitcom parser since 2018. Bridge compatibility with the existing six-year ecosystem.
Read the spec →The overlay layer is first-class
In legacy stacks the overlay is an indexer derived from chain. In this profile it is promoted to a peer of the on-chain channels: input-script-data is invisible to standard output-scanners, token-state requires UTXO-set maintenance, and at Teranode-scale single-overlay re-derivation from chain becomes uneconomic.
Per-topic Merkle roots
Each overlay-managed topic — profile, post, identity_claim, tip-receipt — maintains a Merkle tree of its current state. The root is publishable and comparable peer-to-peer.
GASP-style subtree sync
Overlay-to-overlay sync uses BRC-22's General Asset Synchronization Protocol with subtree-rooted topic state. New peers bootstrap in near-constant time regardless of chain history depth.
Idempotent submission
Every overlay submission carries a client-side nonce or content-hash. Repeat submissions of the same key return the same response. Missed-response retry is safe.
On-chain anchoring
Topic state-roots commit to chain at configured cadence. Overlay-derived state stays auditable against Bitcoin: anyone can verify that an overlay's served state matches what was anchored at block N.
Game-theoretic acceptance
Federation maintains integrity by audit and reputation, not proof-of-work. An overlay that publishes a state-root inconsistent with its peers becomes detectable and isolatable. N-of-M peer-agreement is a configurable client policy.
Teranode-native
Direct Kafka consumption replaces JungleBus. Subtree-grain anchor cadence inherits Teranode's parallel-validation shape one layer up. Centrifuge real-time push for live UX.
Compared to existing decentralized-social
Each row gives up exactly one property — except the last, which is the bet this protocol family is making.
| Identity | Verifiability | State enforcement | Read availability | |
|---|---|---|---|---|
| Mastodon / ActivityPub | server | server | app policy | server |
| Bluesky / AT Protocol | DID at PLC | PDS-trusted | app policy | server |
| Nostr | sovereign pubkey | signed events | relay policy | relay |
| Farcaster | FID in registry | hub-trusted | hub policy | hub |
| Lens | on-chain registry | hash-anchored | app policy | split |
| overlay.social | BRC-100 key | AIP / BRC-77 | OP_PUSH_TX | federated overlay |
Reference implementations
Demonstration sites for the protocol family. They share the same chain, the same indexer, the same overlay — different voices, different shapes.
Where this is
Honest snapshot. Specs are revising in public; implementations are partial. The point of the teaser is to tell you that — not to oversell.
| Specifications | draft · revising in public |
| Reference implementations | partial · peck.to family in flight |
| Federation | single overlay today · GASP sync designed |
| Token-state contracts | templates sketched · awaiting Rúnar tooling |
| Direct Teranode Kafka | documented · pending |
Acknowledgments
overlay.social is not a unilateral declaration. It writes down conventions consistent with where the public BSV overlay-developer conversation is converging.
- Bitcoin Schema (rohenaz / b-open-io) — B / MAP / AIP foundation.
- The BRC family (BSV Association) — 100, 43, 52, 77, 78, 104.
- sCrypt (BSV Association) — years of stateful contract patterns.
- Rúnar (icellan) — multi-language compiler to Bitcoin Script.
- 1Sat-ordinals — the spendable-output-with-data convention.
- Teranode + GorillaPool — chain layer subtree-validated and live in production since May 1, 2026.
- Deggen, John Calhoon, Brayden Langley and the overlay-developer community — for the GASP / per-topic-Merkle / subtree-sync direction this profile inherits.
- Dr. Craig Wright — the automata-theoretic frame (arXiv:2507.02464) that grounds federation-with-convergence formally rather than handwaved. Cited for the technical content.
- schema.org and the broader open-Web data-typing community — structured data that composes across implementations.