Rename Castle Accounting extension to Libra

Full identifier rename: module path lnbits.extensions.castle →
lnbits.extensions.libra, DB ext_castle → ext_libra, URL prefix
/castle/ → /libra/, manifest id castle → libra, fava ledger slug
default castle-ledger → libra-ledger, Beancount source metadata
castle-api → libra-api and link prefixes castle-{entry,tx}- →
libra-{entry,tx}-, column castle_wallet_id → libra_wallet_id, all
Python/JS/HTML identifiers (castle_ext, CastleSettings,
castle_reference, castleWalletConfigured, etc.).

Display name "Castle Accounting" → "Libra" (the scales/balance
metaphor — fits double-entry bookkeeping).

No backward compat: production hosts will be force-updated. Old
castle-prefixed Beancount metadata in existing Fava ledgers is
historical; new entries use libra-* prefixes going forward.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/ACCOUNTING-ANALYSIS-NET-SETTLEMENT.html

@@ -195,13 +195,13 @@ id="toc-professional-assessment">Professional Assessment</a></li>
 <h1 id="accounting-analysis-net-settlement-entry-pattern">Accounting
 Analysis: Net Settlement Entry Pattern</h1>
 <p><strong>Date</strong>: 2025-01-12 <strong>Prepared By</strong>:
-Senior Accounting Review <strong>Subject</strong>: Castle Extension -
+Senior Accounting Review <strong>Subject</strong>: Libra Extension -
 Lightning Payment Settlement Entries <strong>Status</strong>: Technical
 Review</p>
 <hr />
 <h2 id="executive-summary">Executive Summary</h2>
 <p>This document provides a professional accounting assessment of
-Castle’s net settlement entry pattern used for recording Lightning
+Libra’s net settlement entry pattern used for recording Lightning
 Network payments that settle fiat-denominated receivables. The analysis
 identifies areas where the implementation deviates from traditional
 accounting best practices and provides specific recommendations for
@@ -214,7 +214,7 @@ hierarchy</p>
 <hr />
 <h2 id="background-the-technical-challenge">Background: The Technical
 Challenge</h2>
-<p>Castle operates as a Lightning Network-integrated accounting system
+<p>Libra operates as a Lightning Network-integrated accounting system
 for collectives (co-living spaces, makerspaces). It faces a unique
 accounting challenge:</p>
 <p><strong>Scenario</strong>: User creates a receivable in EUR (e.g.,
@@ -223,7 +223,7 @@ accounting challenge:</p>
 <p><strong>Challenge</strong>: Record the payment while: 1. Clearing the
 exact EUR receivable amount 2. Recording the exact satoshi amount
 received 3. Handling cases where users have both receivables (owe
-Castle) and payables (Castle owes them) 4. Maintaining Beancount
+Libra) and payables (Libra owes them) 4. Maintaining Beancount
 double-entry balance</p>
 <hr />
 <h2 id="current-implementation">Current Implementation</h2>
@@ -231,7 +231,7 @@ double-entry balance</p>
 <pre class="beancount"><code>; Step 1: Receivable Created
 2025-11-12 * &quot;room (200.00 EUR)&quot; #receivable-entry
   user-id: &quot;375ec158&quot;
-  source: &quot;castle-api&quot;
+  source: &quot;libra-api&quot;
   sats-amount: &quot;225033&quot;
   Assets:Receivable:User-375ec158     200.00 EUR
     sats-equivalent: &quot;225033&quot;
@@ -344,7 +344,7 @@ class="sourceCode sql"><code class="sourceCode sql"><span id="cb8-1"><a href="#c
   payment-hash: &quot;8d080ec4...&quot;
 Assets:Receivable:User-375ec158   -200.00 EUR
   ; No sats-equivalent needed here</code></pre>
-<p><strong>Option B - Use EUR positions with metadata</strong> (Castle’s
+<p><strong>Option B - Use EUR positions with metadata</strong> (Libra’s
 current approach):</p>
 <pre class="beancount"><code>Assets:Bitcoin:Lightning           200.00 EUR
   sats-received: &quot;225033&quot;
@@ -452,8 +452,8 @@ OR payable)</li>
 (receivable AND payable)</li>
 </ul>
 <p><strong>When Net Settlement is Appropriate</strong>:</p>
