peck-social — protocol overview

Status: Draft. Master orientation document for the peck-social protocol family. Authors: Thomas (kryp2) and contributors. Started: 2026-05-05. License: MIT.

This document is the master overview of the peck-social protocol. It is meant to be read first; the per-channel detail specifications (peck-social-token.md, peck-social-overlay.md, peck-social-v1.md) are the implementation references. This document explains how those pieces compose into one coherent protocol, why each piece is shaped the way it is, what formal properties the composition is meant to guarantee, and what foundations the design rests on.

0. Thesis

peck-social is a protocol family for sovereign, BRC-100-native social applications on the BSV blockchain that does not sacrifice any of the four properties existing decentralized-social attempts have each given up:

• Identity sovereignty — users own their cryptographic identity; no server-administered identity registry.
• Content verifiability — every assertion (post, like, follow, profile update) is cryptographically signed and verifiable against the signing key.
• State enforceability — entities with ownership semantics live as stateful UTXOs whose update rules are cryptographically enforced by Bitcoin Script, not by application code.
• Read availability — federated overlays with formally-grounded consensus mechanics serve queries with bounded latency and bounded divergence even under network partition.

The thesis is that the combination of (a) BSV's economic model (small-data on-chain is affordable), (b) the BRC-100 wallet abstraction layer, (c) restored Satoshi-era opcodes plus OP_PUSH_TX (stateful contracts), (d) Teranode's subtree-based parallel-validation architecture (high throughput, sub-block finality), (e) BRC-22 federated overlays with GASP-style sync, and (f) a formal automata-theoretic frame (Wright 2025 ¹) for reasoning about partition tolerance, is the first stack capable of supporting all four properties simultaneously. The constituent technologies are individually proven; the combination has not been deployed.

peck-social is the protocol that documents the combination. peck.to, peck.ink, peck.blog, and Margin are reference implementations.

1. Layer architecture

+---------------------------------------------------------------+
|  Application layer                                            |
|  peck.to — social feed                                        |
|  peck.ink — collaborative pixel art (sCrypt-stateful)         |
|  peck.blog — long-form content                                |
|  Margin — web-comments anywhere                               |
|  any future BRC-100-native social application                 |
+---------------------------------------------------------------+
|  Read + sync layer (federated)                                |
|  BRC-22 overlays with GASP-style subtree sync                 |
|  Merkle-rooted topic state, idempotent submission             |
|  Centrifuge real-time push, Asset-Service-shape API           |
+---------------------------------------------------------------+
|  Write channels                                               |
|  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐         |
|  │ Token-state  │  │ Input-script-│  │  OP_RETURN   │         |
|  │ stateful     │  │ data         │  │  (legacy +   │         |
|  │ UTXO with    │  │ payment-     │  │  high-volume │         |
|  │ rules-       │  │ coupled      │  │  attribution)│         |
|  │ enforced     │  │ actions      │  │              │         |
|  │ ownership    │  │ in unlock    │  │              │         |
|  │ entities     │  │ scripts      │  │              │         |
|  └──────────────┘  └──────────────┘  └──────────────┘         |
+---------------------------------------------------------------+
|  Identity & content                                           |
|  BRC-100 wallets (sovereign keys, getPublicKey, signMessage)  |
|  BRC-43 (typed protocol IDs), BRC-52 (certificates),          |
|  BRC-77 (signed messages), BRC-104 (UHRP content addressing), |
|  BRC-78 (encrypted messages)                                  |
+---------------------------------------------------------------+
|  Contract framework                                           |
|  Rúnar (multi-language → Bitcoin Script) for stateful         |
|  contracts; sCrypt as fallback. Restored opcodes (OP_SUBSTR,  |
|  OP_LEFT, OP_RIGHT, OP_2MUL, OP_LSHIFTNUM, etc.) for          |
|  efficient OP_PUSH_TX state-machine logic.                    |
+---------------------------------------------------------------+
|  Substrate                                                    |
|  BSV chain, Teranode-era (subtree-validated, parallel,        |
|  Aerospike-backed UTXO store, Kafka-streamed events)          |
+---------------------------------------------------------------+

