How it works

Announcements

How your wallet discovers it was paid, given that transactions name no addresses. A payment carries an announcement: a public note with a receiver identifier on the outside and a sealed message inside. The sealed part holds the coin's full description and the sender randomness, the sender's half of the secret the commitment was sealed with. The other half is baked into the recipient's address. The recipient needs the announcement's half, together with keys only they hold, to recognize the payment and later spend it.

Both halves together are the deliberate exception to the mutator set's unlinkability, and they open different doors. The recipient, who also holds the private key behind the address, can connect the coin to its entry in the set and produce the removal record that spends it. The sender can watch the coin confirm, but without that key cannot recognize the removal record, so they cannot even tell whether the coin has since been spent. The commitment is the payment and nobody can read it; the announcement is the notice about it, and with the strongest address format exactly one person can. The addresses card covers the formats that widen that circle.

The identifier on the outside is a deliberate trade-off. It lets your wallet spot payments meant for it instead of trial-decrypting every announcement on the chain. The cost: two payments to the same address carry the same identifier and can be linked to each other, which is the mechanism behind the advice to use a fresh address per payment, or to notify the recipient directly off-chain instead.

What you get: payments that find their recipient without putting either of you on the chain.

Addresses, and why one is enormous

Neptune has three shareable address formats because different situations call for different trade-offs: address length, post-quantum strength, and what the holder gets to see.

The m in each prefix marks mainnet.

Generation is the strongest, and the enormous one: it encodes a lattice-based public key, built on mathematics resistant to quantum attacks, and that key is what a sender uses to encrypt the announcement from the previous card. The length is the price of post-quantum privacy.

EC hybrid is the compact option. Its key exchange uses an elliptic curve, the one piece here a quantum computer could break. Even a successful attack would require the address itself, which never appears on the chain, and would only reveal what that address received; spending would remain out of reach.

A viewing address gives away your incoming payments: anyone holding it can see every payment announced to you on-chain and its amount, though they cannot spend anything. That is useful when the transparency is the point: an accountant, an auditor, or a donation page can verify incoming payments with no power to move them.

What you get: control over the trade: the strongest post-quantum privacy when you can share a long address, a compact option when you cannot, and a watch-only format whose holder can see your payments but never spend them.

Lock scripts and type scripts

Neptune's rules are small programs attached to coins, and they come in two kinds. They run in Triton VM and are proven with STARKs, the next two cards. This is what "programmable" concretely means here.

A lock script decides who may spend a UTXO. Usually it checks knowledge of a secret key, but it can be arbitrarily complex: shared ownership, quorums, or conditions unrelated to keys entirely.

A type script decides how a kind of coin may behave: the native currency type script is what enforces that a transaction's inputs cover its outputs plus its fee, so no coins appear from thin air. The three-year timelock on half of every mining reward is a type script too: the rule lives on the coins themselves, not in anyone's policy.

What you get: ownership and money rules enforced by proofs rather than policy, and the foundation Neptune's programmability builds on.

Triton VM, or proving instead of replaying

Think of Triton VM as the computer Neptune's transaction rules run on: a simulated machine that every node can run identically. The interesting part is what it is used for. Most chains use their VM to replicate state, so every node re-executes everything and ends up holding the same data. Neptune uses Triton VM to validate updates to a state commitment instead: one sealed fingerprint of the whole ledger, a chain-sized sibling of the per-coin commitments in the last section. Nodes agree on that fingerprint, and that it changed correctly, without needing to see the private data behind the change.

Verifying proofs instead of replaying data is what lets a chain be both verifiable and private. Programs for it are written in its own low-level language, tasm.

zk-STARKs

The proof system Triton VM ships with. The zk stands for zero-knowledge: a proof that convinces you a program ran correctly without showing you what it ran on. The rest of the acronym, Scalable Transparent ARgument of Knowledge, matters here for two reasons: transparent means there is no trusted setup ceremony to take on faith, and the proofs are built out of hash functions, the next card's subject, not out of math a quantum computer can break. Validating a Neptune transaction largely means verifying such proofs.

checking the proof is cheap, so every node does it

The cost is asymmetric by design: proving is expensive, verifying is cheap. That asymmetry is why composing a block needs serious hardware while checking one does not, and it is why STARKs sit at the center of the design: the network verifies private computation without ever seeing it. Who does that expensive proving, the last card in this section explains.

Tip5, the hash everything rests on

A hash function turns any data into a short fingerprint that cannot feasibly be run backwards. Tip5 is Triton VM's built-in hash, co-designed by one of Neptune's founders for recursive STARK machines like this one: cheap to reason about inside the VM rather than merely fast on a CPU. It seals the commitments in the hiding half of this page, and it is the hash the mining race is run with.

That is why the GPU miner lists its Neptune algorithm as tip5 rather than neptune: the algorithm is the hash, and the coin is one thing that uses it.

Post-quantum, precisely

Spending is hash-based. Lock scripts and the key derivation behind them, how your seed phrase becomes spending keys, run on Tip5. Authority over your coins rests on hash functions, which a quantum computer does not meaningfully weaken. That is the heart of Neptune's post-quantum claim, and it holds.

Encryption is not all hash-based. A generation address carries a lattice-based public key, used to encrypt the announcement, the payment notice, for its recipient. An EC hybrid address uses secp256k1, an elliptic curve, for that key exchange instead. Elliptic curves are exactly what a large quantum computer is expected to break; lattices, like hashes, are believed to resist one. So the curve appears in one optional address format, for confidentiality rather than custody: a break there would let an attacker read what you received, but only if they also hold the address, which never appears on the chain, and it would still not let anyone spend it.

Succinctness, on the roadmap

Neptune does not have this yet; it is on the roadmap and in active development. The aim is that verifying the whole chain takes only a small amount of work regardless of how much history exists, instead of downloading and checking every block one by one. The mechanism is recursive block validation: every block carries a STARK proof, the same kind built in the section above, that its predecessor was valid, so checking the newest block transitively checks the chain.

each block proves its predecessor valid · not shipped