§00 Profile · v1 working draft

Sovereign social,
read at scale.

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.

SubstrateBSV / Teranode

IdentityBRC‑100 + BRC‑43

StateOP_PUSH_TX · sCrypt · Rúnar

ReadBRC‑22 + GASP overlays

ConvergencePer‑topic Merkle, anchored

Read the protocol overview Token-state spec Identity spec Overlay spec

12 topics · 161 live outputs · 12/12 anchoredpeck-schema 7b6af8d7f4… ✓tm_social-content ff4ced4d85… ✓tm_social-profile dc161ad751… ✓tm_social-handle 83622749ef… ✓tm_peck-cat 4aeea7d31e… ✓tm_peck-cat-funding e3b0c44298… ✓tm_key-binding 2af5702c70… ✓tm_identity-profile 9177334117… ✓tm_identity-handle aaeccb8219… ✓tm_identity-cert 6f1d0d1436… ✓tm_social-friend e3827755b2… ✓tm_social-lens 4d094e0404… ✓§03 →

Fig. 0.1 The four layers, read top-down. Each is independently auditable against the layer below.1080 × 540 mm

§00.1

One post, end to end

Follow a single post through the stack.

The rest of this sheet is dense. Before it, one concrete path: Ada writes a post in one app, Bob reads it in another. Scroll and the figure builds up one layer at a time.

01 · Sign

Ada writes a post.

She uses an app — peck.to, say. Her BRC‑100 wallet signs the post with a key she holds. No server issued that key and no server can take it back.

02 · Write

It lands on chain.

The post becomes a token‑state output: the data plus the rules for changing it, enforced by Bitcoin Script. A like would take the cheap OP_RETURN channel instead; a tip would ride inside the payment. Three channels, one ledger — §02.

03 · Index

The overlay files it.

The chain is the truth, but it is slow to query. The overlay reads each new output, files it under a topic — social content, identities — and keeps a Merkle tree of each topic's current state. It also sees data carried inside payments, which ordinary indexers miss.

04 · Anchor

The overlay commits to what it serves.

Each topic's state‑root is written back to chain. Anyone can now check that what the overlay serves matches what it anchored. The overlay is a convenience, not an authority. This runs live today — see the readout.

05 · Read

Bob sees it — in a different app.

Bob opens another app built on the same overlay. It asks the overlay, gets the post with Ada's signature, and can check both the signature and the root. Apps share the same overlay and differ only in how they render — §05.

06 · Federate

More than one overlay.

Overlays compare Merkle roots and sync only the branches that differ (GASP). One that serves a root its peers disagree with stands out. Roadmap Designed, not yet deployed — one overlay serves today.

Fig. 0.2

One post, end to end. Each stage is checkable against the layer below.§01–§03

§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.

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. AIP, BRC‑77.

State enforceability

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

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 · Friend · Tag · Channel message

Read the spec →

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

Where each channel writes, inside one transaction. Scroll through the three artifacts; the drawing marks the part each one fills.

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

Fig. 2.5

Anatomy of a transaction: one input, three outputs. A composite — each channel can appear on its own.CH-A · CH-B · CH-C

§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

social content

live outputs54

state-rootff4ced4d85…

anchor txid9c604c9a…6ebfd2

anchored✓ on-chain · 32 h ago

identities

live outputs14

state-root9177334117…

anchor txid9e007622…83e621

anchored✓ on-chain · 7 d ago

Source: overlay.peck.to/statecomputed 21 s ago

Fig. 3.1 · GASP subtree syncFederation: designed, not yet deployed

Each overlay publishes the root of its topic tree. The roots differ.
Compare one level down. The left branch matches; the right does not.
Walk only the branch that differs, down to the leaf: b2 against b2′.
Overlay A fetches that one leaf — not the chain history behind it.
Recomputed, the roots match again — and match the root anchored on chain.

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.

Fig. 5.1 One rail, many birds — each app is a voice on the same overlay.

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.

Fig. 6.1 Served state, anchored through to Bitcoin.

Identity layer

LIVE. Light self-attestation family: BRC-3-signed profiles, first-come handle claims, key-binding (posting key ↔ identity root, mutual signatures), curated cert publication. Resolution collapses bound keys on every surface — feed authors, mentions, notifications.

live90%

State anchoring

LIVE. Every topic's Merkle state-root anchors on-chain as a 1Sat ordinal with a logical prev-chain; the scheduler anchors on change, autonomously. All topics anchored and matching live state today — verify it yourself in the readout above.

live85%

Social graph + messaging

LIVE. Mutual-consent friendship (two one-way BRC-3 attestations = a pair; unfriend revokes one side), friend-gated E2E DMs — BRC-42 encryption between identity roots over BRC-103 mutual-auth message-box transport. The wallet talks to the message box directly; no application server sees plaintext.

live75%

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%

SDKs (TypeScript + Python)

@overlay-social/sdk 0.2.0 on npm — typed read client: identity resolution, social graph (friends), notifications, geo queries, anchored state. Python twin (overlay-social) mirrors it 1:1.

live65%

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 — anchored on-chain so a second overlay can audit the first. 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, and overlay drafts render live on this site; the federation / write-channel roadmaps live with them, 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, anchored: (.anchor.matchesLive // false)}'

{
  "topic": "tm_social-content",
  "count": 20,
  "anchored": true
}
{
  "topic": "tm_identity-profile",
  "count": 10,
  "anchored": true
}
# …every topic carries its Merkle state-root + the on-chain anchor
# (1Sat ordinal txid) it currently matches.

# Identity — resolve any author key/address to its canonical identity:
$ curl -s -X POST https://overlay.peck.to/v1/identities/resolve \
     -H 'content-type: application/json' \
     -d '{"addresses":["<p2pkh-address>"]}'

# Social graph — mutual-consent friendships for an identity root:
$ curl -s https://overlay.peck.to/v1/friends/<identity-pubkey> \
     | jq '.light'

§08

Acknowledgments

Foundations are theirs.

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

Cited works · technical foundations

[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
[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).

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.
The BSV overlay-developer community for the public 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.

Follow a single post through the stack.

Ada writes a post.

It lands on chain.

The overlay files it.

The overlay commits to what it serves.

Bob sees it — in a different app.

More than one overlay.

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.