The diagram is structural, not procedural. A given peck-social application reads from the overlay layer, writes through one or more of the three write channels, signs with its BRC-100 wallet, and the overlay layer parses the chain via Teranode's Kafka topics or Asset Service APIs. Everything below the application layer is shared across all peck-social applications.

2. Why each layer is the way it is

2.1 Substrate — BSV with Teranode

Every other blockchain has either fees that prohibit social-volume usage (Ethereum L1, BTC), aggressive fee-market scaling that makes data on-chain cost-volatile (Solana, L2s), or no smart-contract semantics rich enough for stateful contracts (Nostr's relay model, Mastodon's federation). BSV with restored opcodes is the only mainstream-secured chain where every social action — a post, a like, a profile update — has a marginal on-chain cost in the cents range AND can carry data in spendable outputs with cryptographically enforced rules.

Teranode is the chain layer becoming what it always meant to be — horizontally scalable, microservice-decomposed, subtree-validated. The May 2026 GorillaPool transition is the operational signal that this is now production-ready, not aspirational.

2.2 Contract framework — Rúnar

Stateful contracts are not optional in this stack — they are how ownership-bearing entities are made enforceable. The choice between sCrypt and Rúnar is not nominal: Rúnar's multi-language compilation (TypeScript, Go, Rust, Python, Java, Ruby, Zig — all producing byte-identical output) directly matches peck.to's heterogeneous stack (TS frontend, Go indexer, Python web). Each component writes contract verifications natively without learning a single TS-DSL. Nanopass auditability lets us inspect every compilation step independently. sCrypt remains a fallback when Rúnar tooling is insufficient; the structural choice is Rúnar.

2.3 Identity & content — BRC family

BRC-100 is the wallet abstraction. BRC-43 is namespacing. BRC-52 is certificates. BRC-77 is signed messages (the signing primitive that should eventually replace BSM in AIP). BRC-104 is content addressing (off-chain hosts with hash-locked references on chain). BRC-78 is encrypted messages.

These are not chosen because they exist; they are chosen because each one is the right shape for its concern. Identity sovereignty without BRC-100 means inventing wallet abstraction from scratch. Verifiable identity attestations without BRC-52 means custom cert formats that don't compose with other BRC-100 apps. Off-chain content without BRC-104 means custom URI schemes that don't compose with other apps.

The composability across BRCs is the value. peck-social does not invent any new BRC; it composes existing ones with explicit conventions documented in the channel-specific specs.

2.4 Write channels — three because three is needed

Three channels exist because real social applications have three distinct kinds of state changes:

• Ownership-bearing entities (Profile, Post, IdentityClaim, BRC52Cert) need stateful update rules cryptographically enforced. Token-state UTXO is the right shape. (peck-social-token.md)
• Payment-coupled actions (tip+comment, paywall-receipt, paid-follow, anointing) bind monetary value to record. Data in the unlocking script of the spend that pays IS the right shape — payment and record are one event. (peck-social-overlay.md §2)
• High-volume attribution (Like, Follow, Tag, Channel-message) needs to be cheap and cheap-and-fast-to-parse. OP_RETURN is the right shape — same as Bitcoin Schema since 2018. (peck-social-v1.md)

A single application produces all three kinds of TX as appropriate per entity. They are not alternatives; they are complements. The hybrid policy is documented in peck-social-overlay.md §5.

2.5 Read+sync layer — federation, not single-server

BRC-22 overlay services are not optional UX scaffolding. They are the read layer — apps query overlays, not chain directly. The reason is twofold: chain reads at social-application latency are infeasible without an indexed cache, and federation of multiple specialized overlays gives integrity-via-game-theory that no single-overlay or central-server arrangement can.

The overlay-federation pattern is what Wright's distributed-automaton framework formalizes ¹. Each overlay is a node in a distributed automaton. Topic-rooted Merkle trees are the state representation. Subtree-based GASP sync is the partition-reconciliation protocol. Resilient Nash equilibria emerge when nodes follow protocol because deviating is penalizable via the audit-and-penalty mechanism design.

