The private-transfer work is coming together inside the wallet. After the sustained development and testing covered in our recent updates, we have now completed private test-token transfers through the actual Chrome wallet popup on public Monero stagenet, including restoring both accounts in fresh installations.
Since Edition 05, we have also completed the additional stagenet recovery run, brought the wallet and CLI into a common integration test suite, and tested a migration path for tokens already launched through XMR20. Alongside that research, the website wallet has gained more native-token controls and the launch page has a new interface.
Our focus is making XMR20 tokens straightforward to hold and move on native Monero, building the wallet experience that can support native trading on Monero Market. The private-transfer work described here is experimental and uses test funds; independent security review and production preparation remain separate steps before public use.
Private transfers through the actual wallet popup
24–25 October follow-up
The dedicated stagenet build of the Chrome wallet completed a full run with two fresh test accounts. Private test tokens moved between them through the actual popup, with the expected token change and exact native XMR fees checked along the way. Both transfer transactions were confirmed through a third-party stagenet node.
We also tested the everyday parts of using a wallet: closing and reopening it, locking and unlocking it, and restoring each account in a fresh installation. The recovered accounts showed the expected balances. Reopening the wallet did not trigger another send.
When a test deliberately withheld the network’s reply after a send, the wallet found the transaction already on the network and continued tracking it without sending it again. This is the kind of behaviour that makes a transfer feel dependable from approval through confirmation.
This milestone uses a separate extension labelled for stagenet and test funds. It brings the private-transfer prototype into the real popup interface while keeping the research build separate from the everyday wallet.
What we checked
The public-stagenet popup run completed on 24 October, 17:50–20:00 UTC. It checked two transfers, exact token balances and native fees, third-party confirmations, recovery after a missing reply, and fresh-installation recovery of both accounts. The results are published in draft PR #10. This was a test-fund run, not a mainnet release.
The recovery run is complete, and the components are being tested together
24–25 October
The additional stagenet recovery run that was still underway in Edition 05 has now finished with all 57 checks passing. This is a separate set of recovery checks from the earlier 57-step transfer rehearsal. It followed interrupted operations and wallet restarts through to their final balances and transaction fees.
On 25 October, we completed an integrated research test suite bringing together the browser popup, the experimental CLI, transaction records, wallet recovery and token migration. Testing these pieces together gives us a clearer picture of how the complete workflow behaves.
The combined checks include transfers between the popup and CLI, exact token change, recovery of the same account across applications and viewing-only access. We also checked that an indexer rebuilt from chain history reaches the same token state as one that has been running continuously through the tested scenarios.
The extension and CLI continue to share one cryptographic engine. The benefit here is consistency across the two applications and the surrounding token services as we finish integrating the prototype.
What we checked
The additional public-stagenet recovery run completed 57/57 checks on 24 October at 13:00 UTC. The 25 October integration report records 19/19 test groups: 17 executed on the recorded build and two reused with matching recorded input hashes. That integration suite uses simulated chains and includes checks that deliberately reproduce settlement scenarios still under evaluation; passing the suite is not a production-readiness verdict. The public-stagenet results are separate, retained runs.
Building the private-token path for existing holders
24–25 October
Private transfers need a practical path for tokens already launched through XMR20. We are testing one migration rule driven by the token catalog, rather than a separate implementation for every token. Each asset is identified by its mint address, so tokens that happen to share a ticker remain distinct.
The simulated tests exercised five selected existing tokens and one token added after the test service had started. They checked the migration claim, recovery of an interrupted claim, prevention of a second credit, a private transfer with exact change and redemption using the same token identity.
In the test, a legacy entitlement of 10,000 tokens became exactly 10,000 private tokens. Migration preserved the full entitlement without applying another bridge tax; the test issuer paid the migration credit’s Monero transaction fee. Subsequent deposits and redemptions followed each token’s own fee setting.
We also checked asset identifiers and metadata across all 66 entries in the catalog snapshot. The full simulated migration journeys covered the six selected cases, giving us a common path to build on as we prepare the production integration. No real holder balances were migrated.
What we checked
The candidate records successful end-to-end simulation for five selected existing mints plus one added after startup, using synthetic holdings. Asset identity and metadata checks cover the 66-entry catalog snapshot. Exact entitlement, duplicate-claim prevention and per-token fee accounting were verified. Real cutover snapshots and integration with the production indexer remain future work.
More wallet controls and a clearer launch experience
24 October, after Edition 05
The website wallet now includes Monero token Send and Bridge to Solana controls, bringing more of the wallet experience directly into xmr20.org. This is a separate website release from the experimental private-transfer work above.
Captured from the live launch page on 25 October. Clearer launch choices, token setup and a transaction summary, with real inscriptions in the background.
The launch page has also been refreshed with clearer mode cards, a form alongside its transaction summary and an itemised estimated cost breakdown. A background feed draws on real inscriptions, connecting the page to the activity already happening across XMR20.
The interface was checked at desktop and mobile sizes. This release improves how the existing launch choices and costs are presented; the availability of each launch mode continues to follow its existing service controls.
What we checked
The website wallet update and subsequent launch redesign were promoted after Edition 05. The live deployment and sampled public files match the recorded release. Wallet checks include 29 bridge/send browser-fixture steps and eight swap-fixture steps; the launch work records 286 passing tests and desktop/mobile browser checks. These interface checks do not establish a funded website send, bridge or launch.
More code, test results and build details on GitHub
24–25 October
We have published two more draft pull requests since the previous update. PR #10 contains the separate stagenet test wallet, its popup integration and the completed public-network results. PR #11 builds on that work with the integrated candidate, migration rules, test reports and a documented release checklist.
We also rebuilt the four compiled components used in the research tests from their recorded source and toolchains, reproducing the same bytes on the development machine. The build recipe and results give reviewers a clearer connection between the source and the components behind the recorded tests.
These public submissions make more of the work available for developers to inspect and follow. Both remain open drafts: publication of the research is a milestone of its own, with independent review and production release still separate steps.
What we checked
GitHub confirms PRs #10 and #11 are public, open drafts and unmerged. PR #11 includes the integration report and build recipe. All four recorded components reproduced byte-for-byte on the same machine and recorded paths; this is not an independent or path-independent rebuild, and the four rebuilt binaries and private wallet material were not published.
Evidence & release status
This edition covers work completed after Edition 05 on 24 October and recorded progress on 25 October. Public-stagenet wallet and recovery runs, simulated integration/migration checks, public draft pull requests and live website interface changes are identified separately. Private transfers remain experimental; production proof parameters, independent security review and settlement decisions remain outstanding. Private-token bridge payouts and native XMR trading are not enabled by these research milestones. Website interface verification did not include funded send, bridge or launch operations.
| Workstream | Recorded state |
|---|---|
| Private transfers | Chrome popup on public stagenet · passed |
| Testing progress | Recovery run complete · integrated checks recorded |
| Existing tokens | Common migration path · simulation passed |
| Website progress | Website wallet and launch interface · live |
| Open source | Two new public draft PRs |
What comes next
The pieces are coming together: private transfers in the actual wallet interface, successful public-network recovery checks, a common migration path under test and more of the code available for the community to inspect. We are continuing to finish the integration around an experience that makes native XMR20 tokens easier to hold, move and eventually trade.
Back to all updates