Trust & security

What to trust, and what to verify.

BitUnlock is deliberately narrow: it verifies payments and releases a per-buyer encrypted delivery. It never holds your money. This page states exactly where trust still lives — and how to check each claim yourself.

Limited mainnet beta. Real Lightning payments work, but the service is young and unproven at volume. Use small amounts and a dedicated wallet. Don't connect a wallet holding meaningful funds, and don't make BitUnlock the sole path to an irreplaceable delivery secret yet. \u201cAccepting commerce\u201d (the signed policy status) is a separate axis from operational maturity.

What BitUnlock can and cannot do

The boundaries below are enforced by design, not by promise. Where trust remains, it is named plainly.

It cannot

  • Issue a wallet spending request. Its NWC RPC allowlist contains only make_invoice, lookup_invoice, and get_info, even when a connected wallet advertises broader permissions.
  • Take custody of funds. Each payment leg is a separate invoice minted on that recipient's own wallet; sats go buyer \u2192 recipient directly. The Worker never holds or forwards funds.
  • Release a secret without full payment. Every quoted leg must settle first. Partial, expired, mismatched, or replayed payments never unlock.
  • Read a Nostr private key. Sellers and buyers authorize with NIP-98 signatures; keys never leave the signer.

It can (residual trust)

  • Refuse or delay fulfillment. It is an availability dependency. If it is down after payment, your funds are still yours (legs are direct), but delivery waits until it returns.
  • Learn that a buyer bought from a seller. Order metadata is visible to the operator.
  • Hold seller material temporarily. Delivery secrets, wallet credentials, execution-provider API keys, and private product prompts/configuration are encrypted in service custody. Credential theft could expose wallet funds when a connected wallet grants broad permissions, even though BitUnlock never invokes spending methods.
  • Send execution data to a third party. For an execution product, the selected provider receives the bounded input, private system prompt, model request, and whatever metadata its API observes. Provider availability, retention, billing, and model behavior remain outside BitUnlock's control.
  • Incur tenant inference cost. A paid execution consumes the tenant's provider balance. Retry budgets and health alerts bound abuse and surface failures; they do not guarantee provider credit or output quality.
  • Change its published fees going forward. Each order snapshots its fee policy immutably, but future policy versions can differ.

Verify this service

Don't take the claims above on faith — pin the identity and read the signed, machine-verifiable sources.

Pin the pubkey. Every signed policy and product tag names it. A client should verify the discovery document is signed by exactly this key before trusting a quote.

Report a vulnerability

Send an encrypted Nostr DM before disclosing anything publicly. BitUnlock is the primary contact; thePR0M3TH3AN is the fallback.

BitUnlock on NostrthePR0M3TH3AN on Nostrsecurity.txt
BitUnlocknpub1q8lu523pnj3rkfhrfdyxycydu75wgzpcy8s4sjs23w2w5jaaex9q748hl8
thePR0M3TH3ANnpub15jnttpymeytm80hatjqcvhhqhzrhx6gxp8pq0wn93rhnu8s9h9dsha32lx