# nBTC Treasury operating guide

September 26, 2026 · Software release with persistent SQL storage

## First use

Open https://dclxvi.lc/nbtc/wallet and sign in using the existing owner account.
Only that verified owner can initialize the Treasury. Initialization creates
the 21 million-unit inventory and its signed genesis record; no customer receives
coins automatically. Open your own wallet by accepting the displayed terms.

Customers use the same wallet URL and their own ChatGPT sign-ins. Each chooses
a display name and accepts the 30-day rule. No external financial credentials
are collected by this application.

The Treasury controls panel lists purchase requests. For each request, quote
the total USD price, choose a payment method, and enter the actual private
instructions. The buyer accepts and then reports payment. Independently verify
the money arrived using the receiving institution's own records. Only then
confirm settlement and release the coins. Use a unique receipt reference.

The software cannot choose or verify the owner's receiving bank/account, price,
permitted payment method or legal operating status. Those are real business
inputs. A buyer report and a completed invoice are not proof of cleared funds.
Do not enter an unapproved PayPal method or ask customers to mislabel a purchase
as a Friends and Family transfer.

Grants are explicit owner allocations without a purchase payment. Their amounts,
wallet destinations and reasons are public. Do not issue a grant to conceal an
unverified sale. There are no fees on grants or internal transfers.

Grant entry now has two steps: Review grant checks the receiving wallet, then
Confirm & issue authorizes that exact allocation. Completion replaces the form
with its amount, recipient and signed receipt number beside the controls.
Prepare another grant deliberately opens a blank form for a new allocation.
The ten most recent grants remain visible below it.

The browser saves each grant's request ID and exact details in session storage
before sending. Reloading the same tab restores a completed receipt or checks
the outcome of a pending request. A lost response can be retried using the same
ID without issuing another grant. Do not clear site data or begin a new grant
in another tab to resolve an uncertain result; check the existing receipt and
recent-grants list. A deliberate new grant has its own ID, even if its amount
and recipient match an earlier allocation.

The owner dashboard separates the owner's personal wallet from Treasury
inventory. A grant reduces inventory and increases a recipient's wallet. A
payment back to the owner's wallet moves those circulating units between
wallets; it does not restore inventory or increase total supply. The owner's
personal wallet has the same 30-day rule as other holders. Returning funds
voluntarily to inventory is not implemented by an ordinary wallet payment.

## State and concurrency

The new tables are isolated under the nbtc_ prefix. They do not share customer
access with the private LSM research tables or assets.

Each mutation is one database batch transaction: append a signed journal event,
add balanced accounting postings, change lots/orders, and advance the global
head. A SQL constraint guard rejects a stale head; the application retries from
fresh data. A unique request identity prevents duplicate effects after a lost
response. A failed batch rolls back all its changes. Supply conservation and
balanced postings are also checked by SQL constraints inside each batch.
The application only appends journal entries; a person with direct database
administration access can still alter storage. Retained signed checkpoints
are needed to reveal that kind of tampering.

Amounts are whole talents: 1 talent = 0.00000000001 nBTC (eleven decimal places).
One nBTC contains 100,000,000,000 talents. Monetary arithmetic uses BigInt and
SQLite signed 64-bit integers; JSON carries talent counts as decimal strings.
The legacy `atoms` field names now count talents. Receipt schema 2 and backup
schema 5 declare this precision. Earlier signed receipts remain byte-for-byte
unchanged at eight decimal places; one historical atom equals 1,000 talents.
The database upgrades all amount columns together, without changing nBTC
values, deadlines, Bitcoin satoshis or local currency amounts. Browser balances and input checks
are conveniences only; server checks are authoritative. Owner and holder
authorization are checked on every action. Non-owner sign-ins continue to have
no access to staff research.

