Back to Engineering Notes

Mooncoin Mobile Wallet Experiment for Atomic Swap Readiness

wallet engineering 2026-02-19

Context

To support the long-term mooncoin atomic swap roadmap, we initiated a mooncoin wallet experiment focused on mobile execution constraints. The goal is not a demonstration UI, but a production-feasible architecture in which mobile clients can perform secure local signing while remaining compatible with real mooncoin node behavior.

This track is evaluated from a mooncoin dev perspective: operational reliability first, UX second, with no custodial components hidden behind convenience abstractions.

Objective

  • Define a mobile wallet signing model that keeps private keys outside server-side infrastructure.
  • Validate the minimum mooncoin node and API dependencies required for reliable balance and history queries.
  • Identify wallet-layer requirements for swap-capable flows without requiring protocol changes.

Technical Approach

Current design candidates:

  1. Local key ownership with transaction proposal + local signing
  2. Watch-only address synchronization with deferred spending authorization
  3. Optional hardware-backed secure enclave signing path

Baseline node query flow:

mooncoin-cli getnewaddress
mooncoin-cli listunspent
mooncoin-cli getrawtransaction <txid> 1

Representative unsigned-send flow:

mooncoin-cli createrawtransaction \
'[{"txid":"INPUT_TXID","vout":0}]' \
'{"DEST_ADDRESS":1234.0}'

These RPC primitives define the minimum interface required between a mooncoin wallet and a mooncoin node for deterministic transaction construction and verification.

What We Implemented / Verified

Verified

  • Mooncoin node RPC queries for transactions and UTXO sets behave consistently under normal operating conditions.
  • Transaction proposal objects for a mooncoin wallet can be constructed deterministically using existing RPC primitives without requiring node-side signing.

Partially Verified

  • The offline-first signing model is defined at the architectural level, but has not been validated under sustained network interruptions or node reconnection scenarios.
  • Error-recovery state transitions are specified conceptually but have not been exercised through full end-to-end wallet workflows.

Not Yet Verified

  • Atomic swap-specific mobile interaction flows, including HTLC claim/refund timing awareness, are not implemented.
  • Production-grade key backup procedures and multi-device restore safety guarantees are not yet defined or tested.

Risks and Open Questions

  • Can a single mooncoin wallet UX support both basic payments and HTLC-aware atomic swap flows without introducing user error?
  • Should swap functionality be integrated into the primary wallet UX or isolated behind an advanced mode?
  • How should mooncoin node unavailability be surfaced to prevent signing of stale transaction intents?

Failure boundary example:

  • If the wallet signs a transaction derived from stale UTXO state while the mempool changes rapidly, the signed transaction may fail to broadcast or confirm as intended. This represents a reliability failure, not a key-compromise scenario, and must be handled explicitly.

Engineering reflection: reliable atomic swap support depends more on deterministic signing boundaries than on UI design.

Next Steps

  • Implement deterministic transaction-intent serialization for auditability and reproducibility.
  • Add explicit pre-sign validation checks for UTXO freshness and fee assumptions.
  • Prototype a swap-specific interaction screen for HTLC claim/refund timing awareness.