XMR20alphaminingexplorerupdatesdocs
All updates
Edition 04

Bringing private XMR20 transfers into the wallet.

After a week of extensive development and testing, private XMR20 transfers are coming together into a more complete wallet experience.

Over the past week, we have spent substantial time building and testing private transfers for XMR20 tokens on native Monero. That work is bringing us closer to completing the prototype’s end-to-end wallet workflow: finding your tokens, preparing a private transfer, reviewing the network fee and signing the transaction.

Our focus is practical: give people an easy way to hold and move XMR20 tokens on native Monero, laying the foundations for trading on Monero Market. The latest milestones build on that sustained work, with transfers, recovery and proof validation exercised in an isolated research wallet using synthetic funds and an offline test chain. Independent review and production integration remain separate steps before a public release.

Private transfers, prepared inside your wallet

Overnight into 23 October

The research extension now derives the holder’s token keys, scans the test chain, recognises incoming tokens and prepares transfer proofs inside the wallet. This moves the holder’s private token state and spending logic into the extension, giving the wallet a central role in the transfer process.

The prototype is designed around private token balances by default. In its test deposit flow, tokens arrive directly at the holder’s private token address, without an additional shielding step. Existing-format balances have a separate, explicit migration flow.

Recorded browser tests followed the complete research journey: a test deposit, private credit, a transfer to another wallet, migration and redemption. The same wallet also demonstrated combining several pieces of a token balance to prepare a larger send.

What we checked

The overnight holder-wallet report records completed browser flow, recovery and saved-operation suites. A subsequent parameter-authenticated build repeated the full browser flow successfully on 23 October. These runs used disposable wallets, synthetic funds and isolated test services.

Next: Continue bringing the private-transfer workflow together with the familiar wallet experience and preparing the design for specialist review.

Signing and funding transfers from the holder’s wallet

23 October

A major part of today’s work connects the private token record to the Monero transaction that carries it. In this prototype, the holder’s wallet builds and signs that transaction, pays its network fee from the holder’s own XMR and submits it directly to the test-chain daemon.

The flow is being built around a clear fee review before proof generation and submission. The holder can see the XMR needed for the network fee and approve or cancel. Token amounts and the XMR network fee remain distinct parts of the transaction.

Completed engine checks exercised transfers using one, two and three token inputs, with the expected token change reaching the sender. They also covered redemption, restoration of native wallet state and resubmission of the same saved transaction with a single fee. This is a concrete step toward letting the wallet manage the full native transfer lifecycle.

What we checked

The holder-funded transaction engine run completed in the isolated Monero environment. Its results record six transfers, native transaction acceptance and mining, token-record admission, exact fee accounting and a redemption. Browser integration is a separate validation stage; test-chain fees are not mainnet fee estimates.

Next: Complete the browser validation of the holder-funded flow, then evaluate integration and real-network transaction requirements.

Recovering tokens in a fresh wallet installation

23 October

Private transfers need a recovery experience people can rely on. In the recorded tests, a completely fresh extension profile recovered the same private token address, balance and confirmed token history from the recovery phrase, the prototype’s public parameters and the test chain. No wallet database was copied into the new profile.

The restored wallet then spent tokens recovered from the chain, demonstrating recovery through to a usable balance. This check was repeated with the parameter-authenticated build later today.

The research wallet also includes explicit viewing-key sharing. In the tested flow, the holder chose to grant visibility into the token balance without granting spending authority. That keeps optional viewing access a deliberate action by the holder.

What we checked

Completed fresh-profile browser runs reproduced the confirmed balance and spent/unspent token records, then spent recovered tokens. Separate checks covered account separation and view-only access. Confirmed on-chain recovery and resuming unpublished operations from the original encrypted journal are distinct workflows.

Next: Keep testing recovery and optional viewing access as the native transaction flow develops.

Checking the proof material before it is used

23 October

Today’s work also added checks around the public material used to generate and verify proofs. The candidate build includes a versioned manifest that identifies its expected proving keys, public parameters and test ledger.

The wallet checks downloaded and cached material against that manifest before using it. Browser tests exercised both a fresh download and reuse of a verified local cache, followed by successful private transfers.

These checks help make the research build reproducible: the wallet can establish that it is using the exact proof material expected by that build. The current material comes from a disposable test setup; reviewed circuits and a production setup are separate milestones.

What we checked

The parameter-authentication report records passing loader and engine checks, 561 extension tests, a dedicated browser parameter suite, the full browser transfer flow and fresh-profile recovery. The checks included rejecting altered or mismatched material before use.

Next: Build on the recorded evidence to support independent cryptographic review and a reviewed production parameter setup.

Evidence & release status

This edition covers research completed overnight into 23 October and during 23 October. It draws on the saved holder-wallet, parameter-authentication and holder-funded transaction reports. The results describe specific isolated runs, not a production release or an independent security audit. This research does not change the privacy properties of today’s live XMR20 tokens.

WorkstreamRecorded state
Private transfersResearch wallet · tested locally
Native XMR transactionsHolder-funded prototype · engine checks passed
Recovery and viewingFresh-install recovery · browser verified
Proof validationParameter authentication · checks passed

What comes next

A week of development and extensive testing is bringing these pieces together into a more complete private-transfer prototype: discover tokens, prepare a proof, review the XMR fee, sign, send and recover confirmed balances. Our next focus is completing and validating that connected wallet experience.

Back to all updates