# Dev Update 23 Sep 2025 **URL:** \ **Category:** News and Announcements\ **Tags:** dev-updates\ **Created:** [September 23, 2025, 5:28am UTC](https://talk.neptune.cash/t/dev-update-23-sep-2025/108 "2025-09-23T05:28:38Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![danda](https://talk.neptune.cash/letter_avatar_proxy/v4/letter/d/b19c9b/32.png) [@danda](https://talk.neptune.cash/u/danda)\ **Post date:** [September 23, 2025, 5:28am UTC](https://talk.neptune.cash/t/dev-update-23-sep-2025/108/1 "2025-09-23T05:28:39Z")
![neptune-banner](https://talk.neptune.cash/uploads/default/original/1X/3e76822acc7dcfcb498d95fe5340996dc945ea98.jpeg) ### Last week by the numbers **neptune-core** - [12 commits to master branch](https://github.com/Neptune-Crypto/neptune-core/commits/master/?since=2025-09-14&until=2025-09-21) - [4 issues closed](https://github.com/Neptune-Crypto/neptune-core/issues?q=is:issue+state:closed+closed:2025-09-14..2025-09-21) - [3 pull requests raised](https://github.com/Neptune-Crypto/neptune-core/issues?q=is:pr+created:2025-09-14..2025-09-21) - [4 pull requests merged](https://github.com/Neptune-Crypto/neptune-core/issues?q=is:pr+merged:2025-09-14..2025-09-21) **neptune-proton** - [24 commits to master branch](https://github.com/Neptune-Crypto/neptune-proton/commits/master/?since=2025-09-14&until=2025-09-21) ## Neptune Happenings This week was all about wallet development. ### QR Codes in neptune-proton wallet. @danda added a prototype implementation of QR codes to [neptune-proton](https://github.com/Neptune-Crypto/neptune-proton) this week. Both Generation Addresses and symmetric key “addresses” are supported. _important: symmetric key “addresses” are only intended for sending to self, since anyone with the key can spend the funds. They are normally used as change addresses since they require much less blockchain space for the associated announcement._ Neptune’s default address-type is called a _Generation Address_. These addresses, when bech32m encoded, are over 3600 ascii (7-bit) chars. This barely fits into the very largest QR code level (level 40) at the lowest level of error correction. In preliminary testing, it was determined that some typical laptop webcams do not have sufficient resolution to reliably read addresses encoded in this manner. Another solution is needed. Two primary options present themselves: 1. JabCodes. a barcode format that uses color and can encode much more data. 2. Animated QR. break the data into multiple QR images displayed in sequence. Unfortunately JabCodes do not presently have a pure rust implementation, which means they cannot be compiled for wasm32, which the neptune-proton wallet uses for the web platform. This leaves Animated QR as the easiest solution to implement, at least for now. The custom implementation for neptune-proton creates animated SVG files. SVG is chosen (over PNG) because it is a vector format that scales well to any display size on any device. Modern web browsers are able to display animated SVG files correctly. #### Future work 1. It seems worthwhile to refactor and extract some of the QR generation and scanning code into its own rust crate. This would be useful for anyone working on a neptune wallet. 2. Determine optimal chunk size, number of frames, and time per frame for a generation address. Present values are somewhat arbitrary. Not critical since scanning works with any sensible variation. 3. Evaluate if it makes sense to conform to either of these animated QR formats created in the bitcoin ecosystem: - [BBQr - Better Bitcoin QR | BBQr](https://bbqr.org/BBQr.html) - [Animated QRs - Developer Resources](https://developer.blockchaincommons.com/animated-qrs/) ### VxBlocks Wallet merged PR for compatibility with neptune-core 0.3.0 plus. (post chain reset) The blockchain reset introduced functionality in neptune-core (including block-proof in the block’s hash) that broke the [VxBlocks Wallet](https://github.com/VxBlocks/neptune-wallet-app). @sword-smith looked into the matter and was able to provide a fix. He also implemented a privacy-preserving method for the wallet to request membership proofs from the server without leaking privacy or amount information, by sending only the absolute index set, which is data that would eventually appear on the blockchain anyway. Anyone interested in the details can have a look at the PR: > > > 1. Upgrade to latest \`neptune-core\` wallet server that can be found on \ > 1. Switch from \`Block\` data types to \`ExportedBlock\` to allow block hash calculation without the block proof. > 2. Upstream renamed \`UtxoNotifyMethod\` to \`UtxoNotificationMethod\`. > 3. Drop unnecessary \`RpcBlock\` abstraction, rely on \`ExportedBlock\` instead. > 4. Use new mutator set membership proof recovery endpoint that does not leak privacy > 2. Format imports > 3. Delete some unused code > 5. Avoid removal record maintenance in wallet state updater. This maintenance is only needed if you want to maintain membership proofs \*without\* access to a mutator set archival state. This wallet gets its membership proofs from the server which is assumed to maintain a mutator set archival state. > 6. Upgrade dependencies > > Prior to this PR, the wallet leaked information to the server about \*\*which\*\* AOCL leafs were being spent in each transaction. With the functionality added in \`neptune-core\` in a384f655b8be63701a081ff788b6e17ee363004e, this privacy leak is no longer necessary. The wallet now leaks no more information when requesting the mutator set membership proofs than you do when your transactions gets included into a block, namely the fuzzy timestamp you can derive from the absolute indices. Another security related PR has been raised here: > > > This gives the wallet app a type guarantee that the a \`PrimitiveWitness\`, which …contains secret keys, is never sent to the RPC server. Also: This is the type expected by the caller now, so it will not work with any other types. ### Improvements to neptune-dashboard CLI wallet @aszepieniec has been buried deep in slide preparation for an upcoming presentation but found time between slides to fix some pet peeves in the neptune-dashboard wallet, which is included with neptune-core. He simplified the mempool table display and added a UTXOs screen that provides an overview of all known UTXOs. He also fixed a sign error in neptune-core that was appearing in the dashboard. ### Reminder: 0.5.0 Feature Wishlist A wishlist has been created for the next version of neptune-core. The team is soliciting community feedback, so please add your desired features on github, or just comment in this thread. > > > Wishlist for next major version of \`neptune-core\` > > \- \[x\] Revise directory restru…cture #691 > \- \[x\] Ability to create arbitrary coinbase transactions, for mining pools for distribution of timelocked UTXOs. #693 > \- \[x\] Faster updating of archival mutator set, preferably linear in the number of inputs in the block #684 > \- \[\] Hardfork: Free (no delay/need to redo memory preprocessing) switch between block proposals with the same parent > \- \[x\] Don't share local IPs in peer discovery process #660 > \- \[\] Faster initial block download -- through smaller batch requests, out-of-order block downloading from multiple peers #634 #585 > - \[x\] Smaller batches > - \[\] Parallel block download > \- \[x\] Don't create new address whenever dashboard is opened. #719 > \- \[\] Don't relay \`ProofCollection\`-backed transaction with low fees. #722 > > Feel free to contribute with your own suggestions for this list :) ## Contributor Updates: @aszepieniec - slides - dashboard improvements @danda neptune-proton wallet: - got desktop build working - implemented QR codes for wasm32 and desktop environments