-<pre><code>User owes Castle:    555.00 EUR (receivable)
-Castle owes User:     38.00 EUR (payable)
+<pre><code>User owes Libra:    555.00 EUR (receivable)
+Libra owes User:     38.00 EUR (payable)
 Net amount due:      517.00 EUR (true settlement)</code></pre>
 <p>Proper three-posting entry:</p>
 <pre class="beancount"><code>Assets:Bitcoin:Lightning           565251 SATS @@ 517.00 EUR
@@ -461,8 +461,8 @@ Assets:Receivable:User            -555.00 EUR
 Liabilities:Payable:User            38.00 EUR
 ; Net: 517.00 = -555.00 + 38.00 ✓</code></pre>
 <p><strong>When Two Postings Suffice</strong>:</p>
-<pre><code>User owes Castle:    200.00 EUR (receivable)
-Castle owes User:      0.00 EUR (no payable)
+<pre><code>User owes Libra:    200.00 EUR (receivable)
+Libra owes User:      0.00 EUR (no payable)
 Amount due:          200.00 EUR (simple payment)</code></pre>
 <p>Simpler two-posting entry:</p>
 <pre class="beancount"><code>Assets:Bitcoin:Lightning           225033 SATS @@ 200.00 EUR
@@ -515,7 +515,7 @@ positions - ❌ Requires metadata parsing for SATS balances</p>
 id="approach-3-true-net-settlement-when-both-obligations-exist">Approach
 3: True Net Settlement (When Both Obligations Exist)</h3>
 <pre class="beancount"><code>2025-11-12 * &quot;Net settlement via Lightning&quot;
-  ; User owes 555 EUR, Castle owes 38 EUR, net: 517 EUR
+  ; User owes 555 EUR, Libra owes 38 EUR, net: 517 EUR
   Assets:Bitcoin:Lightning           517.00 EUR
     sats-received: &quot;565251&quot;
   Assets:Receivable:User-375ec158   -555.00 EUR
@@ -570,7 +570,7 @@ Method</h4>
 <p><strong>Decision Required</strong>: Select either position-based OR
 metadata-based satoshi tracking.</p>
 <p><strong>Option A - Keep Metadata Approach</strong> (recommended for
-Castle):</p>
+Libra):</p>
 <div class="sourceCode" id="cb25"><pre
 class="sourceCode python"><code class="sourceCode python"><span id="cb25-1"><a href="#cb25-1" aria-hidden="true" tabindex="-1"></a><span class="co"># In format_net_settlement_entry()</span></span>
 <span id="cb25-2"><a href="#cb25-2" aria-hidden="true" tabindex="-1"></a>postings <span class="op">=</span> [</span>
@@ -604,7 +604,7 @@ class="sourceCode python"><code class="sourceCode python"><span id="cb26-1"><a h
 <span id="cb26-12"><a href="#cb26-12" aria-hidden="true" tabindex="-1"></a>    }</span>
 <span id="cb26-13"><a href="#cb26-13" aria-hidden="true" tabindex="-1"></a>]</span></code></pre></div>
 <p><strong>Recommendation</strong>: Choose Option A (metadata) for
-consistency with Castle’s architecture.</p>
+consistency with Libra’s architecture.</p>
 <hr />
 <h4 id="rename-function-for-clarity">1.3 Rename Function for
 Clarity</h4>
@@ -713,7 +713,7 @@ class="sourceCode python"><code class="sourceCode python"><span id="cb28-1"><a h
 <span id="cb28-45"><a href="#cb28-45" aria-hidden="true" tabindex="-1"></a>            payment_hash<span class="op">=</span>payment_hash</span>
 <span id="cb28-46"><a href="#cb28-46" aria-hidden="true" tabindex="-1"></a>        )</span>
 <span id="cb28-47"><a href="#cb28-47" aria-hidden="true" tabindex="-1"></a>    <span class="cf">else</span>:</span>
