Back to Engineering Notes

Mooncoin and Litecoin Atomic Swap Research Notes

protocol research 2026-02-18

Context

This research workstream investigates the feasibility of a non-custodial mooncoin-litecoin atomic swap mechanism using standard Bitcoin-family primitives. The focus is on whether a practical swap flow can be implemented using the existing mooncoin node infrastructure without introducing protocol changes or custodial intermediaries.

Mooncoin currently operates on a Litecoin-derived consensus model, and recent development work has modernized the codebase toward a Litecoin 0.21.4 baseline. While this modernization improves maintainability and compatibility, it does not automatically guarantee interoperability at the script level. Atomic swap support requires careful validation of script execution, timelock semantics, and wallet capabilities.

Atomic swaps represent a technically conservative path toward interoperability. Unlike bridges or wrapped assets, swaps rely only on the native consensus rules of each chain. For a network such as Mooncoin, where long-term security depends on maintaining stable infrastructure, this approach aligns with the philosophy of incremental protocol evolution.

This research is being conducted from the perspective of a mooncoin dev maintaining full-node infrastructure rather than building a custodial exchange or specialized swap server.

Relevant components under evaluation include:

  • Mooncoin Core full node behavior
  • Mooncoin wallet script capabilities
  • Litecoin atomic swap script patterns
  • HTLC construction assumptions
  • Timelock and refund safety margins
  • Compatibility with Electrum-style light wallets

The goal is to determine whether atomic swaps can be realistically executed between standard mooncoin wallet installations and standard Litecoin nodes.

Objective

The primary objective is to determine whether a minimal viable mooncoin-litecoin atomic swap can be implemented using standard full nodes and basic wallet functionality.

Specifically:

  • Validate that Mooncoin consensus rules can safely support HTLC-style scripts
  • Confirm compatibility with known litecoin atomic swap patterns
  • Define a deterministic swap flow with explicit timeout guarantees
  • Identify the smallest viable feature set for Mooncoin wallet support
  • Ensure compatibility with real-world mooncoin node operation

This work explicitly avoids:

  • Protocol modifications
  • Token wrapping
  • Custodial swap services
  • Trusted relayers

The intended result is a documented reference flow that can be reproduced by developers running independent Mooncoin and Litecoin nodes.

Technical Approach

The current approach follows the classical cross-chain HTLC design used in Bitcoin-family atomic swaps.

The swap model assumes:

  1. A shared secret S
  2. Hash commitment H = SHA256(S)
  3. Mooncoin HTLC output locked by H
  4. Litecoin HTLC output locked by H
  5. Coordinated timelocks allowing safe refunds

The standard swap sequence:

  1. Initiator generates secret S
  2. Initiator locks LTC into HTLC
  3. Counterparty verifies HTLC
  4. Counterparty locks MOON into HTLC
  5. Initiator redeems MOON revealing S
  6. Counterparty redeems LTC using S

Testing focuses on verifying that Mooncoin script evaluation behaves consistently with Litecoin for:

  • OP_SHA256
  • OP_EQUALVERIFY
  • OP_CHECKLOCKTIMEVERIFY
  • OP_CHECKSIG

Mooncoin’s Litecoin-derived consensus suggests compatibility, but script-level verification must be confirmed in practice rather than assumed.

A minimal test environment includes:

  • One Mooncoin full node
  • One Litecoin full node
  • RPC-enabled wallets
  • Manual transaction construction

Minimum Reproducible Test Checklist

Use this checklist to keep test results comparable across runs:

  • Mooncoin node and Litecoin node both fully synced before swap test starts
  • -txindex=1 enabled on both sides
  • RPC authentication verified on both nodes
  • Dedicated test UTXOs prepared and labeled for swap use
  • Explicit timelock parameters recorded before broadcasting HTLC transactions
  • Success criteria pre-defined:
    • Claim path succeeds on both chains, or
    • Refund path succeeds after timeout without manual chain intervention

Example Mooncoin node configuration:

mooncoind \
  -server=1 \
  -txindex=1 \
  -rpcuser=user \
  -rpcpassword=password \
  -rpcallowip=127.0.0.1

Example RPC interaction:

mooncoin-cli getblockchaininfo
mooncoin-cli getnewaddress
mooncoin-cli listunspent

Manual transaction assembly remains necessary during early research phases before automated swap tooling is considered.

What We Implemented / Verified

Current work has focused on validating assumptions rather than building production tools.

The following items have been confirmed or partially verified:

