Overview
OC Lock is end-to-end encryption keyed to Bitcoin identities. You sign one BIP-322 message to register a device, then any sender can encrypt to your Bitcoin address. Decryption happens locally in the browser that holds the device key — under three seconds, zero on-chain transactions.
It's a sub-product of OrangeCheck. Lock uses OrangeCheck's identity primitive (proof of control over a Bitcoin address via BIP-322) as the identity layer for a sealed-envelope protocol. Where OrangeCheck answers "is this address real stake?", Lock answers "only the holder of this address can read this."
Who this is for
- People who want E2E without PGP. Sign a wallet message instead of managing a keyring.
- Senders who want identity-bound encryption. Encrypt to a public Bitcoin address. The recipient doesn't need to have used OC Lock before you decide to send.
- Integrators. Embed sealed envelopes in any transport — Nostr DMs, email attachments, paper QR codes, URLs.
- Protocol implementers. The specification is tight. The reference SDK is MIT and shippable today.
Who this is not for
- You want access control enforced by Bitcoin transactions. That was v1 (adaptor signatures and Proof-of-Access). It didn't ship for reasons that are inherent to the design; the postmortem explains why. v2 treats Bitcoin as an identity system, not an access oracle.
- You want real forward secrecy. Device-key rotation gives coarse-grained FS; for per-message ratchets use Signal.
- You want post-quantum security today. Not yet. A PQ variant that wraps the content key under Kyber is on the v3 list.
Where to go next
| You want to… | Read |
|---|---|
| Install and seal a message | Quickstart |
| Understand how v2 works | Protocol walkthrough |
| Read the normative rules | Specification |
| Know every field in an envelope | Envelope format |
| Understand device keys end-to-end | Device keys |
| DM someone via their Bitcoin address | Chat transport |
| Know why v1 failed | Why v2 |
| Answer a specific question | FAQ · Glossary |
House rules
- No servers in the critical path. Identity mode is pure client-side crypto plus Nostr for the device directory. A relay is only introduced for payment-gated mode and is always named.
- No custody, ever. Funds stay in user wallets. OC Lock never holds private keys.
- Every device record is verified before use. Senders run a BIP-322 check on each fetched record before adding it to the candidate set; a hostile relay can't funnel envelopes to an attacker's key.
- Open protocol. The spec is MIT; the packages are MIT. You can run this against any client that canonicalizes envelopes the same way.
- Bitcoin is load-bearing. If a feature works identically with Ed25519 or a JWT, it doesn't belong here.
Architecture in one paragraph
Every user has a Bitcoin address. On first visit to this browser, they generate an X25519 keypair, sign a BIP-322 binding statement tying the pubkey to the address, and publish a Nostr kind:30078 event addressed by their Bitcoin address. Senders look up the recipient's device key from Nostr, derive a shared secret via X25519 ECDH, wrap a fresh AES-256-GCM content key, and produce a self-contained envelope. The envelope is signed with the sender's Bitcoin wallet (BIP-322 over the envelope id). Recipients match envelopes against their local device secret, unwrap, and decrypt. No chain transactions. No server state.
Related work
- OrangeCheck — sybil-resistance via proof of Bitcoin stake. Lock depends on OrangeCheck's BIP-322 flow; sender and recipient sign the same kind of canonical message.
- Nostr (NIP-01, kind 30078) — the addressable event store for the device directory. Lock does not depend on any Nostr social features.
- WebCrypto /
@noble/*— the crypto primitives are standard. No WASM dependency.