Private settlement.
Verifiable supply.

01 / Thesis

The case for private settlement

A payment system should verify the transfer of value without making every user's financial history public.

NIGHTFALLCOIN (NIGHT) is a native proof-of-work currency built around confidential values, non-interactive stealth payments and publicly checkable monetary accounting. Its ledger represents amounts as commitments, authorizes spends with one-time keys and aggregates transaction components into canonically ordered blocks. It is a settlement system, not a general-purpose smart-contract platform.

The central design choice is to combine private payment amounts with an explicit supply invariant. Nodes check a relationship between unspent commitments, accumulated kernel excesses, issuance and burned fees. That relationship is useful only together with valid range proofs, signatures, authorization and correct state transitions. An equation by itself is not a security proof.

This paper explains the implementation represented by release 1.0.4, protocol 8 and wire version 6. It also identifies operational trust, unresolved security risks and research objectives. It makes no claim of universal anonymity, hardware neutrality, guaranteed finality or investment performance.

Sources [1] [3] [11]

02 / System architecture

One currency, explicit trust boundaries

The wallet, the node and the website perform different jobs. Their security claims should not be interchangeable.

A wallet constructs outputs and authorizes spending. A full node maintains the unspent-output set, validates candidate blocks and selects a permitted history by accumulated work. Peers deliver data; their messages are inputs to validation, not authority to create money. Miners assemble blocks and search for an acceptable proof of work.

Core and the browser are not equivalent validators

Core combines a local node, wallet and miner. The browser wallet performs key operations locally but obtains chain data through a remote light API. A remote node can withhold or misreport information even though node access alone does not reveal the spending key. A compromised wallet application or device is a separate, stronger threat.

Consensus rules do not remove implementation or distribution trust. A user still chooses a client binary, its checkpoint policy, an operating system and a way to obtain peers. These dependencies are made explicit throughout this paper.

Sources [5] [4] [11]

03 / Payment construction

From an address to a one-time output

Receiving a payment does not require the recipient to participate in an interactive signing session.

The address contains a scan public key A and a spend public key B. A sender samples an ephemeral scalar r and publishes Ke = rG. The sender and receiver derive the same shared secret from rA and aKe, where a is the scan secret. Domain-separated derivations produce a blinding scalar, a one-time key offset and payload-encryption material.

The output carries a commitment, range proof, ephemeral key, one-time public key, view tag, encrypted payload and sender signature. The receiver scans for matching outputs, decrypts the value and memo, and checks that the recovered opening recreates the published commitment. A successfully decrypted payload alone is not enough.

Why the sender cannot reclaim the payment

The sender knows the derived offset and blinding factor, but not the recipient's spend secret s. Spending requires authorization under Ko, whose secret is s + o. The input verifier obtains Ko from the existing UTXO entry, not from a replacement key supplied by the spender.

Sources [2] [3]

04 / Primitives and composition

A compact cryptographic foundation

Established primitives reduce the invention surface. Their integration still requires its own security analysis.

Commitments and range proofs use the same generator pair from PedersenGens. Binding relies on the assumed hardness of finding the discrete-log relation between G and H. Proof and signature checks must reject invalid encodings and bind the intended context. Bulletproofs require no trusted setup, but that property does not certify Nightfall's application of them.

Native payment cryptography stands alone in 1.0.0. The experimental Bitcoin swap adapter, which added secp256k1, a cross-curve proof and a second implementation of the same curve arithmetic, was withdrawn with the feature; that review surface is no longer part of the build.

Sources [2] [12] [13] [14]

05 / The supply invariant

Confidential value, public accounting

The ledger checks conservation without publishing each user's balance.

For an ordinary transfer, output value plus the public fee equals input value. Its remaining commitment difference is a blinding excess. Kernels carry Schnorr signatures relative to H. The verifier requires both the expected excess and valid signatures; merely publishing the publicly computable difference would prove nothing.

Starting from the defined genesis state, accepted transitions preserve this invariant. Range proofs exclude invalid value encodings; input signatures establish spending authority; UTXO checks prevent double spending; emission rules bound coinbase issuance. Removing any of these checks changes the security argument.

What the public website can demonstrate

The network page displays a node's reported totals and invariant result. The browser does not independently replay the ledger or verify the full cryptographic statement. Independent verification requires a validating implementation and an understood policy for trusted local state and historical checkpoints.

