Lightning Network volume grew 300% in 2025, crossing $1 billion per month. More exchanges are running Lightning nodes. LSPs are processing millions of transactions. At that scale, Lightning node accounting can't be an afterthought.
Bitcoin on-chain accounting is hard enough. Lightning adds a state machine on top. A payment channel isn't a transaction. It's a two-party contract with a funded balance, continuous state updates, and multiple possible settlement paths. Every channel open locks capital. Every channel close triggers an on-chain settlement. And every routing forward in between earns revenue that needs to be recognized.
A single channel generates a funding transaction, potentially thousands of off-chain state updates, routing fee income, possible rebalancing expenses, and a closing settlement. Each requires different accounting treatment.
The Channel Lifecycle Problem
The channel lifecycle isn't just opens and closes. Splicing (see Phoenix wallet) creates accounting events that span on-chain and Lightning. A simple payment may trigger a channel resize and an on-chain transaction under the hood. If your tooling only sees one layer, half the journal entry is missing.
To further illustrate the complexity, consider just the close. Every close type has different financial implications:
Cooperative close — both parties agree to close. The settlement transaction splits the channel balance according to the final state. Straightforward: record the settlement amounts, calculate the closing fee, close the books on the channel.
Force close — one party broadcasts a commitment transaction unilaterally. Funds are time-locked and not immediately available. Any unsettled hash time-locked contracts (HTLCs) must be resolved individually, each with its own timeout and separate on-chain transaction. With anchor channels, resolving these requires a fee-bumping transaction funded from your on-chain wallet. Every step is a distinct accounting event: the pending settlement, the time locks, the HTLC resolutions, the fee bump from a separate wallet.
Breach close — a revoked commitment is broadcast, triggering a penalty transaction. The entire channel balance may shift to the non-breaching party. This is a fundamentally different economic event than a cooperative close, and it needs to be journaled as one.
Each close type produces different on-chain transactions with different fee structures. A tool that records "channel closed" as a single line item is losing information your auditor may ask for.
Routing Revenue at Scale
Running a routing node means earning fees on every forwarded payment. For active nodes, this is thousands of micro-transactions per day, each one a revenue event.
The accounting challenge isn't conceptual. Routing fees are income. The challenge is operational: capturing every forward, categorizing it as routing revenue distinct from payment income, and doing this at a scale where manual tracking is impossible.
Then there's the expense side. Channel rebalancing (circular payments that shift liquidity between your own channels) costs routing fees but generates no revenue. These are operational expenses. If your accounting system can't distinguish a rebalance from an external payment, your profit and loss statement is wrong.
What Lightning Accounting Infrastructure Requires
Lightning's accounting challenges were flagged as early as 2019. The open questions have only grown since: when does a taxable event occur, at the off-chain state update or the on-chain settlement? How should funds locked in a channel be classified? What's the cost basis treatment for a force-closed channel with time-locked outputs?
The answers exist, but they require tooling purpose-built for Bitcoin's UTXO model and Lightning's state machine, not adapted from general-purpose accounting software.
The starting point is native node sync. Not CSV exports, but direct connections to nodes that pull the full picture: invoices, payments, forwards, open channels, closed channels, and on-chain transactions. From there, the tooling needs to classify what it sees. A cooperative close and a breach close are fundamentally different economic events. A routing forward is revenue. A rebalance is an operational expense. The tooling needs to classify each correctly.
Precision matters too. Lightning operates at millisatoshi granularity, but on-chain settlements are denominated in satoshis. Every channel close involves a rounding boundary — the millisatoshi balances tracked off-chain don't map cleanly to the satoshi outputs on-chain, and that difference needs to be captured, not silently dropped. Rounding errors compound at scale, and scale is the whole point. A routing node processing millions of forwards needs tooling that handles that volume without degradation or per-transaction pricing. And when a node is decommissioned, the historical data still needs to be audit-ready.
Start Here
Your node is infrastructure. Your accounting should be too.
Connect your LND or Core Lightning node directly. Sync your full transaction history. One binary, self-hosted, no metered pricing.
Get started with Clams or read the API guide to automate your Lightning accounting pipeline.
Clams Team