<?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>Tax Records Archives - LadyChain</title>
	<atom:link href="https://www.ladyww.net/tag/tax-records/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.ladyww.net/tag/tax-records/</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>Tax Records Archives - LadyChain</title>
	<link>https://www.ladyww.net/tag/tax-records/</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>Reading Your Exchange Statement</title>
		<link>https://www.ladyww.net/exchange-statement/</link>
					<comments>https://www.ladyww.net/exchange-statement/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 12:02:14 +0000</pubDate>
				<category><![CDATA[Exchanges]]></category>
		<category><![CDATA[Cost Basis]]></category>
		<category><![CDATA[Data Export]]></category>
		<category><![CDATA[Exchange Statement]]></category>
		<category><![CDATA[Fee Reporting]]></category>
		<category><![CDATA[Portfolio Accounting]]></category>
		<category><![CDATA[Reconciliation]]></category>
		<category><![CDATA[Record Keeping]]></category>
		<category><![CDATA[Tax Records]]></category>
		<category><![CDATA[Transaction History]]></category>
		<category><![CDATA[Withdrawal Log]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/exchange-statement/</guid>

					<description><![CDATA[<p>An exchange statement is a record of what the venue did with your money, not a record of what your money is worth. Those two things diverge constantly, and most [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/exchange-statement/">Reading Your Exchange Statement</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>An exchange statement is a record of what the venue did with your money, not a record of what your money is worth. Those two things diverge constantly, and most of the confusion around statements comes from reading the second meaning into the first.</p>
<p>A good exchange statement answers three questions: what moved, when it moved, and what was charged for moving it. It does not answer whether you made money, because it does not know your cost basis on assets you transferred in, and it does not know what you did elsewhere. Read it as a record of events, and it becomes useful.</p>
<ul>
<li><strong>Statements describe flows, not performance.</strong> Deposits, withdrawals, trades and fees are events. Profit and loss is a derived figure that depends on assumptions the statement does not contain.</li>
<li><strong>Timestamps are usually in one timezone.</strong> Most venues record in UTC. A trade at 23:40 UTC lands on a different calendar day in many local timezones, which matters at period boundaries.</li>
<li><strong>Fees appear in two currencies.</strong> Some are charged in the asset bought, some in the quote currency. Summing a column without checking the unit produces nonsense.</li>
<li><strong>Reconciliation is the test.</strong> Opening balance plus inflows minus outflows should equal closing balance. If it does not, something in the statement is missing or misread.</li>
</ul>
<h2>What an exchange statement is built from</h2>
<p>A statement is a rendering of the venue&#8217;s internal records over a period. Each line corresponds to a booked event, and the same event can appear more than once in different sections — once as a trade, once as a fee, once as a balance change.</p>
<p>Double counting is therefore easy. Knowing which section is authoritative for which question is most of the skill.</p>
<h3>The four sections you will find</h3>
<p>Most exports contain a transaction history, a fee summary, a deposit and withdrawal log, and an opening and closing balance. The first is the detail, the second is a subtotal of the first, and the third records movements that never touched the order book.</p>
<p>For activity, use the transaction history. For charges, check the fee summary against the detail. For anything leaving without your knowledge, use the withdrawal log — the shortest and most important section.</p>
<h3>Why the statement will not match your screen</h3>
<p>Your portfolio view marks holdings to current prices. The statement records historical events at their historical prices. Between the two sits every price change since the event, which the statement has no reason to know about.</p>
<p>Recent activity commonly lags by a day or more, and pending withdrawals can appear in one section before another. Neither is an error; both make same-day comparison misleading.</p>
<h2>The numbers people misread on an exchange statement</h2>
<p>Three line items cause most of the arguments, and each has a specific reading error behind it.</p>
<h3>Realised versus unrealised</h3>
<p>Realised amounts come from closed positions and are fixed at the moment of the closing trade. Unrealised amounts move with price and are an estimate at the timestamp on the report. A statement that shows a large unrealised figure is describing a moment, not a result.</p>
<p>A statement run at a different hour of the same day can show a materially different total with no trade in between. Note the generation time when comparing periods.</p>
<h3>Fees quoted in the asset, not the currency</h3>
<p>Many venues charge a fee in the asset you receive. Buy a small amount of a token and the fee arrives as a slightly smaller amount of that token, not as a separate currency charge. On the statement it may appear as a reduced quantity rather than an explicit cost.</p>
<p>This is the most common source of &#8220;where did my fee go&#8221; questions. The cost is real, just denominated in what you bought; its currency value at the time of the trade is the figure you need.</p>
<h3>Transfers in versus trades</h3>
<p>An asset arriving from an external wallet is not a purchase. It has no price on the statement, because the venue never saw the price you paid. Treating an inbound transfer as a buy at the day&#8217;s market price will overstate or understate your position by however far your original entry price sits from today.</p>
<h2>Reconciling an exchange statement</h2>
<p>Reconciliation means proving the closing balance from the opening balance and the events in between. Worked through on a small illustrative account, the method is straightforward.</p>
<p>Start with 10,000 USDC and no other holdings. During the period you buy 2 units at 2,500 each with a 5 USDC fee, sell 1 unit at 3,000 with a 3 USDC fee, and withdraw 500 USDC. Every figure is illustrative.</p>
<ol>
<li>Opening balance: 10,000.00 USDC, 0 units.</li>
<li>Buy: −5,000.00 for the two units, −5.00 fee. Cash is now 4,995.00, holdings are 2 units.</li>
<li>Sell: +3,000.00 for one unit, −3.00 fee. Cash is now 7,992.00, holdings are 1 unit.</li>
<li>Withdraw: −500.00. Cash closes at 7,492.00.</li>
<li>Closing balance should be 1 unit and 7,492.00 USDC. If the statement says otherwise, find the discrepancy before drawing any conclusion from the period.</li>
<li>Total fees for the period are 5.00 + 3.00 = 8.00, or about 16 basis points on the 5,000.00 of buying and 3,000.00 of selling combined.</li>
<li>Repeat the check against the venue&#8217;s own closing balance field; a mismatch there usually means a pending item or a timezone boundary, not a missing trade.</li>
</ol>
<blockquote><p>A statement you cannot reconcile is not evidence of a problem, but it is a reason to stop reading the summary and start reading the detail.</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>Line item</th>
<th>What it records</th>
<th>What people assume it records</th>
</tr>
</thead>
<tbody>
<tr>
<td>Trade history</td>
<td>Fills with price, size and time</td>
<td>Their profit on the position</td>
</tr>
<tr>
<td>Fee summary</td>
<td>Charges, sometimes in mixed units</td>
<td>A single currency total</td>
</tr>
<tr>
<td>Deposit log</td>
<td>Assets arriving from outside</td>
<td>A purchase at market price</td>
</tr>
<tr>
<td>Withdrawal log</td>
<td>Assets leaving, with destination</td>
<td>Only the amounts they remember sending</td>
</tr>
<tr>
<td>Closing balance</td>
<td>Holdings at the cut-off timestamp</td>
<td>Value at today&#8217;s prices</td>
</tr>
</tbody>
</table></div>
<h2>Using an exchange statement beyond bookkeeping</h2>
<p>The statement is also the input to any tax or audit process, and that is where its limits bite hardest. Cost basis methods differ — some jurisdictions use first-in-first-out, others allow average cost, and the treatment of transfers between your own accounts varies.</p>
<p>A venue only sees its own side, so one statement cannot describe assets held elsewhere. Consolidating across accounts is your job, and it is easier monthly than annually.</p>
<h3>What to keep and for how long</h3>
<p>Keep the full transaction-level export, not the PDF summary. Summaries drop the identifiers you need to match trades across accounts, and retention periods differ by jurisdiction. Check local rules for how long records must be kept; the safe habit is to keep everything and archive it offline.</p>
<p>Name exports with their generation date and keep a copy that does not depend on continued access to the venue. If an account is closed or restricted, the export is all you will have.</p>
<p>The post <a href="https://www.ladyww.net/exchange-statement/">Reading Your Exchange Statement</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/exchange-statement/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