Sources [2] [3] [11]

06 / Ordering and validation

Proof of work, with bounded finality

Valid history is selected by cumulative work within the rules enforced by the client.

Mainnet uses Nighthash-v2 with Argon2id parameters of 32 MiB, one iteration and one lane. The design imposes a memory cost on each hashing instance. It does not establish that GPUs or purpose-built hardware have no advantage, that every CPU earns equally, or that mining is profitable. No hardware-efficiency benchmark is claimed here.

A miner's proposed block must satisfy shape, ordering, parent linkage, timing, difficulty, proof-of-work, authorization, commitment and issuance checks. Rejected transitions must not partially alter ledger state. Transaction selection in the current mempool sorts candidates by fee and skips conflicts; fees are nevertheless burned during subsidy eras.

A checkpoint is a trust decision, not finality magic

The client refuses histories conflicting with its compiled checkpoint and rewinds beyond its bound. These rules constrain which forks it can adopt; they do not prevent an adversary from mining a competing history or guarantee automatic recovery from a deep disagreement. Checkpoint-anchored replay can also skip costly verification of a historical prefix.

Sources [1] [4] [14]

07 / Issuance and fees

A monetary schedule written in integers

No premine, no tail emission, and a ceiling that the integer schedule never quite reaches.

The initial subsidy is 6 NIGHT per block. Each paying era contains 7,500,000 blocks. Integer truncation eventually reduces the subsidy to zero: there are 30 paying eras, with total scheduled issuance of 89,999,999.25 NIGHT. The 90,000,000 ceiling is therefore not a promised terminal balance.

A fair-launch rule does not guarantee a fair distribution of ownership. Access to hardware, energy, information and early participation still matters. Likewise, a fee-only future does not guarantee an adequate security budget: demand for settlement and the economics of securing it remain open empirical questions.

Sources [1] [3] [4]

08 / Exact emission schedule

Every era, down to the last dark

All figures are derived using integer darks, not floating-point approximations of a geometric curve.

Era e covers heights e x 7,500,000 through (e + 1) x 7,500,000 - 1. At height 225,000,000 the scheduled subsidy is zero. Fees burned in earlier eras are not reissued. Actual circulating supply can therefore be lower than the cumulative issuance shown.

Sources [1] [3]

09 / What observers can learn

Privacy is a threat model, not a slogan

Hiding amounts and addresses is meaningful. It is not the same as erasing every relationship or concealing every network interaction.

Aggregation is not graph erasure

Blocks merge and sort inputs, outputs and kernels rather than retaining their original transaction grouping. Observers who saw transactions before aggregation may retain that grouping. Low activity also limits the ambiguity a block can provide. A block containing a single payment is not a large anonymity set.

Cut-through is not applied in this construction. Inputs retain explicit authorization under one-time output keys. Simply removing created-and-spent components would discard evidence needed by the present validation design. This is a constraint of this implementation, not a proof that every future non-interactive design must make the same trade-off.

Sources [2] [3] [5] [11]

10 / View keys and receipts

Disclosure belongs to the holder

Proving one payment should not require handing over the ability to spend or the history of every payment.

A view key contains the scan secret and spend public key. It enables the holder to identify and open matching outputs without the spend secret. Treat it as continuing access to sensitive financial information, including future matching outputs. It is not a harmless public identifier or a revocable web-session token.

A receipt discloses an individual commitment opening and a signature by the address's spend key. Verification checks the opening and signature. A verifier still needs appropriate chain evidence to establish inclusion and confirmation; the receipt alone does not establish that the output remains unspent.

A recipient should ask what the verifier actually needs before sharing a view key. A receipt can support reconciliation or evidence of a specific transfer; it is not a legal attestation, identity certificate or guarantee of exclusive ownership. Time-window proofs and balance lower bounds remain research objectives, not current receipt features.

Sources [2] [7] [11]

11 / Core and web wallet

Self-custody across two interfaces

The same asset is available through different operating models, with different failure modes.

Recovery words are a specific format

Nightfall encodes its 32-byte wallet seed directly as 24 BIP-39 words. It does not derive that seed using BIP-39's PBKDF2 wallet-seed procedure, and it does not support a BIP-39 passphrase or '25th word'. The familiar word encoding does not imply Bitcoin or Ethereum wallet compatibility. Do not reuse another wallet's phrase.

