Nocturnal: a small, readable privacy coin

Abstract

Nocturnal is a proof-of-work chain with confidential amounts, sender ambiguity and unlinkable recipients, carrying two permanent value pools: one using ring signatures, one using zero-knowledge proofs. A user chooses which anonymity protocol to transact with; neither choice is a transparent one, so privacy is not something anybody can switch off.

It deliberately contributes no new cryptography. The ring pool's commitments, range proofs and ring signatures come from the monero-oxide crates, which implement Monero's reviewed construction; the shielded pool is Zcash's orchard — Halo 2, with no trusted setup. The contribution is the chain around them, and the boundary between them: written to be small enough that one reviewer can read all of it, with the reasoning behind each rule written down and the internal security review published in full, including the parts that turned out to be wrong.

This document describes intent and design. The normative rules live in the protocol specification; where the two disagree, the specification and then the code are authoritative.

1. The problem

A transparent ledger publishes every payment forever. Anyone who learns one address learns a balance, a set of counterparties, and — by intersecting timing and amounts — often an identity. Chain analysis is a mature industry precisely because the data is simply sitting there waiting to be read.

Money should not work that way. Cash does not itemise your life to strangers. The technical problem is to build a ledger everyone can verify but nobody can read, and that problem is solved: Monero has run this construction under sustained adversarial pressure for a decade.

So Nocturnal does not attempt a cryptographic contribution. It asks a narrower question: how small and how legible can the surrounding chain be, if the cryptography is treated as a dependency rather than an achievement?

2. Design

2.1 Confidential amounts

Every output carries a Pedersen commitment C = xG + aH rather than a plaintext amount. Commitments are additively homomorphic, so a verifier can confirm that inputs equal outputs plus fee without learning any individual value. Each output additionally carries an aggregated Bulletproofs+ range proof establishing that the amount lies in [0, 2^64) — without which a negative amount could mint supply from nothing.

2.2 Sender ambiguity

Inputs are signed with CLSAG ring signatures over exactly sixteen members. The signature proves the signer owns one of the sixteen without revealing which. A key image, deterministic in the spent key, prevents double spends: spend the same output twice and the same image appears twice, and the second is rejected.

The ring size is fixed rather than a floor, and that distinction matters. A variable ring size is itself a fingerprint: the count partitions users by whichever wallet, version or setting produced it, so a user who picks an unusually large ring becomes less private, not more. Uniformity is the property being defended.

2.3 Unlinkable recipients

Each output is paid to a one-time key derived from the recipient's address and a per-transaction secret, so two payments to the same person share no on-chain identifier. Subaddresses let a single wallet hand out unlimited distinct receiving addresses under one view key, so a merchant can publish a fresh address per customer without managing more keys.

2.4 Proof of work

RandomX — the same function Monero uses — chosen because it is designed to run well on general purpose CPUs and poorly on specialised hardware. This is a distribution argument rather than a security one: a chain that ordinary machines can mine spreads issuance wider than one that requires a fabrication plant.

2.5 A second value pool: zero-knowledge proofs

Everything above describes the ring pool, which is what the testnet runs today. Nocturnal also carries a shielded pool built on Zcash's Orchard protocol — Halo 2, with no trusted setup — and both pools are permanent. A transaction picks which one it spends from, and value can move between them in either direction.

This is not optional privacy, and the distinction is the whole point. Zcash offers a choice between private and public: pick the transparent pool and a transaction's sender, recipient and amount are published for ever. Nocturnal's choice is between two private protocols. Nobody can opt out of privacy and nobody can leak by accident. What a user chooses is which anonymity model they trust — a ring of sixteen decoys, or an anonymity set of every note the chain has ever created.

The two make genuinely different bets. A ring of sixteen is cheap to verify, easy to reason about, and has a bounded anonymity set that a well-funded observer can attack statistically. A note-commitment tree hides a spend among everything ever created, but rests on far more mathematics and costs about nine milliseconds per action to verify and hundreds of milliseconds to produce. Rather than choose on a user's behalf, this chain runs both.

2.6 The turnstile

Each pool's supply is tracked as a separate public total, and neither may go below zero. Their sum is the emitted supply, and that is checked on every block. The purpose is containment: a counterfeiting flaw in one pool's cryptography cannot mint coins in the other, because taking value out of a pool that does not hold it is refused by arithmetic that involves no cryptography at all. A single pool holding the whole supply would have no such boundary, and that is the main argument for keeping two.

