Cowrie Research

breez

4 min read

Breez

  • Name: Breez
  • URL: https://breez.technology/
  • Category: Bitcoin payments SDK / Lightning infrastructure / app-embedded wallet and stable-balance tooling
  • Tags: bitcoin-ecosystem
  • Summary: Breez is mostly embedded Bitcoin payment infrastructure, not a consumer wallet note. The real product is the SDK layer: app-integrated Lightning, Spark or Liquid variants, passkey onboarding, sync, swaps, and stable-balance packaging for teams that want Bitcoin payments without building the whole stack themselves. The separate operator / entity boundary now lives in breez, which is the cleaner place to reason about API-key issuance, migration steering, reference-app distribution, and other company-run control surfaces around the SDK.
  • What it does:
    • Provides SDKs for integrating non-custodial bitcoin payments and wallet functions into apps, services, wallets, and neobanks
    • Supports multiple implementation paths including Breez SDK - Spark and Breez SDK - Liquid, with different underlying settlement/connectivity models
    • Exposes payment rails and formats including Lightning addresses, LNURL variants, Bolt11/Bolt12, BTC addresses, Spark addresses, BIP353, and Liquid-based flows depending on implementation
    • Adds higher-level product features such as passkey login, stable-balance UX, multi-device/app sync, external signers, fiat onramps, and language bindings across major mobile, web, and backend stacks
    • Publishes substantial open-source implementation material through public repositories, CLI examples, bindings, demo apps, and SDK documentation
  • Key claims:
    • Homepage and SDK pages position Breez as a way to add “instant, non-custodial bitcoin” to any app or service and repeatedly frame value transfer as a developer-embeddable feature rather than a standalone consumer product
    • Official SDK docs say the product is “nodeless,” end-to-end, non-custodial, and intended to remove the need for third parties while simplifying Bitcoin and Lightning integration work
    • Spark docs show Breez expanding beyond classic Lightning flows into a Bitcoin-native Layer 2 path with Spark payments, passkey login, stable-balance support, Spark token support, and multi-device sync
    • Liquid docs show a parallel implementation built around Liquid + Lightning interoperability, submarine swaps, reverse submarine swaps, on-chain interoperability, and multi-asset support including USDT on Liquid
    • Public GitHub materials show that the real source of truth is heavily docs/repo driven: Spark and Liquid documentation sites, open-source SDK repositories, multi-language example CLIs, and a public org positioning Glow as a white-label showcase app
    • Case-studies copy claims 75+ apps and services are building with Breez, which helps place it as ecosystem infrastructure rather than only an internal SDK experiment
  • Whitepaper: No classic whitepaper or litepaper was found during this pass. The strongest primary materials were Breez’s homepage, SDK landing page, Spark and Liquid documentation, public GitHub organization, and Spark SDK repository; see ../whitepapers/breez-primary-sources-2026-04-25.md.
  • Sources:

Internal linkages

  • Separate the product surface from the operator boundary: use breez when the question is who controls API-key issuance, migration guidance, sync and passkey defaults, white-label distribution, or partner composition around the SDK.
  • App-embedded Bitcoin payments peer built around a different stack lineage: lightning-dev-kit
  • Packaged backend contrast for teams that want an API-first Lightning service rather than an embedded SDK: phoenixd

Protocol / company boundary

  • Keep this note on the product family itself: Breez SDK - Spark, Breez SDK - Liquid, passkey onboarding, sync, swaps, stable-balance packaging, supported payment formats, and the implementation choices developers wire into their own apps.
  • Use breez for the company-run layer above that surface: API-key issuance, Spark-versus-Liquid steering, migration guidance, hosted coordination around sync and passkeys, reference-app distribution, partner composition, and the named operator shell shaping what downstream teams inherit by default.
  • That split matters because what does the Breez SDK expose? and which company is normalizing the recommended rail, onboarding path, and white-label distribution pattern? are related but not identical questions.

Control surface

  • At the product layer, practical leverage accumulates around which SDK mode gets normalized, which liquidity and swap paths are first-class, how passkey or sync workflows are mediated, and how much policy the host app can silently impose on top of ostensibly non-custodial rails.

  • The broader distribution, migration, and operator-shell questions now point upward to breez.

  • Read Breez as wallet-and-payment middleware. The app shell is downstream of that.

  • Last reviewed: 2026-08-13 UTC

Graph View

Backlinks