<?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>Jurisdiction Archives - LadyChain</title>
	<atom:link href="https://www.ladyww.net/tag/jurisdiction/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.ladyww.net/tag/jurisdiction/</link>
	<description>Crypto fees, wallets and offers — checked against the terms page</description>
	<lastBuildDate>Tue, 27 Oct 2026 14:02:30 +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>Jurisdiction Archives - LadyChain</title>
	<link>https://www.ladyww.net/tag/jurisdiction/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<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>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>
		<item>
		<title>Self-Custody and the Rules Around It</title>
		<link>https://www.ladyww.net/self-custody-rules/</link>
					<comments>https://www.ladyww.net/self-custody-rules/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 08:02:32 +0000</pubDate>
				<category><![CDATA[Regulation]]></category>
		<category><![CDATA[Backups]]></category>
		<category><![CDATA[Compliance]]></category>
		<category><![CDATA[Counterparty Risk]]></category>
		<category><![CDATA[Jurisdiction]]></category>
		<category><![CDATA[Key Management]]></category>
		<category><![CDATA[Record Keeping]]></category>
		<category><![CDATA[Self Custody]]></category>
		<category><![CDATA[Source Of Funds]]></category>
		<category><![CDATA[Wallets]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/self-custody-rules/</guid>

					<description><![CDATA[<p>Self custody regulation is the body of rules that applies when you hold keys yourself, and it mostly does not regulate the act of holding. It regulates the businesses around [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/self-custody-rules/">Self-Custody and the Rules Around It</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Self custody regulation is the body of rules that applies when you hold keys yourself, and it mostly does not regulate the act of holding. It regulates the businesses around you: the venues that convert between fiat and crypto, the custodians that hold on your behalf, and the intermediaries that transmit value across borders. The individual holding a hardware wallet is usually at the edge of these rules rather than at their centre.</p>
<p>That framing matters because most self custody regulation debates conflate two different questions. One is whether an intermediary must identify and monitor its customers; the other is whether a private holder owes anything when moving their own assets. The first is heavily regulated in many jurisdictions. The second varies enormously, and often depends on where you are resident rather than where the wallet is.</p>
<ul>
<li><strong>Rules usually attach to intermediaries, not to keys.</strong> The reporting burden sits mostly on businesses that move or hold assets for others.</li>
<li><strong>Your obligations follow your residence and citizenship.</strong> Wallet location is not the test most systems apply.</li>
<li><strong>Self-custody shifts operational risk to you.</strong> With no custodian, there is no recovery process and no support desk.</li>
<li><strong>Documentation is a control, not paperwork.</strong> Records of where funds came from and went are the main defence in any review.</li>
</ul>
<h2>What self custody regulation actually targets</h2>
<p>Most frameworks aim at the points where crypto touches the regulated financial system, because those are the points where an identifiable business can be made responsible for a rule.</p>
<h3>Intermediaries rather than keys</h3>
<p>A venue that lets you buy, sell or transfer assets generally has to identify customers, keep records, and report certain activity. Custodians holding assets for clients take on additional duties around segregation and safekeeping. A person holding their own keys is not performing those functions for anyone else, which is why the rules are usually written around service providers — and why the practical friction shows up at the boundary rather than inside the wallet.</p>
<h3>Obligations that follow the person</h3>
<p>Separately from intermediary rules, tax and reporting duties attach to individuals. Holding assets in self-custody does not suspend those duties, and in several jurisdictions the obligation to report disposals is unaffected by where the assets sat. The mechanism differs by country: some rely on self-declaration, some require specific disclosures, some ask for details of foreign or self-held accounts in particular circumstances. Rules differ by jurisdiction and change, so the only reliable answer is the one for where you are resident.</p>
<h2>Where self custody regulation reaches an individual holder</h2>
<p>For a private holder, the rules mostly appear at three moments: entering the regulated system, leaving it, and explaining the gap between the two.</p>
<h3>On-ramps and off-ramps</h3>
<p>Buying with fiat and selling for fiat are the points where identity checks and source-of-funds questions normally appear. A transfer from a self-custody wallet into a venue may prompt questions about where the assets came from, particularly for large or unusual amounts. These questions are routine in most jurisdictions and are easier to answer with records than with explanations.</p>
<h3>Reporting and record-keeping</h3>
<p>Disposals, income events and sometimes holdings themselves can carry reporting duties, depending on the jurisdiction. The common thread is that the duty is on you, and it does not disappear because the transaction happened wallet-to-wallet. Keeping a dated record of acquisitions, transfers and disposals is the cheapest way to satisfy it later.</p>
<h3>Sanctions and source-of-funds checks</h3>
<p>Venues screen deposits against sanctions lists and may freeze or query funds that arrive from flagged addresses. That screening is a property of the intermediary, not of your wallet, but it means an address&#8217;s history can follow the funds. Using a wallet whose history you cannot explain is a practical risk regardless of what the rules say.</p>
<h2>Custodial and self-custodial compared</h2>
<p>The trade is not &#8220;regulated versus unregulated&#8221;. It is a different allocation of responsibility, and each side has failure modes the other does not.</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>Dimension</th>
<th>Custodial</th>
<th>Self-custodial</th>
</tr>
</thead>
<tbody>
<tr>
<td>Who can move funds</td>
<td>The provider, with your instruction</td>
<td>Whoever holds the keys</td>
</tr>
<tr>
<td>Reporting support</td>
<td>Statements and returns provided</td>
<td>You produce everything</td>
</tr>
<tr>
<td>Recovery after loss</td>
<td>Provider process, subject to terms</td>
<td>Your backup, or nothing</td>
</tr>
<tr>
<td>Counterparty risk</td>
<td>Provider solvency and controls</td>
<td>None from a provider</td>
</tr>
<tr>
<td>Identity checks</td>
<td>At onboarding</td>
<td>At on-ramps and off-ramps</td>
</tr>
<tr>
<td>Access friction</td>
<td>Low, but mediated</td>
<td>High, and entirely yours</td>
</tr>
</tbody>
</table></div>
<p>Neither column is uniformly better. Custodial accounts are simpler for reporting and worse for counterparty exposure. Self-custody removes the counterparty and replaces it with key management, which is a skill rather than a service.</p>
<blockquote><p>Self custody regulation is mostly about what happens at the edges of the system. The middle — the wallet itself — is governed less by rules than by the fact that a mistake there has no appeal process.</p></blockquote>
<h2>A defensive routine for self-custody</h2>
<p>The controls that matter are ordinary and boring. None of them require trusting a third party, and all of them reduce the chance that a technical failure becomes a permanent loss or an unexplained transaction.</p>
<ol>
<li>Write down what each wallet is for, so a balance can be interpreted later without guessing.</li>
<li>Keep at least two independent backups of recovery material, stored in separate physical locations.</li>
<li>Verify a backup by restoring it on a spare device before relying on it, not after.</li>
<li>Test every address with a small transfer before sending a meaningful amount.</li>
<li>Record each transfer with date, asset, amount, counterparty and purpose in a file you control.</li>
<li>Keep the records of where funds originated — exchange statements, purchase receipts — alongside the wallet records.</li>
<li>Review access: who else knows the backups exist, and whether that list is still correct.</li>
</ol>
<p>Steps two and three are the ones people skip, and they are the reason self-custody failures are usually permanent. A backup that has never been restored is a hypothesis, not a backup.</p>
<h2>Common misconceptions about self custody regulation</h2>
<p><strong>&#8220;Self-custody is unregulated.&#8221;</strong> Holding keys is largely outside intermediary rules, but the surrounding activity — buying, selling, reporting — is not. The obligations follow the person, not the wallet.</p>
<p><strong>&#8220;Rules only apply above some size.&#8221;</strong> Thresholds exist in many regimes, but they govern specific reporting duties rather than the underlying tax treatment, which generally applies regardless of size.</p>
<p><strong>&#8220;A privacy wallet removes the obligation.&#8221;</strong> It may reduce visibility, but it does not change what is owed, and unexplained gaps are exactly what a review looks for.</p>
<p><strong>&#8220;Custody terms are the same everywhere.&#8221;</strong> Account terms, segregation practices and recovery processes vary widely between providers, and reading them before depositing is a five-minute exercise with a long tail.</p>
<p>The post <a href="https://www.ladyww.net/self-custody-rules/">Self-Custody and the Rules Around It</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/self-custody-rules/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
