§orangecheck docs
docs / overview

Ecosystem — shared concepts

Every sibling protocol in the OrangeCheck family (Attest, Lock, Stamp, Vote, Agent) inherits the same plumbing. Learning it once saves re-learning it five times. This section is the shared layer.

What's in here

  • The canonical message — every sibling protocol produces a signed "canonical message" in the same shape (header line + field lines + ack line, LF line endings, lexicographically sorted extensions). Byte-identical across implementations, which is how we can ship a TS SDK and a Python SDK that produce the same attestation IDs.
  • BIP-322 signing — every protocol signs the canonical message via BIP-322. Why not legacy signmessage. What wallets support it. The one-line answer to "which signing scheme do I use?" is always "BIP-322, unless you're on a pre-SegWit P2PKH address."
  • Nostr kind-30078 — NIP-78 parameterized-replaceable addressable events are how every sibling publishes its artifacts (attestations, device records, stamps, ballots). The d tag convention is per-protocol; the event shape is shared.
  • Conformance vectors — every sibling ships normative test vectors in its oc-*-protocol repo. Reference impls are required to pass them on every CI run. This is how we catch implementation drift before it reaches npm.
  • Security model — the shared threat model across every sibling. What Bitcoin stake proofs DO protect against (sybil at-scale, bot spam, anonymous cheap identity farming). What they DON'T (proof of personhood, privacy-preserving claims, chain-analysis resistance). Read this before shipping anything.

Why a shared section

Writing the canonical-message format five times (once per protocol) would produce five slightly-different descriptions and, over time, actual drift in the impls. By specifying it once and linking from every protocol's pages, we keep the docs in sync with the reality — which is that all five protocols literally use the same builder in @orangecheck/sdk (TS) or orangecheck (Python).

When a protocol extends a shared concept — like Vote's secret-mode commitment, or Lock's envelope canonicalization rule — the protocol's own pages cover only the delta, and link back here for the baseline.

Reading order

If you're new:

  1. Skim canonical message — 5 minutes.
  2. Read BIP-322 if you're not already comfortable with it — 5 minutes.
  3. Skim security before shipping anything — 10 minutes, high-value.
  4. Dive into the protocol you picked in the decision tree.

Kind-30078 and conformance vectors are reference sections — no need to read them linearly. Come back when an SDK surprises you.