Changelog

Before today, the audit log only captured transaction edits and merchant-level settings changes. That was a hole: delete a wallet, tweak a rule, rename a merchant — none of it left a trace. Today it does.

Every create, update, and delete across the four entities that matter — merchants, wallets, rules, transactions — now writes an audit row. Sensitive values (xpubs, addresses, secrets) are stored as presence flags like hasXpub: true, never the raw material. Each row carries a SHA-256 checksum so you can detect later tampering.

Three improvements to the log page itself:

1. Entity column. At-a-glance badge telling you whether that DELETE wiped a transaction or a whole wallet. Derived from the action name — no schema changes, no backfill.
2. Filter + search. Narrow by entity, action, or date range. The search box matches user email and transaction hash (case-insensitive substring).
3. Proper pagination. Same First / Prev / Next / Last + page-size control used on the transactions table. Default 50/page, up to 200.

If you're on a team plan, the "who did what" picture is finally complete. Single-user accounts mostly benefit from the tamper-evidence — the shield icon on each row re-verifies on render, so you'll see red immediately if someone rewrites history at the DB layer.

Two additions to the dashboard.

All time. The year picker now has an All time option at the top. Select it and every summary card, the revenue chart, and the P&L table recompute across your merchant's entire history:

• Summary cards switch from "Revenue 2026" to "Revenue (all time)" and the "vs last year" comparison pill hides (there's nothing to compare to).
• The monthly revenue chart swaps to yearly bars — one bar per calendar year.
• The P&L table's first column becomes "Year" and rows aggregate per year.

The default is still the current year, so nothing changes unless you pick All time.

Network fees on the revenue chart. The chart now has a second Y-axis on the right dedicated to network fees (always in BTC). This means:

• You can toggle the primary axis between fiat and BTC for revenue without losing the fees bar — it was previously hidden in fiat mode to avoid mixing units on one scale.
• Fees and revenue read on their own axes, with the right-side ticks showing BTC to 4 decimals.

The charts themselves picked up a small polish pass: theme-aware tooltips via the shadcn Chart wrapper, proper legends, and consistent coloring with the shadcn --chart-1..5 palette.

During these early beta months we want every scrap of feedback — bugs, rough edges, "why does this work that way" questions. So there's a new Help button in the dashboard header, on every page.

Click it and a dialog opens with a single textarea. Type whatever, hit Send — the message lands in support@txbooks.app along with your user ID, the exact page you were on, your locale, and your browser. No need to describe where you were or what account you're using; we already know.

Why a dialog instead of a mailto: link: a plain mailto: relies on your desktop having a mail client configured. A lot don't — clicking does nothing. An in-app form always works.

A visible Need help? line also shows under the sign-in form, so people who can't get in can still reach us.

Honest heads-up in the dialog: while we're in beta, replies come from a personal Gmail address (masked as gdtr******@gmail.com) rather than support@txbooks.app. We'll wire up send-as once the plan's up.

If you run more than one wallet under the same merchant — a hot wallet for daily use, a cold wallet for reserves, treasury splits, whatever — you've likely moved BTC between them. Until today, that was awkward:

• The outgoing and incoming legs both got attributed to the same on-chain transaction, creating phantom revenue and expense on reports.
• The transaction sat in UNCATEGORIZED forever. Any category rule you'd built (e.g. "outflow → expense") would mis-classify it as soon as you clicked Apply.

Two changes fix this end to end:

1. Per-wallet attribution. A new WalletTransaction junction records each wallet's delta for an on-chain tx. The single Transaction row's amount is recomputed as the merchant-level net — for a self-transfer, that's just the network fee. No more double-counting, no more +0.1 on one wallet offset by −0.1 on another.

2. Auto-tagging. After every xpub sync, if a transaction has two or more wallet attributions whose sum ≈ the network fee, we flag it as INTERNAL_TRANSFER with the memo "Internal transfer between wallets (auto-detected)". Your category rules then skip it — isTransfer: true rows are never re-classified.

Side effect that's nice: the tax/capital-gains exports exclude internal transfers automatically. Moving coins between your own wallets isn't a taxable event, and now the books agree.

Works retroactively — the detection runs over the whole merchant on each sync, so older transfers get picked up once the wallet on the other side syncs too.

Two rule-engine changes this week. Both came from real user reports.

Direction is a first-class condition. The existing "BTC amount ≥ N" rule compared the absolute value, so a rule like amount ≥ 0 → SALE matched every transaction — including outflows. Worked until it didn't. You can now write a rule with field Direction is Inflow (received) or Outflow (sent) and it compares against the signed amount. The common case — "anything received is a sale" — is now literally that rule: Direction is Inflow → SALE.

The existing amount_gte / amount_lte conditions keep their absolute-value behavior and were relabeled "BTC size" so it's clear they mean magnitude. Pair them with Direction if you need signed thresholds ("inflow ≥ 1 BTC → whale_sale").

Rules run after xpub sync. They already ran after CSV imports. Now they also run at the end of every xpub sync, so newly-pulled transactions get categorized without you clicking anything. If you have conflicting rules (an "outflow → expense" rule and an internal wallet-to-wallet move), the internal-transfer detection runs first and its isTransfer: true tag protects those rows from further re-classification.

Also new on the rules page: a "How rules work" explainer with worked examples for each field type, and a badge showing the direction on existing rules (so "Direction is Inflow" shows "Inflow (received)" instead of the raw string).

TxBooks auto-detects nine known CSV formats (BTCPay, Strike, Cash App, Coinbase, Kraken, Electrum, Exodus, OpenNode, CoinTracker). But CSV formats drift, and new sources show up.

Before today, if auto-detect failed and none of the manual format overrides matched, you were stuck. Now there's an escape hatch:

• Upload fails to auto-detect → we show you the actual headers from your file.
• Pick date column and BTC amount column from two dropdowns.
• Optional: map fee, transaction hash, and memo columns too.
• Choose a sign convention (positive = received / always absolute).
• Import.

The fallback handles any CSV with at least a date and a BTC amount column. Tested on hand-crafted weird exports and real data from sources we don't recognize. If the accountant can read it, TxBooks can import it.

TxBooks started as a US-first tool: Form 8949 and Schedule C cover American merchants, but everyone else was stuck mapping US-specific output to their local tax form by hand.

That's fixed. In merchant settings, pick your tax jurisdiction (United States, Brazil, Mexico, Portugal, Spain, or Other) and your reporting currency (now including BRL and MXN). Non-US merchants get a new Capital Gains Report export — per-lot disposal records with acquisition date, disposal date, cost basis, proceeds, realized gain, and holding period, in your local currency.

Hand it to your local accountant. They'll map it to IRPF, Modelo 100, or whatever your country's filing requires. We don't pretend to know your country's tax code — we produce clean bookkeeping data, they produce the filing.

US merchants see Form 8949 + Schedule C as before. Nothing changes for them.

If you tried to add a Taproot account from a Ledger before today, the sync silently found zero transactions. Ledger Live only exposes an xpub-prefixed key even for Taproot accounts, which TxBooks was interpreting as a legacy (1-prefix) wallet. Wrong derivation, wrong addresses, no matches.

Two changes fix it:

1. P2TR derivation added. Our xpub scanner now walks bc1p… Taproot addresses in addition to legacy, nested-segwit, and native-segwit.
2. Auto-fallback on zero results. If the prefix-detected derivation finds nothing, we automatically try the other three. Cost is small — at most ~40 extra Blockstream calls, paid only when the prefix doesn't match the actual account type — and invisible when detection is right on the first try.

In practice: paste any xpub, ypub, or zpub from any modern wallet. If it has on-chain activity, we find it. Ledger, Trezor, Sparrow, Electrum, BlueWallet, Exodus — all verified.

Multisig wallets (Casa, Unchained, Sparrow multisig, Nunchuk) still aren't supported — on the roadmap.