OrangeCheck

• Name: OrangeCheck
• URL: https://docs.ochk.io/
• Category: Bitcoin-address attestation and delegation protocol family / stake-bound identity middleware / Nostr-published signed-message stack
• Tags: bitcoin-ecosystem nostr-ecosystem
• Summary: OrangeCheck is a Bitcoin-address signed-message stack with a small protocol family attached. The point is not the badge layer. It is the reuse of BIP-322 signing, canonical message rules, and Nostr publication across attestations, delegation, signed statements, and a few adjacent protocols. Useful note. Still niche.
• What it does:
  • Defines a family of sibling protocols rooted in Bitcoin-address control, including OC Attest (am), OC Lock (whisper), OC Vote (decide), OC Stamp (declare), OC Agent (delegate), and OC Pledge (swear)
  • Reuses the same BIP-322-style signing discipline, canonical-message rules, publication flow, and verification logic across those protocols instead of inventing a new trust envelope for each one
  • Uses OC Attest as the base address-control and optional stake-signal layer, while other protocols can reference that attestation without hard-wiring themselves to it
  • Extends the envelope into scoped delegation, signed statements, directed encrypted messaging, voting, and bonded commitments
  • Publishes separate specs, repos, SDKs, CLIs, and managed products such as OC Me and OC Fleet on top of the protocol family
• Key claims:
  • The docs present OrangeCheck as a family of open protocols rooted in Bitcoin-address control, not as one app or one credential API
  • The useful design move is envelope reuse: the same signing and publication pattern shows up across attestations, delegation, statements, messaging, and other sibling protocols
  • OC Agent is the part that most clearly justifies the note, because it turns Bitcoin-address control into scoped, revocable delegation instead of stopping at identity signaling
  • OrangeCheck is not a proof-of-personhood system and not a broad schema-first attestation rail; it is narrower signed-message middleware with optional stake weighting
• Whitepaper: No single canonical OrangeCheck whitepaper surfaced in this pass. The strongest primary material was the official overview, charter, per-protocol overview pages for Attest / Lock / Stamp / Agent / Pledge, and the GitHub organization overview collected in ../whitepapers/orangecheck-primary-sources-2026-05-15.md.

Internal linkages

• Best comparison points: agent-passport-system and sign-protocol.
• The useful contrast is simple: OrangeCheck starts from Bitcoin-address control and signed-message discipline, while the others start from gateway enforcement or broader attestation infrastructure.

Control surface

• The protocol family is cleaner than the product story, but practical authority still accumulates in verifier policy: which message formats get accepted, whether Nostr publication is required, how optional stake proofs are interpreted, and whether managed surfaces like OC Me or OC Fleet become the default way users interact with it.

• Treat OrangeCheck as Bitcoin-address signed-message middleware with delegation extensions, not as a general identity layer.

• Sources:

  • https://docs.ochk.io/
  • https://docs.ochk.io/charter
  • 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
  • https://github.com/orangecheck

• Last reviewed: 2026-06-05 UTC