Dev Update 2026-05-26

Dev Update: Neptune & Triton

1. Last Week by the Numbers

neptune-core

  • Issues: 1 raised

triton-vm

  • Pull Requests: 1 merged
  • Issues: 1 closed
  • Commits: 2 merged into master

2. Stand-up Summary

Alan Szepieniec

  • Last Week: Conducted cryptographic reviews of two new proposed address formats, confirming their safety against dangerous elements. Noted that potential nonce reuse is handled properly via unique sender randomness.
  • Coming Week: Ongoing code reviews as time permits.

Ferdinand Sauer

  • Last Week: Enhanced testing infrastructure by increasing generated randomness for property tests across twenty-first, triton-vm, and neptune-core. Authored a comprehensive Triton assembly tutorial.
  • Coming Week: Scheduled to implement univariat batching as a performance enhancement. Following this, will begin working on the TIP 10 implementation and publishing the assembly tutorial to the website.

Thorkil Værge

  • Last Week: Analyzed feedback on block explorer visibility and address formats (noting substantial multi-dimensional improvements for addresses and announcements). Started addressing wallet synchronization discrepancies between neptune-core and the wallet application by allowing backup file importing.
  • Coming Week: Reviewing Ferdinand’s Triton assembly tutorial draft. Moving forward with porting the existing block explorer over to the new JSON RPC to meet external ecosystem standards.

3. Technical Discussion

Address Format Optimizations

The team evaluated two new address formats. While lacking a formal security proof, they have been deemed cryptographically safe, provided that the sender randomness is never reused. To streamline the codebase and eliminate redundancies, the team discussed whether to remove a superfluous XOR operation used during the AES key derivation in the open PR.

TIP 10 Implementation & Soundness Strategy

A clear scope has been established for TIP 10. The implementation will introduce a dedicated instruction to write directly to an independent output stream and integrate code words into the batching process using STIR rounds. The entire rollout is estimated to take between two to three weeks. Consequently, the recursive verifier implementation has been postponed indefinitely.

To preserve the soundness of Triton VM, the development strategy remains anchored on maintaining small, iterative releases. Minimizing the delta between consecutive versions ensures codebase changes are easily auditable, reducing the likelihood of architectural errors.

Wallet and Network Infrastructure

To resolve user-reported synchronization errors and balance discrepancies between neptune-core and the Neptune wallet, functionality is being introduced to let users import data via a backup cryptographic file. Address index bumping continues to be a primary engineering challenge for this workflow. Additionally, the team confirmed that the foundation for mining pool endpoints is already present in neptune-core, which will support future expansion.


4. Updates and Announcements

  • Upcoming Release: The Triton assembly tutorial will be published to the documentation site and linked across official GitHub landing pages following final peer review.
1 Like

I enjoy reading these, and it’s great to hear there’s so much going on.

Is this about succinctness? What’s the long term plan for it, still on the table?

It’s still scheduled for implementation eventually; the point of this paragraph is merely to say that the implementation of the recursive verifier after other stages of upgrades to Triton VM but before Tip10 will be skipped in favor of speeding up Tip10 ASAP.

1 Like