Validation Status (Explicit)

  • Verified: Mooncoin node RPC operation for transaction construction and inspection
  • Verified: Preliminary script primitive availability (OP_SHA256, CLTV-related flow assumptions, P2SH usage checks)
  • Partially Verified: HTLC script assembly workflow via raw transaction methods
  • Not Yet Verified: Full end-to-end claim + refund atomic swap cycle on Mooncoin-Litecoin pair
  • Not Yet Verified: Relay consistency for HTLC transactions across heterogeneous public peers

Node-Level Compatibility

  • Mooncoin nodes derived from Litecoin 0.21.4 operate correctly with standard RPC interfaces.
  • Transaction construction via RPC behaves as expected.
  • ScriptPubKey inspection works normally.

Script Assumptions

Preliminary checks indicate that Mooncoin supports:

  • SHA256 hash operations
  • Timelock primitives
  • Standard P2SH execution

However, full HTLC redemption and refund scenarios still require end-to-end validation.

Wallet Constraints

A key constraint is that the standard mooncoin wallet does not currently provide:

  • Native HTLC construction tools
  • Script templates
  • Automated refund tracking

This implies early implementations will likely depend on:

  • Raw transaction workflows
  • RPC-level scripting
  • External tooling

The possible role of electrum-style wallets is under evaluation. Lightweight clients could eventually provide better swap usability, but only if script compatibility is confirmed.

Example raw transaction workflow:

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

Signing example:

mooncoin-cli signrawtransactionwithwallet HEXSTRING
mooncoin-cli sendrawtransaction SIGNEDHEX

These commands represent the minimum viable workflow for testing atomic swap transactions on a Mooncoin node.

Consensus & Script Considerations

Atomic swaps rely on Hash Time Locked Contracts (HTLCs) that enforce two independent spending paths:

Claim Path (Hashlock)

Funds can be spent if the redeemer provides the secret S matching the committed hash H.

Refund Path (Timelock)

Funds return to the original owner after a timeout.

A simplified HTLC structure:

IF
    OP_SHA256 <H> OP_EQUALVERIFY
    <ReceiverPubKey> OP_CHECKSIG
ELSE
    <Locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <SenderPubKey> OP_CHECKSIG
ENDIF

Correct ordering of timelocks is critical:

  • LTC timelock > MOON timelock

This ensures the initiator can always recover LTC after a failed swap.

Key technical considerations include:

  • Absolute vs relative timelocks
  • Mempool policy compatibility
  • Standardness rules
  • Fee estimation reliability

Even if consensus rules allow a script, standard relay policy may reject transactions if they do not meet standard script templates.

This distinction is particularly important for Mooncoin because network relay policies may differ from Litecoin.

Risks and Open Questions

Several uncertainties remain.

Consensus Uncertainty

Even Litecoin-derived consensus does not guarantee identical script behavior.

Questions include:

  • Are Mooncoin standardness rules identical to Litecoin?
  • Are CLTV edge cases handled identically?
  • Will HTLC scripts relay consistently across Mooncoin nodes?

Wallet Limitations

The current Mooncoin wallet does not expose HTLC primitives.

Questions include:

  • Should HTLC construction live inside Mooncoin Core?
  • Is an external swap tool sufficient?
  • Should Electrum compatibility be prioritized?

Operational Risks

Atomic swaps require strict timing coordination.

Failure boundary example:

  • If the MOON-side timelock is configured too close to the practical confirmation window during high variance periods, the refund transaction may become operationally fragile.
  • In that case, the swap remains theoretically safe at the script level, but practically unsafe for routine users due to narrow reaction time.

Questions include:

  • How large should timelock safety margins be?
  • How does Mooncoin block variance affect refund safety?
  • What happens if one chain stalls temporarily?

Engineering Reflections

Several design decisions remain open:

  • Should the first production implementation depend entirely on raw RPC workflows, or should a minimal swap helper tool be developed first?
  • Is maintaining Litecoin script-level compatibility a strict requirement, or can Mooncoin define a slightly different HTLC template?
  • Does Mooncoin benefit more from Electrum-based swap tooling or full-node swap tooling?

Next Steps

The next phase focuses on reproducible swap execution tests.

Planned work includes:

  • Constructing complete HTLC transactions on Mooncoin
  • Testing full claim and refund paths
  • Verifying mempool acceptance
  • Measuring safe timelock intervals
  • Documenting reproducible procedures

Future development may include:

  • Minimal atomic swap reference scripts
  • Mooncoin wallet RPC helpers
  • Electrum compatibility testing
  • Automated swap test harness

The immediate goal is a deterministic reference procedure demonstrating that a Mooncoin node and a Litecoin node can complete a full atomic swap cycle without custodial infrastructure.