How to Track Lightning and On-Chain Bitcoin Together Using Clams

If you run a Lightning node, you already know the accounting challenge: routing fees trickle in across thousands of forwards, channel opens lock up capital in funding transactions, force closes scatter satoshis across timelocked outputs, and somewhere in the middle of it all, you need to figure out your cost basis for tax season.

Most crypto tax tools either ignore Lightning entirely or treat it as a CSV dump disconnected from your on-chain activity. Clams takes a different approach. Released as v1 in July 2026, it maintains a single double-entry ledger that spans on-chain Bitcoin, Lightning channels and payments, and even Liquid Network assets. The result is a coherent, auditable record where every satoshi's journey from cold storage through channel funding to routing fee to cooperative close can be traced.

Here's how to set it up.

Connecting Your Lightning Node

Clams supports direct connections to both LND and Core Lightning nodes, and this native sync is the recommended approach. CSV exports from mobile wallets work in a pinch, but they miss channel lifecycle details and can't match on-chain activity to its Lightning origins.

For LND Nodes

Clams connects to LND via gRPC or Lightning Node Connect (LNC). You'll need your node's host address and a macaroon with read permissions. The connection pulls your complete channel history, all payments sent and received, routing activity, and current channel states.

From the Clams CLI, you'll configure the connection with your LND credentials, then run a sync command that imports the full transaction history. The specifics depend on your setup (local node, remote server, Voltage hosting), but the Clams documentation walks through each scenario.

For Core Lightning Nodes

CLN users connect via Rune authentication. You generate a read-only Rune on your node, configure it in the Clams CLI, and sync. As of the February 2026 beta update, Clams connects directly to CLN without requiring a proxy, which simplifies the setup considerably.

Once connected, Clams pulls channel opens and closes, invoices, payments, routing forwards, and on-chain transactions associated with your node.

How Clams Models the Channel Lifecycle

This is where Clams differs from general-purpose tax tools. It explicitly models the full Lightning channel lifecycle:

• Channel opens: Single-funded and dual-funded transactions are tracked, with the funding transaction linked to its originating on-chain wallet.
• Cooperative closes: The closing transaction is matched to the channel it closes, and proceeds flow back to your on-chain balance.
• Force closes: Delayed outputs, anchor outputs, and timelocked sweeps are tracked separately and linked to the original channel.
• HTLCs: Offered, received, timeout, and success states are categorized correctly.
• Penalty transactions: Revoked-state penalties (yours or your counterparty's) are captured.

Critically, Clams matches all of this to your on-chain wallets. When you open a channel, it knows the funding came from your cold storage. When you force close, it tracks the sweep back into your on-chain balance. This matching prevents the common error of misclassifying internal transfers as taxable disposals.

Processing Journal Entries

After syncing your node, you run the journal processing command:

```

clams journals process

```

Clams normalizes your Lightning activity into canonical record types:

• Forwards: Routed payments that earn you routing fees, booked as income with timestamp, amount, and channel details.
• Pays: Payments you originated, including rebalances. Routing fees you paid are tracked as expenses.
• Transactions: On-chain events like funding transactions, cooperative closes, and force-close sweeps.

Every entry is double-entry: debits and credits balance, and the total satoshi flow across your ledger is conserved. This isn't just accounting theater; it means you can trace any satoshi's path through your system and audit the books if needed.

Handling Internal Transfers

One of the trickier aspects of Bitcoin accounting is distinguishing between internal moves and actual disposals. Moving bitcoin from your hardware wallet to a Lightning channel isn't a taxable event; spending it to buy something is.

Clams automatically detects transfers between your own wallets, including moves between on-chain and Lightning. These are booked as internal transfers rather than sales, preserving cost basis continuity. Ambiguous events get flagged for manual review rather than defaulting to taxable treatment.

This requires connecting all your relevant wallets. Clams supports descriptor and xpub-based scanning for major hardware wallets (Coldcard, Trezor, Ledger, BitBox02, Jade, Passport) and popular software setups (Sparrow, Electrum, Nunchuk). The more complete your wallet connections, the better Clams can match internal transfers.

Generating Cost-Basis and Capital Gains Reports

With your Lightning node synced and journals processed, you can generate tax reports:

```

clams reports capital-gains

```

Clams calculates gains or losses per lot of bitcoin across both on-chain and Lightning spending, supporting FIFO, LIFO, and HIFO cost basis methods aligned with IRS guidance in effect since 2025.

The reports cover:

• On-chain UTXOs spent in regular transactions
• Bitcoin spent via Lightning payments
• Routing fee income
• Rebalancing and channel lifecycle expenses

Because everything lives in one ledger, you don't have to manually reconcile separate reports or guess at cost basis when sats moved through Lightning before being spent.

What About Mobile Lightning Wallets?

For wallets like Phoenix or Wallet of Satoshi that don't expose a direct node interface, Clams falls back to CSV imports. This works, but with limitations.

Phoenix's CSV export, for example, doesn't include deposit on-chain addresses. Clams treats incoming funding transactions as income unless it can match them to outgoing transactions from other connected wallets. If you fund your Phoenix wallet from a connected on-chain wallet, Clams can match the transfer. If you fund it from an exchange you haven't connected, it can't.

The Clams documentation recommends native node sync wherever possible precisely because CSV exports lose the connection between Lightning activity and its on-chain footprint.

Measuring Node Profitability

Beyond tax compliance, Clams provides the data for profitability analysis. A May 2026 Clams article walked through a real node's economics: 5,967 routed forwards, 103,804 payments, and 5 on-chain transactions during the sample period, all transformed into journal entries.

Using connection-scoped ledgers, you can isolate each node's economics:

• Routing income from forwards
• Rebalancing costs
• On-chain fees for channel management
• Capital locked in channels

This turns opaque node activity into a coherent profit-and-loss picture. For Lightning Service Providers and serious routing node operators, this kind of visibility is essential.

Limitations and Considerations

Clams is Bitcoin-only by design. If you hold other cryptocurrencies, you'll need a separate tool for those assets (though you may find that's a feature rather than a bug).

The local-first architecture means your ledger lives on infrastructure you control. Clams doesn't have access to your transaction data. This is great for privacy but means you're responsible for backups and maintenance.

Finally, while Clams covers Lightning comprehensively, the tax treatment of some edge cases (penalty transactions, for instance) may still require professional judgment. The software gives you the data; interpreting it for your jurisdiction is still your responsibility.

Getting Started

Clams offers a CLI and REST API, so you can integrate it into existing node automation or run it standalone. Licenses can be paid in bitcoin via Lightning or fiat via Stripe.

For Lightning node operators who've been cobbling together spreadsheets and CSV exports, the value proposition is straightforward: one ledger that actually understands how Lightning works, from channel funding through routing fees to force-close sweeps. For once, your accounting can match the complexity of what your node actually does.