Signing uses an Ed25519 private key stored as NBTC_SIGNING_PRIVATE_JWK in the
site's runtime secrets. The public key is pinned in the initialized database.
A mismatched or missing key stops mutations. Never replace that secret on an
initialized ledger without an explicit, verified key-transition procedure.
No such rotation is implemented in this first release.

## Expiry, availability and throughput

The ledger uses a clock that stops during declared maintenance. Pausing stops
transfers, issuance and new quotes. Payment reporting and recording a completed
external refund remain possible. Resuming extends deadlines by the pause duration.
Expiry works without a background scheduler: every balance query excludes due
lots, and public supply includes them in Treasury inventory. Wallet activity
materializes signed recall records in batches of at most 100 lots. Use Refresh
to record more pending recalls when necessary.

The visible journal timestamp is recording time; a recall also retains each
lot's effective deadline. There is no claim that an always-running cron job,
email system or independent uptime monitor has been installed. Set operational
monitoring and keep a procedure for outages that start before a manual pause.

The initial release caps one transfer at the first 100 unexpired source lots.
Wallet history shows 100 financial entries; all unspent lots load in pages of 500 at one ledger revision; buyer orders show
100; the owner queue shows 200 and exact-address recipient lookup remains
available. Public audit records paginate in blocks of 100 using ?after=SEQUENCE.
The total displayed wallet balance includes all unexpired lots. These bounds
keep an initial service manageable; it has not been independently audited or
load-tested as a large-scale financial system.

## Backups and inspection

Use the owner-only Download private Treasury backup action regularly. It exports
a consistent SQL snapshot of accounts, lots, orders, events, postings and state.
It does not export the signing private key. Keep the key separately in an
owner-controlled secure recovery arrangement before relying on recovery from
total hosting loss. Access to site/runtime secrets is a separate requirement
from having the JSON backup.

The in-app export is bounded to 25,000 rows per table. For a larger service use
the hosting database export. The public checkpoint downloader and signature
verifier allow holders to keep their own evidence without obtaining private
customer data. Signed logs identify the issuer; independently retained copies
are necessary to detect a rewritten history. No independent witness is claimed.

The repository provides scripts/nbtc-verify-backup.mjs to check exported data
offline and scripts/nbtc-backup-to-sqlite.mjs to restore it into a NEW local
SQLite database. The restore refuses to overwrite an existing file. Test a
restore before depending on a backup. Restoring data alone does not create a
working authentication or public payment service.

## NAS or local hosting path

A NAS capable of running containers or a small dedicated server can host the
application service, a database and encrypted backups. Publish only the HTTPS
application through a reverse proxy or tunnel; keep the database and NAS
administration interface on the private network. Use durable local storage,
an independent backup copy and power/network continuity appropriate to the
service you promise users.

Today's release runs on the existing hosted site. It has NOT been installed
on a NAS or exposed from a home network. The data is exportable as JSON and
restorable to standard SQLite; the source and migrations are retained in the
site repository. A dedicated deployment can instead adapt storage to PostgreSQL.

Before moving the live Treasury: implement real authentication for the local
application, preserving verified user-to-wallet bindings; migrate the signing
key securely or establish a verified public key transition; pause the old
writer; export and verify the final signed head; restore and reconcile the
new database; switch the HTTPS route; then resume once. Never run two writable
Treasuries against diverging copies of the same ledger.

The platform's authenticated-user headers are trustworthy only behind its
dispatcher. A NAS must not accept these headers from arbitrary internet clients.
The Cloudflare Worker entry point is not a ready-made NAS server; local service
and authentication adapters still need to be installed for that deployment.

## Financial operating scope

Self-hosting removes a payment processor from internal transfers; it does not
establish permission to operate a currency exchange or create collateral rights.
The exact administrator/issuer and payment arrangement needs classification
under the applicable rules before public real-money sales. FinCEN's guidance
on virtual-currency administrators/exchangers is one starting point:
https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-persons-administering

No completed licensing determination, independent appraisal, collateral
assignment, guaranteed BTC parity, automatic redemption or payment-provider
approval is asserted by deploying this software.