-<span id="cb28-48"><a href="#cb28-48" aria-hidden="true" tabindex="-1"></a>        <span class="co"># PAYABLE PAYMENT: Castle paying user (different flow)</span></span>
+<span id="cb28-48"><a href="#cb28-48" aria-hidden="true" tabindex="-1"></a>        <span class="co"># PAYABLE PAYMENT: Libra paying user (different flow)</span></span>
 <span id="cb28-49"><a href="#cb28-49" aria-hidden="true" tabindex="-1"></a>        <span class="cf">return</span> <span class="cf">await</span> format_payable_payment_entry(...)</span></code></pre></div>
 <hr />
 <h3 id="priority-3-long-term-architectural-decisions">Priority 3:
@@ -742,7 +742,7 @@ architectures:</p>
 <p><strong>Recommendation</strong>: Architecture A (EUR primary)
 because: 1. Most receivables created in EUR 2. Financial reporting
 requirements typically in fiat 3. Tax obligations calculated in fiat 4.
-Aligns with current Castle metadata approach</p>
+Aligns with current Libra metadata approach</p>
 <hr />
 <h4 id="consider-separate-ledger-for-cryptocurrency-holdings">3.2
 Consider Separate Ledger for Cryptocurrency Holdings</h4>
@@ -754,7 +754,7 @@ from fiat accounting</p>
   Assets:Receivable:User-375ec158      -200.00 EUR</code></pre>
 <p><strong>Cryptocurrency Sub-Ledger</strong> (SATS-denominated):</p>
 <pre class="beancount"><code>2025-11-12 * &quot;Lightning payment received&quot;
-  Assets:Bitcoin:Lightning:Castle    225033 SATS
+  Assets:Bitcoin:Lightning:Libra    225033 SATS
   Assets:Bitcoin:Custody:User-375ec  225033 SATS</code></pre>
 <p><strong>Benefits</strong>: - ✅ Clean separation of concerns - ✅
 Cryptocurrency movements tracked independently - ✅ Fiat accounting
@@ -902,7 +902,7 @@ Entry balances</p>
 <p><strong>Is this “best practice” accounting?</strong>
 <strong>No</strong>, this implementation deviates from traditional
 accounting standards in several ways.</p>
-<p><strong>Is it acceptable for Castle’s use case?</strong> <strong>Yes,
+<p><strong>Is it acceptable for Libra’s use case?</strong> <strong>Yes,
 with modifications</strong>, it’s a reasonable pragmatic solution for a
 novel problem (cryptocurrency payments of fiat debts).</p>
 <p><strong>Critical improvements needed</strong>: 1. ✅ Remove
@@ -912,7 +912,7 @@ Separate payment vs. settlement logic (accuracy and clarity)</p>
 <p><strong>The fundamental challenge</strong>: Traditional accounting
 wasn’t designed for this scenario. There is no established “standard”
 for recording cryptocurrency payments of fiat-denominated receivables.
-Castle’s approach is functional, but should be refined to align better
+Libra’s approach is functional, but should be refined to align better
 with accounting principles where possible.</p>
 <h3 id="next-steps">Next Steps</h3>
 <ol type="1">
@@ -935,7 +935,7 @@ Characteristics of Accounting Information</li>
 <li><strong>ASC 105-10-05</strong>: Substance Over Form</li>
 <li><strong>Beancount Documentation</strong>:
 http://furius.ca/beancount/doc/index</li>
-<li><strong>Castle Extension</strong>:
+<li><strong>Libra Extension</strong>:
 <code>docs/SATS-EQUIVALENT-METADATA.md</code></li>
 <li><strong>BQL Analysis</strong>:
 <code>docs/BQL-BALANCE-QUERIES.md</code></li>
@@ -948,6 +948,6 @@ implemented</p>
 <p><em>This analysis was prepared for internal review and development
 planning. It represents a professional accounting assessment of the
 current implementation and should be used to guide improvements to
-Castle’s payment recording system.</em></p>
+Libra’s payment recording system.</em></p>
 </body>
 </html>