The phrase recovers key material, not every piece of application state. Contacts, labels and preferences require separate treatment.

Wallet interfaces must distinguish spendable, pending and immature funds. A retry is a rebroadcast attempt, not evidence of confirmation. Back up recovery words offline, protect the device and verify the destination before signing.

Sources [7] [2] [11] [16]

12 / Network and light access

Propagation without pretending it is anonymity

Privacy, availability and resource limits must be evaluated together.

Native peers exchange bounded newline-delimited JSON messages over TCP. Handshakes check the network, wire version and genesis. The implementation caps individual P2P messages at 4 MiB and serialized blocks at 2 MiB. These ceilings are defenses against some resource-exhaustion paths, not a complete denial-of-service analysis.

Dandelion-class relay, accurately described

A locally originated transaction initially takes a stem path. Relays probabilistically continue stemming, with a configured probability of 90%, or fluff to a wider set. The current session-based path records an embargo of 12-28 seconds and later fluffs transactions still retained in the mempool. A fallback path for absent live sessions has different delivery behavior.

These mechanisms are inspired by Dandelion research; the paper's formal guarantees cannot simply be assigned to this implementation. Topology, adversarial peers, timing and fallback behavior all matter. Delivery still depends on connectivity, and pending-send retry logic remains relevant.

Sources [1] [5] [11] [15]

13 / Storage and bootstrap

Synchronization is part of the trust model

Faster delivery of chain data should not be confused with stronger evidence that the data is correct.

The client supports binary chain storage as well as legacy JSON storage. A disk-format change is not a consensus change: block identity is not defined by the choice between those encodings. Operating-system data-directory locks prevent concurrent writers; they neither encrypt keys nor defend against a compromised local account.

Bootstrap archives reduce the work of obtaining historical bytes. A checksum confirms agreement with the published checksum, not the honesty of an operator who controls both. The archive is not an independent trust anchor. Its contents remain subject to the client's import and replay policy.

Trusted replay must be named

Local validation records and checkpoint-anchored replay can avoid repeating expensive checks. The checkpoint optimization requires a reached mainnet pin with the expected hash. NIGHTFALL_NO_ASSUME_VALID disables that checkpoint-based optimization, not every use of previously validated local state. 'Every proof is checked on every startup' would be inaccurate.

Pruned operation retains the state and recent history needed by the supported local policy, including the last 500 block bodies. It cannot replace an archival peer for all historical or light-API requests. If the evidence needed to trust pruned local state is invalid, omitted history may need to be obtained again.

Sources [4] [6] [11]

14 / Withdrawn interoperability

Atomic swaps: built, reviewed, withdrawn

A NIGHT/BTC atomic swap was implemented, reviewed, and withdrawn before 1.0.0. The reason is a property of the chain, not a defect that was fixed.

The experimental protocol coordinated Bitcoin P2WSH 2-of-2 transactions, ECDSA adaptor signatures, relative-timelock abort paths and a shared NIGHT spend condition, with a cross-curve proof connecting the two cryptographic domains. It worked. It is not shipped and it is not scheduled.

Nightfall has no script language, and that property is what makes the chain private: outputs are commitments and signatures, not programs, so there is no place to express “return this after a deadline”. A Bitcoin lock can refund itself on a relative timelock; a NIGHT lock cannot, and cannot be made to without changing what the chain is. Every swap construction available here is therefore asymmetric, and the asymmetry is where the losses live.

The outstanding fee work was not a patch: raising a fee changes a signature that had to exist before either side funded anything, so a correct treatment is a second protocol — and a finite fee ladder still cannot guarantee inclusion. A source review on 17 September 2026 then found four confirmed defects in an implementation that already looked finished; the defect rate was the finding.

The removal is a wallet change: no consensus rule, protocol version, genesis parameter or emission value was altered. The wallet database refuses unknown fields, so the swap journal field and its guards remain defined and a file written by an experimental build still opens. Nothing replaces the feature.

Sources [8] [9] [11]

15 / Verification and review

Evidence with a defined scope

A useful assurance statement names what was tested, against which source, and what was not covered.

The internal review dated 8 September 2026 records a targeted Rust 1.98.0 test run executed on 7 September across ledger, consensus, storage, wallet and the then-present swap packages. The totals above are evidence from that review, not a fresh full-workspace run performed for this whitepaper, and they predate the removal of the swap subsystem.

