Every discipline this series teaches — the sizing rules, the security tiers, the rebalancing bands, the inheritance letter — assumes something deceptively simple: that you know what you hold. And crypto, more than any asset class a household touches, resists that knowledge by its very architecture: holdings fragment across exchange accounts (the transit layer), hardware wallets (the savings layer), the ETF in the brokerage (the wrapper layer), the stablecoin balance in the payments app, the DCA platform's custodial sliver, and — for the unlucky — the forgotten venue from two cycles ago. The result is the most common quiet failure in household crypto: nobody actually knows the total — which means the sizing rule governs a guess, the security budget protects an unknown, the tax file is a reconstruction waiting to fail, and the inheritance letter maps half the territory. This article builds the tracking system: the unified inventory across venues, the cost-basis layer the tax authority will eventually demand, the privacy-and-security constraints that make crypto tracking different from stock tracking, and the cadence that keeps the picture true without feeding the checking compulsion.
Why crypto fragments — and the inventory that reunifies it
The fragmentation is structural, not sloppy: the security doctrine itself mandates multiple venues (the airport rule splitting transit from savings; the wrapper article splitting keys from ETFs; the multi-exchange redundancy from the crisis playbook) — meaning a well-run household crypto position is supposed to live in four or five places, and the tracking problem is the success condition's shadow; add the accidental layer (the platform that got abandoned mid-cycle, the wallet from the experimentation phase, the fork-coins and airdrops that landed unasked) and the family layer (the spouse's separate exchange account, the DCA app in one name and the hardware wallet in another), and the average multi-year holder's true map has seven locations, two of them foggy; the unified inventory — one row per holding-location: the register that reunifies it, with the columns that matter: venue (the specific exchange account, the specific device, the brokerage), asset and amount (in native units — sats and coins, not just currency value: amounts are the truth, values are the weather), custody type (custodial / self-custody / wrapper — the column the security audit and the crisis playbook both read), access notes by reference (which seed backup, which account — pointing to the security system's artifacts, never containing secrets: the inventory is a map, not a keyring), and status (active / dormant / to-be-consolidated); the first assembly — the archaeology session: one honest evening: every exchange email ever received searched (the signup confirmations are the venue census), every device and drawer checked for wallets and seed backups (the recovery drill doubling as discovery), the brokerage and pension wrappers swept for crypto ETF positions (the exposure people forget they hold), the family venues merged into the household view (the shared-finances doctrine: one picture, whoever's name is on each account) — and the standard outputs of the first assembly being one pleasant surprise (the forgotten sliver), one security flag (the balance still sitting on the abandoned platform — the airport rule violation the audit exists to catch), and the consolidation list that shrinks seven venues toward the deliberate four.
The cost-basis layer: the records the tax authority will want
The inventory says what you hold; the cost-basis layer says what it cost — and the second is the one households skip until it's expensive: why it matters almost everywhere — most jurisdictions tax crypto disposals (sales, and in many systems crypto-to-crypto swaps and even spending — the taxable-event surprise from the tax article), computed as proceeds minus cost basis: without acquisition records, the taxpayer either reconstructs under audit pressure (years later, from dead platforms) or concedes the worst-case treatment (basis of zero — tax paid on the entire proceeds, a self-inflicted penalty measured in percentages of the whole position); the lot record — per acquisition: date, amount, price paid, fees, venue, and the evidence attachment (the exchange confirmation, the statement — the payment-proof doctrine applied to buys): trivially easy to keep in real time (the DCA schedule producing one identical row monthly, captured by habit or by the tracker's import), miserable to reconstruct (the archaeology session's second job: exporting full transaction histories from every venue while the accounts still exist — platforms die, get acquired, and purge histories: the export you can download today is the audit defense you can't download in five years, making the quarterly-export habit from the evidence article a tax strategy, not just tidiness); the method question, flagged for the professional hour — jurisdictions differ on which lots you're deemed to sell (FIFO, average cost, specific identification — the choice materially changing the tax bill on partial sales), and the household's job is not to master the doctrine but to keep records complete enough that any method is computable — completeness being the strategy that survives every rule change; and the special-events ledger — the acquisitions that aren't purchases, each with its documentation quirk: the fork and airdrop arrivals (valued at receipt in many systems — date-stamped), the gifts (donor's basis or market value by jurisdiction — the family transfer worth documenting like the family loans article documents lending), the mining or staking income where it applies (income at receipt, basis set thereby), and the payments received in crypto (the freelancer's invoice settled in USDT being income at that day's rate — the rate screenshot joining the invoice in the file).
The privacy and security constraints: tracking crypto is not tracking stocks
The practices that make crypto tracking safe rather than self-endangering: the aggregation-risk principle — a complete crypto inventory is a target dossier (the exact map an attacker wants: what exists, where, how much), so the tracking system inherits the security checklist's standards: the inventory lives in the protected tier (encrypted, access-controlled — the same class as the seed-storage documentation), never contains secrets (no seeds, no keys, no passwords — references only: "wallet A, backup per security doc"), and never gets shared whole (the accountant gets the cost-basis export; the dispute gets its exhibit; nobody gets the map); the API and read-only discipline — portfolio apps that sync exchange balances via API keys are convenient and graded by one rule: read-only keys, always (a tracking key with withdrawal permissions is a standing invitation — the permission checked at creation and the key list audited semi-annually per the checklist), with the tracker-app vetting mirroring the exchange vetting (who holds this data, where, trained on what — the AI article's privacy audit applying to any tool that sees your whole position); the address-tracking option — self-custody balances trackable by watching public addresses (the blockchain's transparency working for you: the watch-only wallet that sees balances without holding keys — the correct pattern for monitoring cold storage without touching it), with the privacy note attached: address reuse links your holdings publicly (the fresh-address hygiene from the security articles doubling as tracking hygiene — the watch-only wallet handles many addresses fine); and the household-access design — the tracking system as the inheritance letter's living companion: the inventory IS the "what exists and where" half of the letter (maintained continuously instead of annually), the access half stays in the security system's sealed artifacts, and the spouse's briefing covers reading the first without needing the second until needed — the division that lets the family see the position without the map becoming a shared attack surface.
The cadence: a true picture without the checking compulsion
The system's rhythm, tuned against both failure modes (the stale map and the obsessive refresh): continuous, by habit — new acquisitions logged at purchase (the four-second capture: the DCA fill, the P2P buy — the iron rule's crypto edition: no coins exist until they're in the inventory), venue changes logged at execution (the consolidation move, the cold-storage sweep — the inventory updating the moment custody does, because "I'll log it later" is how maps rot); monthly, in minutes — the reconciliation glance: venue balances against inventory rows (the read-only syncs doing it automatically; the manual venues eyeballed), the discrepancy rule being immediate investigation (a balance that doesn't match its row is either a logging gap or the security incident the checklist's audit exists to catch — both urgent); quarterly — the export ritual (every venue's transaction history downloaded and filed — the tax-defense habit), and the dormant-venue review (the to-be-consolidated list worked down); annually, at the review — the full audit: the inventory verified against reality (the recovery drill's discovery function), the sizing rules run against the true total (the whole point of the picture: the allocation percentage computed on facts, the rebalancing bands checked, the trim executed per written rules), the cost-basis file's completeness confirmed (the professional hour's raw material ready before it's needed), and the inheritance letter's map reconciled (the venues that changed this year reflected — the letter that describes last year's custody protects no one); and the anti-obsession guardrails — the tracking system deliberately decoupled from the price feed: the inventory's job is amounts and locations (which change rarely and by your own hand), the valuation layer is the weather (checked on the anxiety article's schedule, not the compulsion's), and the practical settings that enforce the split: no price notifications from the tracking app (the alerts article's levels live elsewhere, attached to decisions), the portfolio view opened for the monthly reconciliation and the scheduled reviews — because the entire architecture serves one sentence the series keeps earning: know exactly what you hold, check it on schedule, and let the number the crowd screams about all day remain, in your system, just the multiplier applied on review days to amounts you already trust.
Frequently asked questions
Do I really need this for my small monthly DCA into one platform?
You need the two-minute version, and you already almost have it: one venue means the inventory is one row, the platform's own history is your lot record (with the quarterly export as the one non-negotiable habit — small positions on single platforms are exactly the holdings that become unreconstructable when that platform dies), and the sizing check is a glance. The system earns its full depth at the first structural step — the first hardware wallet, the second venue, the ETF addition — which is also exactly when holdings start outgrowing memory. Start the habit at one row and the growth never outruns the map.
Portfolio apps want API keys to all my exchanges. Safe?
Safe within two hard rules: read-only permissions on every key (created that way, verified in the exchange's key settings — withdrawal-enabled tracking keys are the standing invitation the security checklist bans), and the app itself vetted like any custodian of sensitive data (who runs it, where data lives, breach history — a portfolio app knowing your total across venues is aggregation risk even without keys to move anything). The privacy-maximal alternative stack: manual entry for exchange balances (minutes monthly at household scale) plus watch-only addresses for cold storage — more friction, zero third-party map. Both patterns are legitimate; the choice is the standing convenience-versus-exposure trade, made knowingly.
I have years of untracked history across dead and living platforms. How do I rebuild cost basis?
Triage like the evidence article's backfill: living platforms first (full history exports today — the accounts that still work are the easy 80%), bank statements second (the fiat side of every buy is in your banking records — dates and amounts that anchor reconstruction even where the crypto side is foggy), email archaeology third (trade confirmations, deposit receipts — searchable by platform name), and the genuinely lost lots handled with professional guidance (jurisdictions have practices for undocumentable basis — conservative estimates with documented methodology beat both zero-basis surrender and invented numbers). Then the system starts today at full strength, because the rebuild's real lesson is its own cost: the quarterly export habit is an hour a year; the reconstruction was a weekend plus an accountant's bill.
Should my tracker show crypto merged with everything else, or separately?
Merged for decisions, separable for operations: the sizing rules that govern crypto are percentages of the whole household picture (the allocation question is unanswerable from a crypto-only view — the reason this series keeps crypto, gold, cash, and obligations in one system), while the operational layers (the security audit, the cost-basis file, the venue reconciliation) work the crypto rows specifically. The practical design: one unified net-worth view where crypto sits beside the metals band and the cash layers at live values, with the crypto detail one tap deeper — which is, not coincidentally, the architecture this blog's own tool runs, because the alternative (the crypto app over here, the real picture nowhere) is how allocations quietly double without anyone deciding it.
Key takeaways
- Fragmentation is the success condition's shadow: the security doctrine itself scatters holdings across venues, so the unified inventory — one row per holding-location, amounts in native units, custody type flagged, secrets referenced never contained — is what makes the rest of the system governable.
- Keep the cost-basis layer in real time: per-lot records with evidence attached, quarterly full-history exports while platforms still exist, and the special events (forks, gifts, income) documented at receipt — completeness is the strategy that survives every rule change.
- Track under security constraints: read-only API keys always, watch-only addresses for cold storage, the inventory in the protected tier, and the map never shared whole — a complete crypto inventory is a target dossier and gets guarded like one.
- Run the cadence: capture at acquisition, reconcile monthly in minutes, export quarterly, audit annually against the sizing rules and the inheritance letter — with the discrepancy rule making any mismatch an immediate investigation.
- Decouple amounts from prices: the inventory tracks what changes by your hand, the valuation is weather checked on schedule — know exactly what you hold, and let the screaming number be just the multiplier on review day.
The closing image: two families each believe they hold 'about five percent' in crypto. In the first, the number is folklore — an exchange balance nobody's opened since the last cycle, a hardware wallet whose amount is 'roughly half a coin?', an ETF the other spouse forgot to mention — and the truth, assembled painfully after a tax letter, turns out to be eleven percent, a dead platform, and a missing seed. In the second, the number is a row total: seven venues once, four now, every lot dated and evidenced, the annual trim executed last spring because the true picture crossed the written band. Same intention, same asset class. One household had a feeling about its position. The other had a map — and in an asset class that scatters by design, the map was never optional; it was just either built on schedule or reconstructed under pressure.
How Wajib AI helps
This is native Wajib AI territory: holdings logged across every venue — exchange, cold storage, ETF — valued live in your currency beside the gold and cash layers, cost basis and evidence attached per lot, and the whole position visible as one number the sizing rules can actually govern.
Download Wajib AI free and keep every commitment, price, and payment in one place.