overlay.social

§01

Four properties at once

Pick all four.
That is the wager.

Every decentralized‑social protocol so far has given up exactly one of these four.

We think the giving‑up is no longer necessary. The substrate has changed underneath the conversation: BSV with restored opcodes plus Teranode, BRC‑100 as a wallet abstraction, BRC‑22 federation with formally‑grounded convergence. The overlay.social profile is an attempt to write down what falls out of that combination.

P1

Identity sovereignty

Users own their cryptographic identity. No server‑administered registry. BRC‑100 wallets, BRC‑43 namespaced keys.

P2

Content verifiability

Every assertion — post, like, follow, profile update — is signed and verifiable against the signing key. AIP, BRC‑77.

P3

State enforceability

Ownership‑bearing entities live as stateful UTXOs whose update rules are enforced by Bitcoin Script, not application code.

P4

Read availability

Federated overlays serve queries with bounded latency and bounded divergence even under partition. BRC‑22 + GASP.

§02

Three write channels

Three shapes of write.
Not alternatives — complements.

Real social applications have three distinct kinds of state change. Implementations choose, per entity, which channel fits.

What follows below is not a hierarchy. Token‑state is not "better" than OP_RETURN. A like is exactly the right shape for OP_RETURN; a profile is exactly the right shape for a stateful UTXO; a tip is exactly the right shape for input‑script‑data. The whole point of the profile is to make that selection legible.

Token-state

CH-A · stateful 1Sat-style UTXO

The locking script encodes data plus the rules for its mutation. Updates are spends; ownership is the spend authority. Sovereign and mutable in the same construct.

Profile · Post · Reply · IdentityClaim · BRC-52 cert

Read the spec →

Input-script-data

CH-B · payload on a normal spend

Data rides along in the spend that pays. Payment and record are one event. Invisible to standard output‑scanning indexers, which is why overlays are required to surface them.

Tip + comment · Paid follow · Paywall receipt · Anointing

Read the spec →

OP_RETURN

CH-C · attribution / high-volume

Cheap, fast, indexable by every Bitcom parser since 2018. The bridge of compatibility with the existing six‑year ecosystem. Bitcoin Schema lives here.

Like · Follow · Tag · Channel message

Read the spec →

Fig. 2.1 Three channels, one ledger — chosen per entity, never per implementation.

Fig. 2.2Token-state locking script — ProfileCH-A · stateful UTXO

01 OP_FALSE OP_RETURN
02   "ord"                            — 1Sat ordinal envelope
03   "application/profile+json"
04   { "@type": "Profile",
05     "name": "ada",
06     "key":  <brc43-pk>,           — immutable identity binding
07     "seq":  7 }                    — monotone update counter
08 OP_PUSH_TX                              — exposes spending tx to script
09   require next.@type == this.@type      — shape preserved
10   require next.key   == this.key        — key never rotates
11   require next.seq    >  this.seq       — update strictly forward

Data and rules colocated in one output. Ownership is the spend authority over key.RFC 8785 · BRC-43

Fig. 2.3Input-script-data — tip + commentCH-B · payload on a spend

01 Unlocking script (P2PKH spend):
02   <sig> <pk>                            — normal P2PKH satisfaction
03   PUSH {
04     "@type": "Tip",
05     "to":     <post-outpoint>,         — reference target
06     "sats":   12000,
07     "comment": "loved this"
08   }
09 Tx outputs:
10   out[0]  → P2PKH(payee)  12000 sats   — the payment itself
11   out[1]  → P2PKH(change)              — no new burn output

Payment and record are one event. Standard output-scanners miss the payload — overlays surface it.BRC-22

Fig. 2.4OP_RETURN — like, with AIP signature trailerCH-C · attribution channel

01 OP_FALSE OP_RETURN
02   "1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5"   — B protocol prefix
03   "like"
04   <target-outpoint>                       — what is being liked
05 |
06   "15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva"   — AIP signature trailer
07   "BITCOIN_ECDSA"
08   <signing-address>
09   <sig over bytes 01..04>                 — verifiable against the address

Cheap, fast, signed. Verifiable by any Bitcom parser since 2018.Bitcoin Schema · AIP

§03

The overlay is first-class

A peer, not a derivative.

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.

