New · 17 OctoberLight-wallet swap on the public Litecoin testnet
No Litecoin node needed: on 17 October the app's own Litecoin light wallet paid the Litecoin side of an LTC/XMZ swap on the public Litecoin testnet, with no Litecoin node wallet involved. The app reviewed the payment, signed it without sending, sent it only after a separate approval, re-sent the identical transaction, and then saw it confirmed in a block through the light wallet. The XMZ lock, Litecoin redemption and XMZ payout followed, and every app check passed on its first attempt. Afterwards the light wallet held exactly its change: 0.25 tLTC funded, minus the 0.2 tLTC traded, minus a 0.00001 tLTC fee. The whole swap took 94 minutes.
Problem found and fixed: the app only offered light-wallet funding when the wallet was on a local test chain, so on testnet the option never appeared. It now follows the network chosen at startup.
Dropped connections now recover by themselves: if the connection between the two traders drops in the middle of a trade, the apps now reconnect on their own instead of waiting for a restart. They rebuild the trade session from what is saved on disk, the same steps an app restart takes, and retry at growing intervals. They also re-exchange the already signed refund agreement, so the trade carries on. Messages that fail a check still stop the trade, and nothing is retried in that case. If the drop happens during the final settlement messages, the apps repeat only the steps already under way before the drop: the funding proof, and a release the user had already approved for that same payment. No new approval is ever created, and a settlement that had finished stays finished. In tests the connection was cut on each side after both coins were locked, after the funding proof, and after the release, and once more during a refund. The apps reconnected within 33–54 seconds, and all six trades finished with every check passing on its first try.
Litecoin MWEB payments: Litecoin's private MWEB layer stores some transactions in an extended format that the light wallet could not read. So a payment out of an MWEB wallet into a light wallet, a common way to send Litecoin, would have stopped the light wallet from refreshing. The light wallet now reads these transactions while still checking every one against its block. On the public Litecoin testnet, 0.02 tLTC was sent from an MWEB-only wallet to a light wallet: the previous version failed to refresh, and the fixed version showed exactly 0.02 tLTC more.
Fast light-wallet startup: the light wallet used to check every Litecoin block header from the start of the chain each time it started, about 19 minutes on testnet. It now starts from a built-in checkpoint and, on restart, rechecks proof of work only for the most recent headers, while still checking that every saved header links to the one before it. A testnet sync now takes under a second and stores 230 KB instead of 394 MB. Mainnet still needs its own checkpoint.
New · 16 OctoberMonzero Pool is online
Mine XMZ together: the project now runs a public RandomX mining pool on the same server as the public node. Point XMRig at pool.monzero.org:3333 (CPUs and laptops) or :5555 (servers), with your own XMZ address as the username: xmrig -o pool.monzero.org:3333 -u YOUR_XMZ_ADDRESS -p rig1 -a rx/0. Live statistics are at pool.monzero.org.
How it pays: PPLNS with a 1% fee. Blocks are credited after 60 confirmations, and only if the chain still holds the exact block the pool found. Payouts are on: balances of 1 XMZ or more are paid every hour. The pool's first 14 blocks were credited to the atomic unit before payments were switched on.
Built for this chain: the pool was written for Monzero and checks every share with the node's own proof-of-work code. Tests on a private chain cover rejected shares, found blocks, orphaned blocks, exact reward splits and payments arriving in miners' wallets. A pool also lets Monzero be listed on mining statistics sites, and more independent miners make the network harder to attack.
New · 15–16 OctoberLTC/XMZ first, tested on moving chains
First market chosen: LTC/XMZ is the first pair we aim to open. Work on other pairs is paused until a small, capped test with invited testers is running.
Trades on chains that keep moving: a new test runs a whole trade between two running apps while both chains produce blocks on their own clock, as real networks do. Success and refund both passed, and every safety check passed on its first attempt. A separate regression run still rejects reorganised chains and actions taken too early.
Problems found and fixed: the connection between traders closed after five idle minutes, which would have ended every real trade before redemption; it is now kept alive. XMZ checks failed when the wallet briefly lagged its node or a block arrived mid-check; they now refresh and re-read a limited number of times, and every amount and depth rule is unchanged. A new Litecoin block during redemption release is now re-checked instead of failing.
Operator controls and recovery: a signed control document can pause new trades or cap their size, and trades already running keep their refund and recovery paths. The network is chosen at startup: local test chains by default, testnet on request, and mainnet cannot be selected. Each trade is kept in its own folder and reopens automatically. A step-by-step recovery guide covers every stage of a trade.
Testnet: the first LTC/XMZ swap on the public Litecoin testnet completed on 16 October, against a private XMZ test network, in 78 minutes. Both apps locked, redeemed and paid out on their own, with blocks arriving at the network's own pace, and every confirmation check passed on its first attempt. Two problems surfaced first and were fixed: the app accepted only local-test Litecoin addresses, and the test tool stopped on a momentary empty reply from the Litecoin node. That earlier attempt had already locked its Litecoin when the apps stopped, so it was recovered the way a user would: after the 72-block cancellation window, the saved trade was reopened and the Litecoin side approved the cancel and the refund. The refund returned exactly 0.1998 tLTC (the 0.2 tLTC lock minus the two agreed fees) to the agreed address.
New · 13–14 OctoberLight-wallet swaps and four light wallets
LTC/XMZ from a light wallet: the app’s Litecoin light wallet funded a full success path on isolated chains. The steps were approved funding, retry-safe submission, confirmation with reorganisation rejection, redemption, recovering and reopening the XMZ claim wallet, payout review and the final XMZ payout. Funding fees are accounted for on both chains. This uses node-backed test services.
Refunds and interruptions: the light-wallet refund path also passes, with the exact Litecoin balance returned to the local wallet and XMZ refunded. Recovery was accepted after an app restart after broadcast, a restart between signing and sending, a lost broadcast reply and the send helper being killed mid-relay. Each time the app retried the same signed bytes after fresh approval. Power-loss recovery is not yet tested.
BCH from the light wallet (14 October): the light wallet can now pay BCH P2SH32 contract addresses. The helper prepares, reviews and signs BCH/XMZ swap funding for both wallet formats, and Bitcoin Cash Node accepts the result. Broadcast, app integration and a complete BCH light-wallet swap are next.
One light wallet, four coins: the light-wallet core now supports Litecoin, Bitcoin, Bitcoin Cash and Dogecoin. 176 unit checks pass with none failed, and the original 153 Litecoin checks are unchanged. Each coin passes regtest receive/send tests against its real node software. In the app, each coin’s wallet can be created, reopened after restart, backed up and checked, and its recovery phrase revealed and hidden again. Mixing up coins is rejected. These are regtest results only. BCH and DOGE public-network header checks and Bitcoin testnet4 are not implemented, and no public light-wallet servers are running.
In developmentLitecoin / XMZ
Shared trade setup now connects startup, pinned peer negotiation, reservation, funding, redemption and recovered-payment controls. Each payment requires its own review and approval. Success and refund paths pass through the Qt bridge on isolated nodes. The same running engines now complete success and cancellation/refund paths, including recovered XMZ payments and fresh-app checks after restart. A separate mature punishment fixture verifies early rejection, exact payout, retry, reorganisation rejection and restart. Broader interruption and recovery acceptance remain outstanding.
The light-wallet mode is intended to work without a personal Litecoin node. Its private app controls now create an encrypted wallet, verify the initial backup and separately open the reviewed configuration. Saved wallets reopen without recreating keys. Users can receive, review exact payment amounts and fees, approve signing, explicitly send retained bytes and request a dated chain observation. Backup and restore cover seed and address allocations; they do not recover active trade journals. Isolated Litecoin-node tests fund newly created wallets, restore their keys, accept payments, handle a lost send reply and reject stale proof after a reorganisation. Light-wallet DEX funding now completes isolated success and refund paths (see the update above); public setup, active-trade backup and settlement without node-backed test services remain unfinished. Server observations cannot prove complete wallet history or global freshness. A local Litecoin Core wallet remains the planned advanced option.
Private funding controlsBitcoin Cash / XMZ
Latest verified progress: Authenticated payment-proof retention, restoration of the saved funding context, fresh XMZ confirmation checks and public settlement review now pass through production Qt workers and the real Rust helper against isolated BCH/XMZ chains. The accepted proof, observation and review changes are integrated into the engine. Saved receipts remain separate from current chain evidence, and a settlement review does not release funds.
Private XMZ deposit preparation and separately approved broadcast also pass paired-chain Qt/helper tests. Amounts use XMZ’s 11-decimal denomination: the 200,000,000,000-atom fixture deposit displays as 2 XMZ. The wallet builds, 70 interface checks and 55 DEX checks pass; 21 additional DEX cases require external fixtures and were skipped in that suite.
Private settlement preparation and saved-preparation status now pass paired-chain tests through the actual Qt workers and Rust helper, and both changes are integrated into the engine. Checks cover exact consent, unchanged records after rejected approval, identical preparation after restart and refusal when the chain observer is unavailable. Saved status works without node credentials; it reports historical records, not fresh chain confirmation.
Encrypted Qt identity signing now also passes an isolated paired-chain interoperability test: the engine rejects an invalid signature without changing records, accepts the correct signature after fresh checks of both chains and restores the identical signed message. This verifies the signing components, not a complete protected desktop signing session.
Separate signing and signed-release review panels are implemented, with explicit requests, exact amounts and fees, and stale-result clearing. The wallet build and 70 interface checks pass, alongside 85 protocol checks and 29 review-worker checks. These panels only review public details; they do not sign or release funds. Operation-specific consent and the public signing/release review helper now pass paired acceptance and are integrated, including the actual Qt review worker. Private signing-helper, parser and local-process components have focused test evidence; their complete protected desktop integration remains unfinished. Protected signing and peer transport, complete desktop settlement, broader recovery and public-market activation remain unfinished.
Earlier BCH funding and recovery milestones
The corrected controller snapshot completed with 50 passes and 8 optional tests skipped, covering negotiated funding, BCH settlement/refund and recovered XMZ payouts using offline cryptography and loopback RPC services. Preparation does not broadcast.
Agreement review, explicit admission and read-only restart checks now pass complete retained-negotiation fixtures through the Qt launcher and Rust helper for both roles, including expiry and altered consent. The app also reviews exact retained BCH funding, fees, destination scripts and recovery transaction IDs; a complete Qt/helper fixture passes with the mock node stopped before review. The wallet build, 20 admission checks, 65 funding-launcher checks, 82 preparation/locking/signing/recovery-launcher checks and 61 QML checks pass. Admission does not fund a trade, and funding review neither broadcasts nor checks the chain. Private app controls now require a saved-status check, fresh review and explicit consent before sending retained funding. Four complete Qt/helper fixtures verify one broadcast request, saved acknowledgement, refusal to resend after a lost reply, and historical status after expiry. Acknowledgement is not confirmation; saved status does not check the chain.
A separate node check now reports confirmed unspent funding, mempool status or absent funding through the actual Qt job and helper. It works after quote expiry, rejects changed transaction data and chain tips, and clears stale display evidence on a failed check. Saved relay history remains visible beside the point-in-time node result. Observation never authorizes another send or settlement. The corrected controller snapshot now passes. This archived result does not substitute for separate validation of newer app controls. Wallet-selected unsigned preparation now passes 22 local-RPC scenarios, including exact fees, change, parent transactions and input confirmations, without locking, signing or broadcasting. A complete local fixture now verifies retained wallet preparation: restart reuses the original inputs, changed policy or damaged records block progress, and an interrupted publication resumes without selecting replacements. Private app preparation controls now pass initial wallet selection, restart without reselection and offline saved-status checks through the Qt launcher and Rust helper. The panel shows every saved input and output and the exact fee. Startup only reads saved status; preparing funding requires an explicit click and does not lock coins, sign or broadcast. Separate wallet-lock controls now require a fresh review and explicit consent. Complete Qt/helper fixtures cover a lost lock reply, historical intent without automatic retry, and approved reconciliation of the original inputs without reselection. The panel separates saved intent from the latest wallet check; locks are advisory and do not authorize signing or broadcast. Separate signing controls now show the exact transaction and require fresh, explicit consent. Complete Qt/helper fixtures cover a lost signing reply, saved intent without a result, and refusal to create another signature. Recovery controls review and import the exact recovered transaction through Qt and the production helper with the RPC descriptor removed. Changed candidate files, altered transaction details and wrong approval are refused; recovery remains available after expiry. Importing the reviewed bytes neither signs again nor broadcasts. Startup only reads saved admission, peer protection, peer funding receipts, preparation, lock, signing, private recovery, funding and cancellation status. The native-funder app now reviews the authenticated peer funding message, showing the exact BCH outpoint, principal, fee and contract script before explicit acceptance. A real Qt/helper fixture passes, including saved receipt status after removal of the peer message. Saving a receipt neither confirms the BCH lock nor approves an XMZ payment. Shared operation guards prevent overlapping BCH actions; the DEX regression run passes 52 checks with 21 external-fixture skips. New isolated BCHN tests verify covenant spends, recovery success/refund/punishment, exact recipient amounts, restart and reorganisation handling. Production chain observation passes 45 node-backed checks. A real-node funding fixture now uses the production controller for preparation, input locking, signing and relay. BCHN accepts and confirms the transaction with 100,000 atoms locked and a 235-atom fee. The controller restores the same saved transaction, and its confirmation survives a node restart. A second real-node fixture passes the authenticated funding handoff: it rejects the wrong peer signature, restores the same receipt after restart, refuses native funding while BCH is unconfirmed and accepts the confirmed lock. It then rejects funding as the cancellation boundary approaches. A paired-chain funding fixture now also passes production XMZ deposit preparation, approved relay, authenticated proof and incoming-payment confirmation in the negotiated shared wallet. Independent accounting records both funding fees, and the BCH confirmation survives a node restart. The next paired fixture also passes approved BCH redemption and recovery of the negotiated XMZ spend key from the confirmed transaction. It verifies a 99,000-atom BCH recipient output, a 1,000-atom redemption fee, refusal before confirmation and exact transaction recovery after node restart. The complete controller success path now passes on both isolated chains, including claim-wallet restore and reopen, separately approved XMZ payout and independent recipient balances. The recipient receives 100,000,000,000 XMZ atoms; 99,042,560,000 atoms return from the reserve and 957,440,000 atoms pay the payout fee. The recovered wallet is empty. The separate native funding fee is also accounted for. This is controller acceptance; complete app settlement, broader recovery and live-market readiness remain unfinished. The app now has separate peer refund-protection review and consent controls, with 22 worker checks and 61 QML checks passing. A complete retained-negotiation fixture now verifies acceptance through the Qt worker and real helper, then recovery of the identical receipt in a fresh process without the peer-message file. Saving protection neither funds the trade nor proves complete recovery readiness.
The app now separately reviews and retains the private recovery bundle before funding. A complete Qt/real-helper fixture verifies approved retention and recovery of the same saved bundle in a fresh process. Direct helper tests also verify exact retry, recovery after an interrupted metadata-pin write and rejection of damaged snapshots. Only public transaction IDs and commitments enter the interface; private refund bytes stay private.
Cancellation controls now show the exact transaction and BCH fee, require separate submission consent and distinguish saved acknowledgement from a fresh chain check. The real helper passes acknowledged and lost-reply cancellation cases against an owned loopback RPC fixture, including maturity refusal, one relay request only and exact confirmation checks. The cancellation worker and protocol validators pass 29 checks, and the app passes 61 QML checks. The combined cancellation Qt/real-helper fixture now passes, including one relay request, lost-reply recovery, refusal to resend and exact confirmation checks. Cancellation does not release a refund or complete the XMZ payment. New refund controls show the exact amount, fee, destination and safety margin and require consent explaining the effect on the peer’s XMZ recovery. Offline review and saved status pass through the production Qt worker and real helper. Refund relay now passes through the production Qt worker and real helper against an owned loopback RPC fixture: spent-output refusal, exact approval, acknowledgement and lost-reply recovery, no automatic resubmission, changed-margin rejection and exact confirmation checks. Full two-chain recovery remains unfinished. Protected peer transport, complete recovery and settlement controls, broader interruption recovery and full authenticated BCH/XMZ execution remain unfinished; this market stays disabled.
Dogecoin
Two isolated Dogecoin node fixtures now verify timelock/refund transactions and production chain observation, including unspent-to-spent transitions, exact refunds, restart and reorganisation handling. One uses the engine signer and one independently constructs its refund. New checks show that another valid legacy funding signature can change the transaction ID and invalidate a previously signed refund. A complete DOGE/XMZ protocol must resolve this before trading can be enabled.
Settlement pendingEthereum
Previews preserve 18-decimal precision and large wei amounts. Contract settlement, gas and nonce management, recovery and contract tests are still required.
Direct-pair researchXMZ / XMR
Twelve-decimal previews are available. Direct XMZ/XMR feasibility and recovery are under review; BTC-intermediary route work is paused pending route-design clarification. No direct pair or intermediary route is executable yet.
Route implementation pendingNative RUNE
Eight-decimal previews target native THORChain RUNE. Explicit routing is approved; route execution, chain integration and recovery remain unfinished.
Existing foundationBitcoin / XMZ
Existing settlement and recovery work remains the foundation. New market previews cannot reuse its signing authority. Complete GUI execution and release acceptance are still required.
Evidence spans 5–16 October 2026. BCH counts describe an archived controller snapshot; newer app and node-backed milestones have separate results. The complete BCH/XMZ controller success path passes against isolated chains, including final payout. Full desktop settlement, protected transport and broader recovery remain unfinished. After earlier incomplete runs, fresh Litecoin continuous success and refund fixtures passed with final reports. These results do not establish complete recovery coverage or live-market readiness. This update announces no new downloadable release, independent security audit or real-money market. Earlier BTC/XMZ evidence is retained below as a dated historical checkpoint.