This is the layer where peck.to's existing infrastructure already lives — overlay.peck.to is a BRC-22 overlay; peck-broadcaster is the asynchronous-submit-to-overlay shim; peck-indexer-go is the chain-reader. The existing pieces only need to extend to (a) parse input-script-data and token-state outputs alongside OP_RETURN, (b) implement GASP-style subtree-rooted state-export, (c) accept idempotent submissions, and (d) anchor topic-roots to chain at configured cadence.

3. Formal grounding (Wright 2025)

Wright's "Resolving CAP Through Automata-Theoretic Economic Design" ¹ models distributed systems as partition-sensitive deterministic automata where nodes behave as rational agents under incentive-compatible mechanisms. Several constructions in that paper are the formal articulation of design choices in peck-social:

• (ε_C, ε_A)-bounded conformance (Definition 4.4) replaces binary CAP with measurable bounds on consistency and availability under partition. peck-social overlays operate under this regime — the question is not "are we consistent" but "what is our ε_C bound under current partition state".
• Convergent automaton model of Bitcoin Script (§8.1) formalizes the substrate property: deterministic, decidable, bounded execution over finite instruction set. Every Bitcoin Script execution converges on a verdict that all honest validators reach. This is the substrate guarantee peck-social token-state contracts inherit.
• Merkle-proof state representations (§8.2) ground subtree-rooted overlay sync formally — Merkle proofs are polynomial-sized, logarithmic-cost stateless-verification primitives. peck-overlay's per-topic Merkle roots are not implementation convenience; they are formal commitment schemes.
• Partition reconciliation via timestamped evidence (§8.3) — exchange of signed log segments, conflict detection via commutativity, causal merge ordering, reconciliation transition. This is the protocol shape for overlay-to-overlay sync after partition.
• Resilient Nash equilibria (Definition 5.2) — strategy profiles where deviating from protocol is dominated by participating. The peck-social-overlay federation is engineered to make protocol-conforming behavior the strategically dominant choice for overlay operators (via audit, reputation, idempotent-submit anchoring).
• Reversible automaton formalism (Definition 6.1) — recovery transitions are designated subset of the transition relation. Token-state contracts embed this directly: every state-change has a defined revert/burn path; cross-walking identity-claims have bilateral revoke; certs have issuer-revoke.

The Wright frame matters for peck-social because it makes the protocol's properties provable, not merely architecturally stated. Federation-with-game-theory is not handwaved; it is a Nash-equilibrium claim under explicit utility functions. State convergence is not optimistic; it follows from convergent-automaton formalism. Reconciliation under partition is not best-effort; it is a defined recovery-transition function.

This grounds the protocol family in something that can be reasoned about formally rather than only empirically. That matters when a sceptical engineer (or regulator) asks "what makes you think this works".

4. What this is, what it isn't

peck-social is: - A protocol family with three write channels and one federated read+sync layer. - A specification of conventions for using existing BRCs together coherently. - A vision for sovereign social media on Bitcoin without surrendering identity, verifiability, enforcement, or availability. - A reference implementation surface (peck.to, peck.ink, peck.blog, Margin) that demonstrates the conventions.

peck-social is not: - A new BRC. It composes existing BRCs without inventing new ones at that layer. - A new blockchain or sidechain. It runs on BSV mainnet. - A complete implementation as of writing. Significant pieces are draft specifications; the implementation roadmap (§7) lists what is built vs. what is designed. - A claim that other social-on-chain protocols are wrong. They are differently-shaped responses to the same underlying problems; this is the response shape that reaches all four properties simultaneously.

5. Component documents

5.1 peck-social-v1.md — bridge profile (OP_RETURN canonical)

The legacy/bridge profile that lets peck-social applications produce content readable by the entire pre-existing Bitcom-parser ecosystem (memo, twetch-archive, treechat). Codifies canonical AIP signing, BRC-43-namespaced MAP keys, BRC-104 content addressing, BRC-52 cert references. This is the profile that ships first because it preserves backwards compatibility while introducing the BRC-native conventions.

5.2 peck-social-token.md — sovereign token-state model