Three forces push it up. Input‑script‑data is invisible to standard output‑scanners. Token‑state requires live UTXO‑set maintenance, not just a transaction log. And at Teranode scale, single‑overlay re‑derivation from chain becomes uneconomic. The fix is the same thing it always is: replicate, anchor, audit.

Federation readout

profiles

live outputs5

state-rootdc161ad751…

sourceprofile_tokens

social content

live outputs27

state-root2a23dce955…

sourceoverlay_outputs

Source: overlay.peck.to/statecomputed server-side

Fig. 3.1 GASP subtree-sync between two overlays serving the same topic. A divergent leaf is reconciled at depth d, not by re-fetching chain history.BRC-22

3.2.1

Per-topic Merkle roots

Each topic — profile, post, identity_claim, tip‑receipt — maintains a Merkle tree of its current state. The root is publishable and comparable peer‑to‑peer.

3.2.2

GASP-style subtree sync

Overlay‑to‑overlay sync uses BRC‑22's GASP with subtree‑rooted topic state. New peers bootstrap in near‑constant time regardless of chain history depth.

3.2.3

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.

3.2.4

On-chain anchoring

Topic state‑roots commit to chain at configured cadence. Overlay‑derived state stays auditable against Bitcoin: anyone can verify the served state matches what was anchored at block N.

3.2.5

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.

3.2.6

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.

§04

Compared honestly

Every other row
gives up exactly one.

Read the matrix as concessions. The bet of this profile is the last row: that the substrate has changed enough that the concession is no longer necessary.

Protocol	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[BRC-100] · [BRC-43]	AIP · BRC-77[AIP] · [BRC-77]	OP_PUSH_TX[sCrypt] · [Rúnar]	federated overlay[BRC-22] · [CW-2025]

▸ This row concedes nothing. Citations link each claim to a BRC, paper, or repo — see §08 Cited works.

Variant B · trade-off frame

The same protocols, read as choices.

No implicit winner. Each row names what it optimizes for and what that choice forecloses. We ship variant A; this view is for readers who'd rather decide for themselves.

Protocol	Optimizes for	Gives up
Mastodon · ActivityPub	Operator control, moderation legibility	Identity portability across servers
Bluesky · AT Protocol	UX of a centralized app with identity portability	Enforcement at the substrate; the PDS is trusted
Nostr	Identity sovereignty, ease of relay deployment	Convergent read availability, state enforcement
Farcaster	Hub-grade throughput, registry-mediated identity	Sovereignty of the FID registry
Lens	On-chain provenance for social primitives	Cost and latency of EVM writes
overlay.social	All four properties at once	Substrate choice: BSV + Teranode required

§05

Reference implementations

Same chain.
Same overlay. Different voices.

Demonstration sites for the profile family. They share the same indexer and the same overlay, and differ only in the shape of the assertions they render.

peck.to

The social feed. The primary demonstration site of the profile family — short posts, replies, follows, tips, the whole thing.

Open peck.to →

peck.ink

Collaborative pixel art with sCrypt‑stateful canvases. Each tile is a token‑state UTXO; ownership is the spend key.

Open peck.ink →

peck.press

Long‑form content. ordfs‑hosted, sovereign rendering. Your prose lives where your keys live.

Open peck.press →

Margin

Web‑comments anywhere. A permanent comment layer keyed by URL — the same overlay primitives, deployed against the open web rather than a single site.

Not yet public

§06

Honest snapshot

Where this actually is.

Specs revising in public. Implementations partial. The point of saying so is to tell you that — not to oversell.

Identity bridge

LIVE. Canonical ProfileToken resolution over the overlay — POST /v1/identities/resolve, /identity/:pubkey, /resolve/:handle, /v1/bio/profile, /cert/verify/:sha. peck.to renders feed authors through it today.

live80%

Specifications

Protocol, token-state, identity, overlay + roadmaps. Open BSV License v5; drafts render on this site and live in public at github.com/overlay-social/specs. They iterate openly.

live70%

TypeScript SDK

@overlay-social/sdk on npm — a read-only client for state, identity resolution, profiles and feed. v0.1.0; write paths to follow.

live55%

Reference implementations

peck.to family in flight. peck.to public, peck.ink and peck.press partial, Margin internal.

partial50%

Federation

Single overlay today, serving real per-topic state-roots. Multi-overlay GASP sync and peer-quorum are designed, not yet deployed.

