Boltz

• Name: Boltz
• URL: https://boltz.exchange/
• Category: Bitcoin layer-bridging infrastructure / non-custodial swap backend / Lightning-Liquid node middleware
• Tags: bitcoin-ecosystem
• Summary: Boltz is a swap backend plus node middleware for moving liquidity between Lightning, Bitcoin, and Liquid. The useful point is not the website. It is the operating stack: a hosted API/backend, a self-run daemon and CLI for CLN or LND operators, and a Liquid-heavy route for swaps, rebalancing, and payment handling without taking custody of user funds. The broader named-operator boundary now lives separately in boltz when the real question is who runs the official backend, publishes the default docs and recovery guidance, and decides what pair support or service posture integrators inherit.
• What it does:
  • Operates a non-custodial swap service for moving between different Bitcoin layers, with the public site positioning Boltz as a Bitcoin bridge
  • Publishes the production backend that powers boltz.exchange and exposes a REST HTTP API for supported pairs plus swap creation and monitoring
  • Provides Boltz Client, a daemon (boltzd) and CLI (boltzcli) that connect to CLN or LND nodes and automate swaps via the Boltz API
  • Supports operational use cases like fully unattended channel rebalancing and accepting Lightning payments without running a Lightning node
  • Leans into Liquid interoperability, with official client docs describing a Liquid-first approach for fee-efficient Lightning-to-Liquid and Bitcoin swap flows
  • Ships as open-source infrastructure with public repos, release artifacts, Docker images, and setup/configuration documentation for node operators
• Key claims:
  • The homepage brands Boltz as a “Non-Custodial Bitcoin Bridge,” which is the clearest high-level statement of its role
  • The official backend README says the backend powers swaps at boltz.exchange, enables non-custodial swaps between different Bitcoin layers, and exposes a RESTful HTTP API to query supported pairs and create or monitor swaps
  • 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
  • The Boltz Client introduction says the stack is CLI-first, CLN-first, Liquid-first, and self-contained, which helps clarify that this is operator tooling and middleware, not just a retail swap frontend
  • The client docs define boltzd as a daemon running alongside a Lightning node and boltzcli as the CLI used to interact with its gRPC interface, making the operator-control-plane shape explicit
  • The client docs also note a standalone mode and recovery-oriented swap mnemonic handling, which shows Boltz ships workflow and risk-management tooling beyond simple swap execution
• Whitepaper: No canonical Boltz whitepaper or litepaper surfaced in this pass. The clearest current source of truth is the official site, public backend/client repositories, and the client/API documentation; see ../whitepapers/boltz-primary-sources-2026-04-28.md.
• Sources:
  • https://boltz.exchange/
  • https://docs.boltz.exchange/
  • https://client.docs.boltz.exchange/
  • https://raw.githubusercontent.com/BoltzExchange/boltz-backend/master/README.md
  • https://raw.githubusercontent.com/BoltzExchange/boltz-client/master/README.md
  • https://github.com/BoltzExchange/boltz-backend
  • https://github.com/BoltzExchange/boltz-client

Internal linkages

• Company / operator boundary above the product surface: boltz.
• Strongest service-coupled liquidity-management peer: lightning-loop.
• Direct-peer contrast when the operator wants to keep rebalancing inside an existing channel relationship: peerswap.

Protocol / company boundary

• Keep this note 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 Boltz exposes.
• Use boltz for the named operator layer above that product: the official backend, public API availability, supported-pair policy, documentation and support workflow, recovery guidance, and the public node / channel shell users inherit.
• That split matters because how do Boltz swaps and client tooling work? and who controls the easiest hosted API and operating shell around them? are related but not identical questions.

Control surface

• Practical leverage at the product layer sits in pair support, swap pricing and timeout policy, API and daemon defaults, Liquid-versus-mainchain routing, recovery handling, and how much operator workflow gets delegated to the hosted service instead of kept local.

• For the broader operator shell around those defaults, docs, and service surfaces, read boltz.

• Read Boltz as reusable swap middleware with a real service edge, not as a neutral bridge primitive.

• Last reviewed: 2026-08-09 UTC