Community curated plugins for Core-Lightning.
Name | Short description | CLN24.02 /24.05 /24.08 /master |
---|---|---|
backup | A simple and reliable backup plugin | |
bolt12-prism | Split payments triggered manually or by paying a BOLT 12 | |
btcli4j | A Bitcoin Backend to enable safely the pruning mode, and support also rest APIs. | |
clearnet | A plugin that can be used to enforce clearnet connections when possible | |
cln-ntfy | Core Lightning plugin for sending ntfy alerts. |
|
clnrest-rs | Drop-in rust implementation of CLN's clnrest.py | |
clnrod | Channel acceptor plugin. Configurable with external data from amboss/1ml and notifications | |
currencyrate | A plugin to convert other currencies to BTC using web requests | |
datastore | The Datastore Plugin | |
donations | A simple donations page to accept donations from the web | |
event-websocket | Exposes notifications over a Websocket | |
feeadjuster | Dynamic fees to keep your channels more balanced | |
go-lnmetrics.reporter | Collect and report of the lightning node metrics | |
graphql | Exposes the Core-Lightning API over graphql | |
hold | Hold invoices that do not require the preimage to be known when created | |
holdinvoice | Holds htlcs for invoices until settle or cancel is called (aka Hodlinvoices) via RPC/GRPC | |
invoice-queue | Listen to lightning invoices from multiple nodes and send to a redis queue for processing | |
lightning-qt | A bitcoin-qt-like GUI for lightningd | |
ln-address-pay | Allows payments to lightning addresses | |
monitor | helps you analyze the health of your peers and channels | |
nloop | Generic Lightning Loop for boltz | |
persistent-channels | Maintains a number of channels to peers | |
poncho | Turns CLN into a hosted channels provider | |
pruning | This plugin manages pruning of bitcoind such that it can always sync | |
rebalance | Keeps your channels balanced | |
sauron | A Bitcoin backend relying on Esplora's API | |
sitzprobe | A Lightning Network payment rehearsal utility | |
sling | Rebalance your channels with smart rules and built-in background tasks | |
summars | Print configurable summary of node, channels and optionally forwards, invoices, payments | |
summary | Print a nice summary of the node status | |
torq-plugin | Better CLN integration into Torq | |
trustedcoin | Replace your Bitcoin Core with data from public block explorers | |
watchtower-client | Watchtower client for The Eye of Satoshi | |
webhook | Dispatches webhooks based from event notifications | |
zmq | Publishes notifications via ZeroMQ to configured endpoints |
This is a list of plugin managers that can help you install these plugins:
Name | Short description |
---|---|
coffee | Reference implementation for a flexible core lightning plugin manager |
reckless | Comes with CLN. Reckless currently supports python and javascript plugins. |
If you can't find a plugin you're looking for, it may have been archived. Plugins are archived when they start to fail integration testing with the latest CLN release, at which point they will be considered unmaintained.
To install and activate a plugin you need to stop your lightningd and restart it
with the plugin
argument like this:
lightningd --plugin=/path/to/plugin/directory/plugin_file_name.py
Notes:
- The
plugin_file_name.py
must have executable permissions:chmod a+x plugin_file_name.py
- You must have git core.fileMode set to true to reflect the permissions in git
- On Windows you might need to do the git add command in WSL to be able to change the permissions
- A plugin can be written in any programming language, as it interacts with
lightningd
purely using stdin/stdout pipes.
Alternatively, especially when you use multiple plugins, you can copy or symlink
all plugin directories into your ~/.lightning/plugins
directory. The daemon
will load each executable it finds in sub-directories as a plugin. In this case
you don't need to manage all the --plugin=...
parameters.
Most of the plugins can be managed using the RPC interface. Use
lightning-cli plugin start /path/to/plugin/directory/plugin_file_name
to start it, and
lightning-cli plugin stop /path/to/plugin/directory/plugin_file_name
to stop it.
As a plugin developer this option is configurable with all the available plugin libraries,
and defaults to true
.
To simplify plugin development you can rely on pyln-client
for the plugin
implementation, pyln-proto
if you need to parse or write lightning protocol
messages, and pyln-testing
in order to write tests. These libraries can be
retrieved in a number of different ways:
- Using
pip
tools:pip3 install pyln-client pyln-testing
- Using the
PYTHONPATH
environment variable to include your clightning's shippedpyln-*
libraries:
export PYTHONPATH=/path/to/lightnind/contrib/pyln-client:/path/to/lightnind/contrib/pyln-testing:$PYTHONPATH
The pyln-testing
library provides a number of helpers and fixtures to write
tests. While not strictly necessary, writing a test will ensure that your
plugin is working correctly against a number of configurations (both with and
without DEVELOPER
, COMPAT
and EXPERIMENTAL_FEATURES
), and more
importantly that they will continue to work with newly release versions of
Core-Lightning.
Writing a test is as simple as this:
- The framework will look for unittest filenames starting with
test_
. - The test functions should also start with
test_
.
from pyln.testing.fixtures import *
pluginopt = {'plugin': os.path.join(os.path.dirname(__file__), "YOUR_PLUGIN.py")}
def test_your_plugin(node_factory, bitcoind):
l1 = node_factory.get_node(options=pluginopt)
s = l1.rpc.getinfo()
assert(s['network'] == 'regtest') # or whatever you want to test
Tests are run against pull requests, all commits on master
, as well as once
ever 24 hours to test against the latest master
branch of the Core-Lightning
development tree.
Running tests locally can be done like this:
(make sure the PYTHONPATH
env variable is correct)
pytest YOUR_PLUGIN/YOUR_TEST.py
Additionally, some Python plugins come with a requirements.txt
which can be
used to install the plugin's dependencies using the pip
tools:
pip3 install -r requirements.txt
Note: You might need to also specify the --user
command line flag depending on
your environment.
The minimum supported version of Python for this repository is currently 3.8.x
(14 Oct 2019).
Python plugins users must ensure to have a version >= 3.8
.
Python plugins developers must ensure their plugin to work with all Python versions >= 3.8
.
Whenever submitting code contributions for this repository, we should try to stick to the format 'lightning' uses, something like:
plugin name: One subject line
(empty line)
more detailed description (if any)
- @conscott's plugins
- @renepickhardt's plugins
- @rsbondi's plugins
- Core-Lightning plugins emulating commands of LND (lncli)
- Description of the plugin API
- C Plugin API by @rustyrussell
- Python Plugin API & RPC Client (PyPI) by @cdecker and a video tutorial by @renepickhardt
- Go Plugin API & RPC Client by @niftynei
- C++ Plugin API & RPC Client by @darosior
- Javascript Plugin API & RPC Client by @darosior
- TypeScript Plugin API & RPC Client by @AaronDewes
- Java Plugin API & RPC Client by @vincenzopalazzo
- C# Plugin Guideline and example project by @joemphilips
- Kotlin plugin guideline and example by @vincenzopalazzo