A transaction states the movement as one public signed integer, from the ring pool's point of view: positive means value left the ring pool for the shielded one. The bundle states the same movement from its own side, and the two must agree exactly or the transaction is refused — they are one movement described twice, and if they could differ the two pools would drift apart.

What this costs, stated rather than buried. The amount moving between pools is public, and only for those who move it. Shielding an unusual amount and later unshielding the same one links the two. A payment that stays inside one pool publishes nothing but its fee. The reason the crossing amount cannot be hidden is not laziness: the pools commit to value in different groups — Pedersen commitments over ed25519 on one side, value commitments over Pallas on the other — and a point on one curve cannot be added to a point on the other. The only quantity both sides can agree on is a plain integer. Hiding it would need a cross-curve equality proof in the consensus path, and this project's standing rule is that its cryptography is unoriginal so it can be audited by comparison. A bespoke cross-curve proof is the opposite of that.

2.7 What a shielded transaction looks like

A transaction carrying a bundle may have no ring side at all: no inputs, no outputs and no range proof. That is what a payment inside the shielded pool is. It pays its fee by crossing exactly the fee out of the pool, which the block's coinbase then collects like any other fee, and the ordinary balance rule holds with nothing on either side of it. The same freedom on the other half gives a full shield with no change output, so there is nothing tying the payment back to the sender's ring outputs.

A bundle's zero-knowledge proof does not cover the value it claims to move: the value balance is a public input carried beside the proof, and what ties it to the notes is the binding signature. Verifying the proof and not that signature would let a bundle claim any balance it liked — minting coins from nothing on the way into the pool and minting them in the ring pool on the way out. That was a real defect in this implementation, found and fixed before deployment, and it is recorded here because the shape of the mistake is instructive: the expensive, impressive check was present and the cheap one that actually guards the arithmetic was missing.

2.8 Maturity without a spend to inspect

A coinbase must be buried before it can be spent, and in the ring pool a validator can simply ask how old the output being spent is. An Orchard spend names nothing — that is the entire feature — so nobody can ask. Maturity therefore becomes a property of the tree: a shielded coinbase note is withheld from the note-commitment tree until the chain has buried it, so until then no published root contains it and no proof can be made against it. Nothing in the audited circuit changes.

The consequence to accept is that the spendable supply lags the emitted supply by up to one maturity window, and a wallet has to show that as pending rather than as balance. Both kinds of reward become spendable on exactly the same block, which is asserted by a test that drives both through real blocks rather than restating the arithmetic.

The miner chooses which pool its reward is created in, per block, the same way it already chooses an address. If every reward entered one pool, anyone who preferred the other would have to cross to reach it — publishing an amount purely for choosing a mechanism. A choice that is free in one direction and costs privacy in the other is not much of a choice.

3. Consensus

Blocks target 120 seconds. Difficulty retargets over a windowed average with a lag, outlier trimming at both ends, and a per-step clamp — three independent defences, because an unbounded retarget compounds after a burst of fast blocks and can leave the chain unmineable.

Fork choice is cumulative difficulty, not height. This matters more than it sounds. An earlier version advertised chain height in its gossip messages while consensus compared work, so a peer holding a shorter but heavier branch had no way to say anything the network would act on. That is a persistent chain split with no attacker involved. It was found and fixed before launch, and it is the kind of defect that only shows up when someone writes down what each layer actually believes.

Coinbase outputs mature for one hundred blocks before they can be spent — including as ring decoys, since ring signatures hide which member is real — so a reorg cannot invalidate an already-spent fresh coinbase.

That number is one hundred for a reason, and an earlier version of this document was wrong about it. It said sixty, and claimed a reorg could not invalidate an already-spent fresh coinbase, full stop. That holds only while reorgs are shallower than the maturity window, and a node will consider a reorg up to 100 blocks deep. A reorg between sixty and a hundred would have invalidated a coinbase that had already matured and been spent — exactly what the rule exists to prevent.

The gap is closed: maturity is now equal to the deepest reorg a node will accept, so there is one number rather than two that have to be kept in a relationship nobody is checking. The anchor history the shielded pool keeps is the same hundred, for the same reason — an anchor older than the deepest reorg can never be invalidated by one.

It is recorded this way rather than quietly corrected because the gap was found by running the chain and writing down what each layer actually believed, and that is the part worth keeping.

4. Economics

Supply approaches 1,000,000 NOCT asymptotically along a smooth emission curve, followed by a 0.03 NOCT tail emission that never terminates. A permanent tail is deliberate: a chain whose security budget falls to zero must rely entirely on transaction fees, and no proof-of-work chain has yet demonstrated that this holds in practice.

