Mooncoin Browser Wallet Concept and Threat Model Draft

Context

This devlog records a first-principles design pass for a mooncoin browser wallet. The main question is whether browser delivery can improve accessibility without weakening critical security boundaries.

A browser-based mooncoin wallet can reduce onboarding friction and speed up integration for web-adjacent tools. At the same time, browser environments increase exposure to extension interference, script injection risk, and session-state ambiguity. The design therefore treats usability and security as a coupled problem, not separate tracks.

Objective

Define a browser-native mooncoin wallet model with explicit key ownership boundaries.
Enforce architectural separation between read paths (query) and write paths (sign + broadcast).
Evaluate whether this model can support future Mooncoin atomic swap UX requirements.
Keep data compatibility with existing mooncoin node and Electrum-backed services.

Technical Approach

Candidate architecture:

Read path through Electrum/proxy APIs for fast address-state queries
Local transaction construction inside browser runtime
Local signing with user-controlled key material
Broadcast through a controlled API boundary

Representative query call:

curl -sS https://<api-host>/v1/address/<address>/balance

Representative local flow check:

mooncoin-cli decoderawtransaction <hex>

Threat-model baseline checks:

- Key never leaves local runtime
- Session state is invalidated on tab close or lock event
- Broadcast requires explicit user confirmation with full tx preview

What We Implemented / Verified

Verified

Concept-level boundaries are documented for query, sign, and broadcast paths.
Browser integration constraints with existing Mooncoin backend services are mapped.
Core trust assumptions for a browser-hosted mooncoin wallet are explicitly stated.

Partially Verified

Usability assumptions for advanced flows are drafted but not user-tested.
Session hardening strategy is defined conceptually, not implemented.
Risk communication patterns for non-technical users are still iterative.

Not Yet Verified

Production-grade key storage and recovery policy for browser-only mode
End-to-end signing flow under adversarial extension environment
Operational safety under long-lived multi-tab sessions

Risks and Open Questions

Should the default mode be watch-only with optional local signing enablement?
How should users audit transaction intent before signing in a constrained UI?
Can browser storage guarantees meet the project’s security bar for non-trivial balances?
Which backend freshness signals should be mandatory before presenting spendable balance?

Failure boundary example

If the wallet relies on a trusted query source without exposing freshness metadata, users may sign transactions based on stale UTXO assumptions. This can cause avoidable failures and degrade perceived safety even when backend consensus is healthy.

Next Steps

Build a minimal prototype with explicit transaction preview and intent hash display.
Add threat-model test cases for extension interference and stale-state signing.
Compare browser wallet risk profile against mobile wallet track before deciding public beta scope.
Define minimum release criteria for any public-facing browser wallet experiment.

FAQ

Why explore a mooncoin browser wallet instead of only desktop or mobile?

Browser delivery lowers integration friction and onboarding time, especially for web-based tooling, while reusing existing Mooncoin backend infrastructure.

Does this design replace the mooncoin node?

No. The browser wallet depends on mooncoin node-derived data through Electrum/proxy services and does not alter consensus behavior.

Will private keys be sent to backend services?

The design goal is local signing only. Private key material should remain in local runtime and never be transmitted to query services.

Is this ready for production funds?

Not yet. This entry is a concept and threat-model draft. Key storage, recovery policy, and hostile-environment validation are still incomplete.