Core Lightning Node Hardening — DevOps / Plugin Developer

Core Lightning (CLN) Plugin Developer — Node Hardening & Payment Routing Controls Description We're building a production Lightning Network payment infrastructure using Core Lightning (CLN) in a hub-and-spoke topology. We need an experienced CLN developer to harden our user-facing nodes before launch by implementing two Python CLN plugins and a channel audit/management script. Our setup: We run three logical node roles — Merchant nodes, Client nodes, and Routing nodes — all on the same CLN codebase, differentiated by configuration. Routing nodes carry all liquidity. Merchant and Client nodes connect to users and businesses. Plugins are baked into Docker images and auto-load with the CLN daemon. Deliverable 1 — Forwarding Block Plugin (Merchant + Client nodes) Implement a htlc_accepted hook plugin that: Inspects the forward_to field in the HTLC payload Allows payments where the node is the final destination (forward_to absent) Rejects any payment the node is being asked to forward (forward_to present) Returns a clean failure message that fails fast for the sending peer Emits structured logs on every rejection Fires a loud alert to our ops system if any forward ever succeeds (signals plugin failure) As a defense-in-depth backstop, also configure high failsafe routing fees (e.g., 10 BTC base + 100% ppm via setchannel) at provisioning so that forwarding is economically dead even if the plugin is temporarily unavailable. Deliverable 2 — Peer Connection Whitelist Plugin (Merchant nodes only) Implement a peer_connected hook plugin that: Checks each connecting peer's Node ID against a whitelist of our routing node pubkeys Immediately disconnects any peer not on the whitelist Reads the whitelist from an environment variable (e.g., CLN_ALLOWED_PEERS) injected at container provisioning, with a baked-in fallback Includes a toggle mechanism to temporarily disable the whitelist lock during initial merchant funding channel setup and re-channeling (must be re-enabled after finalization) Logs all disconnections in structured format Client nodes do not get this plugin — they must remain open to connect with anyone (friends, family, other businesses). Deliverable 3 — Splice Capability Audit & Enforcement (Routing nodes) Part A — One-time/periodic audit script: Calls listpeers and inspects each peer's features field for splice feature bits (162/163) Identifies peers lacking splice support Initiates mutual close of non-splice channels, or flags high-value channels for manual review Outputs a structured report of affected peers and channels Part B — Persistent openchannel_custom_filter plugin: Rejects new inbound channel requests from peers without splice support (feature bits 162/163) Logs rejections with peer Node ID and reason Compatible with a separate node-blacklist hook on the same filter (per Issue #14 design) Applies to all four routing nodes: rn_one, rn_two, rn_three, rn_four. Technical environment: Core Lightning (CLN) — current production version Python plugins using pyln-client Docker-based deployment; plugins ship in the image and register in CLN config Tor-based peer connections on routing nodes (IP-based filtering is not viable) Staging environment: SN2 | Live environment: EWS What we're looking for: Demonstrated experience writing CLN plugins (Python preferred) Solid understanding of Lightning Network HTLC mechanics and channel lifecycle Familiarity with CLN hooks: htlc_accepted, peer_connected, openchannel_custom_filter Ability to write clear structured logs and integrate with ops/alerting systems Clean, documented code — these plugins go into production Docker images Nice to have: Experience with splicing (CLN v23.08+) Prior work on Lightning routing node operations or liquidity management To apply, please answer briefly: Have you written CLN plugins using pyln-client? Link to any public work if available. Which CLN hooks have you worked with directly? Describe how you would implement a peer_connected whitelist that can be toggled at runtime without restarting the daemon.