## Merchant invoices

The Accept payments tab creates fixed-amount, 24-hour, single-use invoices.
The nbtc_invoices table stores private merchant order references. The public
invoice response omits those references and payer identity; the public journal
still exposes pseudonymous transfer details and invoice identifiers. Seller
lists are restricted to that seller. Direct administrator inspection is via
the owner-only backup.

Invoice payment reuses the guarded transfer transaction. Status, payment event,
recipient lot and sender debits change together. Cancellation, expiration,
insufficient unexpired funds or a concurrent prior payment prevent a debit.
A recipient gets a fresh 30-day lot; the payer's unspent change keeps its age.
The interface shows the most recent 100 seller invoices; at most 100 open,
unexpired invoices are allowed per seller.

Backup schema 2 includes invoices. The verifier and SQLite restore also read
schema 1 backups from before this addition. No automatic merchant integration or provider approval is represented by this feature.

## Capped BTC merchant settlement

After initializing the Treasury and opening your owner wallet, use Pay a BTC
merchant → Owner: funding address & service activation. Use a dedicated mainnet
address in a wallet you control. Fund it and wait for three confirmations.
Keep the private key and seed in your wallet, never in this website or its forms.
Review the published settlement terms, confirm your actual operating arrangements,
and open requests. The address and dated reserve observations become public.
No funded address, outside wallet, operating approval or BTC was supplied by
installing this feature. Its default state is closed.

The initial choices are 0.001 BTC per invoice; 0.01 BTC maximum outstanding
including fee budgets; a matching rolling 24-hour start budget; ten-minute
quotes shortened by the merchant deadline; and three confirmations. Customer
settlement fees are zero. You pay the actual BTC network fee. The UI suggests
2,000 satoshis as a fee budget, not a live fee estimate. Inspect your wallet's
fee estimate before quoting. Only individual accepted quotes receive the 1:1
nBTC/BTC rate; this is not an offer to redeem every issued nBTC.

The owner's sequence is: check the real checkout and quote; wait for customer
acceptance; recheck its deadline and mark payment in progress; send once from
your own wallet; wait for three confirmations; record the final transaction;
confirm merchant acceptance and settle. Always mark payment in progress BEFORE
signing or sending. An unstarted hold is releasable by its customer, so sending
before this state change creates a race and an unrecoverable loss risk.

Use wallet coin control so the payment actually spends an output from the
configured funding address. The observer counts that address only. Change sent
to a different wallet address is not counted toward later service funding.
Refill the dedicated address when necessary; a change of funding address is
blocked while any payment commitments remain. Do not reuse a personal address
whose public history you do not want associated with this service.

The application makes GET requests to the fixed Blockstream Esplora API host.
It validates address responses, unspent outputs, confirmations, transaction
funding input, exact destination amount and current-chain block membership.
These are third-party observations, not full-node validation, ownership proof,
UTXO locks or assurance that reserves have no other obligations. Preserve
committed BTC yourself. An outage stops new verified operations. You can close
an already configured service without a working explorer connection. Closing
stops new requests, quotes and acceptances; existing holds still need resolution.

For an uncertain send, inspect your wallet and chain history. Do not resend
or release a possibly signed/broadcast payment. Fee replacement before
confirmation is handled in your wallet; record only the final confirmed ID.
A confirmed ID cannot be reused or changed by this release. A later reorg,
merchant rejection or refund dispute requires owner reconciliation; there is
no automatic rollback, replacement, force-settlement or dispute-resolution API.
Unresolved holds stay protected. Do not edit database balances to resolve them.

Customer release is possible only before you mark payment in progress. After
that, an owner release needs a public reason and an explicit confirmation that
nothing was signed, broadcast or remains pending. This is an owner attestation,
not proof supplied by the chain reader. Retain supporting records privately.
Once a confirmed transaction is recorded, release is disabled. Settlement
requires a fresh chain check plus merchant acceptance; it returns held nBTC
to inventory. A released unexecuted hold instead restores each lot's saved
remaining lifetime, without renewing it to 30 days.

