Compared to other sybil-resistance primitives
OrangeCheck is one tool in a crowded category. This page sets out where it differs from the obvious alternatives, so you can pick the right one for your use case — even if it's not us.
The one-paragraph framing
Every sybil filter trades friction for signal. KYC costs dignity and creates a honeypot. Proof of personhood (Worldcoin, BrightID) requires a biometric or social oracle. Reputation graphs (Gitcoin Passport) require a pre-existing graph and a scoring committee. OrangeCheck asks for opportunity cost: hold Bitcoin unspent, prove it with a signature. Honest users pay nothing but time; attackers pay real Bitcoin at scale.
The comparison
| System | Signal | Requires | Custodial | Offline-verifiable | Chain | Openness |
|---|---|---|---|---|---|---|
| OrangeCheck | Bitcoin UTXO age × value | BIP-322 signature | ❌ no | ✅ yes | Bitcoin | MIT + CC-BY |
| Worldcoin / World ID | Iris scan | Orb visit, custom hardware | ❌ no (keys user-held) | ❌ no (needs network) | Worldchain (OP rollup) | Proprietary client, open SDK |
| Gitcoin Passport | Stamp aggregation | Third-party stamp graph | ❌ no | ❌ no (score is off-chain) | Ethereum (EAS) | Open source |
| BrightID | Social-graph verification | A verification party + meet | ❌ no | ❌ no (graph state queried) | App-layer | MIT |
| Sismo / zkBadges | zk-proof over on-chain history | An EVM address + history | ❌ no | ✅ yes (zk circuit) | Ethereum | MIT |
| EAS (Ethereum Attestation Service) | Arbitrary signed attestations | An EAS schema + issuer | ❌ no | ✅ yes (on-chain) | Ethereum (per-tx gas) | MIT |
| Nostr NIP-05 | DNS ownership | A domain | ❌ no | ❌ no (HTTP fetch) | none (HTTP) | Spec open |
| Nostr NIP-58 (badges) | Issuer-granted badge | An issuer's npub | ❌ no | ✅ yes (signed event) | Nostr | Spec open |
| Privy / Dynamic / Magic | Custodial embedded wallets | Email / phone / social | ⚠ yes (key custody) | ❌ no | Multi-chain | Proprietary |
| Civic / Fractal ID | Third-party KYC | Document upload | ❌ no (data in vendor) | ❌ no | Multi-chain | Proprietary |
Where OrangeCheck fits best
✅ Pick OrangeCheck when:
- Your users already hold Bitcoin. Asking them to sign a message costs zero and is a ~30-second UX.
- You want a permissionless filter. No whitelist, no governance vote, no oracle. Anyone with
Nsats held forNdays passes, period. - You need offline, deterministic verifiability. An attestation verifies from its JSON envelope alone — no API call, no oracle, no network dependency.
- Your gate logic can be linear in stake (airdrops, relays, governance weight). Sat-value is a raw number your app can compose freely.
- You care about chain-agnostic economic signal. Bitcoin is the most credibly-neutral economic layer on the open internet; it's adversary-agnostic in a way other chains aren't.
- You want to ship today. Three packages, one
curl, no SDK contract to negotiate.
Where OrangeCheck is wrong for you
⛔ Don't pick OrangeCheck when:
- You need proof of uniqueness (one-vote-per-human). OrangeCheck proves stake control, not personhood. A whale can produce N attestations from N addresses. If one-human-one-vote is the hard requirement, biometric (World ID) or social-graph (BrightID) systems are the right tool. Raise
min_satsto make multi-address attacks expensive, but don't expect to hit zero. - Your users don't hold Bitcoin and never will. Forcing someone to buy sats just to post is a terrible UX. Use a graph (Passport) or a free credential (NIP-05) instead.
- You need privacy-preserving proofs. OrangeCheck attestations are public by design — the bonded address,
sats_bonded,days_unspentare all visible. Sismo and zk-badges exist specifically for the "prove stake without revealing wallet" case. - You're building an EVM-first dApp where users already have an ENS name, an EAS history, and a smart-wallet flow. EAS + ENS lives right next to your existing infra; OrangeCheck is a detour.
- You need KYC/AML for regulatory reasons. OrangeCheck is not a compliance product. It proves stake, not identity. Use a licensed KYC vendor (Civic, Fractal, Sumsub) for those requirements — see Terms §10 on regulatory status.
Stacking OrangeCheck with other primitives
The better pattern is often layering:
- OrangeCheck + NIP-05 — "this npub controls
alice@example.comAND staked 100k sats for 30 days." Handle claim + economic skin. - OrangeCheck + BrightID — "humanness + economic cost." Raises the bar for sybils without requiring ruinous bonds.
- OrangeCheck + EAS — use EAS as the attestation layer if you're Ethereum-native; use OrangeCheck as the Bitcoin-stake input schema. EAS stores the signed statement; OrangeCheck defines what it proves.
- OrangeCheck as the floor — require a cheap OrangeCheck attestation (10k sats × 30 days) as the entry bar, then use reputation / EAS stamps / BrightID to rank above the floor. Sybils filter at the economic gate; ranking happens in domain-specific logic.
What makes OrangeCheck unique
Three things, all structural, that no other system in the matrix has simultaneously:
- Uses Bitcoin UTXOs as the signal. The most credibly-neutral economic layer, no oracle required. Most alternatives use EVM balances (volatile, correlated), off-chain graphs (social), or biometrics (require custom hardware).
- Verifiable offline. An air-gapped machine with the canonical message + signature + chain state can verify an attestation end-to-end. No call to
ochk.iorequired — the protocol is the authority; we're just one implementation. - Transparent ledger. Sybil armies with
Naddresses holdingMsats each are all visible on-chain. You can audit the economic footprint of a filter in public, something no zk / social / biometric system lets you do.
Further
- What is OrangeCheck? — the economic thesis in one page.
- Scoring — how raw metrics become a number.
- Security implications — what attestations expose and don't protect against.
- FAQ: How is this different from Worldcoin?