orangecheck-primary-sources-2026-05-15

OrangeCheck primary sources

Reviewed: 2026-05-15 UTC

What I reviewed

• Official docs overview:
  • https://docs.ochk.io/
• Official charter:
  • https://docs.ochk.io/charter
• Official protocol overviews:
  • https://docs.ochk.io/attest
  • https://docs.ochk.io/lock
  • https://docs.ochk.io/stamp
  • https://docs.ochk.io/agent
  • https://docs.ochk.io/pledge
• Official GitHub organization:
  • https://github.com/orangecheck

Key takeaways from primary sources

• OrangeCheck’s most useful primitive is not one protocol but the family design itself: six sibling protocols share a common envelope discipline built around canonical messages, BIP-322 signatures from Bitcoin addresses, shared Nostr publication conventions, conformance vectors, and offline verification.
• The overview page is explicit that OC Attest is the base layer while Lock, Vote, Stamp, Agent, and Pledge are peers rather than subfeatures. That matters analytically because it keeps proof of stake, private messaging, timestamped authorship, agent delegation, and bonded commitments legible as separate protocol surfaces instead of flattening them into one product story.
• OrangeCheck consistently frames Bitcoin stake as an economic-cost signal, not proof of personhood. The Attest docs say the protocol proves control of a Bitcoin address plus live sats held and days-unspent, while any social-handle bindings remain self-asserted and must be checked separately if an integrator cares.
• The other sibling protocols all reuse that economic signal in different ways. Lock uses the Bitcoin address as the addressing root for encrypted envelopes; Stamp combines BIP-322 authorship with OpenTimestamps anchoring and can optionally include stake at signing; Agent uses BIP-322-bound delegations with scope and expiry; Pledge wraps future-verifiable commitments around a bonded stake reference and public-state resolution.
• The charter is unusually revealing because it states monetization and governance boundaries in writing: no token, no unwanted custody, open specs only, free self-hostable protocol sites, offline-verifiable audit artifacts, and managed products that remain optional layers. That is stronger and more specific than the usual startup-language commitment to openness.
• The docs also make the commercial layering explicit. OC Me and OC Fleet are presented as managed products on top of the family, using the same envelopes and anchor rules rather than extending the wire format privately. That helps separate protocol surfaces from productized operations, compliance review, and enterprise integration layers.
• The GitHub organization overview reinforces the pattern by listing one repo per sibling protocol plus a shared oc-packages monorepo, reference web apps, and spec-plus-implementation expectations. OrangeCheck is therefore attempting to make cross-implementation conformance a first-class part of the brand, not just an implementation detail.

Specific source signals worth retaining

• Docs overview: strongest source for the six-verb family framing, the shared-plumbing model, the optional composition arrows between protocols, and the explicit split between open protocols and commercial products.
• Attest overview: strongest source for the family’s base-layer claim that Bitcoin-address control plus sats-held and days-unspent can act as a sybil-resistance primitive without claiming proof of personhood.
• Lock overview: strongest source for how OrangeCheck extends the same Bitcoin-address root into encrypted communication via device-key binding, directory publication, and self-contained envelopes.
• Stamp overview: strongest source for the authorship-plus-priority framing and for how OrangeCheck combines BIP-322 with OpenTimestamps instead of an x509 or smart-contract-centered notarization path.
• Agent overview: strongest source for the scoped-delegation framing that pushes OrangeCheck beyond identity into machine authority, including scope grammar, revocation, and optional stake-at-signing.
• Pledge overview: strongest source for the forward-looking commitment design, especially the refusal to be custodial or slashing-based and the emphasis on deterministic resolution from public state.
• Charter: strongest source for OrangeCheck’s intended governance and business boundaries, especially no token, no forced custody, protocol openness, free protocol sites, offline-verifiable auditability, and public spec stewardship.
• GitHub org overview: useful source for repo structure, package breadth, and the claim that each protocol has both a spec repo and reference implementation plus shared conformance expectations.

Why this entry belongs in the corpus

• OrangeCheck is a strong corpus addition because it is not just another identity project, Bitcoin login layer, or proof-of-stake badge. It is a protocol family that tries to grow multiple internet primitives out of one Bitcoin-address-native signing and publication discipline.
• It is especially useful for comparison work because it bridges several clusters that are often analyzed separately: identity/attestation middleware, agent authorization, timestamped provenance, stake-weighted coordination, and public commitments. The same root identity primitive is made to do all of them.
• The reusable insight is that open identity protocol projects often centralize less in the base signature primitive than in shared envelope formats, directory conventions, conformance suites, hosted reference apps, and the managed products layered above them. OrangeCheck makes those control surfaces unusually legible.