The nine ignored cases include a performance measurement, a long soak and Bitcoin-node-dependent integration tests. They are not counted as passes. The review did not establish a fresh Windows runtime assessment, external cryptographic proof, full dependency/CVE audit, server penetration test or active mainnet attack analysis.

Native implementation claims are anchored to v1.0.4 and selected code paths were checked against outdated prose. Website configuration and the September review are separately dated; the live site is not part of that release baseline.

Sources [11] [3] [4] [8]

16 / Security and economic limitations

The risks that govern deployment

Read these as present constraints on use, not as problems a future roadmap has already solved.

This is not an exhaustive risk inventory. No token price, exchange listing, liquidity, investment return or adoption forecast is asserted. Protocol rules and user demand cannot guarantee each other. Users should not infer suitability for a particular financial or operational purpose from the visual polish of a wallet or document.

Sources [11] [9] [4]

17 / Project boundaries

Minimal authority, visible responsibility

No monetary administrator does not mean no human influence. Software and operational decisions still need accountability.

The current monetary construction has no premine, special treasury allocation or administrative mint/freeze credential. That is narrower than saying nobody can influence the system. Maintainers choose releases, operators run infrastructure, miners choose which transactions to include and users choose which software and chain rules to accept.

History cannot be redesigned away

Nightfall has discarded earlier chains. The v4 monetary construction was unsound; later iterations exposed engineering and emission-design problems. The current v8 genesis is a distinct chain. Earlier-genesis balances do not automatically migrate into it. This history should remain discoverable and should make future compatibility decisions more deliberate.

In this implementation, protocol-version configuration contributes to genesis identity, while wire version gates network compatibility. A software-version increment does not by itself imply either kind of change. Release documentation must distinguish client updates from chain resets and must not silently reinterpret historical balances.

Sources [1] [10] [11]

18 / Research and engineering priorities

Progress measured by acceptance criteria

These are proposed work tracks. None is a promise of a feature, a deadline or a future mainnet activation.

Performance claims should publish hardware, workload, implementation version and verification cost. Privacy claims should publish the adversary and observation model. A proposed optimization that changes which evidence a node checks is also a trust-policy change, even if the user interface calls it faster sync.

Sources [11] [9] [4] [5]

19 / Parameters and terminology

Implementation reference

A compact reference for readers moving from this paper to code. The tagged implementation remains authoritative for exact behavior.

UTXO: an unspent output recorded by the ledger. Commitment: a group element representing a hidden value and blinding factor. Kernel: a signed record of public transaction terms and excess. Range proof: evidence that a committed value is within the allowed interval. Coinbase: the miner's permitted output, subject to maturity. Reorganization: replacement of a suffix of accepted history. Checkpoint: a compiled height/hash constraint. Bootstrap: a delivery format for historical chain data, not a new consensus authority.

A view key enables observation, not spending. A receipt proves a limited cryptographic statement, not continuing unspent status. 'Live' denotes a reported or running state; it does not mean independently audited or irreversible.

Sources [1] [3] [4] [7]

20 / Reproducible references

Sources and document scope

Implementation references are pinned to v1.0.4. The website review is dated separately. External literature describes primitives, not an endorsement of Nightfall.

1. Protocol identity, monetary constants and PoW parameters
2. Native cryptography: commitments, stealth, signatures and mnemonic encoding
3. Ledger validation, UTXO authorization and exploit regressions
4. Consensus, emission, checkpoints, replay and mempool selection
5. Node runtime: session relay, embargo timers and network behavior
6. Storage implementation and operating-system directory locks
7. Wallet keys, state and receipt implementation
8. Why atomic swap was withdrawn before 1.0.0
9. Swap loss model, kept as the historical record
10. Project history and discarded chain epochs
11. Internal security review, 8 September 2026 - scope and open risks
12. RFC 9496: The ristretto255 and decaf448 Groups (2023)
13. Bunz et al., Bulletproofs: Short Proofs for Confidential Transactions and More (2018)
14. RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications (2021)
15. Fanti et al., Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees (2018)
16. BIP 39: Mnemonic code for generating deterministic keys

Editorial status: English edition, 18 September 2026; AI-assisted source synthesis and design revision. Supersedes the 0.9.5 edition, whose chapter on atomic swaps describes a feature that has since been withdrawn. No independent audit was performed in creating this document. The PDF and HTML edition are generated from the same content source.