# nBTC physical registry · v0.2 An executable local extension of the published nBTC negative-height ledger. Operator proposed for a future service: Ben Đ Om / DCLXVI LC. This release is a developer kit. There is no live registry endpoint, deposit address, merchant network, token sale, or claim on Bitcoin or LSM assets. ## Start here Unzip `nbtc-v0.2.zip` and open a terminal in its `nbtc-v0.2` folder. Python 3.12 was used for release testing. ```sh python3 -m venv .venv source .venv/bin/activate python3 -m pip install -r requirements.txt python3 -m unittest -v test_nbtc test_registry python3 demo.py python3 registry_demo.py ``` On Windows, use `py -3.12 -m venv .venv` and `.venv\Scripts\Activate.ps1` in PowerShell, then `python` for the remaining commands. Follow your existing local environment policy if activation is disabled. `demo.py` mines a nine-block local ledger and demonstrates guardian recovery. `registry_demo.py` mines and replays the physical lifecycle, writes `registry-output/registry-chain.json` and `registry-result.json`, and reports preserved supply and holder claims. Days advance in simulation, without waiting. Keys are disposable and discarded on exit. Local mining is a reproducible work experiment; it neither joins a shared network nor earns a future public allocation. ## The physical object Start with the 45 mm disk in `coin.scad`. Its value-bearing face has an embossed nBTC mark. A recessed base and lid make room for a tag; the underside is blank. This is a single marked face, not a topologically one-sided surface. A Mobius shell could use the same registry rules after its print design is validated. 1. Measure the actual insert and adjust `tag_diameter`, `tag_thickness`, and `clearance`. Defaults allow a 28 mm diameter, 0.8 mm thick insert. 2. Open the file in OpenSCAD. Set `part="base"`, render, and export STL; repeat with `part="lid"`. Print both flat in a suitable nonconductive filament. PETG is a candidate, not a tested manufacturing specification. The model has not been physically printed or fit-tested in this release. 3. Fit the insert, apply a tamper-evident seal, and add a unique public coin identifier/QR. The identifier and credential epoch must be checked against the registry. Never print a private key or recovery phrase on the shell. 4. Run the local lifecycle before building any NFC integration. A copied QR or ordinary NFC tag is only an identifier; neither authorizes spending. A production authenticated tag needs a reviewed challenge-response integration. The reference kit implements wallet and registry signatures, not an NFC driver. For an installed OpenSCAD command-line application: ```sh openscad -o coin-base.stl -D 'part="base"' coin.scad openscad -o coin-lid.stl -D 'part="lid"' coin.scad ``` Printing creates a shell, not monetary supply. Each funded coin has one escrow balance in the ledger. Loading moves existing units from its holder's wallet. Redemption moves that same balance back; an empty shell can be reused. ## Public operator authority and default rules Every physical operation requires the registered issuer's signature. Holders accept this model when a coin is registered or handed over. This is centralized recovery authority. It is not an anonymous bearer asset or an offline cash system. | Event | Default rule | Effect on value | | --- | --- | --- | | Credential age | Renew after 90 days with authenticated holder activity | No expiry or destruction of the balance | | Lost physical coin | Verified report, frozen transfers, seven-day challenge | Issuer can return the coin record to registry custody | | Inactivity | 365 days without authenticated holder activity, then 30 days' notice | Issuer can recall if no successful holder challenge | | Recall | Issuer-signed resolution, fresh credential epoch | Old credential revoked; balance and beneficial-holder account preserved | | Reissue | Issuer plus current holder authorize after verification | Same units, replacement credential; no minting | Loss reports are either co-signed by the current holder or explicitly attested by the issuer after external ownership verification. Merely receiving an unverified report is not sufficient. Evidence and notice fields contain hashes of external case records, not personal details. They do not themselves prove ownership or delivery of a notice; the operator must retain and verify the underlying evidence and provide reachable notice and appeal channels. A holder's authenticated challenge cancels a dormancy notice and renews activity. A lost-coin dispute is recorded for review. The issuer may quarantine a disputed coin after the delay, but cannot use that transition to replace its beneficial holder or sweep its value into the treasury. Cancellation and resolution remain in the signed block history. The reference service requires issuer co-signing even for a challenge; a live deployment needs an independently reachable intake channel so the operator cannot silently suppress appeals. Recall is an explicit `coin_recall` command. The demo is not a running monitor: production operation would need a scheduled eligibility check, notice delivery, case handling, and authorized signing after the deadlines. These are not deployed. ## Transfers and signatures `coin_register` reserves a unique account identifier with zero balance and requires issuer and initial-holder approval. The prototype represents the physical credential as `(coin account ID, epoch)`, a public reference checked online rather than a spendable secret. Every action also checks a nonce. `coin_load` debits the holder's existing balance and fee; `coin_handoff` requires issuer, sender, and recipient signatures and atomically changes the holder and credential epoch. `coin_redeem` pays only the current holder's ordinary wallet. Base wallet operations and mining rewards cannot bypass the coin escrow rules. Supply is conserved across ordinary wallets and coin accounts, with only the already-published mining subsidy and initial treasury allocation creating units. The recipient must check the issuer, network identity, active status, balance, expiry, and final recorded handoff before accepting a coin. Passing the shell without a registered handoff does not transfer its recorded ownership or recovery rights. The old holder and their guardians have no authority over the new holder's account. An ordinary tag cannot make this process safe for anonymous offline use. ## Keep recall authority recoverable The network configuration identifies an issuer **account**, not one irreplaceable key. That account uses the existing five-guardian, three-signature recovery mechanism. Its owner key can be replaced after the demonstration's six-block challenge period; the former key then loses registry authority. Registry actions pause while issuer recovery is pending. Holder wallet recovery works in the same way without changing which account owns a physical-coin claim. Before live custody: provision Ben's operational issuer account; independently hold guardian keys; practice issuer and holder recovery; maintain encrypted, access-controlled backups of keys and case records; retain and replay the ledger; and support key and guardian replacement with reviewed operating procedures. No software can guarantee recovery after all authorization keys, guardian paths, and recoverable records have been destroyed. The included demo keys are not operational credentials and must never be used for valuable balances. ## What is and is not enforced `RegistryChain` reuses the v0.1 hashing, negative heights, issuance cap, signatures, atomic state transitions, and block replay. The issuer account and time intervals are committed in its distinct network manifest. It does not silently modify the recorded v0.1 chain; no migration or interchange with BTC is implemented. The local rules enforce elapsed intervals against issuer-attested UTC seconds and reject backwards time within each coin record. An issuer can misstate time; there is no independent clock or decentralized timestamp consensus in this prototype. Likewise, evidence hashes do not automate real-world adjudication. A live service needs clock controls, an auditable operator, durable storage and wallet custody, anti-rollback protection, monitoring, hardware integration, and security review. The Python tests verify the executable rules, not those unimplemented operations. Production financial terms, issuance distribution, public network launch date, and any future IP-backed rights remain undefined. Early developers gain experience and can build products; this package makes no promise of returns, preferential allocations, or being first to market.