Block rewards are consequently sub-NOCT from the start — roughly 0.95 NOCT at genesis, decaying from there. Simulated across the entire smooth phase, emission reaches 96.85% of the supply parameter after about 3.6 million blocks.

4.1 The premine, stated plainly

The planned mainnet genesis block mints 500,000 NOCT to the founder — 50% of the supply parameter. This is the most consequential economic decision in the project and the one every reader should interrogate hardest.

The case against. Monero has no premine, and that fact underwrites a great deal of its credibility. A 50% allocation means one party holds as much as every future miner combined, forever. It is the single largest concentration risk here, it invites precisely the criticism that sinks projects, and no amount of technical care offsets it if you consider the distribution illegitimate. A reader who stops at this paragraph and walks away is behaving rationally.

The case for. It is disclosed everywhere — this document, the front page of the website, the README, the specification and the security review — rather than discovered later by someone reading a genesis block. It is a fixed, verifiable, one-time number rather than an ongoing founder's reward or a permanent tax on every block. There is no sale, no allocation round, no private round at a better price, and nothing being offered to anyone. And it is earmarked for work the project genuinely cannot do without — an audit above all, which costs real money and which no volunteer effort substitutes for.

What it is for. The allocation exists to fund the project rather than to enrich its author, and specifically to pay for:

• A professional security audit. The largest single line item and the one the project most needs. An audit of a chain this size is a five-figure engagement, it cannot be done with goodwill, and shipping money software without one would be indefensible.
• Community. Faucets, bounties for people who find real bugs, grants for wallet and tooling work, and paying contributors who are not the founder.
• Marketing and listings. Making the coin findable by the people it is for, and meeting the costs exchanges and aggregators charge.
• Infrastructure. Seed nodes, explorers, build and release machinery — the parts that must keep running whether or not anyone is paying attention.
• Ongoing development and the project's other operating costs.

What that is worth, stated honestly. The paragraph above is a stated intention, not an enforceable commitment, and you should read it as exactly that. Today the allocation sits in a single wallet controlled by one person. Nothing on-chain compels it to be spent this way, no schedule releases it gradually, no second signature is required, and no third party can block a transaction. A reader who treats "it is for the community" as a guarantee has misread the situation; a reader who treats it as a claim to be verified later has it right.

The address, published. The mainnet premine is paid to:

C4do37CzzKCV3XJHDinLAoL7MaEtRU5oHgGTWLVb8JBY5zEDayjqYqHGoyzGMF3VakXa2QjUgN9UJH7jpDQpMUVuRD1jNA

This was always derivable — the founder's public keys are baked into the source, along with the genesis transaction secret. Writing it down removes a step, which is the difference between a fact being technically available and actually checkable. Because that secret is public, anyone can confirm the genesis output really is addressed here and holds exactly 500,000 NOCT. A test in the codebase pins this address to the genesis constants, so the two cannot drift apart.

What publishing it does not give you. An earlier version of this document said the address let every movement out of the premine be watched. That was wrong, and wrong in the project's own favour, so it is worth correcting plainly: this is a ring-signature chain. A spend is signed against sixteen possible inputs, and the key image that would identify the real one is derived from the output's private key. Nobody can tell from the address when the premine moves. Watching this address does not watch the money.

The key image, published. The premine output's key image is:

06f1c57958aea772c2a687cd456121fea003af3b84238767d2429a5d2795db16

Unlike the address, this one binds. A key image is a one-way function of an output's secret key: it reveals nothing, cannot be forged by anyone who does not hold that key, and cannot spend anything. But it is exactly what a spend must publish — the network rejects a second appearance of the same image, which is how it prevents double spending. So the moment this value appears in a block, anyone can see the premine has moved; and for as long as it does not, anyone can see it has not. Once published it cannot be withdrawn, which is the property that makes it worth anything.

What the first movement will be, said in advance. The premine is a single output of 500,000 NOCT. Spending any part of it spends all of it — a payment of 20,000 returns 480,000 as change — so a published key image would otherwise turn the first ordinary payment into a signal indistinguishable from moving the lot.

So the first transaction will be a split, and nothing else: the 500,000 will be divided into 50 outputs of 10,000 NOCT, all paid back to the founder wallet, across roughly seven transactions. The key images of all fifty will be published here as soon as they exist. After that, visibility is proportionate: spending 10,000 makes exactly one of the fifty appear, and the other forty-nine are demonstrably untouched.

