CraysClams
Clams sits after the payment. It is the layer that turns wallets, Lightning nodes, NWC connections, exchange CSVs and channel history into books a serious Bitcoiner can review.
Bitcoin books after the payment
Clams belongs in the part of the Bitcoin and Nostr stack that many people only notice when the year is almost over. A zap arrives. A Lightning invoice settles. A merchant receives payments through BTCPay Server. A node routes thousands of small payments. An exchange buy lands in cold storage. A self-custody user moves funds through several wallets. At the moment of payment, everything feels immediate. Months later, the same activity becomes a ledger problem: where did the sats come from, what did they cost, were they income, were they a transfer, what fee was paid, what was disposed, and which report can be shown to an accountant without hours of manual reconstruction?
That is the problem Clams is trying to own. The current Clams website calls it Bitcoin accounting infrastructure and describes one install with two main interfaces: CLI and Server. The product page emphasizes audit-ready books, double-entry accounting, automated reconciliation, cost-basis tracking, capital-gains calculations, transfer matching between a user's own wallets, and reports that can move into compliance or planning work. This is a very different reader need from a Nostr social app. You do not open Clams to post, follow, react or publish. You open it when money movement needs to become understandable.
The Nostr connection is still real, but it is not the public feed layer. Clams appears in the NWC ecosystem because it can use Nostr Wallet Connect as a data connection for Lightning activity. The integration page lists Alby Hub and Zeus under NWC, and the Clams skill reference lists `Nwc` as a connection kind with a `nostr+walletconnect` URI. That means a Nostr-native wallet path can become an accounting source. The useful question for the reader is not whether Clams is a Nostr client. It is whether Clams can turn the payment traces created by Nostr commerce and Lightning apps into books you can actually inspect.
What Clams is today
The present-day Clams product is best understood as a Bitcoin accounting engine with several surfaces around it. The CLI is for local and scriptable workflows. The Server runs the same accounting work behind an HTTP API for self-hosted or team use. Clams Cloud is the hosted option for people who want multi-device access or a managed backend. The deployment page makes the tradeoff explicit: local keeps data on your machine, self-hosted runs on your infrastructure, and managed or cloud options move availability and maintenance to Clams-operated infrastructure.
That multi-surface design matters because the audience is broader than a single hobbyist wallet. Clams has pages for individuals, small businesses, accountants, CFOs, developers, exchanges, Lightning service providers, miners and nonprofits. Those are not cosmetic personas. Each one points at a different accounting pain: cost basis across wallets, high-volume exchange reconciliation, Lightning channel events, mining income, nonprofit donation valuation, board reporting, API integration, and audit trails. A tool that only exports a spreadsheet cannot cover that range for long.
The current release track confirms the product's direction. The latest public release observed during this review was `clams-v1.0.0-beta.13`, published on May 25, 2026, with binaries for Apple Silicon macOS, Intel macOS, x64 Windows, ARM64 Linux and x64 Linux. The release notes discuss Core Lightning Commando preflight checks, holding-period terms in capital-gains rows, Custom CSV transfer references, USDT and USDC asset catalog support, Lightning proof diagnostics and more careful Lightning on-chain journaling. That is not a toy app release note. It is the language of an accounting engine learning Bitcoin's edge cases.
Why Nostr users should care
Nostr makes small payments feel natural. Zaps, Lightning Address, app subscriptions, paid relays, NWC-powered pay buttons, store invoices and tip flows can all happen inside a social or app experience. That is good for adoption, but it creates a quieter second problem: the money activity is no longer concentrated in one exchange account or one bank statement. It is spread across wallets, hubs, nodes, mints, merchant processors and Nostr-connected applications.
Clams matters here because it treats NWC as one input into a larger Bitcoin ledger, not as the entire story. A Nostr creator might receive zaps through an Alby Hub connection, withdraw to cold storage, buy more bitcoin through River or Swan, sell a product through BTCPay Server and keep a Phoenix wallet for mobile spending. None of those events are difficult alone. Together, they can be painful to reconcile. Clams tries to put the activity into one set of books where transfers can be matched and income or disposals can be reviewed.
The Nostr ecosystem tends to celebrate the moment of value transfer. Accounting celebrates the moment of explanation. That makes Clams a useful counterweight. It is not exciting in the same way a new client or wallet interface is exciting, but it answers a question serious users eventually ask: can the open payment stack produce records that survive accountant review, business reporting and personal memory?
The NWC connection is an input, not a blank cheque
The Clams integration page lists NWC nodes as a supported Lightning category and names Alby Hub, Zeus and compatible Nostr Wallet Connect implementations. The Clams connection reference shows the configuration shape: a connection of kind `Nwc` with a `nostr+walletconnect` URI and a timeout. That tells the reader where Nostr enters the product. Clams can connect through the NWC pattern to gather wallet or node activity for accounting.
The product's FAQ also says Clams requires only read access to wallets and never has access to spending funds. That is an important claim, because NWC as a protocol can be used for many different permission sets depending on the wallet service and connection string. When using Clams, the careful user should still inspect the NWC connection in the wallet that issued it. Confirm what methods are allowed, how long the connection lives, which relay is used, and where revocation happens.
For a Nostr user, the safest mental model is simple: Clams should be allowed to understand history, not control money. If a wallet offers a read-only or accounting-oriented NWC capability, use that. If the wallet presents a broader permission bundle, slow down before pasting it into any accounting tool. The value of Clams is that it can read and reconcile activity. It does not become better accounting software because a connection can spend.
On-chain, Lightning and multisig in one ledger
The feature page is unusually explicit about the Bitcoin shapes Clams wants to understand. On-chain support includes modern and legacy address types, xpub, ypub and zpub watch-only imports, output descriptors, multisig, fee accounting and transfer matching. That matters because many Bitcoin users split custody by purpose. A hot wallet receives payments. A hardware wallet stores savings. A multisig vault holds treasury. A mobile wallet handles daily spending. A ledger that treats every movement between those as income or sale will be wrong.
Lightning makes the problem harder. The same feature page says Clams tracks the channel, not just the payment, and calls out channel opens, closes, sweeps, routing fees, invoices, payments, forwards, Core Lightning, LND, NWC nodes and mobile wallet CSV exports. A Lightning node operator needs more than a list of invoices. They need to know when capital moved on-chain into a channel, when fees were paid, when routing revenue arrived, when a force close created on-chain outputs, and which pieces belong together.
This is why Clams feels relevant to Nostr commerce. Nostr apps can make Lightning easy enough that users forget the underlying complexity. Clams is for the moment when that complexity has to be brought back into view. It is trying to produce a ledger that understands UTXOs, channels, custodial imports, Lightning events and transfers as related pieces of one Bitcoin life, not as disconnected CSV rows.
Connections are the backbone
The integration list is long enough to show the product's ambition. It includes Alby Hub, BitBox02, Blockstream Jade, BlueWallet, BTCPay Server, Casa, Cash App, Coinbase, Coldcard, Core Lightning, Electrum, Foundation Passport, Gemini, Kraken, Ledger, LND, Nunchuk, OpenNode, Phoenix, River, Sparrow Wallet, Specter, Strike, Swan, Trezor, Unchained, Voltage, Wallet of Satoshi, Wasabi and Zeus. Some are real-time or native connections. Others are CSV or descriptor paths. The point is not that every connection behaves the same. The point is that Clams wants one accounting model across many sources.
The public skill reference makes the connection model more concrete. It lists connection kinds for Core Lightning via Commando RPC, LND via LNC or gRPC, NWC, xpub, descriptors, address lists, Phoenix CSV, River CSV and Custom imports. It also describes sync and import flows separately. CoreLn, Lnd, Nwc and on-chain watch sources can sync; Phoenix and River are import-only; Custom depends on the mapping. That distinction is the sort of detail a reader should care about before assuming a wallet will stay automatically current.
For unsupported sources, Clams leans on Custom CSV mapping. The custom-connection reference describes patterns that classify rows into canonical types such as trades, deposits, withdrawals, Lightning payments and Lightning invoices. It also says re-imports are deduplicated by canonical IDs. This is the difference between a random spreadsheet upload and a proper import layer. The user still needs to inspect the source CSV and mapping, but Clams gives a path for data that does not have a native adapter yet.
The accounting engine does the hard part
Clams is most interesting where it refuses to be only an importer. Importing wallet data is necessary, but not enough. The product pages and skill references keep returning to journals, cost basis, rates, metadata, quarantines and reports. The recommended workflow is sync connections, sync exchange rates, process journals, then generate reports. That sequence matters because reports are only as useful as the processed ledger underneath them.
The reports reference names five report families: balance sheet, balance history, portfolio summary, capital gains and journal entries. Balance sheet and portfolio summary are display reports by default. Capital gains and journal entries are CSV-first data reports. The capital-gains reference is especially careful: PDF output is a summary document, while CSV is the complete line-item record. That is exactly the kind of distinction a user needs when using a tool for tax or accounting work.
The product also supports multiple cost-basis approaches in profile settings, including FIFO, LIFO, HIFO, LOFO and average cost. The presence of a setting does not make every method appropriate in every jurisdiction. It does, however, show that Clams is modeling lot selection as an accounting decision rather than hiding it inside a black box. A reader should choose a method deliberately and review it with a professional when reports are used for legal filing.
Quarantine is a feature, not a failure
One of the healthiest signs in the Clams material is the repeated mention of quarantines and manual resolution. Bitcoin accounting has ambiguous cases. Lightning channel closes can lack enough evidence. Custom CSV rows can omit identifiers. Internal transfers can look like income or spending if the matching data is missing. Exchange exports can be incomplete. A tool that pretends every event is obvious will create cleaner-looking reports and worse books.
The skill reference warns that unresolved quarantined events are omitted from reports and tells the user to check quarantines when numbers look wrong. The latest release notes go even deeper, adding Lightning proof diagnostics to quarantine output and changing several Lightning on-chain behaviors to fail closed when evidence is ambiguous. That phrase is important in practice: Clams would rather require review than silently assign a doubtful event to the wrong place.
For the reader, quarantine should be treated as the review desk. If Clams pauses on an event, it may be protecting the ledger from a bad assumption. Resolve those events with context, not impatience. Check the wallet source, transaction hash, channel history, imported CSV row and any notes or tags before pushing the event into the books. The time spent there is usually cheaper than discovering a wrong report after it has been shared.
CLI, Server and Cloud change the privacy story
Clams has three deployment postures, and they are not equivalent for privacy. The FAQ says data is stored directly on the user's device by default. The privacy policy says local and self-hosted use keep data on the user's device or infrastructure, while Clams Cloud transmits and stores transaction data on servers operated by Clams. The deployment page says local is best for individuals and small businesses prioritizing privacy, self-hosted is for teams wanting control, and managed options trade operational burden for availability.
That choice should be made before connecting sensitive wallets. A full Bitcoin accounting database can reveal more than a single wallet balance. It may include addresses, exchange activity, channel history, invoices, payees, tags, notes, income classifications, rates, lot history and business relationships. If you run Clams locally, you are protecting that database like any other local financial file. If you self-host, you are protecting the server, backups, TLS, access control and logs. If you use Cloud, you are trusting the provider's operational and privacy posture.
The FAQ adds two useful privacy details. Clams says it has no trackers or analytics scripts in the product, and it explains a few external requests that may be needed for complete data, such as looking up older Core Lightning block timestamps or LND channel-close transactions. These are better than vague privacy promises because they tell the user where metadata can still leak. Good privacy practice here means choosing the right deployment mode and understanding which network calls your accounting workflow makes.
The old Remote app is a different chapter
Older public Clams material can confuse the story if read without dates. The open-source `Remote` repository describes a browser-based interface for controlling Core Lightning nodes through the Lightning Network. It uses a trustless WebSocket proxy, local encryption, Core Lightning runes, Lightning Address style node addressing, invoice and payment controls, keysend, BOLT12 offers and mobile PWA installation. OpenSats grant material from that era described Clams as work around remote Lightning node control.
That history is still relevant because it explains why Clams understands Lightning at a low level. The Remote app had to care about runes, permissions, node connectivity, encrypted local storage, BOLT12 offers and Core Lightning behavior. Those concerns did not disappear. They show up in the current accounting product as Lightning connection handling, proof diagnostics, Core Lightning preflight checks and careful modeling of channel events.
But the reader should not evaluate current Clams as if Remote were the current main product. The active website now describes the accounting layer, CLI, Server, Cloud, integrations, reports and business use cases. The public GitHub organization still contains older open-source projects, while the FAQ states the current Clams product itself is not open source. That distinction matters for trust. You can inspect the older Remote code and the public skills, docs and releases, but you cannot audit the full current accounting engine from source.
What the Server API adds
Clams Server turns the accounting engine into an HTTP surface. The Server page describes a self-hosted REST API with CLI access, deployment behind infrastructure you control, role-based access, and resources for authentication and OpenAPI references. The OpenAPI description names the scope plainly: manage connections, journals, metadata, reports and more. This makes Clams more than a desktop accounting app for one person.
The API paths are revealing. They cover workspaces, workspace members, profiles, accounts, assets, connections, CSV and JSON imports, connection sync, connection kind validation, journal events, journal processing, quarantines, quarantine resolutions, metadata records, notes, tags, exclusions, BTC-fiat overrides, on-chain sources, canonical records for channels, deposits, forwards, invoices, pays, trades, transactions, UTXOs and withdrawals, plus reports for balance sheet, capital gains, journal entries and portfolio summary. That is a serious accounting surface.
For developers building Nostr commerce, merchant operations or Bitcoin treasury workflows, the Server interface is the part to study. It can sit behind internal dashboards, reconciliation jobs, reporting tools or agent workflows. The caution is that a Server deployment increases responsibility. Authentication, HTTPS, backups, access control, log handling and tenant boundaries matter because the API is exposing financial history and accounting actions, not a harmless public feed.
What to verify before trusting a report
A Clams report should be treated as the result of a workflow, not as magic. Start by checking every connection. Is the NWC URI for the right Alby Hub or Zeus node? Is the Core Lightning rune appropriately scoped? Is the LND connection using the right transport? Is the xpub, descriptor or address list from the correct wallet and account? Is the exchange CSV complete for the date range? A missing connection can make a tidy report quietly wrong.
Next, process the ledger deliberately. Sync connections, sync rates, process journals and inspect quarantines before generating reports. Add notes and tags where they help future review. Use exclusions and rate overrides carefully, then re-process journals so changes take effect. Export capital gains and journal entries as CSV when you need line-item records. Use PDFs only as summaries when that is what the recipient actually needs.
Finally, remember what Clams does not replace. It does not decide your jurisdiction's tax law. It does not know your business intent unless the data and metadata express it. It does not make an incomplete exchange export complete. It does not prove a NWC connection was permissioned safely just because it synced. Clams gives Bitcoin users a better accounting instrument. The user still has to play it like someone who understands the stakes.
Where Clams fits in the Nostr commerce stack
Nostr commerce needs more than storefronts and pay buttons. It needs invoices, wallets, relays, identity, reputation, fulfillment, support, refunds, and eventually accounting. Clams sits in that last part. It is not the checkout. It is not the buyer-seller conversation. It is not the zap button. It is the tool that can help turn the activity behind those experiences into a ledger that a business owner, creator, node operator or accountant can review.
That position makes Clams easy to overlook. A buyer never needs to know it exists. A casual zapper may not need it. But the moment a Nostr project starts earning meaningful revenue, running a Lightning node, operating a paid service, accepting donations, issuing grants, selling products, moving funds through multiple wallets or preparing financial reports, the accounting layer becomes part of the product's durability. Open payments are only half the promise if nobody can later explain the money trail.
Clams is still beta-era infrastructure, and the reader should use it with the caution that deserves. But the direction is important: Bitcoin-native, Lightning-aware, NWC-compatible accounting that can run locally, on your own server or through a managed backend. That is the kind of quiet tooling that lets a social payment ecosystem become a real operating environment rather than a pile of exciting transactions nobody can close.
Sources worth opening
Open the product pages, integration list, release notes, API specification and Clams skill references together. The public story only makes sense when the current accounting product is separated from the older open-source Remote app.
- Clams official website
- Clams features
- Clams wallet integrations
- Clams downloads
- Clams CLI page
- Clams Server page
- Clams Cloud page
- Clams deployment options
- Clams FAQ
- Clams about page
- Clams brand assets
- Clams privacy policy
- Clams terms of use
- Clams disclaimer
- Clams blog index
- Clams V1 beta announcement
- Clams v1.0.0-beta.13 release post
- Clams REST API guide
- Clams custom connections guide
- Clams Lightning node profitability guide
- Clams private Bitcoin accounting guide
- Clams privacy blog post
- Clams Bitcoin-only accounting comparison
- Clams GitHub organization
- Clams releases repository
- Clams v1.0.0-beta.13 release
- Clams REST API docs
- Clams REST OpenAPI JSON
- Clams Auth API docs
- Clams skills repository
- Clams skill instructions
- Clams connections reference
- Clams custom connections reference
- Clams onboarding reference
- Clams reports reference
- Clams journal processing reference
- Clams metadata reference
- Clams troubleshooting reference
- Clams Remote repository
- Clams Remote documentation repository
- Core Lightning Commando rune documentation
- NIP-47 Nostr Wallet Connect
- NWC documentation
- Alby Hub documentation
- Zeus website
- BTCPay Server documentation
- Clams Nostr profile
- Clams Matrix community
- Clams YouTube channel