Stateful UTXOs holding ownership-bearing entities (Profile, Post, IdentityClaim, BRC52Cert, Reply, Message). Each entity is a 1Sat-ordinal-style spendable output whose locking script encodes data plus update rules via OP_PUSH_TX-driven sCrypt/Rúnar contracts. Updates are cryptographically enforced state transitions, not application-policy. The migration path from v1 OP_RETURN profiles to token-state profiles is opt-in per user.

5.3 peck-social-overlay.md — input-script-data + federated overlay

Documents both the input-script-data write channel (data carried in the unlocking script of normal P2PKH spends, ride-along with payment) and the federated overlay read+sync layer (BRC-22 with GASP, per-topic Merkle trees, idempotent submission, Centrifuge real-time push, Asset Service integration). Section 9 ("Teranode integration") binds the abstract layer to concrete Teranode primitives.

The hybrid policy in §5 of the overlay spec — which entity goes which channel — is the cross-cutting decision document that ties all three profiles together at the application level.

6. Comparison to existing decentralized-social protocols

	Identity sovereignty	Content verifiability	State enforceability	Read availability
Mastodon / ActivityPub	server-administered ID	server-trusted	application-policy	server-availability
Bluesky / AT Protocol	DID at PLC or Web	server-trusted (PDS)	application-policy	server-availability
Nostr	sovereign pubkey	signed events	application-policy (relay-policy)	relay-availability
Farcaster	FID in registry	hub-trusted	hub-policy	hub-availability
Lens	sovereign + on-chain registry	hash-anchored	application-policy	server-content / chain-graph
peck-social	sovereign BRC-100 key	canonical AIP / BRC-77	sCrypt-enforced via OP_PUSH_TX	federated overlay with formal convergence

Each existing protocol gives up exactly one of the four properties. peck-social claims all four because it composes BSV (cheap on-chain), Teranode (high-throughput chain), BRC-100 (sovereign identity), Rúnar/sCrypt (state enforcement), and BRC-22 federated overlays with Wright-grounded convergence semantics.

The claim is a hypothesis until reference implementations demonstrate it at non-trivial scale. peck.to is the primary demonstration site.

7. Implementation status as of 2026-05-05

Already deployed: - Canonical AIP signing in bitcoin-agent-wallet 0.4.0 (npm published, git pushed). - peck-mcp 0.5.0 with namespace-stripping + paymail-synthetic-removal (npm published, git pushed). Cloud Run redeploy pending. - peck-indexer-go with canonical-AIP verifier, cutover env-bryter (default off), and per-subscription progress persistence (running on peck-indexer VM, image deployed). - Margin canonical AIP code path (margin-api + WAB /auth/margin/identity + DER→BSM-compact bridge). Not yet deployed. - peck-ink wallet-adapter rewritten to canonical AIP (committed, not deployed). - peck-web app.js rewritten to canonical AIP for both BSV-Desktop and local-xPriv flows (committed, not deployed). - WAB HKDF defense-in-depth (WAB_HKDF_SERVER_SECRET env-mixed into key derivation; backward-compat with one-time warning).

Designed but not implemented: - peck-social-token contract templates (Profile, Post, IdentityClaim, BRC52Cert, Reply). Sketched in peck-social-token.md §6; awaiting Rúnar tooling work. - BRC-22 GASP-style subtree-sync between overlays. Designed in peck-social-overlay.md §3-4 + §9; needs implementation in peck-indexer-go and overlay.peck.to. - Direct Teranode Kafka consumption in peck-indexer-go (replacing JungleBus dependency). Documented in peck-social-overlay.md §9.1; pending. - Idempotent overlay submission. Documented in §3.5; partially exists via peck-broadcaster, needs formalization. - Wallet-toolbox extensions for spending stateful contract UTXOs from BRC-100 wallets. Open question; required before token-state can be used by sovereign BRC-100 users (vs. agent-wallet users who hold privkey directly). - BRC-77 signing lane for AIP. Reserved as v2 spec for the per-channel profiles. - BRC-78 encrypted messages replacing custom PECK1 envelope. - Cert revocation via spend (BRC-52 cert-tokens that revoke when their UTXO is spent).

