Cowrie Research

boltz

4 min read

Boltz

  • Name: Boltz
  • URL: https://boltz.exchange/
  • Category: Bitcoin swap-operator company / Lightning-Liquid routing and node-middleware operator / hosted API and support boundary
  • Tags: bitcoin-ecosystem
  • Summary: Boltz belongs in companies/ because the useful control surface is not only a non-custodial swap exists. A named operator runs the official backend that powers boltz.exchange, publishes the public API other clients rely on, ships the supported boltzd / boltzcli workflow, and sets the docs, support, recovery guidance, and public node posture many users inherit. The practical question is who decides which pairs, routes, defaults, and operational workflows stay live and documented. That authority sits with the Boltz operator boundary more cleanly than with the product note alone.
  • What it does:
    • Operates the official Boltz Backend that powers swaps at boltz.exchange
    • Exposes the REST API used to query supported pairs and create or monitor swaps
    • Ships Boltz Client as an operator-facing daemon-and-CLI stack (boltzd and boltzcli) for CLN- or LND-connected workflows
    • Packages operational guidance for unattended channel rebalancing, payment acceptance, standalone mode, and swap recovery through the official client docs
    • Publishes the main docs portal, client docs, support center, and official repos that shape how integrators and node operators interact with the stack
    • Maintains public Lightning node presence and operator-facing support / blog channels that make the company boundary more than a static code repository
  • Key claims:
    • The official backend README says This is the source of the official Boltz Backend powering swaps at boltz.exchange, which is the clearest first-party statement that a named operator boundary exists above the protocol mechanics
    • The same README says the backend enables non-custodial swaps between different Bitcoin layers and exposes a RESTful HTTP API for supported pairs plus swap creation and monitoring, making the hosted service edge explicit
    • The official client README says Boltz Client connects to CLN or LND nodes and allows fully unattended channel rebalancing or accepting Lightning payments without running a node via the Boltz API, which shows the company is shipping more than a website or thin SDK
    • The client docs say the stack is composed of boltzd and boltzcli, and define design principles as CLI-first, CLN-first, Liquid-first, and Self-contained, which is unusually direct evidence of the operator posture and workflow defaults users inherit
    • The client docs also document standalone mode, swap-mnemonic backup and recovery, Lightning-node connectivity requirements, and the exact config shape for CLN/LND integrations, which means the operator is publishing real custody-adjacent and recovery-adjacent workflow guidance rather than only market-facing copy
    • The official repos point users to Boltz’s support center, docs home, blog, social accounts, and public Lightning channels, reinforcing that the practical surface is a maintained operating shell rather than a detached protocol artifact
  • Whitepaper: No standalone Boltz company whitepaper is the important artifact here. The strongest source snapshot remains the existing project-layer primary-source capture in ../whitepapers/boltz-primary-sources-2026-04-28.md, especially the backend README, client README, and client docs.
  • Sources:

Internal linkages

  • Product-layer note: boltz.
  • Strongest hosted-LN workflow comparison: lightspark.
  • Useful Bitcoin infrastructure company contrast: blockstream.
  • Useful product-level peer when the question is still swap mechanics rather than the operator shell: lightning-loop.

Protocol / company boundary

  • boltz should stay on the product and mechanism surface: non-custodial swaps across Bitcoin layers, the boltzd / boltzcli workflow, Liquid-heavy routing, and the exact node-middleware behavior the stack enables.
  • This company note isolates the named operator boundary above that surface: the official backend, public API availability, supported-pair policy, documentation and support workflow, recovery guidance, and the public node / channel presence that many users will treat as the default path.
  • That split matters because how do Boltz swaps and client tooling work? and who controls the easiest hosted API, documentation, and operational shell around them? are related but not identical questions.
  • The non-custodial claim does not erase the operator boundary. Users may still depend on company-shaped defaults for pair support, service availability, timeout behavior, support handling, and recommended recovery paths.

Control surface

  • Practical leverage sits in which swap pairs and routes are supported, how the official backend and API behave, what timeout and recovery assumptions the docs normalize, how strongly the stack pushes Liquid-first versus mainchain paths, and how much of the workflow is delegated to the hosted Boltz edge instead of kept fully local.

  • The client docs make the operator boundary concrete: node requirements, standalone mode, macaroons, swap mnemonic handling, and CLI defaults are all part of the live experience rather than neutral background detail.

  • Read the durable risk here as who operates and documents the easiest Bitcoin-layer swap and node-middleware path?, not only as is the swap contractually non-custodial?

  • Last reviewed: 2026-08-09 UTC

Graph View

Backlinks