<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Crypto Tax Archives - LadyChain</title>
	<atom:link href="https://www.ladyww.net/tag/crypto-tax/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.ladyww.net/tag/crypto-tax/</link>
	<description>Crypto fees, wallets and offers — checked against the terms page</description>
	<lastBuildDate>Tue, 27 Oct 2026 16:02:49 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1</generator>

<image>
	<url>https://www.ladyww.net/wp-content/uploads/2026/10/mark-512-150x150.png</url>
	<title>Crypto Tax Archives - LadyChain</title>
	<link>https://www.ladyww.net/tag/crypto-tax/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Accounting for Staking Rewards</title>
		<link>https://www.ladyww.net/staking-accounting/</link>
					<comments>https://www.ladyww.net/staking-accounting/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 16:02:49 +0000</pubDate>
				<category><![CDATA[Staking]]></category>
		<category><![CDATA[Cost Basis]]></category>
		<category><![CDATA[Crypto Accounting]]></category>
		<category><![CDATA[Crypto Tax]]></category>
		<category><![CDATA[FIFO]]></category>
		<category><![CDATA[Portfolio Reporting]]></category>
		<category><![CDATA[Reward Ledger]]></category>
		<category><![CDATA[Slashing]]></category>
		<category><![CDATA[Staking Income]]></category>
		<category><![CDATA[Staking Rewards]]></category>
		<category><![CDATA[Tax Records]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/staking-accounting/</guid>

					<description><![CDATA[<p>Staking rewards accounting begins with an awkward fact: value arrived in your wallet without a sale, a trade, or an invoice. Nothing was bought, yet something was earned, and the [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/staking-accounting/">Accounting for Staking Rewards</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Staking rewards accounting begins with an awkward fact: value arrived in your wallet without a sale, a trade, or an invoice. Nothing was bought, yet something was earned, and the earned thing needs a number attached to it before it can be reported.</p>
<p>For most individual filers, staking rewards accounting means keeping two linked records — ordinary income at the moment the reward becomes controllable, valued in your functional currency at that moment, and a cost basis carried forward from that same value. The first number is the one people get wrong, and it is the one that cannot be reconstructed a year later.</p>
<ul>
<li><strong>Income and basis are the same number.</strong> What you report at receipt becomes what you subtract at disposal; if one is fudged, the other is wrong too.</li>
<li><strong>Frequency matters, not just the total.</strong> Twelve small receipts at different prices produce a different result from one annual receipt of identical size.</li>
<li><strong>Rewards paid in a second token are a separate asset.</strong> Track quantity, price and basis per asset, not per wallet.</li>
<li><strong>Auto-compounding still creates receipts.</strong> Value received and immediately redeployed is value received, whether or not it ever sat still in your balance.</li>
</ul>
<h2>Why staking rewards accounting is harder than dividend reporting</h2>
<p>A dividend arrives as cash in a currency with one price, on a published date, in a round number. A staking reward arrives as a protocol token, often every epoch, sometimes in a token you did not choose, at a price that moved while you slept.</p>
<p>Three properties do the damage. Receipt is continuous rather than discrete, so there is no single date to point at. The asset received is usually the same asset you staked, so the wallet balance barely appears to change. And the value is denominated in something you never transacted in, which means every receipt requires a price lookup from a source you should be able to defend later.</p>
<h2>The three events that create an entry</h2>
<p>Almost every entry in a staking ledger traces back to one of three events: receipt, disposal, or penalty.</p>
<h3>Receipt</h3>
<p>Receipt is the moment the reward becomes yours to move. For most networks that means it lands in an address you control, not the moment a validator was assigned the work. Record quantity, asset, timestamp, and the price in your functional currency at that timestamp.</p>
<p>The price source matters. A single exchange&#8217;s last trade at 03:00 on a low-volume pair is a weaker number than a volume-weighted average across several venues, so pick one reference and stick to it.</p>
<h3>Disposal</h3>
<p>Disposal is any moment the asset leaves your control in exchange for something else — a sale, a swap, a payment, or a conversion to another token. Here you realise gain or loss equal to proceeds minus the basis accumulated at receipt.</p>
<p>Swaps are the trap. Trading token A for token B is a disposal of A in most jurisdictions, even though no fiat ever touched the transaction. The gain is measured in your functional currency, not in the token you received.</p>
<h3>Penalty and slashing</h3>
<p>A slashing event reduces your staked balance without a disposal, and treatment varies. Some frameworks treat the loss as a capital loss on the underlying, others as a reduction of previously recognised income, and some are silent. Rules differ by jurisdiction, so this is a question for a local adviser rather than a general article.</p>
<h2>Choosing a staking rewards accounting method</h2>
<p>The method you pick determines which basis gets consumed first, and therefore how much gain lands in a given year. It is a choice worth making deliberately rather than by default.</p>
<h3>FIFO, LIFO and specific identification</h3>
<p>First-in-first-out consumes your oldest basis first and is the default in many frameworks. Last-in-first-out is permitted in fewer places and often needs explicit election.</p>
<p>Specific identification lets you point at particular lots, which is the most flexible and the most demanding. It requires lot-level records from the beginning — you cannot reconstruct lot identity after the fact from an aggregated balance.</p>
<h3>Pooled or per-wallet tracking</h3>
<p>Pooling treats all units of one asset across all your addresses as a single balance. It is simpler and usually adequate for a personal portfolio. Per-wallet tracking is more precise and becomes necessary if you run separate entities, keep business and personal funds apart, or need to explain a transfer between your own addresses.</p>
<blockquote><p>Transfers between addresses you control are not disposals in most frameworks, but they are the single most common cause of a broken cost basis — because the receiving wallet&#8217;s software often treats the arrival as a zero-cost acquisition.</p></blockquote>
<div class="slv-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-800/70 bg-ink-900" data-slv-table><table>
<thead>
<tr>
<th>Method</th>
<th>What it produces</th>
<th>Record burden</th>
<th>Common constraint</th>
</tr>
</thead>
<tbody>
<tr>
<td>FIFO</td>
<td>Oldest basis consumed first</td>
<td>Low — chronological list only</td>
<td>Default in many jurisdictions; little flexibility</td>
</tr>
<tr>
<td>LIFO</td>
<td>Newest basis consumed first</td>
<td>Low to moderate</td>
<td>Not permitted everywhere; may need an election</td>
</tr>
<tr>
<td>Specific identification</td>
<td>Chosen lots consumed</td>
<td>High — lot-level from day one</td>
<td>Must be documented at the time, not later</td>
</tr>
<tr>
<td>Weighted average cost</td>
<td>Single blended basis per asset</td>
<td>Moderate — periodic recalculation</td>
<td>Available for some asset classes only</td>
</tr>
<tr>
<td>Pooled across wallets</td>
<td>One basis per asset, all addresses</td>
<td>Moderate</td>
<td>Blurs entity boundaries if you hold more than one</td>
</tr>
</tbody>
</table></div>
<h2>A worked year, and the ledger that produces it</h2>
<p>Assume a hypothetical delegation of 10,000 units of a token, paying 50 units monthly for twelve months — 600 units in total — at the prices in the table below. Numbers are illustrative, not a rate forecast.</p>
<p>Receipts: January 50 units at 1.00 = 50.00; February at 1.10 = 55.00; March at 1.20 = 60.00; April at 1.30 = 65.00; May at 1.40 = 70.00; June at 1.20 = 60.00; July at 1.00 = 50.00; August at 0.90 = 45.00; September at 1.10 = 55.00; October at 1.50 = 75.00; November at 1.80 = 90.00; December at 2.00 = 100.00. Total ordinary income recognised: 775.00, against 600 units received, an average basis of 1.2917 per unit.</p>
<p>Now sell 300 units at 2.20 for proceeds of 660.00. Under FIFO the 300 units come from January through June — six receipts of 50 units, costing 50.00 + 55.00 + 60.00 + 65.00 + 70.00 + 60.00 = 360.00. Realised gain: 660.00 − 360.00 = 300.00. Remaining basis for the 300 unsold units: 775.00 − 360.00 = 415.00.</p>
<p>Under a weighted average cost approach the same sale would consume 300 × 1.2917 = 387.51 of basis and realise 272.49 — same receipts, same sale, different reported gain.</p>
<ol>
<li>Fix one functional currency and one price source before the first receipt, and record both in the file header.</li>
<li>Export every reward payout monthly as a raw list of timestamp, asset and quantity, straight from the address&#8217;s transaction history.</li>
<li>Attach a price to each line on its own date; never use a month-end price for a mid-month receipt.</li>
<li>Tag each line with the address and the entity that owns it, so pooled totals can be split later if needed.</li>
<li>Reconcile the reward total against on-chain balance changes quarterly; unexplained differences are usually a missed auto-compound or a fee.</li>
<li>Store the file with the price source URLs alongside the numbers, so a reviewer can reproduce any single line.</li>
<li>Re-run the disposal calculation whenever the method changes, and keep the prior output rather than overwriting it.</li>
</ol>
<p>The post <a href="https://www.ladyww.net/staking-accounting/">Accounting for Staking Rewards</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/staking-accounting/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Crypto Tax Basics: What Counts as an Event</title>
		<link>https://www.ladyww.net/crypto-tax-basics/</link>
					<comments>https://www.ladyww.net/crypto-tax-basics/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 14:02:30 +0000</pubDate>
				<category><![CDATA[Regulation]]></category>
		<category><![CDATA[Capital Gains]]></category>
		<category><![CDATA[Cost Basis]]></category>
		<category><![CDATA[Crypto Tax]]></category>
		<category><![CDATA[Disposals]]></category>
		<category><![CDATA[Income]]></category>
		<category><![CDATA[Jurisdiction]]></category>
		<category><![CDATA[Record Keeping]]></category>
		<category><![CDATA[Reporting]]></category>
		<category><![CDATA[Taxable Event]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/crypto-tax-basics/</guid>

					<description><![CDATA[<p>A crypto taxable event is a transaction a tax authority treats as a realisation — a point where you are considered to have given something up and, usually, to have [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/crypto-tax-basics/">Crypto Tax Basics: What Counts as an Event</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>A crypto taxable event is a transaction a tax authority treats as a realisation — a point where you are considered to have given something up and, usually, to have received something in return. The trigger is legal and accounting-based rather than technical, which is why a transfer between two wallets you control is a blockchain event but normally not a crypto taxable event, while a swap between two coins you never withdraw almost certainly is.</p>
<p>Most people meet this rule the hard way, at year end, in front of a list of transactions they have already forgotten making. The cheaper approach is to classify as you go. Once a transaction can be sorted into disposal, income, or neither, the record-keeping becomes mechanical and the annual reconciliation stops being archaeology.</p>
<ul>
<li><strong>Realisation, not movement, is the trigger.</strong> A transfer between wallets you control usually changes nothing; a trade changes ownership twice in one moment.</li>
<li><strong>Income and disposal are separate events.</strong> Earning coins creates income at receipt, and selling them later creates a second, independent event.</li>
<li><strong>Fees belong in the numbers.</strong> Network and trading fees typically adjust either proceeds or basis, and which one depends on the jurisdiction.</li>
<li><strong>Classification is cheapest at the moment of the trade.</strong> A note written that week is worth more than a reconstruction two years later.</li>
</ul>
<h2>The two families of crypto taxable event</h2>
<p>Almost every crypto taxable event falls into one of two families: a disposal, where you give up an asset, or income, where you receive one for work, rewards or a distribution. The families are not exclusive — one transaction can produce both — but they are computed and reported differently, so the label matters before any arithmetic starts.</p>
<h3>Disposals</h3>
<p>A disposal happens when ownership changes: selling for fiat, trading one coin for another, paying for goods or services, and in many jurisdictions spending crypto in any way that transfers it to someone else. The measure is usually proceeds minus basis, with the difference landing as a capital gain or loss. The detail that surprises people is that a coin-to-coin trade generally counts as two disposals in sequence, because you disposed of what you gave and acquired what you received at the same instant.</p>
<h3>Income</h3>
<p>Income events are receipts. Mining rewards, staking distributions, interest paid in kind, airdrops with a determinable value, and salary paid in crypto are commonly treated as ordinary income when received, measured at the value at that moment. That value usually becomes your basis in the coins, which means the same coins generate a second event when you later dispose of them. Nothing is being counted twice; two distinct events exist.</p>
<h3>Why the distinction changes the outcome</h3>
<p>The two families are often taxed under different rules, and in many jurisdictions at different rates. Ordinary income is generally recognised when received, while capital treatment can depend on how long the asset was held in places that distinguish holding periods. Because characterisation drives the result, recording an income receipt as though it were a simple transfer is one of the more expensive bookkeeping errors available.</p>
<h2>Transactions that are usually not crypto taxable events</h2>
<p>Several common actions look like events and usually are not, provided nothing of value changes hands.</p>
<h3>Moving between your own wallets</h3>
<p>Sending coins from an exchange account to a hardware wallet is normally not a disposal, because beneficial ownership did not change. It still matters for basis tracking: the receiving wallet inherits the original cost and date, and the transfer fee is usually treated either as an adjustment to basis or as a small separate disposal, depending on the jurisdiction.</p>
<h3>Buying with fiat and holding</h3>
<p>An acquisition on its own is usually not a taxable event; it establishes basis. The event arrives later, when you dispose. This is why a year of accumulation produces a long list of records and no reportable events at all, and why the disposal year is the one that needs those records.</p>
<p>Two grey areas deserve their own paragraph. Wrapping or bridging an asset, and receiving a new token through a migration or rebrand, are treated inconsistently: some jurisdictions see a continuation of the same holding, others see a disposal followed by a fresh acquisition. Neither view is universal, and the defensible answer depends on facts you should document at the time rather than reconstruct later.</p>
<h2>Sorting transaction types at a glance</h2>
<p>The table below is a starting point for classification, not a substitute for local rules. Every row has exceptions, and the exceptions tend to be where the money is.</p>
<div class="slv-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-800/70 bg-ink-900" data-slv-table><table>
<thead>
<tr>
<th>Transaction</th>
<th>Usual treatment</th>
<th>Record it creates</th>
</tr>
</thead>
<tbody>
<tr>
<td>Buy with fiat</td>
<td>Acquisition, no event yet</td>
<td>Basis, date, fee</td>
</tr>
<tr>
<td>Sell for fiat</td>
<td>Disposal</td>
<td>Proceeds, basis, result</td>
</tr>
<tr>
<td>Coin-to-coin swap</td>
<td>Usually two disposals</td>
<td>Both legs at value on the day</td>
</tr>
<tr>
<td>Staking or mining reward</td>
<td>Usually income at receipt</td>
<td>Value at receipt, new basis</td>
</tr>
<tr>
<td>Transfer between own wallets</td>
<td>Usually not an event</td>
<td>Original basis and date carried over</td>
</tr>
<tr>
<td>Gift sent or received</td>
<td>Depends on jurisdiction</td>
<td>Value, counterparty, date</td>
</tr>
</tbody>
</table></div>
<p>Note what the third column has in common: every row demands a value on a specific day. That single requirement drives most of the operational cost of crypto tax work, because the value has to come from somewhere defensible — a venue statement, a timestamped price source, or a documented convention applied consistently.</p>
<blockquote><p>The question is never &#8220;did the blockchain change?&#8221; It is &#8220;did ownership change, and was anything received in exchange?&#8221; Everything after that is bookkeeping.</p></blockquote>
<h2>How to classify a transaction in seven steps</h2>
<p>Run this on every entry in an export before you look at any totals. Doing it in this order prevents the common mistake of treating a swap as a single line.</p>
<ol>
<li>Identify whether you gave up an asset, received one, or both.</li>
<li>Ask whether ownership changed or only the address holding it changed.</li>
<li>If you received something without paying for it from your own capital, treat it as possible income and record the value at receipt.</li>
<li>If you gave something up, record proceeds — including the value of anything received in kind — and the basis of the specific units disposed of.</li>
<li>Record fees separately and attach them to the correct side; which side is a jurisdictional question.</li>
<li>Tag the entry with the wallet, the venue, and a transaction reference so it can be tied back to a statement.</li>
<li>Review the tagged list monthly rather than annually, while the context is still recoverable.</li>
</ol>
<p>The monthly habit matters more than the tooling. A transaction you cannot explain is a transaction you will eventually have to defend, and the difference between a two-minute note and a two-hour reconstruction is usually whether the browser tab was still open.</p>
<p>The post <a href="https://www.ladyww.net/crypto-tax-basics/">Crypto Tax Basics: What Counts as an Event</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/crypto-tax-basics/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Reconstructing Cost Basis From On-Chain History</title>
		<link>https://www.ladyww.net/reconstruct-cost-basis/</link>
					<comments>https://www.ladyww.net/reconstruct-cost-basis/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 12:02:31 +0000</pubDate>
				<category><![CDATA[Regulation]]></category>
		<category><![CDATA[Accounting]]></category>
		<category><![CDATA[Average Cost]]></category>
		<category><![CDATA[Compliance]]></category>
		<category><![CDATA[Cost Basis]]></category>
		<category><![CDATA[Crypto Tax]]></category>
		<category><![CDATA[FIFO]]></category>
		<category><![CDATA[On-Chain Analysis]]></category>
		<category><![CDATA[Reconstruction]]></category>
		<category><![CDATA[Record Keeping]]></category>
		<category><![CDATA[Specific Identification]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/reconstruct-cost-basis/</guid>

					<description><![CDATA[<p>Cost basis crypto work is the discipline of attaching a price and a date to every unit you later dispose of. The chain proves movement, not money: a wallet receives [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/reconstruct-cost-basis/">Reconstructing Cost Basis From On-Chain History</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Cost basis crypto work is the discipline of attaching a price and a date to every unit you later dispose of. The chain proves movement, not money: a wallet receives an amount at a block height, and nothing in the transaction says what you agreed to pay, what fee you paid, or whether the transfer was a purchase, a gift, or a shuffle between two addresses you own.</p>
<p>Reconstructing cost basis crypto from history is therefore an accounting exercise wearing a blockchain costume. The chain gives you a ledger of quantities and timestamps of unusually good quality. Everything that determines tax — price, intent, ownership, fees — has to be recovered from somewhere else and matched to those quantities.</p>
<ul>
<li><strong>On-chain data answers &#8220;how many&#8221; and &#8220;when&#8221;, never &#8220;for how much&#8221;.</strong> Price has to come from an external, documented source.</li>
<li><strong>Method choice changes the answer.</strong> FIFO and specific identification can produce materially different gains on the same transactions.</li>
<li><strong>Lost basis is not zero basis by default.</strong> It is a documentation problem that usually has a defensible resolution, found before a deadline rather than after.</li>
<li><strong>Reconstruction quality is measured by reproducibility.</strong> Someone else should be able to follow your steps and reach the same numbers.</li>
</ul>
<h2>What the chain proves and what it cannot</h2>
<p>The chain proves that a quantity moved from one address to another at a specific time, and it proves it permanently. That is genuinely useful: it settles sequencing questions that bank records handle badly, and it makes &#8220;which came first&#8221; arguments short.</p>
<h3>What a transfer establishes</h3>
<p>An incoming transfer establishes that a wallet received a precise amount, that it received it after a specific block, and that the amount has not moved since unless a later transaction shows otherwise. For a reconstruction, this is the skeleton: it tells you which holdings existed, in what order, and how they were split across addresses.</p>
<h3>What a transfer leaves ambiguous</h3>
<p>Almost everything that matters financially. An incoming transfer is consistent with a purchase, a withdrawal from a venue, a payment for work, a gift, an internal rebalance, or a loan collateralisation. All of those are the same on-chain shape — value arriving — and they carry completely different tax treatment. Address clustering hints at ownership but is inference, not evidence, and treating a heuristic as proof is how reconstructions go wrong.</p>
<h2>Choosing a cost basis crypto method</h2>
<p>The method decides which units you are treated as having sold when you dispose of part of a holding. It is a policy choice within whatever your jurisdiction allows, and once chosen it should be applied consistently rather than opportunistically.</p>
<h3>First in, first out</h3>
<p>FIFO treats the oldest units as sold first, regardless of which coins you actually moved. It is the default in many jurisdictions and the easiest to defend, because it requires no per-unit identification. The cost is that in a long accumulation, early cheap lots get consumed first, which often produces the largest gain in the year of sale.</p>
<h3>Specific identification</h3>
<p>Specific identification lets you nominate which lots were disposed of, provided you can support the identification with contemporaneous records. It is more flexible and considerably more demanding: it works when you can point to which units went where, and it fails when your only evidence is a wallet balance.</p>
<h3>Average cost</h3>
<p>Some jurisdictions permit a pooled average cost across units of the same asset. It smooths the result and removes the lot-selection question, but it is not universally available, and mixing it with FIFO across years is usually not allowed.</p>
<div class="slv-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-800/70 bg-ink-900" data-slv-table><table>
<thead>
<tr>
<th>Method</th>
<th>What it assumes</th>
<th>Record burden</th>
<th>Where it fits</th>
</tr>
</thead>
<tbody>
<tr>
<td>FIFO</td>
<td>Oldest units sold first</td>
<td>Low; needs dates and amounts</td>
<td>Default treatment, simple accumulation</td>
</tr>
<tr>
<td>Specific identification</td>
<td>You nominate the lots</td>
<td>High; needs per-lot provenance</td>
<td>Multiple lots, deliberate lot selection</td>
</tr>
<tr>
<td>Average cost</td>
<td>One pooled cost per asset</td>
<td>Medium; needs full history in one pool</td>
<td>Jurisdictions that allow pooling</td>
</tr>
<tr>
<td>Mixed by account</td>
<td>Separate pools per wallet or venue</td>
<td>High; needs clean separation</td>
<td>Segregated strategies, entity accounts</td>
</tr>
</tbody>
</table></div>
<p>Pick the method before you compute anything, write down why, and apply it to every asset in the same year. Switching methods mid-history to reduce a number is the kind of choice that reads as an error even when the underlying position is defensible.</p>
<blockquote><p>Cost basis is not a fact about a coin. It is a fact about a specific unit you once acquired, and the whole job is keeping that unit identifiable after it has been split, merged and moved six times.</p></blockquote>
<h2>A worked reconstruction</h2>
<p>Suppose you bought 1.0 unit at 20,000, then bought 0.5 unit at 40,000, then sold 0.75 unit at 50,000. Total cost was 20,000 + 20,000 = 40,000 for 1.5 units. Proceeds were 0.75 × 50,000 = 37,500. What the gain is depends entirely on the method.</p>
<ol>
<li>FIFO: the 0.75 sold comes out of the first lot at 20,000 per unit, so basis is 0.75 × 20,000 = 15,000.</li>
<li>FIFO gain: 37,500 − 15,000 = 22,500.</li>
<li>FIFO remainder: 0.25 unit at 20,000 plus 0.5 unit at 40,000, total basis 25,000 for 0.75 unit.</li>
<li>Average cost: pooled basis per unit is 40,000 ÷ 1.5 = 26,666.67.</li>
<li>Average cost basis for the sale: 0.75 × 26,666.67 = 20,000.</li>
<li>Average cost gain: 37,500 − 20,000 = 17,500.</li>
<li>Difference between methods on this single sale: 22,500 − 17,500 = 5,000 of gain, from the same three trades.</li>
</ol>
<p>Nothing about the transactions changed. The 5,000 difference is purely a function of which units the method says you sold, and it moves in the opposite direction in a later year because the remaining basis differs too. This is why a reconstruction that skips the method question produces a number that cannot be reconciled later.</p>
<h2>Making a cost basis crypto reconstruction survive review</h2>
<p>A reconstruction is only as good as its worst-supported link. Reviewers do not usually argue about arithmetic; they ask where a price came from and why a transfer was classified the way it was.</p>
<h3>Price sources</h3>
<p>Use a documented source per asset and per period, and keep the export. A venue statement is strongest for trades executed there. For transfers, a timestamped reference price is normal practice, with the convention written down: which timestamp, which market, which currency. Consistency across the whole history matters more than which convention you chose.</p>
<h3>Gaps and estimates</h3>
<p>Some records will be missing — a closed account, an old wallet, a purchase whose confirmation email is gone. Handle gaps explicitly: label them as estimates, state the basis for the estimate, and keep the supporting calculation. An acknowledged estimate is a much better position than a silent guess buried in a spreadsheet cell.</p>
<h3>Fees and transfers</h3>
<p>Network fees paid in the disposed asset are themselves a disposal in many jurisdictions, which means a fee line can create a tiny gain or loss of its own. Trading fees usually adjust proceeds or basis. Neither treatment is universal, which is one more reason to write down the convention you applied.</p>
<p>The post <a href="https://www.ladyww.net/reconstruct-cost-basis/">Reconstructing Cost Basis From On-Chain History</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/reconstruct-cost-basis/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>What Exchanges Report About You</title>
		<link>https://www.ladyww.net/exchange-reporting/</link>
					<comments>https://www.ladyww.net/exchange-reporting/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 10:02:31 +0000</pubDate>
				<category><![CDATA[Regulation]]></category>
		<category><![CDATA[Audit Trail]]></category>
		<category><![CDATA[Compliance]]></category>
		<category><![CDATA[Crypto Tax]]></category>
		<category><![CDATA[Exchange Reporting]]></category>
		<category><![CDATA[Identity Checks]]></category>
		<category><![CDATA[Information Returns]]></category>
		<category><![CDATA[Jurisdiction]]></category>
		<category><![CDATA[Reconciliation]]></category>
		<category><![CDATA[Records]]></category>
		<category><![CDATA[Tax Reporting]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/exchange-reporting/</guid>

					<description><![CDATA[<p>Exchange tax reporting is the flow of account data from a trading venue to a tax authority, and it is narrower than most people assume. A venue generally reports what [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/exchange-reporting/">What Exchanges Report About You</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Exchange tax reporting is the flow of account data from a trading venue to a tax authority, and it is narrower than most people assume. A venue generally reports what it can see: the trades on its own order books, the fiat that moved through its banking rails, and the identity attached to the account. It does not report your wallet balances, your positions elsewhere, or what you originally paid for the coins you deposited.</p>
<p>That gap is the whole story. Exchange tax reporting is an information stream, not an assessment. It tells an authority that something happened; it rarely tells them whether the result was a gain, a loss, or neither — and that determination depends on records the venue has never held.</p>
<ul>
<li><strong>Reporting is usually about gross amounts, not net results.</strong> Proceeds without cost basis look like income to anyone reading a summary.</li>
<li><strong>Coverage is venue-by-venue.</strong> Accounts on different platforms produce separate streams that may never be joined up.</li>
<li><strong>Deposits are the weak point.</strong> A coin bought elsewhere and sold here arrives with no price history attached.</li>
<li><strong>Your own records remain the primary source.</strong> Reporting is cross-checked against them, not a replacement for them.</li>
</ul>
<h2>What exchange tax reporting usually contains</h2>
<p>Reporting scope depends on the jurisdiction, the venue, and the type of account, but the underlying data set is fairly consistent because it comes from the same order management systems that produce your statements.</p>
<h3>Proceeds rather than profit</h3>
<p>Most regimes built for securities reporting were designed around gross proceeds, because the broker knows the sale price and does not know the customer&#8217;s basis. Crypto venues inherit that shape. A report can therefore show a large sale figure that, once matched against an original purchase, turns out to be a modest gain or an outright loss. Reading the reported number as taxable income overstates the liability badly.</p>
<h3>Identity and account scope</h3>
<p>Venues report against verified identity, which is why the account registration details matter more than the trading activity. An account opened in one name, funded from a shared bank account, and used by two people creates a reporting mismatch that is tedious to unwind later. The same applies to business accounts used for personal trades, or personal accounts used for a company&#8217;s treasury.</p>
<h3>What is usually excluded</h3>
<p>Self-custody wallets, activity on venues that do not report in your jurisdiction, peer-to-peer trades, and anything that never touched a reporting entity. This is not a loophole; it is the reason a complete picture requires your own records alongside the reported ones.</p>
<h2>Where exchange tax reporting diverges from your books</h2>
<p>Divergence is normal rather than exceptional. The two datasets are built for different purposes: one for matching identity to transactions, the other for computing a result.</p>
<h3>Transfers in and out</h3>
<p>A withdrawal of coins to a wallet is usually reported as a movement with no gain attached, because nothing was sold. The consequence appears later: when those coins come back and are sold, the venue has proceeds and no basis. If your records also lost track of the original purchase, the same transaction is unattributed on both sides, and the reconstruction becomes the expensive kind.</p>
<h3>Wrapped, rebased and renamed assets</h3>
<p>Wrapped tokens, rebasing balances, and assets that migrate to a new contract all break the simple one-asset-one-history assumption. A venue may report the new ticker, your notes may hold the old one, and the quantities may not match because a rebase changed them without a transaction. Reconciliations fail on these cases far more often than on ordinary trades.</p>
<h3>Fees, rewards and adjustments</h3>
<p>Trading fees are usually visible. Staking distributions, referral credits, and promotional bonuses are less consistently reported, and their treatment varies: some are income at receipt, some reduce cost, some are not reportable until disposal. A venue summary that omits them is not wrong; it is simply reporting a different question.</p>
<h2>Matching reported data against your own records</h2>
<p>The table below maps the usual sources and what each one cannot tell you. Use it to decide where a reconciliation needs a third input.</p>
<div class="slv-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-800/70 bg-ink-900" data-slv-table><table>
<thead>
<tr>
<th>Record type</th>
<th>Who holds it</th>
<th>What it usually misses</th>
</tr>
</thead>
<tbody>
<tr>
<td>Venue trade history</td>
<td>The exchange</td>
<td>Basis on deposited coins</td>
</tr>
<tr>
<td>Information return or statement</td>
<td>The exchange, sent onward</td>
<td>Losses netting, cross-venue activity</td>
</tr>
<tr>
<td>On-chain transaction log</td>
<td>Public ledger</td>
<td>Price, ownership, intent</td>
</tr>
<tr>
<td>Bank and payment records</td>
<td>Bank, processor</td>
<td>What was bought, at what quantity</td>
</tr>
<tr>
<td>Your own ledger</td>
<td>You</td>
<td>Nothing, if maintained; everything, if not</td>
</tr>
</tbody>
</table></div>
<p>The last row is the uncomfortable one. Every other source is a partial view held by someone else. Only your ledger is designed to answer the question actually being asked, which is what each disposal cost you.</p>
<blockquote><p>Reported data answers &#8220;what did this account do&#8221;. Your records answer &#8220;what did this cost me&#8221;. Tax is computed from the second question, which is why the first one so often looks alarming.</p></blockquote>
<h2>Reconciling exchange tax reporting in six steps</h2>
<p>Run the reconciliation once per year, before any filing deadline rather than during it. The sequence below keeps the two datasets separate until the final comparison, which prevents one from quietly overwriting the other.</p>
<ol>
<li>Export the full transaction history from every venue you used, including closed accounts if the export is still available.</li>
<li>Export your own ledger, or build one, with a row per acquisition and a row per disposal.</li>
<li>Match by timestamp, asset, quantity and reference, starting with the largest amounts rather than the earliest.</li>
<li>Flag every disposal in the venue data that has no matching acquisition in your ledger — these are the deposited coins.</li>
<li>Flag every acquisition in your ledger that has no venue record, which usually means a self-custody buy or a transfer in.</li>
<li>Resolve the flags with a documented assumption: a stated price source, a transfer link, or a labelled estimate.</li>
<li>Recompute totals only after the flags are closed, so the arithmetic is not masking a classification error.</li>
</ol>
<p>Expect a residual list that never fully closes. A handful of small unmatched items is normal; a large unexplained block is not, and it usually points to an account you have forgotten rather than to a venue error.</p>
<h2>What to do when the numbers disagree</h2>
<p>Disagreement is a signal about your records, not about the venue&#8217;s honesty. Start by checking whether the two datasets are measuring the same thing: one may include internal transfers, the other may exclude fees, and both may be correct on their own terms.</p>
<p>If the difference survives that check, document it. Write down the size of the gap, the likely cause, and the treatment you applied. A reconciliation file with a short explanation is worth more than a perfectly matched spreadsheet nobody can audit, because the explanation is what makes the position defensible if anyone asks.</p>
<p>Where the amount is material, the right move is to get local advice rather than to guess at a convention. Rules differ by jurisdiction, thresholds differ, and the treatment of a specific transaction type often turns on facts a general article cannot see. Nothing here is tax or legal advice.</p>
<p>The post <a href="https://www.ladyww.net/exchange-reporting/">What Exchanges Report About You</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/exchange-reporting/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