The implementation order roughly follows the dependency chain: bitcoin-agent-wallet → peck-mcp → margin/ink/web Cloud Run deploys → cutover engagement → indexer Kafka migration → overlay GASP federation → token-state contract templates → wallet-toolbox stateful-spend extensions. Some of these are gated by external work (Rúnar tooling maturity, BRC-100 ecosystem stateful-spend support); others are gated only by our own work.

8. Open questions

These are recorded as a single list across the protocol family rather than scattered across the per-profile docs:

• Teranode public Kafka access policy. Are Kafka topics public per Teranode deployment, or miner-relationship-gated? Need to verify against actual GorillaPool / other Teranode-native miner manifests.
• Cross-overlay subtree-format standardization. Teranode subtrees are TX-ID-rooted; overlay subtrees are state-rooted. The shape of the overlay-subtree format needs spec'ing — likely a separate small document referenced from peck-social-overlay.md §3.3.
• BSVA-shelved overlay-sync game-theoretic study. Wright's paper provides a formal frame, but there is also an unpublished BSVA-commissioned study referenced in the Calhoon/Deggen X-thread. Worth surfacing if it can be unshelved.
• Wallet-toolbox stateful-spend integration. BRC-100 wallets currently have no standard "spend a stateful contract" API. Either Rúnar/sCrypt provide wallet-integration libraries, or a BRC extension is proposed. Without this, token-state is only practical for agent-wallet users.
• UTXO-contention UX under concurrent updates. When two clients update the same Profile-token simultaneously, only one can succeed. Need optimistic-submit-with-rebase pattern in client SDKs.
• Federation-membership policy. Open (anyone joins) vs. permissioned (issuer-signed onboarding)? Affects the Wright-frame's resilient-equilibrium calculation. Recommended starting position: open with operator-defined trust scores.
• Cert-handle privacy migration. If any BRC-52 cert is ever issued with a cleartext handle (pre-spec), there's a migration burden. Current state: identity.peck.to has not yet issued production certs, so the privacy posture (hashed-handle by default) can be locked in cleanly.
• Migration tooling from v1 OP_RETURN to token-state. For users with v1 profiles who want token-state profiles, the mint TX is straightforward; the rendering authority preference is documented as "token-state wins where present"; the implementation has not been built.

9. Acknowledgments and lineage

This protocol family stands on:

• Bitcoin Schema (rohenaz / b-open-io) — the foundational B/MAP/AIP stack and the schema.org-derived philosophy of structured-data-on-chain.
• The BRC-100 family of standards (BSV Association) — wallet abstraction, BRC-43 namespacing, BRC-52 certificates, BRC-77 signed messages, BRC-78 encrypted messages, BRC-104 UHRP content addressing.
• sCrypt (BSV Association) — for years of refining the smart-contract programming model on Bitcoin Script and the practical patterns (PeckCanvas demonstrates).
• Rúnar (icellan) — multi-language compiler-to-Bitcoin-Script that makes contract authorship native to each component of a heterogeneous stack.
• 1Sat-ordinals — the spendable-output-with-data convention reused here for token-state.
• Teranode team (BSV Association + ecosystem) — chain architecture that makes subtree-validated parallel processing the default rather than the exception.
• GorillaPool — first miner Teranode-native (May 1, 2026), operational signal that the architecture is production.
• The overlay-developer community on X — Deggen, John Calhoon, Brayden Langley, and others publicly converging on overlay-federation, GASP, and subtree-rooted sync. This protocol writes down conventions consistent with where the public conversation is heading.
• Dr. Craig S. Wright — the formal automata-theoretic and game-theoretic frame that grounds federation-with-convergence claims rigorously rather than handwaved ¹. The technical contributions stand independently of broader political dynamics; cited here for the technical content.
• The BSVA-commissioned game-theoretic study on overlay-syncing — referenced by Deggen as shelf-ware. Worth unshelving if recoverable.
• Run protocol (run.network team) — for years of work on JS-class-as-token model that prefigured stateful-contract-as-application-object thinking.
• schema.org and the broader open-Web data-typing community — for the philosophy that data semantics should be open, parseable, and composable across implementations.

The errors in this document are ours; the foundations are theirs.