<?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>Retail Guides Archives - LadyChain</title>
	<atom:link href="https://www.ladyww.net/tag/retail-guides/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.ladyww.net/tag/retail-guides/</link>
	<description>Crypto fees, wallets and offers — checked against the terms page</description>
	<lastBuildDate>Tue, 27 Oct 2026 12:57:55 +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>Retail Guides Archives - LadyChain</title>
	<link>https://www.ladyww.net/tag/retail-guides/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Moving Crypto Between Your Own Wallets</title>
		<link>https://www.ladyww.net/moving-between-wallets/</link>
					<comments>https://www.ladyww.net/moving-between-wallets/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 00:57:54 +0000</pubDate>
				<category><![CDATA[Guides]]></category>
		<category><![CDATA[Address Book]]></category>
		<category><![CDATA[Address Poisoning]]></category>
		<category><![CDATA[Gas Fees]]></category>
		<category><![CDATA[Network Fees]]></category>
		<category><![CDATA[On-Chain Transfers]]></category>
		<category><![CDATA[Retail Guides]]></category>
		<category><![CDATA[Self Custody]]></category>
		<category><![CDATA[Test Transactions]]></category>
		<category><![CDATA[Wallet Addresses]]></category>
		<category><![CDATA[Wallet Transfers]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/moving-between-wallets/</guid>

					<description><![CDATA[<p>To transfer crypto between wallets you control, three things have to agree: the address, the network, and the fee balance on the receiving side. Two out of three produces a [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/moving-between-wallets/">Moving Crypto Between Your Own Wallets</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p><img class="slv-lead-img" src="https://img1.ladyww.cn/picture/Picture00042.jpg" alt="Moving Crypto Between Your Own Wallets" loading="lazy" decoding="async" />To transfer crypto between wallets you control, three things have to agree: the address, the network, and the fee balance on the receiving side. Two out of three produces a transfer that arrives and then cannot move.</p>
<p>When people transfer crypto between wallets for the first time, the loss is rarely a hack. It is a copy, a paste and a network selector performed quickly on a screen that looked correct, followed by a confirmation that felt routine.</p>
<ul>
<li>A copied address can be valid on a different network than the one you selected.</li>
<li>Always send a small test amount first and confirm it lands before moving the balance.</li>
<li>The receiving wallet needs a little of the native token before it can move tokens out.</li>
<li>Address-poisoning lookalikes appear in transaction history. Copy from a saved address book instead.</li>
</ul>
<h2>Four Checks Before You Transfer Crypto Between Wallets</h2>
<p>The failures cluster in the same four places, and each one is checkable in under a minute. None of the checks requires technical knowledge; they require doing them in order rather than in a hurry.</p>
<h3>Check the network before the address</h3>
<p>The network decides which chain the transfer travels on, and the address is only meaningful inside that chain. Two networks can accept strings that look nearly identical while the funds land in places that cannot see each other at all.</p>
<p>Many venues default to the network you used last, not the one you intend now. Read the selector every time, and treat any pre-filled choice as a suggestion rather than a decision you made.</p>
<h3>Check the fee balance on the receiving side</h3>
<p>A wallet can receive a token with zero native balance and still be unable to do anything with it. The token is there, visible, and completely immobile until some of the native currency arrives to pay for the next transaction.</p>
<p>If the destination is a fresh wallet, fund it with a small amount of the native token first. That single step is the difference between a transfer that completes and one that requires a second transfer to rescue the first.</p>
<h2>The Same Address Exists on Several Networks</h2>
<p><a href="https://www.ladyww.net/crypto-address-formats/">Address format</a>s are not unique to a chain, and some wallets reuse the same string across several of them. A string that is valid on one network may be syntactically valid on another while pointing somewhere you do not control.</p>
<p>This is why the network and the address have to be verified together. When you transfer crypto between wallets, checking one without the other is checking half of a pair, and half a pair is exactly the state in which most losses happen.</p>
<h3>Why a copied address can be for the wrong chain</h3>
<p>Copy buttons often copy only the characters, not the chain context. The clipboard has no field that says which network the string belongs to, so pasting it into a wallet on another network produces no error at the point of pasting.</p>
<p>Some wallets derive the same address across compatible networks, and some do not. Where they do, the same string appears in both, which makes a wrong-network send look correct right up until the balance fails to appear.</p>
<h3>Memos, tags and destination fields</h3>
<p>Some transfers require an extra identifier beyond the address, usually called a memo, tag or destination field. That identifier routes the deposit to your account inside a shared address rather than to the address as a whole.</p>
<p>Leaving it blank can produce a deposit that arrives at the venue and cannot be attributed to you. Recovery, where it exists, is a support process with its own timeline, not an instant fix.</p>
<h2>Lookalikes Live in Your Transaction History</h2>
<p>Address poisoning puts a lookalike address into your history so that you copy it later. The attacker sends a tiny transfer from an address with the same first and last characters, and waits for you to reuse it from habit.</p>
<p>Your history is where you are most likely to copy from, because the address looks like the one you used before. That is the entire mechanism: it does not need to break anything, only to be the nearest thing to hand.</p>
<h3>Copy from the address book, not the list</h3>
<p>A saved address book entry is one you verified once, deliberately, and can name. A history entry is a string produced by whoever sent you something, which includes people you have never met.</p>
<p>Check the middle characters, not the ends. Poisoning exploits the habit of matching the first four and last four, so the middle is where a lookalike has to differ and therefore where a check actually catches something.</p>
<h3>Some wallets change address every transaction</h3>
<p>Several wallets derive a fresh receiving address for each transaction while all previous addresses keep working. Old addresses remain valid forever, so the fact that an address is no longer displayed does not mean it is dead.</p>
<p>Do not treat a changed address as a warning sign, and do not treat an old address as broken. Verify that the address belongs to your wallet by checking it inside the wallet itself rather than by its position in a list.</p>
<h2>A Small Test Transfer, With Arithmetic</h2>
<p>Testing costs a fee, and the fee is small relative to the loss it prevents. Here is the arithmetic on a move of 0.80 of a native token, at a network fee of 0.00042 per transaction.</p>
<ol>
<li>Send a test of 0.01 first. Fee: 0.00042. Balance after: 0.80 − 0.01 − 0.00042 = 0.78958.</li>
<li>Confirm the test arrived in the destination wallet, not merely that the transaction confirmed.</li>
<li>Send the remainder of 0.78958 minus the second fee: 0.78958 − 0.00042 = 0.78916 reaching the destination.</li>
<li>Total fees paid: 0.00084, which is roughly 0.105% of the 0.80 moved. The test cost half of that.</li>
<li>For a token transfer instead, budget for the token fee plus the native fee, and check the destination holds enough native balance for its next move: three token transfers at 0.0008 each need 0.0024 of the native token sitting there first.</li>
</ol>
<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>What you are moving</th>
<th>What the destination needs</th>
<th>Common failure</th>
</tr>
</thead>
<tbody>
<tr>
<td>Native token</td>
<td>Nothing beyond the address</td>
<td>Wrong network selected at send time</td>
</tr>
<tr>
<td>Token on the same chain</td>
<td>A little native balance for future fees</td>
<td>Tokens arrive, then cannot move</td>
</tr>
<tr>
<td>Token to a fresh wallet</td>
<td>Native funding before anything else</td>
<td>Second transfer needed to rescue the first</td>
</tr>
<tr>
<td>Deposit to a venue</td>
<td>Network plus memo or tag</td>
<td>Deposit lands, unattributed to you</td>
</tr>
<tr>
<td>Any transfer from history</td>
<td>A verified address, not a recent one</td>
<td>Lookalike copied from the list</td>
</tr>
</tbody>
</table></div>
<blockquote><p>The cheapest transfer is the one you tested. The most expensive is the one you sent once, confidently, to an address you never checked.</p></blockquote>
<p>The post <a href="https://www.ladyww.net/moving-between-wallets/">Moving Crypto Between Your Own Wallets</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/moving-between-wallets/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Choosing a Stablecoin: Issuer, Rails and Redemption</title>
		<link>https://www.ladyww.net/choosing-a-stablecoin/</link>
					<comments>https://www.ladyww.net/choosing-a-stablecoin/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Mon, 26 Oct 2026 22:57:54 +0000</pubDate>
				<category><![CDATA[Guides]]></category>
		<category><![CDATA[Blockchain Rails]]></category>
		<category><![CDATA[Bridged Assets]]></category>
		<category><![CDATA[Collateral Pools]]></category>
		<category><![CDATA[Exchange Risk]]></category>
		<category><![CDATA[Issuers]]></category>
		<category><![CDATA[Liquidity]]></category>
		<category><![CDATA[Payment Rails]]></category>
		<category><![CDATA[Redemption]]></category>
		<category><![CDATA[Retail Guides]]></category>
		<category><![CDATA[Stablecoins]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/choosing-a-stablecoin/</guid>

					<description><![CDATA[<p>Asking which stablecoin to hold is really three questions wearing one coat: who owes you the money, how you get it back, and where you can spend it. Answer those [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/choosing-a-stablecoin/">Choosing a Stablecoin: Issuer, Rails and Redemption</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p><img class="slv-lead-img" src="https://img1.ladyww.cn/picture/Picture00341.jpg" alt="Choosing a Stablecoin: Issuer, Rails and Redemption" loading="lazy" decoding="async" />Asking which stablecoin to hold is really three questions wearing one coat: who owes you the money, how you get it back, and where you can spend it. Answer those three and the choice usually makes itself without a price chart.</p>
<p>Most comparisons of which stablecoin is best rank names by size and call it safety. Size measures adoption, not the terms of the claim, and the terms are what decide whether you can exit at par on the day you need to.</p>
<ul>
<li>Every stablecoin is a claim, either on an issuer or on a pool of collateral.</li>
<li>Redemption has a route, a minimum and a timeline. Check all three before you need them.</li>
<li>Holding on an exchange adds the exchange&#8217;s risk to the issuer&#8217;s risk.</li>
<li>A discount on one venue is a local condition, not a verdict on the asset.</li>
</ul>
<h2>A Stablecoin Is a Claim, Not a Coin</h2>
<p>A stablecoin is a promise denominated in a unit, recorded somewhere you can inspect. The promise is only as good as the party or pool behind it, and the terms of the promise live in documentation most holders never read.</p>
<p>For an issuer-backed design, you hold a claim on that issuer, redeemable under conditions it sets. For a collateralised design, you hold a claim on a pool, where the value available to you depends on the collateral&#8217;s behaviour in stressed conditions rather than on a company&#8217;s balance sheet.</p>
<p>Neither structure is automatically safer. They fail differently, and the failure modes are the thing to compare: an issuer can freeze, delay or change terms, while a pool can be under-collateralised exactly when liquidations are hardest to execute.</p>
<h2>Which Stablecoin You Pick Depends on the Job</h2>
<p>The right answer changes with the task. If you need a unit of account to price things in, you need stability over hours. If you need an exit, you need a redemption route that works at your size.</p>
<h3>Unit of account or redemption</h3>
<p>As a unit of account, the requirement is that the asset trades close to its target across the venues you use, most of the time. As a redemption instrument, the requirement is a documented route back to the underlying at a stated minimum, with a timeline you can plan around.</p>
<p>These are different tests, and passing one says little about the other. A design can hold its peg in normal conditions on secondary markets while offering no realistic redemption path for a holder of modest size.</p>
<h3>Spend-ability by chain and merchant</h3>
<p>Spend-ability is a property of a chain and a payment processor, not of the asset&#8217;s name. The same stablecoin can be widely accepted on one network, awkward on a second and effectively unusable on a third without a bridge.</p>
<p>Merchant support adds another layer. A processor may accept a token on one chain only, settle to the merchant in local currency, and charge a conversion spread that never appears as a line item on your side of the transaction.</p>
<h2>Rails Decide Where the Claim Can Travel</h2>
<p>Rails are the routes by which a claim moves: native issuance on a chain, a bridge, or a venue&#8217;s internal <a href="https://www.ladyww.net/deals/ledger-offer/">ledger</a>. Each route has its own failure mode, and the route is often more consequential than the issuer&#8217;s reputation.</p>
<p>A native issuance is created and redeemed by the issuer on that chain. A bridged version is a claim on a bridge&#8217;s custody of the original, which means you hold the bridge&#8217;s risk in addition to the issuer&#8217;s, whether or not the interface mentions it.</p>
<h3>Native issuance versus bridged copies</h3>
<p>Two tokens with the same ticker on two chains are frequently not the same instrument. One may be issued natively by the issuer; the other may be a receipt for tokens locked in a bridge contract, redeemable only if that contract continues to behave.</p>
<p>Check which one you are buying before you buy it, and check again before you bridge. The ticker is a label chosen by whoever deployed the contract, not a certification of anything.</p>
<h3>Withdrawal networks are part of the choice</h3>
<p>A venue&#8217;s withdrawal list tells you which routes it supports and what each costs. A chain that is cheap to use but unsupported by your destination is not cheap in practice, because the workaround is another conversion and another fee.</p>
<p>Keep a note of which network you use for each destination, and treat a newly added network as unverified until you have moved a small amount across it.</p>
<h2>Redemption, Discounts and the Price You See</h2>
<p>Redemption terms are the least-read and most important part of the product. An issuer typically publishes a minimum redemption size, a process, a fee and a settlement window, and those four numbers decide whether the claim is real for you.</p>
<p>For a retail holder, a minimum far above your balance means the direct route does not exist. Your exit is then the secondary market, at whatever price it offers on the day, minus the venue&#8217;s fee and the spread.</p>
<p>Waiting matters more than it looks. A settlement window measured in days is a period during which you carry the issuer&#8217;s risk without the ability to act, and that exposure is the price of using the direct route rather than the market one.</p>
<p>A stablecoin trading below its target on one venue is a local condition, usually driven by that venue&#8217;s liquidity or by a queue of sellers. It is not evidence that the asset has failed, and it is not evidence that it is fine either.</p>
<p>The useful question is whether the discount persists across venues and across days. A gap that closes is a liquidity event; a gap that widens while redemption slows is a signal about the claim itself, not about the market&#8217;s mood.</p>
<p>Holding on an exchange adds a second claim to the first. You are owed the stablecoin by the exchange, and the stablecoin is owed to the exchange by the issuer, and neither obligation is visible in your balance.</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>Design</th>
<th>What you hold</th>
<th>Redemption route</th>
<th>Main failure mode</th>
</tr>
</thead>
<tbody>
<tr>
<td>Issuer-backed, fiat</td>
<td>A claim on the issuer</td>
<td>Direct, with a stated minimum</td>
<td>Terms change, or redemption queues</td>
</tr>
<tr>
<td>Over-collateralised</td>
<td>A claim on a collateral pool</td>
<td>On-chain, against collateral</td>
<td>Collateral falls short in stress</td>
</tr>
<tr>
<td>Bridged copy</td>
<td>A claim on a bridge&#8217;s custody</td>
<td>Back across the same bridge</td>
<td>Bridge contract or custody fails</td>
</tr>
<tr>
<td>Exchange balance</td>
<td>A claim on the exchange</td>
<td>Withdrawal, when it is open</td>
<td>Exchange solvency or withdrawal limits</td>
</tr>
<tr>
<td>Yield-bearing wrapper</td>
<td>A claim on a strategy</td>
<td>Unwrap, then redeem</td>
<td>Strategy losses reach the principal</td>
</tr>
</tbody>
</table></div>
<blockquote><p>A peg is a price observed on a venue. Redemption is a right written in a document. The second one is what you actually own, and it is the one almost nobody reads.</p></blockquote>
<h2>A Worked Example: 12,400 Units, Two Exits</h2>
<p>Suppose you hold 12,400 units and the issuer&#8217;s minimum redemption is 100,000. The direct route is closed to you, so the comparison is between selling on a venue and converting into another stablecoin.</p>
<ol>
<li>Direct redemption is unavailable: 12,400 is 12.4% of the 100,000 minimum, so no amount of patience opens that route.</li>
<li>Sell on a venue at 0.35% below par: 12,400 × 0.9965 = 12,356.60 in proceeds, before the venue&#8217;s own trading fee.</li>
<li>Convert into a second stablecoin at 0.05% plus a fixed 4.20: 12,400 − 6.20 − 4.20 = 12,389.60 of the new asset.</li>
<li>Add network fees. At 0.90 per transaction, the sale nets 12,355.70 and the conversion nets 12,388.70.</li>
<li>The conversion keeps 33.00 more units, but it leaves you holding a claim on a different issuer with its own terms and its own redemption minimum.</li>
<li>If your balance were 100,000 instead, direct redemption at a 0.10% fee would return 99,900, which is better than either market route and takes longer to settle.</li>
</ol>
<p>The post <a href="https://www.ladyww.net/choosing-a-stablecoin/">Choosing a Stablecoin: Issuer, Rails and Redemption</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/choosing-a-stablecoin/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Recording Crypto Trades: A System That Survives Tax Season</title>
		<link>https://www.ladyww.net/crypto-record-keeping/</link>
					<comments>https://www.ladyww.net/crypto-record-keeping/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Mon, 26 Oct 2026 20:57:55 +0000</pubDate>
				<category><![CDATA[Guides]]></category>
		<category><![CDATA[Bookkeeping]]></category>
		<category><![CDATA[Cost Basis]]></category>
		<category><![CDATA[Crypto Tax Records]]></category>
		<category><![CDATA[Exchange Exports]]></category>
		<category><![CDATA[Fee Tracking]]></category>
		<category><![CDATA[On-Chain Data]]></category>
		<category><![CDATA[Portfolio Tracking]]></category>
		<category><![CDATA[Record Keeping]]></category>
		<category><![CDATA[Retail Guides]]></category>
		<category><![CDATA[Tax Season]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/crypto-record-keeping/</guid>

					<description><![CDATA[<p>Good crypto tax records are not a folder of exports. They are a running ledger you keep during the year, with a raw archive behind it, so the two can [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/crypto-record-keeping/">Recording Crypto Trades: A System That Survives Tax Season</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p><img class="slv-lead-img" src="https://img1.ladyww.cn/picture/Picture00144.jpg" alt="Recording Crypto Trades: A System That Survives Tax Season" loading="lazy" decoding="async" />Good crypto tax records are not a folder of exports. They are a running <a href="https://www.ladyww.net/deals/ledger-offer/">ledger</a> you keep during the year, with a raw archive behind it, so the two can be reconciled in an afternoon rather than a fortnight.</p>
<p>Crypto tax records usually fail because of timing, not carelessness. Exchanges let you download history for a limited window, chains keep everything forever, and the person reconstructing the year is doing it months later, from memory, under a deadline.</p>
<ul>
<li>Every trade, transfer, reward and fee is a potential line item, including the ones that cost almost nothing.</li>
<li>An exchange export is the starting point and always misses on-chain activity.</li>
<li>Cost basis methods differ by jurisdiction, and switching between them is not free.</li>
<li>Keep the raw files, the running sheet and a timestamped note of why each movement happened.</li>
</ul>
<h2>Every Movement Is a Potential Line Item</h2>
<p>The unit of record-keeping is the movement, not the trade. Anything that changes what you hold, where you hold it, or what you paid to hold it belongs in the ledger, whether or not it produced a gain you noticed.</p>
<p>That includes rewards that arrived without a purchase, fees paid to move assets between your own accounts, and conversions between two assets that both look like cash. In many jurisdictions a swap between two <a href="https://www.ladyww.net/choosing-a-stablecoin/">stablecoin</a>s is a disposal of one and an acquisition of the other, which makes it a reportable event even though the value barely moved.</p>
<p>The reason to capture small items is not that each one matters. It is that the sum of them is invisible later, and reconstructing a hundred small items from memory is the part that turns a weekend into a month.</p>
<h2>Why Exchange Exports Are Not Crypto Tax Records</h2>
<p>An export describes what happened on one venue. It cannot describe what happened anywhere else, and it cannot see the transfers between your own wallets that connect one venue&#8217;s history to another&#8217;s.</p>
<p>This is the gap that breaks most reconstructions. The export shows a withdrawal of a token and the next export shows a deposit of the same token, but nothing in either file establishes that the two are the same asset moving between accounts you control.</p>
<h3>What the export leaves out</h3>
<p>On-chain transactions, gas and network fees, rewards received directly to a wallet, airdrops, and anything executed through a wallet rather than through the venue. It also typically omits the internal transfer that funded the wallet in the first place.</p>
<p>Fees deserve particular attention because they are easy to ignore and they accumulate. Thirty-eight transactions at 6.40 each is 243.20 of cost that never appears as a line in a venue export, and in many jurisdictions those costs affect the number you eventually report.</p>
<h3>Transfers between your own wallets</h3>
<p>Moving an asset between two wallets you control is not a disposal in most frameworks, but it is not nothing either. It changes custody, it usually costs a fee, and it breaks the continuity of a balance history that a reviewer will want to follow.</p>
<p>Record it as an internal transfer with both sides identified, the fee separated, and the reason noted. Without that link, a later reconstruction has to guess whether a withdrawal and a deposit are the same event or two different ones.</p>
<h2>Cost Basis Methods Are Not Interchangeable</h2>
<p>Different jurisdictions allow different methods for deciding which acquisition a disposal came from, and the method changes the number. First in, first out, average cost and specific identification can produce materially different results from an identical set of trades.</p>
<h3>A worked comparison</h3>
<p>Buy 2.0 units at 1,800 each, then 2.0 units at 2,400 each, then sell 1.5 units at 2,600. Under first in, first out, the sold units come from the earliest lot: proceeds of 3,900 against a cost of 2,700, leaving 1,200.</p>
<p>Under average cost, the pool sits at 2,100 per unit, so the same sale carries a cost of 3,150 and leaves 750. The trades did not change; the method moved the figure by 450, which is the entire reason the choice has to be made deliberately and recorded.</p>
<h3>Switching between methods is not free</h3>
<p>Changing method mid-history usually requires recomputing every prior disposal under the new rule, and some jurisdictions restrict when a change is allowed at all. A switch made casually in year three can mean restating years one and two.</p>
<p>Pick a method with local advice, write down the choice and the date, and apply it consistently. Consistency is the part that survives scrutiny; the specific choice matters less than being able to explain it.</p>
<h2>The Running Sheet: Columns and the Why</h2>
<p>A running sheet is one table, updated monthly, that holds every movement in the order it happened. It is not a tax return and it is not a substitute for advice. It is the working document that makes the return possible without archaeology.</p>
<h3>Columns that earn their place</h3>
<p>Date and time in UTC, platform or wallet, asset, amount, direction, the other side of the movement, the fee in its own currency, the reference to a transaction hash or trade ID, and the source file the row came from. Ten columns is enough for most retail histories.</p>
<p>Two columns are usually missing and matter most: the fee as a separate number rather than folded into the amount, and the reference that lets you trace a row back to a raw file. Without the second, the sheet becomes an assertion rather than a record.</p>
<h3>The timestamped why</h3>
<p>Add one short line explaining each movement at the time it happens. Why the funds moved, which wallet it went to, what the transfer was for. Six months later the numbers are readable and the intent is not.</p>
<p>This is the cheapest part of the system and the part people skip. A note written in ten seconds in March replaces an hour of uncertainty in December, and it is the only part of the record that cannot be reconstructed from any export.</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>Where it comes from</th>
<th>What it misses</th>
<th>Keep it for</th>
</tr>
</thead>
<tbody>
<tr>
<td>Venue trade export</td>
<td>The exchange&#8217;s own reporting</td>
<td>On-chain activity and internal transfers</td>
<td>Reconciling trades against balances</td>
</tr>
<tr>
<td>On-chain history</td>
<td>A block explorer or wallet</td>
<td>Anything done on a venue&#8217;s ledger</td>
<td>Fees, rewards and wallet-to-wallet moves</td>
</tr>
<tr>
<td>Internal transfer note</td>
<td>You, at the time of the move</td>
<td>Nothing, if written properly</td>
<td>Linking a withdrawal to its deposit</td>
</tr>
<tr>
<td>Reward statement</td>
<td>Staking or reward source</td>
<td>The date the value was fixed</td>
<td>Establishing acquisition dates</td>
</tr>
<tr>
<td>Fee log</td>
<td>Wallets and explorers</td>
<td>Fees bundled into a venue spread</td>
<td>Supporting costs that reduce a figure</td>
</tr>
</tbody>
</table></div>
<blockquote><p>The export tells you what a venue saw. The sheet tells you what you did. Only the second one can be handed to somebody else and understood.</p></blockquote>
<h2>A Month of Ordinary Housekeeping</h2>
<p>Here is what the maintenance version looks like when it is done monthly rather than annually, on a history of moderate size.</p>
<ol>
<li>Download the month&#8217;s export from each venue and store it unedited, with the download date in the filename.</li>
<li>Pull the on-chain movements for the same month, then delete duplicates caused by a transaction being both sent and received.</li>
<li>Add each row to the sheet: 214 export rows plus 41 on-chain events plus 9 internal transfers gives 264 line items for the year.</li>
<li>Separate fees: 38 transactions at 6.40 each is 243.20, which otherwise sits inside the amounts and disappears.</li>
<li>Link each internal transfer to its counterpart, so the withdrawal and the deposit appear as one movement with two sides.</li>
<li>Reconcile closing balances per account against the sum of the rows. A gap of 12 units is a missing line item, not a rounding error.</li>
<li>Write the why for anything unusual while the reason is still fresh, and stop. The month took under an hour.</li>
</ol>
<p>The post <a href="https://www.ladyww.net/crypto-record-keeping/">Recording Crypto Trades: A System That Survives Tax Season</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/crypto-record-keeping/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
