FAQ

Do coins move?

No. The protocol signs messages; it doesn't spend UTXOs. Your funds never leave your wallet. The only thing the Bitcoin chain is used for is reading UTXO state at verification time.

Is this custodial?

No. Nothing in the protocol requires a third party to hold funds, keys, or signatures. The signed message + signature is the proof; you share it directly.

Is this reputation?

No, and calling it that misleads users. Reputation implies social judgment. OrangeCheck is a cryptographic stake receipt — it tells you someone chose to lock opportunity cost against a handle. That's a different signal.

Is this identity / KYC?

No. Address control plus a self-asserted handle is not proof-of-human. A proof tells you "whoever signs this controls a Bitcoin address and claims to be @alice on GitHub." Whether @alice is a real human, or the same @alice you're thinking of, is out-of-band.

Which wallets work?

Anything that signs messages. BIP-322 is preferred (works with all address types). Legacy signmessage works for P2PKH (1…) addresses only.

Browser: UniSat, Xverse, Leather, Alby.
Desktop: Sparrow, Bitcoin Core, Electrum.
Hardware: via PSBT — Coldcard, Trezor (with limitations), Ledger (limited).

See the @orangecheck/wallet-adapter package for browser normalisation.

What prevents faking?

Three layers:

Bitcoin signatures are cryptographically unforgeable. BIP-322 verification is deterministic public-key math.
Chain state is publicly auditable. sats_bonded and days_unspent are re-derived from mempool.space / blockstream.info / your own node.
Identity bindings are self-asserted. Verifiers MUST check handle ownership out-of-band; nothing in the protocol is "trust the claim".

The only way to fake a high-sats × days attestation is to actually hold that Bitcoin for that long.

What if I spend my bonded UTXOs?

The next verification reports bond_insufficient (if you declared bond:) or bond_zero (if not). Every consumer sees this within one block. There is no grace period — it's live chain state.

Can I revoke a proof?

Two ways.

Implicit — spend the bonded UTXOs. Proof immediately invalidates.
Explicit replacement — publish a newer attestation for the same address; Nostr kind-30078 replacement semantics keep the newest.

There's deliberately no explicit "revocation event" kind. Chain state is authoritative.

How long do proofs last?

Forever, or until:

You spend the bonded UTXOs.
The expires: extension (if you set one) passes.
You publish a replacement attestation.

A proof created in 2026 is still verifiable in 2030 as long as the bonded UTXOs exist.

Can I use a fresh address each time?

Yes — recommended for privacy. Each attestation links one address to one set of handles. Using a fresh address per context (forum vs airdrop vs profile) prevents cross-context linkability.

What if someone buys a ton of coins to game this?

They can. OrangeCheck is a cost-floor raiser, not a moat. A well-capitalised attacker can satisfy any threshold.

But they have to actually hold the Bitcoin — they can't rent it, they can't collateralise it, and they can't timestamp-backdate days_unspent against a sincere snapshot. The cheapest credible attacker still has to buy and hold N sats for N days per fake identity.

For high-value flows (airdrops, payment-gated actions), pair OrangeCheck with additional policy — rate limits, per-address allocation caps, captive-audience checks.

Why Bitcoin, not Ethereum or some other chain?

Because the opportunity cost of holding is the signal, and Bitcoin's is the most legible, adversary-agnostic, and stable of any open chain. Ethereum gas is volatile and staking is loaded with MEV dynamics. Other-chain reserves aren't credibly neutral. Bitcoin UTXOs give us the cleanest economic signal on the open internet.

Also a rule: "If a feature would work identically on Ed25519, it doesn't belong here." The Bitcoin economic layer is load-bearing.

How is this different from NIP-05?

NIP-05 proves DNS → Nostr npub mapping. It says "I can edit example.com/.well-known/nostr.json, therefore I control @alice@example.com."

OrangeCheck proves Bitcoin address → multi-protocol handle mapping with quantifiable commitment (sats + time). Different shape, different signal.

The two compose — a user can have both. NIP-05 says "this is alice@example.com"; OrangeCheck says "alice has 1M sats locked for a year."

How is this different from Worldcoin / Proof of Personhood?

Proof of Personhood systems aim to assert "this is one unique human." They usually involve biometric enrolment, liveness checks, or a trust network.

OrangeCheck makes no personhood claim. A single human can hold many OrangeCheck proofs (different addresses, different contexts). A single OrangeCheck proof can belong to a business, a DAO, an automated service.

OrangeCheck is a cost filter, not an identity system. If you need unique-human guarantees for a one-person-one-vote scenario, OrangeCheck is not sufficient — but it pairs well with those systems as an additional signal.

Do I have to publish to Nostr?

No. Publishing is optional. The attestation envelope is a self-contained JSON blob that verifies offline. You can:

Email it.
Host it on your own server.
Put it in a QR code.
Embed it in a forum profile.

Nostr is just the most convenient decentralised distribution channel.

Is there a paid tier?

Eventually, yes — the free tier is 60 req/min/IP for /api/check (similar for the other endpoints). A paid tier will add webhooks, SLAs, higher rate limits, custom scoring namespaces, and private attestation relays. Contact us via the /contact form for enterprise inquiries.

Can I self-host the verifier?

Yes. The entire stack is open-source at github.com/orangecheck/oc-web. Run your own verifier pointed at your own Esplora-compatible Bitcoin node and your own (or any public) Nostr relays.

What about privacy-preserving proofs (ZK)?

Out of scope for v1. The address is public by design so any verifier can recompute. For privacy, rotate addresses — use a fresh, single-purpose address per proof.

Future versions may support ZK-style private-balance proofs, but the current protocol prioritises offline-verifiability and transparency.

Why is `orangecheck` the header literal instead of something versioned like `orangecheck v0`?

The header is frozen at v0. Any change to the message format — including the header — requires a version bump and breaks every existing signature. Future versions will use a different header (e.g., orangecheck v1), so the absence of a version number in v0's literal is intentional.

FAQ