WikiDeck/wikideck
3
0
Fork 1
Code Issues 8 Pull Requests Actions Packages Projects 2 Releases Wiki Activity

Planning

Browse Source
This commit is contained in:
eric
2026-10-20 13:00:08 -04:00
parent a1de67ea14
commit bcd8630a8e
18 changed files with 483 additions and 172 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/xmr-domain.md
+11 -11
View File
@@ -1,6 +1,6 @@
# Native-XMR domain and migration specification — first increment
Status: exact-amount primitives implemented; **native-XMR marketplace migration and fee policy not delivered/approved**. See [production plan](production-plan.md) and [settlement investigation](settlement-feasibility.md).
Status: exact-amount primitives and version-3 **native-XMR mock marketplace pricing** are implemented. No live settlement architecture/payment, production accounting migration or approved network-cost policy is delivered. See [production plan](production-plan.md) and [settlement investigation](settlement-feasibility.md).
## Implemented amount contract
@@ -29,9 +29,9 @@ This pure result is not a payable quote, does not estimate real network fees, an
Pending operator decisions: author-leg cost allocation/caps, estimator/quote expiry, overrun handling and explicit tiny-checkout policy. The planning assumption is to block uneconomic checkout **before** accepting payment, with no subsidy, pooling or accumulated customer balances. No live checkout currently calls the budget helper.
## Versioned native-XMR terms — integration target, not an active schema
## Versioned terms
The eventual signed terms must use a new domain/schema version, not reinterpret `market-command-v2`. Select exact serialization after M0, binding at least:
New commands use `market-command-v3` and strictly bind network/chain, market, actor/public key, nonce, expiry, action, currency `XMR`, and canonical atomic gross for listing/bid/buy. List and buy terms bind the fixed author rate/address; listing terms bind hosting basis points. New public sale prices no longer use USD or a conversion rate. The current signed model is intentionally a **mock-market terms schema**, not yet the full production economic settlement commitment. The eventual production terms need a reviewed new protocol/domain version (not a silent reinterpretation of v3) binding at least:
- network and chain identity, market and order/listing identity, nonce and expiry;
- card hash/ownership sequence, seller and buyer authorization identities;
@@ -41,17 +41,17 @@ The eventual signed terms must use a new domain/schema version, not reinterpret
- payment destination/conditional-output commitment, payment-evidence/confirmation/unlock policy and selected exchange protocol version;
- lock identity, release/refund/cancel conditions and relevant deadlines.
The buyer must review immutable exact terms and addresses; the seller must authorize network-cost exposure. Validate the supplied allocations by recomputation, not trust them because they are signed. A changed quote needs fresh authorization; callback status or later exchange-rate changes cannot amend it. No native-XMR signatures are generated by this increment.
The buyer must review immutable exact terms and addresses; the seller must authorize network-cost exposure. Validate supplied allocations by recomputation, not trust them because they are signed. A changed quote needs fresh authorization; callback status cannot amend it. The mock v3 checkout currently derives the quote only from the exact gross and hosting rate; it does not set live addresses or use an exchange rate.
## Non-destructive migration specification
1. Inventory copied, stopped-node market data by schema/order state; record counts, original terms/receipts and hashes. Keep existing recovery contract until a reviewed new schema includes all financial journals. No migration is run here.
1. Inventory copied, stopped-node market data by schema/order state; record counts, original terms/receipts and hashes. Keep existing recovery contract until a reviewed new schema includes all financial journals. The v3 runtime reads mixed old/new JSON rows without rewriting old USD rows. No destructive database migration is run here.
2. Keep historical USD/mock listings/orders and `market-command-v2` authorization material in their original version. Never convert `priceCents` into XMR, infer an old seller XMR address, synthesize a signature or issue a real invoice from old orders.
3. Disable new old-version checkouts during the eventual cutover. Reserved/in-flight mock orders require an explicit drain/cancel policy before migration; do not relist their cards while an old obligation remains active. Auctions/bids require disposition; do not silently convert them to funded live bids.
4. Close old open listings through an audited versioned process. Sellers relist with fresh native-XMR terms and authorization. Preserve old records and references; do not delete receipt/idempotency history.
5. Keep live auctions disabled. New fixed-price routes/UI/storage must integrate exact amounts, selected settlement evidence, index/accounting/recovery controls and disclosures together. Public UI remains explicitly USD/mock until this delivery is tested.
6. Dry-run on disposable copies; compare immutable old records and signatures, assert no legacy record reaches a real processor, test every in-flight state, interruption/restart and rollback. Before external effects, rollback may restore the stopped-node copy. After any real external effect, a local DB rollback alone is unsafe: reconcile external history first and retain authoritative intents/events.
3. New v2 USD listing creation, bids and checkout are rejected. Existing v2 reserved orders can still complete their old **mock** pay/refund/delivery route with v2 signatures. This is compatibility, not an external payment obligation. Do not relist their cards while an order is reserved/in flight.
4. Old open USD listings are displayed as legacy/read-only; where eligible (seller-owned and no bid), the seller can close the listing with a fresh v3 authorization. Auctions with bids cannot be retired through this action and expire under the original sandbox rule. Sellers create a new XMR listing with a new v3 signature. Old records and receipts remain; no price conversion or automatic bid transfer.
5. Fixed-price and sandbox-auction v3 terms are native-XMR mock routes. No real payment processor can use them. Before live fixed-price delivery, selected settlement evidence, index/accounting/recovery controls, policy and disclosures still require integrated implementation and review; live auctions remain a separate later gate.
6. Full stopped-copy migration dry-run, complete mixed-record upgrade/restart tests, rollback rehearsal and journal hash/count evidence remain outstanding. No external effects occur in this mock path. Before any future real external effect, a local DB rollback alone is unsafe: reconcile external history first and retain authoritative intents/events.
Acceptance remains open: actual versioned schema/signature tests, copied-data migration executable/dry run, UI review, recovery/invariant tests and approved fee/settlement semantics. [Amount tests](../tests/xmr-amount.test.ts) cover boundary/coercion/newline/precision cases, RPC range, independent rounding, fee-budget exhaustion/spikes, 4,000 deterministic generated conservation/round-trip cases and original mock caller behavior. They are not settlement feasibility or launch evidence.
Versioned XMR signature tests, direct HTTP v3 integration, one-atomic-unit no-minimum fee tests, and legacy-order/listing compatibility tests cover this increment. A full stop-copy data migration dry-run, interrupted-upgrade/rollback evidence, approved network-cost policy, live processor integration and settlement are not covered. [Amount tests](../tests/xmr-amount.test.ts) cover boundary/coercion/newline/precision cases, RPC range, independent rounding, fee-budget exhaustion/spikes, 4,000 deterministic generated conservation/round-trip cases and original mock caller behavior. They are not settlement feasibility or launch evidence.
Validation for this increment (2026-10-20): Docker test-target build passed TypeScript and Vite compilation; the full suite ran with external networking disabled and passed **130 tests, 0 failures, 0 skips**. Includes adjacent USD processor final-newline hardening. This evidence does not close the remaining M0/M1 integration and policy gates.
Validation for this increment (2026-10-20): Docker test-target build passed TypeScript and Vite compilation; the full suite ran with external networking disabled and passed **133 tests, 0 failures, 0 skips**. Includes API v3 signing, one-atomic minimum, legacy read-only listing retirement, and in-flight USD order restart compatibility. This evidence does not close the remaining M0 settlement, fee-policy, data-copy dry-run or launch gates.