This is stated now, before mainnet exists, so that when the image above appears it is a predicted event rather than a discovered one. If the first movement is anything other than that split, it is fair to treat this document as having been wrong.

None of this reveals a destination, a recipient, or how a spend was divided — those stay hidden by the same construction that protects every other user, and no amount of founder disclosure should weaken it. It shows only that a specific output moved, and when.

What would still make it verifiable. Intentions become checkable when they leave the prose and enter the chain. None of the following is in place yet, and each is a fair thing to ask for before extending trust:

• A vesting or time-lock schedule, so the whole balance cannot move at once.
• Multisig control, so no single person — including the founder — can spend it alone.
• Published accounting of what was spent and on what.

Until those exist, the accurate description remains the plain one: half the coin, held by one person, with a stated purpose and no mechanism enforcing it. That is a weaker claim than most projects make, and it is the true one.

On testnet the premine is a tenth of this and its seed phrase is published in the repository, so the mechanism is independently verifiable and the coins are unmistakably worthless.

5. What is not claimed

• No audit. Nineteen internal review passes and one independent model review have found real defects — including an 8.79-second denial of service reachable by any peer, and the fork-choice mismatch described above. Internal review is an argument about the code, not evidence about it, which is why it is published in full rather than summarised.
• No network-layer anonymity. Transactions relay over Dandelion++, which frustrates naive origin tracing. It is not Tor, and an adversary who can observe the whole network is not defeated by it.
• Clock dependence. One validity rule — the future-timestamp bound — depends on the validating node's wall clock rather than on chain data. This is deliberate and matches both Bitcoin and Monero: the alternative makes recovery from a long network outage impossible.
• The two pools do not offer equal privacy, and will not for a while. A ring of sixteen is a ring of sixteen from the first block. A note-commitment tree has to grow: early in a chain's life the shielded pool's anonymity set is small, and a pool holding three notes hides very little however good the proof is. The zk pool's advantage over the ring pool is a promise about the long run, not a property it has on day one.
• Crossing between pools is not private about the amount. Inherent to the two pools committing to value in different groups, as §2.6 sets out — not an implementation shortcut, and not something a later version will quietly fix.
• The shielded pool is younger than everything else here. It is written, tested and adversarially probed, and it has had far less running time than the ring pool. One real defect in it — a missing binding-signature check that would have allowed minting — was found by review rather than by an attacker, which is the argument for review and not evidence that nothing else is there.
• Decoy selection is calibrated but young. Ring members are drawn from a gamma-shaped age distribution fitted to observed spending, so decoys look like real spends instead of being spread evenly over all history — uniform selection makes the newest ring member the real one far more often than chance, which is a handle on every transaction. Two caveats remain. The distribution's median age is about a day and a half, so on a chain younger than that most draws fall back to uniform; the bias only fully expresses itself once there are months of history. And it is calibrated from Monero's fit, not from Nocturnal's own spending data, which will not exist until people actually use it.

6. Status, and what has to happen next

A public testnet is running the ring pool. Mainnet parameters — genesis timestamp, address tags, the RandomX seed schedule — are still placeholders.

The shielded pool is written and not yet deployed. It changes consensus from end to end — a new transaction version, a second coinbase shape, a commitment tree inside the chain state — so it is wholly incompatible with the chain now running and arrives with a testnet reset. What that reset is waiting on is listed first below, because it is the honest answer to "when".

• A minimum-fee floor. A transaction can currently pay nothing, which mattered little when the cheapest thing a verifier could be asked to do was a ring signature; an Orchard action costs every node about nine milliseconds, so the floor is now a denial-of-service parameter rather than a policy preference.
• Moving the genesis premine into the shielded pool, which changes the chain id and so belongs with the reset rather than before it.
• A long and genuinely adversarial testnet — for the shielded pool, starting from zero
• A professional third-party audit, which has not been commissioned
• Reproducible builds on every platform. Linux binaries are reproducible from v0.1.4; Windows is not, and the release archives themselves are not yet byte-stable — only the binaries inside them
• A mechanism binding the premine to its stated purpose — a published address, vesting, multisig, and spending accounts. The intention is now on the record; nothing yet enforces it.

Until those are done, Nocturnal is a research chain with a working implementation. It is not money, and nothing here is an offer or investment advice. It is published now so that it can be read, disagreed with, and broken by people who are not its author — which is the only process that has ever produced trustworthy money software.