# Dev Update 2026-05-11 **URL:** \ **Category:** News and Announcements\ **Created:** [May 11, 2026, 9:04am UTC](https://talk.neptune.cash/t/dev-update-2026-05-11/284 "2026-05-11T09:04:40Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![aszepieniec](https://talk.neptune.cash/user_avatar/talk.neptune.cash/aszepieniec/32/5_2.png) [@aszepieniec](https://talk.neptune.cash/u/aszepieniec)\ **Post date:** [May 11, 2026, 9:04am UTC](https://talk.neptune.cash/t/dev-update-2026-05-11/284/1 "2026-05-11T09:04:40Z")
## Neptune & Triton Dev Update - May 11, 2026 ### 1. Last Week by the Numbers [neptune-core](https://github.com/Neptune-Crypto/neptune-core) - Issues: 1 closed - Pull Requests: 1 opened, 1 merged - Commits: 5 merged into master [triton-vm](https://github.com/TritonVM/triton-vm) - Issues: 1 closed - Commits: 1 merged into master [neptune-explorer](https://github.com/Neptune-Crypto/neptune-explorer) - Commits: 6 merged into master * * * ### 2. Stand-up Summary **Alan Szepieniec** - Last Week / Coming Week: external project commitments. - On the side: public technical communication on Telegram/forums; preparing a technical presentation on Tip5. **Thorkil Værge** - Last Week: Successfully implemented “cold mining” in Neptune Core, allowing for secure block production without hot-key exposure. Developed a new post-quantum secure address format and introduced “viewing keys” for granular transaction visibility. Managed upstream dependency updates, reducing security vulnerabilities by 90%. - Coming Week: Finalizing the merge for the new address format (working title “secret address”); investigating technical solutions for mining pool decentralization; overseeing the scheduled hard fork. **Ferdinand Sauer** - Last Week: Attended the ZK Summit to gather competitive intelligence and architectural ideas; researched Miden VM’s implementation of specific features relevant to Triton VM. - Coming Week: Re-orienting at the office to align on Triton VM development priorities; beginning work on zero-knowledge functionality and evaluating TIP 10 ROI. * * * ### 3. Technical Discussion **Cold Mining & Security** The implementation of cold mining in `neptune-core` now supports all three revenue streams: composing, guessing, and proof upgrading. This architectural shift significantly hardens node security by keeping secret keys offline. Additionally, a major cleanup of upstream dependencies was completed, mitigating the vast majority of inherited security vulnerabilities. One remaining high-priority patch is being finalized to prevent potential node-crash vectors. **Post-Quantum Secure Addressing** A new address format has been designed to provide post-quantum resistance, _assuming address secrecy is maintained_. This format supports QR code integration and utilizes “viewing keys.” These keys allow for the decryption of incoming/outgoing messages to verify fund transfers without granting the ability to spend funds or view full transaction history, offering a balance between privacy and auditability. **Triton VM Priorities: STIR vs. FRI** The team reached a consensus that the zero-knowledge mechanism is the top priority for Triton VM, followed by WASM support. There was a technical debate regarding the implementation of STIR in TASM. The immediate performance gains of STIR remain unverified compared to existing methods. **Upcoming Hard Fork** A hard fork is scheduled for Tuesday. Testing has been completed, and the primary objective is to maintain long-term system stability. The `neptune-explorer` has been updated to track the “lustration status” and counter in real-time following this transition. * * * ### 4. Updates and Announcements - **Scheduled Hard Fork** : Tuesday, May 12th. ---
**Author:** ![LostInTranslation](https://talk.neptune.cash/letter_avatar_proxy/v4/letter/l/e5b9ba/32.png) [@LostInTranslation](https://talk.neptune.cash/u/LostInTranslation)\ **Post date:** [May 12, 2026, 3:26pm UTC](https://talk.neptune.cash/t/dev-update-2026-05-11/284/2 "2026-05-12T15:26:08Z")
> ..new address format has been designed to provide post-quantum resistance, assuming address secrecy is maintained. Could this be elaborated a bit. Aren’t addresses generally meant to be shared between two parties when a transaction needs to be made, so what does secrecy mean in practice? What happens if a secret address is shared? ---
**Author:** ![sword-smith](https://talk.neptune.cash/user_avatar/talk.neptune.cash/sword-smith/32/20_2.png) [@sword-smith](https://talk.neptune.cash/u/sword-smith)\ **Post date:** [May 12, 2026, 10:02pm UTC](https://talk.neptune.cash/t/dev-update-2026-05-11/284/3 "2026-05-12T22:02:38Z")
If the attacker knows your address, _and_ possesses a big enough quantum computer to steal bitcoins, then he would be able to deanonymize transactions sent to these new types of addresses. Edit: Even in this scenario, the attacker would not be able to steal funds. ---
**Author:** ![LostInTranslation](https://talk.neptune.cash/letter_avatar_proxy/v4/letter/l/e5b9ba/32.png) [@LostInTranslation](https://talk.neptune.cash/u/LostInTranslation)\ **Post date:** [May 13, 2026, 5:38am UTC](https://talk.neptune.cash/t/dev-update-2026-05-11/284/4 "2026-05-13T05:38:50Z")
Okay, but only deanonymize, not able to access funds. That sounds like an acceptable compromise, since the sender at least needs to know which address the NPT is being sent to. Can a user generate multiple secret addresses from a single seed, so they don’t need to reuse the same secret address with different parties? If yes, is there a limit how many can be generated? ---
**Author:** ![sword-smith](https://talk.neptune.cash/user_avatar/talk.neptune.cash/sword-smith/32/20_2.png) [@sword-smith](https://talk.neptune.cash/u/sword-smith)\ **Post date:** [May 13, 2026, 11:02am UTC](https://talk.neptune.cash/t/dev-update-2026-05-11/284/5 "2026-05-13T11:02:26Z")
You can generate as many of these addresses as you’d like. So there’s no need to reuse them for multiple parties. Here’s the PR by the way: > > > Missing tests: > > \- \[x\] loop over all key/address types, send to an address of t…his format, and verify that this new UTXO can be spent and included in a block. Also verify that balances are updated this way. > \- \[x\] Verify that \`PrivateAddressKey\` can unlock \`PrivateAddress\`'s lock script. Preferably by going through TVM. > \- \[x\] Test with new key type in existing tests. > > Missing: > \- \[x\] documentation of new address type > \- \[x\] rename to secret address per @aszepieniec's request.