We are continuing to finish out the private-transfer prototype after a week of sustained development and testing. Since our last update, the work has moved beyond the offline test chain: a complete two-wallet transfer and recovery rehearsal has passed on public Monero stagenet.
Our focus remains making XMR20 tokens easy to hold and move on native Monero. We are bringing the transfer, fee-review and recovery pieces together, testing how they behave across different wallet applications and publishing more of the implementation for developers to explore. These are research milestones using test funds; independent security review and production preparation remain separate steps before public use.
A complete private-transfer rehearsal on Monero stagenet
24 October
The latest rehearsal completed 57 steps on Monero stagenet, the public test network. It followed test-token credits into a transfer between two wallets, recovery of both wallets in fresh instances, and further transfers from those recovered wallets.
The run exercised transfers using one, three and two token inputs, with the expected change and balances checked at each stage. Each holder paid the native transaction fee from their own test XMR, with the fee shown before approval and the final deduction matching the quoted amount.
The Monero transactions carrying the token records were accepted with the daemon’s normal sanity checks enabled. A third-party public stagenet node observed the transactions and their ten confirmations. Re-sending the same signed transaction was recognised as already known, without a second payment.
This gives us evidence of the connected transfer-and-recovery workflow operating on a public test network, building directly on the isolated testing covered in our previous edition.
What we checked
The completed stagenet rehearsal records 57 steps with zero failures, exact token accounting, recovery of both wallets, three holder-funded transfers and third-party confirmation checks. It used worthless faucet coins and experimental parameters. Stagenet results are distinct from mainnet measurements or an independent security audit.
Who can read a private transfer?
24 October
Think of a private token note as a locked message. Everyone can see the message on-chain, but the receiving wallet uses its matching viewing key to read the token and amount inside. Try the example below.
One message. Who can open it?
Try the three views, or play the explanation.
Inspect the sample’s encrypted bytes
Loading sample…How your wallet gets the key
The sender locks the note using your public address and a one-time secret. Your wallet can recreate the matching key:
The public data is only part of the puzzle. The recipient’s private viewing key is not published on the blockchain.
Key derivation illustrated. Viewing access can be shared by choice.
Visible message. Hidden details.
- Token
- Hidden
- Amount
- Hidden
Anyone can see the encrypted message. Without the matching key, the token and amount stay hidden.
Sample tokens and public demo keys. The key-derivation steps are illustrated; decryption of the sample is real. No wallet connection, and no decryption of the stagenet transaction below.
The key point: seeing a transaction is different from reading its token details. Encryption protects the note’s contents. Zero-knowledge proofs let the token system check the transfer’s rules without publishing those hidden details.
Anyone given the appropriate viewing key can also read the notes it covers; viewing access alone does not let them spend. The sender already knows what they sent. Transaction timing and fees remain public.
Below the demo is a real transfer from our successful stagenet rehearsal, confirmed in block 2,235,805. Its public tx_extra contains a 996-byte XM3 token record. You can inspect those bytes and open the explorer without any wallet key.
How it works: the technical detail
The prototype uses Penumbra-derived shielded notes. Each note encrypts its token asset and amount with ChaCha20-Poly1305. The wallet derives the note’s encryption key using decaf377 key agreement and a BLAKE2b-based key derivation step.
Commitments refer to notes and values without revealing their contents. Groth16 zero-knowledge proofs check hidden spend and output relationships. Authorization and binding signatures establish permission to spend and conservation of value; public nullifiers prevent a note being spent twice.
The interactive example performs real authenticated encryption/decryption on a synthetic note, using the same ChaCha20-Poly1305 cipher and note-byte layout. Its demo keys are deliberately public. It illustrates opening a note, not the complete wallet: real key derivation, note commitment checks and proof verification are outside this demo. It does not decrypt the stagenet transaction.
Monero validates the native transaction; XMR20 verifiers check the additional token rules. XM3 transfer records do not publish clear-text token amounts, asset identifiers or token sender/recipient addresses. Timing, fees, record type, commitments, nullifiers and proofs remain public. Deposit and redemption records have different disclosure rules. This experimental composition still needs independent security review and production parameters.
A confirmed private-token test transfer
Monero stagenet · Block 2,235,805 · Test funds
Transaction IDc7d959f9f4d75de7fa43f8c3864a09f22778d1293f29ea1b4d77f9a4f00d981f
- Public tx_extra
- 1,056 bytes
- XM3 token record
- 996 bytes
Inside the encrypted note
First 32 bytes of the first output’s 112-byte ciphertext:
81bc7a2aaf908fc2d731144c081b605af4fb4cf3bbdab1086440cf7ddad1785fThe full record also contains public commitments, nullifiers, keys, signatures and a zero-knowledge proof. Not every byte below is encrypted.
View full public tx_extra (1,056 bytes)
01b96183abc3c063ccbcba2e96af9f452f3e57c1110501072bcd56585c83849e
69020901e2bf0d97583cd30c02ff017f584d33fe1a29080e1d7d32931a410499
dd64a11d6d02e40939dd66bd9bb7c887a642840c2cc719407da1fe4efd7c0a9f
a1698254629a79b25b49a3ed52eb2c82853030057c2904a044fe59f28b137fba
c360da6c4a4d251a4146b8b0187d365456611e048eb4470e62cf4df08bb92cb1
a9289de889468edcd0f8df9d1fe02c27db2c25050d1c1c7cdca169143e086dd4
353b266cd23b3bea3c67c1c8733c0f7a5a5ae310745d11f0b93d28195d7915b1
22c9500e967b7bf3521a837039211532cad66a01a373d77e5b7c2ec5b1039677
3ca5005a0747a8ba35e66a5c59d9fdea95f6fb08fcfbd7682e0d1f41f91d00fa
11211602ee68757b34e5735c005d02ff017f56241b49791264630f7f916828da
df3128c2458f78eef21ad02d9810393bf862f10a3b869e0e58b347aa42ca7d5d
995c5355d6700c865373a483fa7751f760fdcec609f78a120e7a750244da2f75
2280e6feb12a417dcc745f2f92a2077cf5205fb7c126150481bc7a2aaf908fc2
d731144c081b605af4fb4cf3bbdab1086440cf7ddad1785fd0559b45b080d500
dd7a14f81ace1a12f628a7306f629ae575f629607f91b147b4a0f4cd617fafe2
8a4e216245ca2553faaef56b694faeb6c8cb48765367ecd42504bdc6e25a39a4
fe209bc1f59b542514eb15d0748ce9026e1cb19ec53800ec1a9eb52a22109121
18fcde628a571c0963a06abe00558d1802ff017f6bc33fa3db7b5b34a48baaac
474c5217c7d1d3e92d4215046cde8f6d7c6d9ec2c47e63c3a3250828834d6866
0fdab95823bc60c8eabc48093ba3e97ea919699541ea23b4e1e2ef51ce0ee541
f0fcfa2c3c94b56f0c6068a0914a774fa93b7f1e9dbac73609312be978662325
67aefe18ec6d7f61c9781bf17a3f0e85e0aa89535c9ea40ef7223e6697a43823
6c07497a6ed887b04171783fe3e509e6c95c5309fc301b5698a300d848941018
a99a3b9c5af03b0a13c85e31c01e8a846f49ebe950f8cbc0759aff02f9cc020c
891e2d7bdf5a6f199b9880f15ed8a81295dab94c5b05f728cd846c02a9fcf86c
43466094034c98142a3af04b322bf131be8f02eb017f04de2d649efda1a7c877
038d7be658d0ab43d6ab2eeeaaa313814006c1cfe43e6ecae44e1394d9bfcd15
a445a9d6416c983097dc127b6ede1eb916ecf8dacd6fa53fcb8fb5c43f9f5200
4de59f8a924f318536e21d15cf5996a4093982f2f44ad10f06b14532e2847160
4455b7382f689c8b943bf98971ba91012214eb153af2a7e32a95ca57776670e9
3277ffa6fe75febd2585cc4819aea9616b5271d83d64e6ade6be1e616db21400
2eac11cca51eeb6c7e786dfe56696114955b6d4b4f14542193fcf831fe42af10
053a1146523786e318dc071929763251a5924f138a21bea7dfbd4c4f64d61800What we checked
The public explorer and two stagenet nodes returned matching tx_extra bytes for this confirmed transaction. Decoding those bytes yields a 996-byte XM3 record inside 1,056 bytes of tx_extra: a public transaction key, an encrypted payment ID and four application-record chunks. The first output contains a 112-byte encrypted note ciphertext. These checks establish the example’s provenance and format; they do not independently establish cryptographic security.
Testing the moments between sending and confirmation
24 October
A dependable transfer experience includes being able to return to an operation after closing a wallet or losing a network response. The latest offline recovery suite passed all 76 checks, using separate wallet processes and deliberately interrupted requests to exercise those moments.
The tests covered restarts after fee review, proof generation and signing, as well as a send whose reply never reached the wallet. They checked the transaction’s actual chain status before retrying and, when a retry was needed, reused the saved signed transaction.
Additional cases exercised older backups, two installations using the same account and recovery after a simulated chain rollback. The checks followed token balances, recipient credit and network-fee accounting through to the recorded outcome.
These results belong to the reference holder process. They provide a tested foundation for bringing the same recovery behaviour into the extension’s popup flow. A separate public-stagenet recovery run is also underway; its final results will be reported once complete.
What we checked
The offline recovery suite completed with 76/76 checks. Supporting checks passed for transaction recovery (6/6), network-role behaviour (4/4) and the six-transfer carrier engine run. Simulated rollbacks and concurrent-installation cases were exercised offline; this edition does not count the additional stagenet recovery run as complete.
Private test tokens moving between the extension and CLI
23 October follow-up
Work completed after our previous update demonstrated the extension and an experimental CLI wallet exchanging private test tokens in both directions. The test used the actual extension popup alongside the command-line application, with both reading the same test-token pool.
The flow covered one-, two- and three-input transfers with exact change, the CLI paying its own transaction fees, and restoring the extension’s account in the CLI from the same recovery phrase. It also exercised optional viewing-only access.
The accompanying work includes a versioned experimental specification, a small wallet library and portable synthetic test vectors. A separate decoder written from the specification passed 42 checks for the record formats and other rules it implements. The extension and CLI share the same cryptographic engine; the decoder provides additional format checks rather than a second implementation of the proof system.
What we checked
The final extension-to-CLI run passed, with eight token records admitted by the shared test indexer. The separate decoder passed 42/42 checks and the host suite passed 10/10. These are isolated research tools and compatibility checks, not a production CLI release.
More of the research and wallet source is now on GitHub
23–24 October
We have continued pushing source, tests and documentation to the public XMR20 repository. Draft PR #8 now brings together the experimental private-token implementation, wallet library, CLI, specification and recorded stagenet results, alongside material prepared for a future independent security review.
Draft PR #9 adds the website wallet source: connection and balance screens, the Monero tab, SOL ↔ XMR exchange integration and the shared bridge pages used by the extension and website. Its published test results include 54 website-wallet unit tests, 29 bridge-browser steps and eight swap-browser steps, all passing in local fixtures.
That builds on the recent wallet 0.1.96 source publication in draft PR #7, covering saved-bridge controls and transaction progress. Together, these submissions give developers more of the code and verification material behind the work we describe in these updates.
All three pull requests remain open drafts. Publishing the source makes the work inspectable; merging and releasing each feature are separate milestones.
What we checked
GitHub confirms PRs #7, #8 and #9 are open drafts. PR #8 includes the completed public-stagenet rehearsal. PR #9 reports 554 existing repository tests and 54 website-wallet tests passing, a successful build, and passing bridge/swap browser fixtures. The newest offline recovery results are taken from the local research report and are not represented here as already pushed to GitHub.
Evidence & release status
This edition covers completed work since Edition 04 and the latest recorded checks on 24 October. It distinguishes the completed 57-step public-stagenet rehearsal, the 76-check offline recovery suite, isolated extension/CLI compatibility tests and public draft pull requests. The separate stagenet recovery run is still in progress in the reviewed evidence. Passing tests support development progress; production parameters, independent security review and integration are separate requirements. Private-token bridge payouts and native XMR trading are not enabled by these research milestones.
| Workstream | Recorded state |
|---|---|
| Private transfers | Public stagenet rehearsal · passed |
| Inside a private transfer | Confirmed stagenet example |
| Recovery testing | Offline recovery suite · 76/76 passed |
| Wallet compatibility | Extension ↔ CLI test · passed |
| GitHub progress | More source published · draft PRs open |
What comes next
We are working through the remaining pieces of the private-transfer prototype with a growing body of successful tests: public-network transfers, restored wallets, recovery scenarios and compatibility across applications. Alongside that work, we are making more of the source and evidence available on GitHub so the community can follow the progress in detail.
Back to all updates