designed35%

Token-state contracts

sCrypt templates sketched. Awaiting Rúnar tooling for the multi-language compiler path.

sketched25%

Direct Teranode Kafka

Documented. Replaces JungleBus for direct subtree consumption.

pending20%

§07

Build on this

Specs in the open. Pull requests welcome.

The specs and the reference implementations are Open BSV License v5 — usable only on Bitcoin SV, by design. Issues, PRs, and proposals are how this profile moves.

CTA-01

Read the specs

Protocol overview, token-state, identity projection, overlay topics, and the federation / write-channel roadmaps render live on this site and are Open BSV-licensed in public at github.com/overlay-social/specs. Issues and PRs welcome.

github.com/overlay-social/specs →

CTA-02

Token-state & overlay drafts

The two companion drafts: how ownership-bearing state lives in a locking script, and how federated overlays serve it. Read them on this site or in the spec repo.

Read the overlay spec →

CTA-03

Talk to the overlay

@overlay-social/sdk is on npm — a typed, read-only client for state, identity resolution, profiles and feed. Or skip it: the overlay speaks plain HTTP and the live federation state is one GET away.

npm i @overlay-social/sdk →

Read live federation state — typed SDK or plain HTTP

# The typed client is on npm:
#   npm i @overlay-social/sdk
#
#   import { createOverlayClient } from "@overlay-social/sdk";
#   const overlay = createOverlayClient({ baseUrl: "https://overlay.peck.to" });
#   const { topics } = await overlay.getState();
#
# Or skip the SDK entirely — the overlay speaks plain HTTP:

$ curl -s https://overlay.peck.to/state | jq '.topics[] | {topic, count, stateRoot}'

{
  "topic": "tm_social-profile",
  "count": 5,
  "stateRoot": "dc161ad75192b3b716d35a9f4384187a6626f383664fe16cdcbc8bb32ba5018d"
}
{
  "topic": "peck-schema",
  "count": 27,
  "stateRoot": "2a23dce955b2b7fdd11b9a1354b441c1a6ef6d07205716d93c741cf1a62f8ceb"
}

# Identity bridge — resolve feed authors to canonical ProfileToken state:
$ curl -s -X POST https://overlay.peck.to/v1/identities/resolve \
     -H 'content-type: application/json' \
     -d '{"addresses":["<p2pkh-address>"]}'

§08

Acknowledgments

Foundations are theirs.

overlay.social is not a unilateral declaration. It writes down conventions consistent with where the public BSV overlay‑developer conversation is converging. Errors here are ours.

Cited works · technical foundations

[CW-2025]Wright, C. S. Resolving CAP Through Automata-Theoretic Economic Design: A Unified Mathematical Framework for Real-Time Partition-Tolerant Systems. arXiv:2507.02464, 2025. — formal grounding for partition-tolerant federation under bounded divergence (§03).
[BRC-22]BSV Association. General Asset Synchronization Protocol & overlay federation. bsv.brc.dev/22
[BRC-100]BSV Association. Wallet abstraction for application-layer key management. bsv.brc.dev/100
[AIP]rohenaz et al. Author Identity Protocol. Bitcoin Schema. github.com/BitcoinSchema/aip

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.
schema.org and the open-Web data-typing community structured data that composes across implementations.

Specifications and reference implementations are released under the Open BSV License v5.

Sovereign social,read at scale.

Pick all four.That is the wager.

Identity sovereignty

Content verifiability

State enforceability

Read availability

Three shapes of write.Not alternatives — complements.

Token-state

Input-script-data

OP_RETURN

A peer, not a derivative.

Per-topic Merkle roots

GASP-style subtree sync

Idempotent submission

On-chain anchoring

Game-theoretic acceptance

Teranode-native

Every other rowgives up exactly one.

The same protocols, read as choices.

Same chain.Same overlay. Different voices.

peck.to

peck.ink

peck.press

Margin

Where this actually is.

Specs in the open. Pull requests welcome.

Read the specs

Token-state & overlay drafts

Talk to the overlay

Foundations are theirs.

Sovereign social,
read at scale.

Pick all four.
That is the wager.

Three shapes of write.
Not alternatives — complements.

Every other row
gives up exactly one.

Same chain.
Same overlay. Different voices.