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

Implemented PostgreSQL v3 allocation-registry groundwork

Browse Source
This commit is contained in:
eric
2026-10-21 14:59:15 -04:00
parent ee5dc35330
commit e70199ecb0
6 changed files with 360 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/custodial-market-design.md
+1 -1
View File
@@ -19,7 +19,7 @@ The operator has authorized proceeding with implementation instead of the previo
**Financial storage update:** [ADR 003](postgres-financial-storage.md) selects PostgreSQL and records the integrated asynchronous custody backend, restricted runtime/schema roles, deferred accounting constraints, explicit SQLite freeze/import, and full dump/restore rehearsal. SQLite remains an opt-in-compatible local sandbox default, not an automatic fallback. Real custody and production operating acceptance remain blocked.
**Read-only Monero observation groundwork:** [server/market/monero-observer.ts](../server/market/monero-observer.ts) defines a narrow mainnet wallet-RPC client for mainnet primary-address verification and bounded incoming-transfer scans. It requires explicit opt-in and a protected external config file, uses authenticated requests with strict HTTPS/literal-loopback-only HTTP, no redirects, bounded response/deadline, JSON-RPC request-ID validation and lossless JSON integer handling. Each observed transfer includes its validated destination address. It exposes no subaddress creation, credit posting, transfer construction, relay, sweep or withdrawal operation and is not wired into server startup/routes. [server/market/monero-observation-store.ts](../server/market/monero-observation-store.ts) persists scan manifests, exact incoming-transfer observations, cursor progress and append-only seen/changed/not-seen/reappeared events in PostgreSQL schema v2, restricted to a dedicated observer DB role separate from the custody API runtime. Confirmation growth updates a projection without emitting an event every poll. A missing output is only a review signal; no automatic journal posting, debit, reversal or customer credit exists. Schema v1→v2 is an explicit additive migration, not an HTTP-runtime migration. The 33-test PostgreSQL suite covers v1 upgrade preservation, least-privilege separation, scan replay/cursor fencing and reorg/reappearance observations. No wallet endpoint, credentials or funds were accessed. This is observation/audit groundwork, not a deposit-address allocator, live deposit processor, or approved mainnet switch. The application only calls read methods, but operators must still use a restricted view-only wallet RPC instance/account; the code cannot prove credential scope.
**Read-only Monero observation and allocation-registry groundwork:** [server/market/monero-observer.ts](../server/market/monero-observer.ts) defines a narrow mainnet wallet-RPC client for mainnet primary-address verification and bounded incoming-transfer scans. It requires explicit opt-in and a protected external config file, uses authenticated requests with strict HTTPS/literal-loopback-only HTTP, no redirects, bounded response/deadline, JSON-RPC request-ID validation and lossless JSON integer handling. Each observed transfer includes its validated destination address. It exposes no subaddress creation, credit posting, transfer construction, relay, sweep or withdrawal operation and is not wired into server startup/routes. [server/market/monero-observation-store.ts](../server/market/monero-observation-store.ts) persists scan manifests, exact incoming-transfer observations, cursor progress and append-only seen/changed/not-seen/reappeared events. **PostgreSQL schema v3** adds [server/market/monero-deposit-allocation-store.ts](../server/market/monero-deposit-allocation-store.ts), which can durably reserve a unique subaddress index for a beneficiary before a future wallet side effect and register a validated mainnet subaddress once. Reservations and beneficiary/index bindings cannot be deleted or reassigned; a registered address cannot be replaced. The registry is currently unreachable to both the custody API and observer roles, and the store is not wired to startup, routes, UI or wallet RPC. A wallet-generation UUID/fingerprint supplied to this groundwork is not proof of wallet ownership. It does not solve wallet-RPC/database crash reconciliation or establish the pinned RPC's per-output identity model. Confirmation growth updates an observation projection without emitting an event every poll. A missing output is only a review signal; no automatic journal posting, debit, reversal or customer credit exists. Schema v1→v3 is an explicit additive migration, not an HTTP-runtime migration. The final disposable PostgreSQL suite passed **35/35**, covering v1/v2 upgrades, concurrent reservations across independent pools, idempotency, immutable registration, role isolation and zero journal postings. The offline suite passed **183/183**, and the test-target build succeeded. No wallet endpoint, credentials or funds were accessed. This is not a working deposit-address allocator, live deposit processor, or approved mainnet switch. The application only calls read methods, but operators must still use a restricted view-only wallet RPC instance/account; the code cannot prove credential scope.
Validation: TypeScript/Vite build and 144 offline tests passed in the serial native-RandomX test run; the initial parallel run encountered a peer-gossip timeout. Browser smoke verified a disposable wallet's signed test credit, withdrawal hold and cancellation restoring the exact balance, plus a 390px viewport without horizontal overflow. No real funds were used. Tests and remaining acceptance gates are below; this is not launch readiness.