A community-run summary of what is happening across the Neptune Cash ecosystem.
\nneptune-core v0.15.0 (30 July) is a security release out of the audit findings. The wallet now checks that a lock script really is yours and really is satisfiable before recording a UTXO, closing a hole where you could be made to credit yourself coins you cannot spend.
\nv0.15.1 (31 July) is a one-day follow-up: sync-loop fixes so a peer feeding you a bad block during catch-up can’t wedge the process, plus new neptune-cli commands to check whether a specific payment has actually landed in the mutator set.
v0.16.0 (7 August) is about syncing. Nodes catching up can now request cryptographically authenticated blocks rather than relying on what a peer provides, and a node that is itself still syncing can serve those onward. Mutator-set removal-record maintenance went from O(N²) to O(N), the operation that dominates catching up after downtime.
\nneptune-wallet-app v4.2.0 (5 August) is about watching and locking. Importing a viewing key (nview… or nechvk…) lets the wallet monitor incoming payments from a machine that holds no spending key, and adding the receiver preimage gives a true balance. The wallet can now be locked manually, and it also locks itself after 15 minutes by default, which is on after upgrading. Sends also survive a block landing mid-proof: a proof in flight when a block arrives is rebuilt against the new tip instead of failing, and once broadcast a transaction is no longer re-proven every block, since keeping it valid is the node’s responsibility.
The payment URI scheme RFC is now a formal proposal, NIP-002. It defines payment links, QR codes and deep-linking using the scheme string neptunecash:. The payoff is practical: an invoice, a donation page or a shop could offer a link or a QR code that opens your wallet with the amount already set alongside the address, and because the format is a standard rather than one wallet’s convention, every wallet and payment tool can support it the same way.
The proposal carries three open questions for reviewers: the scheme name, QR-code capacity against Neptune’s address length, and how amounts are denominated. It has zero replies on the forum and no comments on the PR since 4 August. If you want to influence how Neptune payment links work, now is the time.
\nSeparately, the block-time thread, opened just after Bulletin #1, has produced a concrete idea: Thorkil suggested letting transactions sync against the n last blocks rather than only the current tip, so proofs relating to slightly older blocks aren’t rejected, calling it “not impossible, but challenging.” That is the real constraint on shorter block times, and it is now written down instead of scrolling past in a chat window.
\nWhat transaction chaining would change. Today an output has to be confirmed in a block before it can be spent again, so a run of payments advances one block at a time. Chaining lets the unconfirmed outputs of one transaction be spent as the inputs of the next. For anyone paying in sequence, a merchant settling a series of payments or a wallet spending its own change, that is the difference between waiting for a block at each step and not waiting at all.
\nTransaction chaining is the near-term roadmap, and succinctness is behind it. The 10 August dev update has Alan finishing the TASM code with most unit tests, leaving end-to-end integration, and Thorkil reviewing and integrating it into transaction processing. A security review comes next, to find vulnerabilities and other problems before the implementation goes live.
\nAn earlier audit raised a soundness question about Triton VM, which the team assesses as “a theoretical soundness concern for Triton VM when analyzed in isolation” posing “no risk of funds theft or token inflation within the current Neptune Cash system architecture.” A fix is not yet released.
\nThis site published a Technology page on 11 August, a plain-terms explanation of how Neptune keeps payments private and proves them valid, covering the mutator set, address formats, lock and type scripts, Triton VM, zk-STARKs and Tip5. It is written for newcomers, and assumes no prior knowledge of the cryptography involved.
\nA machine-checked proof about zk-STARKs landed on 3 August: Isabelle/STARK: A Formalization of zk-STARK in Isabelle/HOL (arXiv 2608.01965). Isabelle is a proof assistant, software in which each step of a mathematical argument is stated precisely enough that a machine can check it follows. HOL stands for higher-order logic, a form of logic that can quantify over functions and predicates rather than only over values. The work carries a staged soundness theorem with an explicit probability bound, plus a model that can be executed. Neptune’s entire security argument reduces to “the STARK is sound,” which is what makes machine-checked work on these protocols worth watching.
\nIBM and the University of Chicago claimed verified quantum advantage on 70 logical qubits on 30 July. Worth knowing what it isn’t: an independent fact-check on 1 August concluded these papers “provide no technical basis for revising CRQC or Q-Day estimates, or for changing an organization’s PQC migration plan.” Breaking RSA-2048 needs roughly 1,400 simultaneously active logical qubits under fault tolerance, a different regime. Neptune’s case is better served by being accurate about quantum timelines than by amplifying them.
\nCorrections and additions welcome. Discussion in the Neptune Bulletin thread on the forum.
", "date_published": "2026-08-13T00:00:00.000Z", "authors": [ { "name": "Neptune Cash Community" } ] }, { "id": "https://useneptune.org/blog/how-neptune-cash-works/", "url": "https://useneptune.org/blog/how-neptune-cash-works/", "title": "How Neptune Cash works", "summary": "A new Technology page explains in plain terms how Neptune Cash keeps payments private and proves them valid.", "content_html": "A payment on the Neptune Cash chain is a sealed record plus a proof, and nodes check the proof instead of the record. The chain does not store who paid whom or how much. Coins arrive locked inside envelopes that no one can open or alter, and a zero-knowledge proof shows that every rule was followed. If it holds, the payment is valid. Nothing about the sender, the receiver, or the amount had to be published to make that work.
\nThere is now a page on this site that explains the rest of the system the same way: Technology. Neptune Cash is built on ideas that take some unpacking, and the page exists to do exactly that: to make the technology understandable and digestible for anyone curious about how it all works.
\nThe page is also honest about the edges: what is shipped today, what is still on the roadmap, and where the headline claims have precise boundaries. It stops where the real documentation starts: the official docs and the whitepaper go deeper. If something is unclear or wrong, say so on the forum; corrections are genuinely welcome.
", "date_published": "2026-08-11T00:00:00.000Z", "authors": [ { "name": "Neptune Cash Community" } ] }, { "id": "https://useneptune.org/blog/neptune-bulletin-1/", "url": "https://useneptune.org/blog/neptune-bulletin-1/", "title": "⭐ Neptune Bulletin #1", "summary": "Difficulty up elevenfold behind a faster GPU miner, a security review that found no critical flaws but pushed succinctness back, and the first timelocked NPT trade, at four to one. Covering 15 to 29 July 2026.", "content_html": "This is the first Neptune Bulletin: a regular roundup of what is happening across Neptune Cash, for people who want to follow the project without having to follow every forum thread, Telegram message, X post, release note and commit.
\nDevelopment itself is already well covered, by the forum, the repositories and the core team’s own dev updates. What is harder to find in one place is everything around it: direction, security, mining, tooling, coverage, markets and the occasional thing from outside the project that Neptune ought to be paying attention to. That is the gap this tries to fill.
\nIt aims to be useful rather than promotional. Where something is unclear, contested or simply wrong, it says so, and each edition closes with a short list of things worth acting on. Corrections are welcome and will be published.
\nA much faster GPU miner shipped. Qubic Solutions’ OXZD gained an optimized NPT build in mid-July, announced in Telegram on 16 July with tested rates of 3080 100.7 Mguess/s, 3090 119.8, 4090 293.3 and 5090 388.8, each at a stated power limit, 550W for the 5090. The current release is 0.8.4, a bug fix dated 18 July.
\nDifficulty rose about elevenfold over four weeks, from 3.67 × 10¹² at block 42,000 (29 June) to 4.10 × 10¹³, having peaked at 6.59 × 10¹³ on 26 July. One part of that has a published explanation: the 13 July dev update reported a ~3x surge over a 5 to 10 day window and put it down to a mining pool implementing an optimized hashing algorithm rather than a sudden influx of physical hardware. That surge largely predates this edition’s window, and nothing published accounts for the rest of the rise. If you’re on a stock miner, your share of blocks has quietly fallen.
\nNeptune Cash’s mining hardware partner held a public event. Qubite International is a Hamburg-based colocation provider running data centers in the UAE, and has been Neptune Cash’s exclusive hardware partner since an agreement announced on 10 June. On 25 July it presented alongside the Neptune Cash development team at a free public event at Kraftwerk Rottweil, a 9am–1pm session with talks from developers, data center operators and tax advisers on running mining as a business in 2026. Its nptmining.com sells NPT mining servers rated at 650 MH/s.
\nTwo facts worth holding side by side, without joining them: most of the difficulty rise has no published explanation, and a commercial operator with an exclusive hardware partnership is selling 650 MH/s servers. Nobody has publicly connected the two and this bulletin is not doing so either. For calibration, 650 MH/s is roughly 1.7 times a 5090, and about 0.8% of a network running near 80 GH/s, so it would take a lot of them to move difficulty.
\nIf you’re offering a 64.01 NPT guesser reward, Thorkil wants to hear from you. Miners set up that way are not merging transactions properly. Syncing and merging beats creating a no-op transaction, and it pays better. He has offered to help directly.
\nneptune-core v0.14.3 (23 July) is the one to install if you mine: it fixes guesser rewards being recovered against only some of your keys, meaning recovery could previously miss rewards you had actually earned. It also stops proof-collection transactions flickering in and out of the mempool, and adds viewing keys to generation addresses. Release notes
\nneptune-wallet v4.1.3 (20 July) tightens seed handling and balance reporting. Going back a step or switching between create and import no longer replaces a phrase you have already written down; new phrases come only from an explicit “Change seed phrase” action. Balances are now split into spendable, pending and total, and inputs to unconfirmed transactions no longer count as spendable. Release notes
\nA security review of the software and cryptography stack, carried out with Claude 5. It confirmed cryptographic integrity and monetary soundness with no critical flaws, and identified medium-severity issues in neptune-core. Those findings are being worked through, and the fixes ship in neptune-core v0.15.0.
\nnptstats.org is a new dashboard and explorer built by a community member, covering block height, hashrate, difficulty, block times, supply and pool worker counts, with a halving countdown and wallet lookup.
\nA token standard has been drafted. NEP20 proposes a single shared type script for every token, each one distinguished by a token_id derived from its issuer parameters, so new tokens could be created permissionlessly by producing a valid proof rather than needing a protocol change for each one. The repository carries a normative spec, security notes and an integration guide alongside a Rust implementation.
Neptune Cash was added to QuantumTracker on 25 July, and the grade is an F. Five of the six categories are graded A and shipped: transaction signatures, consensus, on-chain logic and privacy, all post-quantum since genesis. The F comes entirely from the peer transport. The libp2p Noise handshake uses classical X25519 key exchange with Ed25519 node identity, so there is no post-quantum key establishment on the wire, and because that is the only elliptic-curve cryptography left anywhere in the protocol, the EC Sunset category grades F as well.
\nThe core team does not read it as a headline problem. Asked on 26 July whether Neptune uses quantum-insecure networking, Alan’s answer was that there are two network stacks and only the libp2p one uses transport encryption, inherited from libp2p and not post-quantum; monetary integrity and confidentiality are guaranteed post-quantum at a deeper level, and the legacy stack needs neither. Post-quantum transport is “worth postponing until after bigger changes.”
\nNPT is now listed on hashrate.no, a cryptocurrency tracking site. The listing went up on 24 July, the result of legwork by a community member.
\nA community member wrote a technical explainer. An overview of Neptune Cash covering zk-STARKs, mutator sets, post-quantum signatures, proof of work and the 42 million supply cap went up on Medium on 24 July, written for readers new to the project.
\nTracker data has not caught up. Thorkil submitted the CoinGecko correction on 24 July, but the listing still carries wrapped-NPT metadata and Coinpaprika still links the retired @seagodcrypto handle.
\nThe first timelocked-NPT trade executed. On 27 July sword-smith confirmed @drpool filled the standing offer: 60,000 timelocked NPT for 15,000 liquid, via a wallet build that watches the pool’s address using an imported viewing key.
\nSuccinctness now waits on the security fixes. Announcing v0.14.3 in Telegram on 23 July, Thorkil hedged the timing from the outset: “If all goes well, this will be the last time in a while that I work on application stuff, as I’m hoping to work on succinctness starting next week.” The hedge is now doing the work, with v0.15.0 and its security fixes going first. Worth knowing what the feature actually buys: cheap syncing rather than richer smart contracts, a distinction Thorkil drew the same day. The tracking issue has been open since April.
\nTransaction chaining implementation has started, at the TASM layer. The open design question is a recursive one: whether the chain transaction proof must encode the single proof digest. The legacy transaction pipeline is being kept alongside the new one so that low-cost proof generation stays available.
\nThe project has stepped up its public communication. Since the official @NeptuneCash profile was announced on 10 July, posting has settled into a regular cadence, part of a stated shift in communication direction.
\nA voluntary community fund was proposed, and drew 15 votes. A community member ran the pinned poll on 21–22 July, covering marketing, content, outreach and possibly listing costs. The 15 came in over 24 hours from a group of ~3,000, and responses were mostly positive.
\nThe organizer’s own read is the honest one: participation that low can’t be treated as representative, and the engagement question needs answering before a fund is built. Others noted a similar listing-contribution poll has been tried before.
\nThere’s prior work to build on: a forum thread on a Neptune CCS design, modeled on Monero’s. The right technical question has already been asked: can releasing funds require multiple authorizations, or only a single signer? Neptune has no k-of-n lock script today, so for now the honest answer is no.
\nZcash sealed its legacy shielded pool. The Ironwood upgrade activated on 28 July at block 3,428,143, routing 3.76 million ZEC through a public accounting turnstile that will either surface or freeze any counterfeit coins minted through a soundness flaw in the Orchard circuit that had been live since May 2022. The gap was in the elliptic-curve scalar multiplication used to prove every private transaction valid, and it allowed unlimited undetectable minting inside the pool. Fifty-one engineers and more than 1,300 pull requests, in sixty days.
\nDirectly relevant to Neptune: on a private chain, monetary soundness is a property of a circuit, and a circuit can be wrong for four years without anyone noticing. Supply that cannot be audited by looking is supply that has to be proved correct.
\nClaude Mythos found a real weakness in a post-quantum signature scheme, and the scheme was withdrawn. HAWK, a candidate in NIST’s additional signature standardization process that had survived two years of expert scrutiny, turned out to contain an unused symmetry in its lattice structure. Anthropic published the finding on 28 July: its model worked semi-autonomously for around 60 hours, improving the best-known key-recovery attack from 2⁶⁴ operations to 2³⁸ for the smallest parameter set. On 29 July the HAWK team withdrew HAWK from the NIST process after confirming the result.
\nThis does not affect Neptune, whose signatures are hash-based rather than lattice-based, and nothing in production is threatened today. The method is the point: two years of human review missed something a model found in sixty hours. That is the argument for the security review above, and for repeating it rather than treating it as done.
\nGalaxy committed up to $5 million to making Bitcoin quantum-ready, announced 21 July: grants for post-quantum signature schemes, wallet migration tooling and security audits. It is here as a price signal rather than as news about Bitcoin. The cost of retrofitting post-quantum security onto a chain that was not designed for it is now being quantified by people spending the money, and that number is the clearest available statement of what Neptune gets from having started there.
\nThanks to the community members keeping discussion going across the forum, Telegram and X, and turning up in the replies when the project posts. That kind of steady visibility is harder to sustain than it looks, and it does work that no commit log records.
\nCorrections, questions and any other input are welcome in the Neptune Bulletin thread on the forum. If something here is wrong or incomplete, saying so publicly is more useful than letting it stand.
", "date_published": "2026-07-30T00:00:00.000Z", "authors": [ { "name": "Neptune Cash Community" } ] }, { "id": "https://useneptune.org/blog/updates-now-come-from-the-forum/", "url": "https://useneptune.org/blog/updates-now-come-from-the-forum/", "title": "The forum for dev updates, this blog for everything else", "summary": "From now on this blog carries only blog posts, the homepage highlights the latest forum threads, and coverage broadens beyond development to the wider Neptune Cash ecosystem.", "content_html": "Until now the homepage carried a curated list of updates. Most were dev updates: forum threads read, condensed, and written up so they could be taken in at a glance.
\nThat was genuinely useful, and it is worth saying what the change costs. A summary is easier to scan than a thread. But it also meant this site carried a second version of something already published, and it was only ever as current as the last time someone sat down to write one.
\nThe homepage now reads Neptune Talk directly and shows the most recent threads as they appear. Nothing is filtered or reordered here: whatever the forum surfaces, the site shows. The trade is digestibility for currency, and for a single place where a discussion lives.
\nThe summaries themselves are gone from this site, but nothing has been lost with them: every thread they pointed at is still on the forum.
\nWith the summaries gone, the homepage now shows two things side by side: posts from this blog on the left, live forum activity on the right.
\nEverything under Blog is now an actual blog post rather than a changelog entry, which is what makes the third change possible.
\nFrom here, expect regular posts about the Neptune Cash ecosystem as a whole, rather than development alone.
\nDevelopment is already well served, by the forum, by the repositories, and by the people writing the dev updates. Repeating that here adds nothing. What gets less attention is everything around it: the wallets and how they differ, exchanges and liquidity, mining, tooling and integrations, community projects, and practical guides for people who want to use Neptune Cash rather than build it.
\nThat is where this blog is heading. If something in the ecosystem deserves a closer look, or you are building something yourself, the forum is the best place to say so, and a good chance it ends up here.
", "date_published": "2026-07-29T00:00:00.000Z", "authors": [ { "name": "Neptune Cash Community" } ] }, { "id": "https://useneptune.org/blog/neptune-core-0-11-0/", "url": "https://useneptune.org/blog/neptune-core-0-11-0/", "title": "Neptune Core 0.11.0 released", "summary": "Neptune Core 0.11.0 is now available. The main user-facing change is support for two new address formats: viewing addresses and EC hybrid addresses.", "content_html": "Neptune Core 0.11.0 introduces two new address formats — viewing addresses and EC hybrid addresses — that are significantly shorter and easier to work with than the existing generation addresses.
\nFull changelog & download on GitHub ↗
\nThe new formats are much shorter than the existing generation addresses, and they also produce much shorter on-chain announcements when funds are sent to them.
\nThe new address prefixes are:
\nnview for viewing addressesnech for EC hybrid addressesFor comparison, a generation address is 3482 Bech32 characters. A viewing address is 115 characters, and an EC hybrid address is 168 characters.
\nThis makes addresses easier to share, display, and integrate into wallets and other tools.
\nShorter does not automatically mean “safer in every way.”
\nA viewing address works somewhat like a view key: anyone who has it can see UTXOs (unspent transaction outputs) sent to that address when on-chain announcements are used. In practice, this means that if a viewing address is shared publicly or leaks, anyone can look at the blockchain and see which transactions sent money to that address and how much — they cannot spend the funds, but they can track your incoming balance.
\nEC hybrid addresses add an elliptic-curve key-exchange mechanism, giving better privacy properties while keeping addresses compact.
\nThe older symmetric address format is being deprecated because it is easy to use incorrectly. It remains functional for now, but migrating to one of the new formats is recommended.
\nFor more background, read the forum post: Two new address formats
\nThe release also includes fixes and internal improvements around address handling, archival state recovery, sync-mode testing, and test coverage for the new address types.
\nUpdate your node to v0.11.0. If you share addresses publicly or with third parties, consider which format fits your needs: EC hybrid addresses offer the best balance of compactness and privacy, while generation addresses remain the strongest privacy option if that is your priority.
", "date_published": "2026-05-29T00:00:00.000Z", "authors": [ { "name": "Neptune Cash Community" } ] }, { "id": "https://useneptune.org/blog/hardfork-beta/", "url": "https://useneptune.org/blog/hardfork-beta/", "title": "Hardfork beta at block height 38,000", "summary": "Neptune Cash's next consensus upgrade is scheduled for mainnet block height 38,000, estimated around May 12, 2026. Here's what it changes and why you should update your node.", "content_html": "Hardfork Beta is Neptune Cash’s next set of consensus rules, scheduled for mainnet block height 38,000 — estimated around May 12, 2026. PR #912 was merged on April 24, 2026 specifically as “Hardfork beta @ block height 38,000.”
\n\n\nA note on the name: “Beta” is simply an internal codename indicating this is the second hard fork (the first being Hardfork Alpha). It has nothing to do with the maturity or quality of the software.
\n
Old nodes will stop following the valid chain after height 38,000. Neptune’s docs define a hard fork as a rule change where legacy versions do not consider blocks under the new rules valid. If you run a node, you want to be on a release that includes the Hardfork Beta logic before block 38,000 — otherwise your node can fall off the post-fork chain.
\nPoW memory-hardness is removed. The PR drops the requirement that PoW authentication paths match the PoW Merkle root. Mining no longer requires tens of gigabytes of precalculated Merkle-tree data, significantly lowering the hardware barrier to participate.
\nA lustration barrier is added. This is a supply-audit mechanism designed to address an earlier Triton VM soundness bug that could theoretically have inflated supply. Pre-Hardfork-Beta UTXOs must reveal and prove their input values when spent. A global counter is decremented by the value of coins passing through. If the counter reaches zero, remaining pre-fork UTXOs become unspendable. The goal is to prove that no unauthorized coins exist in the supply.
\nPoW difficulty checking changes. Before Beta, PoW was checked against the parent block’s difficulty; after Beta, it is checked against the current block’s own difficulty. This makes future recursive block verification cleaner because a parent block’s PoW verification then depends only on fields in the parent block itself.
\nRelated rule adjustments. Allowed future-dating of blocks is reduced from five minutes to one minute, and the mempool is cleared across the fork to prevent incompatible transactions from being mined.
\nMake sure you are running the minimum required versions before block 38,000:
\nIf you have questions, the community is active on the Neptune Forum and Telegram.
", "date_published": "2026-05-10T00:00:00.000Z", "authors": [ { "name": "Neptune Cash Community" } ] }, { "id": "https://useneptune.org/blog/website-is-live/", "url": "https://useneptune.org/blog/website-is-live/", "title": "Website is live!", "summary": "The first version of useneptune.org is now live. More content, updates, and improvements are coming soon.", "content_html": "The first version of useneptune.org is now live.
\nThis is an independent community site. For wallet downloads, releases, security advisories, and authoritative information, neptune.cash remains the place to go. What this site tries to do is different: make Neptune Cash easier to understand for people who are new to it, and easier to contribute to for people who want to help.
\nMore explanatory content, better onboarding material, and broader coverage of the ecosystem: the wallets, nodes, explorers, and tools people are building around Neptune Cash, and how to actually use them. If something here is unclear, wrong, or missing, that is worth saying out loud. The forum is the best place for it, and corrections are genuinely welcome.
\nThanks for reading, and welcome.
", "date_published": "2026-05-05T00:00:00.000Z", "authors": [ { "name": "Neptune Cash Community" } ] } ] }