live · mainnetoc · docs
specs · api · guides
docs / which protocol do i need?

Which protocol do I need?

A short decision tree. None of these are mutually exclusive — most real deployments compose two or three. But start with exactly one.

Decision tree

flowchart TD
    Q0["Is this user / caller<br/>legitimate or a bot?"]
    Q0 -- "yes — sybil filter" --> ATTEST["<b>OC Attest</b><br/>proof of Bitcoin stake<br/><i>/attest</i>"]
    Q0 -- "no — what do you want?" --> Q1{What do you want to do?}

    Q1 -- "send a message<br/>only X can read" --> LOCK["<b>OC Lock</b><br/>E2E encryption addressed<br/>to a Bitcoin address<br/><i>/lock</i>"]
    Q1 -- "prove X said Y<br/>at time T, permanently" --> STAMP["<b>OC Stamp</b><br/>Bitcoin-block-anchored<br/>signed statements<br/><i>/stamp</i>"]
    Q1 -- "stake-weighted poll<br/>that can't be sybil-farmed" --> VOTE["<b>OC Vote</b><br/>three weight modes,<br/>deterministic tally<br/><i>/vote</i>"]
    Q1 -- "agent / bot signs<br/>on my behalf, revocably" --> AGENT["<b>OC Agent</b><br/>scoped, bonded,<br/>revocable delegations<br/><i>/agent</i>"]
    Q1 -- "swear word against a<br/>future-verifiable claim" --> PLEDGE["<b>OC Pledge</b><br/>bonded commitments,<br/>enforced by exposure<br/><i>/pledge</i>"]

    classDef base fill:#0a0a0a,stroke:#f97316,stroke-width:2px,color:#fafafa;
    classDef question fill:#18181b,stroke:#52525b,color:#fafafa;
    class ATTEST,LOCK,STAMP,VOTE,AGENT,PLEDGE base;
    class Q0,Q1 question;

Match by use case

You're building…Pick
A forum, Nostr relay, airdrop allowlist, dApp gateOC Attest
A dead-drop / sealed-message box addressed to a BTC addressOC Lock
A commit / release signing flow with durable provenanceOC Stamp
A DAO proposal vote with stake × time weightingOC Vote
Delegated signing for an automated pipeline or autonomous botOC Agent (scoped, bonded, revocable)
A research preregistration / public commitment with bonded stakeOC Pledge
An SLA promise with cryptographic resolution and reputational consequenceOC Pledge (resolves via OC Stamp stamp_published)
An open-source delivery commitment tied to a Bitcoin block heightOC Pledge (resolves via on-chain block-height oracle)
A social network where posts are cryptographically bound to Bitcoin identityOC Attest + OC Lock
A governance portal where votes are public + weighted by stakeOC Vote + OC Attest (Attest gates who can vote; Vote weights what they cast)
An archive whose entries prove both authorship and timestampOC Stamp (authorship via BIP-322, time via OTS anchor)
A skin-in-the-game prediction with public exposure on broken wordOC Pledge + OC Attest (Attest is the bond; Pledge is the claim)

Common patterns

Attest as the floor

Most deployments use OC Attest as a cheap entry gate (e.g. 10 000 sats for 30 days) and then layer a domain-specific protocol on top. The Attest proof filters bots at the door; the upstream protocol handles the actual workflow.

Stamp + Attest

An OC Stamp envelope can optionally embed an OC Attest attestation_id as a "stake at signing" signal. This lets anyone verifying the stamp also see how much stake the signer held at the moment they signed — useful for review sites, audit trails, and reputation systems.

Vote + Attest

OC Vote's sats_days weight mode resolves voter weight directly from the signer's Bitcoin UTXOs, which is an Attest-adjacent concept. You don't need an Attest attestation to run a Vote poll — but if you want to gate who can cast a ballot at all, Attest is the door.

Pledge + Attest

A Pledge's bond is an Attest reference — bond.attestation_id points at the sats × days the pledger has staked behind their word. There is no Pledge without Attest. Threshold the bond minimum to filter cheap commitments.

Pledge + Stamp

The canonical pledge-resolution mechanism is stamp_published: the pledger satisfies the claim by publishing an OC Stamp envelope that matches a declared content predicate before the deadline. Pledge writes the contract, Stamp closes it.

Pledge + Vote

When a pledge's outcome is contested (e.g. "did the deliverable ship on time and to spec?"), the dispute mechanism can be a stake-weighted OC Vote poll with the pledger and counterparty bonded. The tally settles the pledge.

If this still doesn't fit

OrangeCheck isn't the right tool for:

  • Proof of personhood / unique-human guarantees. None of these protocols prove that a BTC address maps to a unique human. Use Worldcoin / World ID, BrightID, or similar.
  • Private / zero-knowledge stake proofs. Every OrangeCheck proof is public by design. For privacy-preserving stake signals, look at Sismo or zkBadges.
  • Generic KYC / compliance. None of these protocols collect or verify personal information. They prove cryptographic facts about Bitcoin UTXOs and signatures.