Payment-verified delivery

Sell the file. Keep the key private.

BitUnlock is a hosted Nostr unlock service for digital stores. It verifies every required Lightning split, then sends the buyer their encrypted delivery—without asking each store to operate a bot.

The commerce core needs no LLM. Payment and entitlement decisions stay deterministic; optional execution products may call a tenant-configured provider.

One service, many stores

A small integration surface.

Your storefront owns its checkout experience. BitUnlock owns payment verification, order serialization, and idempotent private delivery.

01

Register the product

Send the signed product coordinate, encrypted delivery secret, fee cap, and seller authorization.

02

Present one payment plan

Receive an immutable quote — one invoice, or a seller-and-BitUnlock split, depending on the product — paid directly to each wallet.

03

Let BitUnlock deliver

After all legs settle, the service sends one idempotent NIP-44 unlock to the authenticated buyer.

Beyond one-time downloads

Gated access, not just file delivery.

The same verified-payment core also backs recoverable, renewable, and revocable access — for a license key, an API, or any gated experience, not only a download.

License keys and API access, too

Delivery isn't limited to a claim URL — a license key or any structured payload is delivered the same verified, buyer-private way.

Recoverable from any device

Every purchase is a signed entitlement receipt a buyer can recover later — no lost download link, no re-purchasing to prove ownership.

Rentals and renewable terms

Sell time-boxed access instead of perpetual access. Another completed purchase renews the term; BitUnlock does not automatically or recurringly charge the buyer.

Revoke access on your terms

Sellers can explicitly revoke a specific buyer's access — useful for refunds, disputes, or ending a term early.

Beyond static files

Pay, then trigger a real call — not just a download.

A product can be a bounded, server-run call to a third-party provider instead of a stored payload: each completed purchase authorizes one paid execution, and BitUnlock delivers the result through the same verified, buyer-private flow. Provider Connections support Routstr and OpenAI-compatible APIs such as OpenRouter.

Your provider credential, held for you

Register your execution provider's API key once; BitUnlock validates it live, encrypts it at rest, and never returns it to anyone — including you.

The buyer never sees your prompt

Your system prompt and provider configuration stay encrypted server-side. The selected provider receives them to perform the call; the buyer only receives their decrypted result.

Bounded by design

Image size, output length, timeout, and retry limits are all set per product — an oversized or malformed input is rejected before it ever reaches your provider.

Same verified-payment core

Identical quote, refresh, unlock, and entitlement contract as a static product — a buyer's client doesn't need special-case logic to support it.

Developer quickstart

One public contract. Any Nostr storefront.

Use the browser ESM SDK or generate a client from OpenAPI. Verify signed discovery and pin the production service identity before sending secrets or accepting quotes.

Everything needed for an MVP

The product schema, signed vector, complete seller-and-buyer example, and agent-readable guide are public and versioned with the service.

  • Publish the exact signed kind 30078 product contract
  • Authorize protected calls with NIP-98
  • Render and pay every invoice returned by the payment plan
  • Decrypt buyer fulfillment with NIP-44
  • Keep storefront-specific metadata storefront-owned
import {
  createBitUnlockClient,
  buildBitUnlockProductEventTemplate
} from "/assets/bitunlock-sdk.js";

const client = createBitUnlockClient({
  endpoint: "https://api.bitunlock.network",
  expectedServicePubkey:
    "66be61cf5b8d286391f7b1a72ffa7c799ec2dc49eff0830c40df1cc964e6787d",
  signer: window.nostr.signEvent
});

const { document } = await client.discoverPolicy();
// Verify first. Then build, publish, and register.

Limited mainnet beta: production uses real Lightning payments. Use small amounts and a dedicated wallet. A hosted fake-sats sandbox is not public yet.

Security model

Custody minimized. Boundaries explicit.

BitUnlock cannot make a delivered digital file uncopyable. Its job is narrower and testable: do not release the delivery secret or run the paid execution until the authorized payment conditions are proven.

No personal or admin nsec in the Worker

Sellers, buyers, and the operator authorize with NIP-98. Only a separate, rotatable service key is stored as a protected Cloudflare secret.

Wallet methods constrained in code

NWC connections advertising pay_invoice or other extra methods are accepted for provider compatibility, but BitUnlock's RPC allowlist permits only invoice creation and status calls. NIP-44 transport is preferred; legacy NIP-04 remains available for providers such as CoinOS and does not expand the RPC allowlist. Seller credentials are AEAD-encrypted in D1. A restricted dedicated wallet remains safest because another client holding a broad credential may be able to spend.

Execution custody is explicit

Provider keys and private prompts are encrypted in D1. For a paid execution, the selected third party receives the bounded input and prompt; its availability, retention, billing, and model behavior remain external dependencies.

All legs or no unlock

Partial, expired, mismatched, or replayed payments cannot transition an order to fulfillment.

Private and idempotent delivery

Each buyer receives one persisted NIP-44 envelope per product, with repeat-safe retrieval and serialized order mutation.