Flint — nodeless Lightning for BTCPay Server

A BTCPay Server plugin that lets a store receive Lightning payments without running a Lightning node. It runs the Breez Spark SDK in-process, gives each store its own Spark wallet from a recovery phrase you hold, and wires that wallet into the store's Lightning and LNURL payment methods for you — there is no connection string to copy and nothing to keep online but BTCPay itself. The balance can then be swept automatically, on a threshold, to the store's own BTCPay on-chain wallet, to a fixed Bitcoin address, or cross-chain to a stablecoin at an address you control on an EVM chain; and it can be held in USDB between sweeps.

What you are trusting, in one paragraph. Spark is a 2-of-3 statechain operated by Lightspark, Breez and Flashnet. A balance sitting on it is not in your sole custody the way an on-chain UTXO or a channel you own is: every Lightning receive rides Lightspark's service provider, and this plugin performs cooperative exits only — it offers no unilateral-exit path anywhere in its UI or its code. Sweeping is the only thing that reduces that exposure, which is why the sweep threshold is the most important setting on the plugin. Stable Balance and cross-chain sweeps each add a further counterparty of a different kind: a regulated stablecoin issuer whose token metadata says it can freeze the balance, and a bridge provider that holds the funds between the two chains. Both are off by default.

Read the full Trust model — every party, what each can do, and what recourse exists — before you configure anything.

What a server needs to run this plugin:

• BTCPay Server 2.4.1 or newer. That is the declared support floor, and BTCPay refuses to load the plugin on anything older. It is compiled against 2.4.1 as well.
• A supported platform. The Breez Spark SDK ships around 200 MB of native libraries for linux-x64, linux-arm64, osx-x64, osx-arm64, win-x64 and win-x86. There is no linux-musl (Alpine) or win-arm64 payload, so the plugin will not load on those platforms. Standard BTCPay Docker images (Debian-based) are fine.
• Mainnet or regtest. The SDK offers no testnet or signet, so neither is supported. Stable Balance and cross-chain sweeps are mainnet-only even on a supported network.
• Disk for the SDK's per-store state, under <DataDir>/Plugins/Spark/, plus an unrotated sdk.log you are expected to point logrotate at — see Known limitations.
• Server-admin rights, or the Non-admins can create Hot Wallets for their Store policy, to set a store up. Spark keeps keys on the server, so the plugin sits behind BTCPay's own hot-wallet gate.

Requires BTCPay Server 2.4.1 or newer on a host the Breez SDK has native libraries for — see Requirements before you start, because Alpine-based images are not among them.

From the BTCPay plugin registry (once this plugin is listed there — it is not yet): in your BTCPay Server, go to Server settings → Plugins, find Spark, and install it. BTCPay restarts itself to complete the install.

From a release artifact, which is the route available today: download BTCPayServer.Plugins.Flint.btcpay from the releases page, then Server settings → Plugins → Upload plugin and select the file. BTCPay restarts to complete the install. Every release artifact is signed; the releases page carries SHA256SUMS and the commands to check both the hash and the signature before you upload anything. Verify them — this plugin holds Lightning keys on your server.

Once installed, the plugin appears per-store under Plugins → Spark, and as a Set up Spark option on the store's Connect to a Lightning node screen. It does nothing at all until a store is set up.

Uninstalling the plugin is not the same as removing Spark from a store. Server settings → Plugins → Uninstall takes the code away; it does not touch a store's encrypted seed, its SDK storage under the data directory, or the Lightning payment-method configuration the plugin wrote — so a store left configured simply loses its Lightning provider. Use the per-store Remove page first if that is what you meant; see Setting a store up for exactly what that destroys.

1. Set the store up — one page under Plugins → Spark, one question (where the seed comes from). LNURL and Lightning addresses work through BTCPay core the moment it finishes.
2. Turn sweeping on — off until you do, and it is the only thing that bounds how much of the store's money depends on the Spark operators. Set the threshold deliberately; the shipped fee defaults are regtest measurements and need raising for mainnet.
3. Fund the wallet on-chain, if you want to start with a balance rather than wait for receives. Read the fee-ceiling warning first.
4. Optionally hold the balance in dollars between sweeps, and drive the whole lot from a script with the Greenfield API.

Running a store on it: setting a store up · sweeping the balance out · funding the wallet on-chain · holding the balance in dollars · known limitations · trust model · automating it with the Greenfield API

Working on it: building · tests · local development and migrations · CI, releases & upstream updates

Full index: docs/.

• CHANGELOG.md — what is in this release, and what its maturity actually is.

Reviewing this for security? Start with the trust model and known limitations, which state the attack surface and the accepted risks plainly. The reasoning behind each guard is written where the guard is, in the doc comments — every one of them names the failure it exists to prevent, and several name a bug this project has already shipped once.

MIT — see LICENSE. Copyright (c) 2026 Seth For Privacy.

This plugin is greenfield, but the BTCPay plugin patterns it follows (per-store Lightning client lifecycle, connection-string handler, LN setup-tab UI extensions, plugin-owned EF schema) descend from Kukks' MIT-licensed BTCPayServerPlugins — specifically the Breez, Blink and MicroNode plugins — which are gratefully acknowledged.

See NOTICE for the full third-party notices, including the sweep settings/UI shape (harvested, with attribution to Kukks as the upstream copyright holder, from the prior-art Spark plugin's treasury pages — its sweep execution logic was deliberately not used) and the sweep destination pattern taken from Boltz's Liquid plugin.