Backup schema 3 adds configuration, requests and protected holds. The verifier
checks escrow balances, signed quote/transaction commitments, saved lifetimes,
request states and total supply; restore includes these tables. Backups contain
private merchant addresses, references and transaction IDs. The verifier still
accepts legacy schema 1 and 2 exports from before these features existed.
Keep signed public checkpoints independently as well as your private backups.

## Wallet reference and expiry display — 26 September 2026

The read-only `/api/nbtc/reference-price` endpoint divides the current company
valuation by the fixed 21 million nBTC ceiling. Before any owner update, it uses
US$50 trillion. No external market feed is required.

The owner can change this value under Wallet → Treasury controls → Company
valuation. Enter whole USD, including zero. The server checks owner authorization
and the request origin. Each save appends a signed `set_valuation` journal entry;
the latest entry is authoritative and is retained in Treasury backups.
The wallet checks for updates every minute and refreshes immediately after a save.
If the saved value cannot be loaded, the reference shows an unavailable state.

The USD display uses only spendable, unexpired lots and excludes settlement holds.
It is a valuation-based reference, not a sale or redemption quote. It does not
change purchase quotes, invoice amounts, BTC settlement rates or wallet balances.

The wallet refreshes its balance and server time every 30 seconds. Every lot is
fetched at one global ledger revision and expiry cutoff; concurrent writes
restart synchronization. Each lot shows UTC, Unix seconds and a ticking timer.
The browser uses monotonic elapsed time, not its wall-clock setting. A local
expiry immediately removes that amount from both displayed balances. Server
confirmation remains authoritative. Paused time stays frozen until a new
server snapshot shows a resume. After loss of synchronization or 90 seconds
without a fresh snapshot, the display asks to reconnect rather than claiming
a current balance. None of these display changes mutates existing funds.

## Local Treasury operator program · October 5, 2026

The public enlistment and payout directory is `/nbtc/branches`. Signed-in wallet
holders can apply free of charge. Owner-only review controls appear on that same
page. There is no automatic approval, inventory grant, fiat payment or guarantee
of local-currency redemption.

Review the operator's identity and common ownership, applicable authority, local
payment arrangements, and evidence of available funds. Do not count the same
external funds toward multiple operators. Set reviewed remaining capital in its
payout currency; accepted net payouts can use at most 80%, leaving a 20% buffer.
Review expires after seven days. Renew only from fresh evidence, including any
completed payouts, withdrawals and replenishment. The branch can pause new business;
the owner can suspend it. Payment reports and disputed holds remain reconcilable.

Operators quote a net local payout and included fee, then pay externally after the
holder has accepted the exact quote and reserved nBTC. An operator's payment report
does not release coins; holder receipt confirmation or evidence-based owner dispute
resolution is required. Never instruct a second external payment merely because a
website response was lost. Preserve independent payment evidence and the signed
receipt. Review repeated start/release cycles and possible related-account trades;
suspend operators using fictitious payments to protect or renew expiry. The platform
blocks cash-out to the same branch wallet but does not establish ownership of every
other account or independently observe external bank reserves.

Unstarted local holds retain original expiry. Payment must start before the earlier
of 24 hours or the earliest original expiry. Promptly release missed reservations;
expired portions return to Treasury. Started holds protect processing time and stay
locked until holder confirmation or owner resolution. Do not release a started hold
until external evidence establishes nonpayment and addresses delayed-arrival risk.
See `/nbtc-local-terms.md` for the separately accepted settlement policy.

Backup schema 4 adds local branches, cash-out requests and held lots. The verifier
checks them against signed application/quote/evidence commitments and escrow
postings. The restore script includes these tables and retains support for prior
backup schemas. Keep backups private: application evidence, private contacts and
external payment references are included.