 jwinterm
|
10b508fa8e
|
feat: XMR/WOW wallet handlers (LWS proxy, stateless-forward)
Second wallet-handler slice. Authenticated, non-custodial, stateless-forward
proxies over the LwsClient: the wallet sends its private view key per request,
the backend forwards it (never stores it; the LWS holds it for scanning), and
the wallet constructs + signs spends locally.
Endpoints (POST, under /api/v1/wallet/lws, asset = xmr|wow in body):
- register -> add/import account (view key) for LWS scanning (+start_height)
- balance -> total_received / unlocked / locked + scan state
- history -> txs incl. mempool pending + candidate spent_outputs
- unspent_outs -> outputs + fee params for client-side spend construction
- random_outs -> ring decoys (count clamped + fan-out capped in the client)
- submit_tx -> broadcast a finalized signed tx
- height -> daemon chain height
- confirmations-> tx confirmation count
- JWT-gated; the view key is skipped from every tracing span (never logged) and
never stored. Feature-gated dispatch; unknown/disabled asset -> 400.
- Boundary validation: view_key (64 hex), address (bounded), txid (64 hex),
tx_hex (even hex, <=2 MiB) — all before any LWS call.
- Shared validators in wallet/mod.rs (validate_hex/view_key/cn_address).
- Colliding DTO names disambiguated (Lws-prefixed) so the openapi schema
registry stays correct; 8 paths + schemas + xmr_wow tag registered; spec
regenerated, drift-clean.
6 L1 integration tests (auth gate on balance/register; unknown-asset,
bad-view-key, malformed-tx-hex, malformed-txid 400s) + validator unit tests.
|
2026-06-23 14:32:38 -04:00 |
|