OC Attest

Proof of Bitcoin stake for the open web. OC Attest is the base-layer sybil-resistance primitive: a signer proves they control a Bitcoin address and have held N sats unspent for N days. Any verifier can re-check the claim in one HTTP call, offline, without trusting a third party.

What it proves

A valid OC Attest attestation proves three things cryptographically:

1. You control a specific Bitcoin address (BIP-322 signature over a canonical message).
2. The address holds N sats right now (re-derived from live chain state at verify time).
3. The bonded UTXO has been unspent for N days (confirmation time vs. now).

And one thing self-assertedly:

4. The holder claims handles like github:alice, nostr:npub1…, etc.

Claims 1–3 are mathematical. Claim 4 is an assertion — verify handle ownership out-of-band if your gate depends on it.

Who this is for

• Platforms — forum operators, Nostr relay operators, airdrop distributors, DAO coordinators, Discord bot authors.
• Integrators — anyone who needs to gate access on a credible economic cost without running a KYC pipeline.
• Signers — anyone on the open internet who wants to stop being mistaken for a bot and doesn't want to hand KYC data to every platform they interact with.

Who this is NOT for

• You need proof of personhood. Use World ID or BrightID; OC Attest is a cost filter, not a humanness proof.
• You need private claims. OC Attest proofs are public by design.
• You need regulatory KYC. Use a licensed provider.

Section contents

• How it works — sign → publish → verify, the whole protocol on one page
• Scoring — sats_bonded, days_unspent, score_v0 (advisory)
• Verification — the exact checks a verifier performs
• HTTP API — /api/check, /api/verify, /api/challenge, /api/discover
• Guide: gate an Express route — drop-in middleware in 10 lines
• Guide: filter an airdrop — turn a candidate list into a sybil-resistant allowlist
• Guide: sign in with Bitcoin — signed-challenge session auth

Read the shared layer first

Many of the concepts an Attest integrator needs are shared across the OrangeCheck ecosystem:

• Canonical message format
• BIP-322 signing
• Nostr kind-30078 publication
• Conformance vectors
• Security model

If you've never touched OrangeCheck before, read those first.