Quantum
Privacy
Protocol
This white paper presents a Layer 1 blockchain protocol designed to support smart contracts with privacy and scalability. Key features include privacy within the UTXO model, smart contracts with efficiently verifiable STARKs, native Layer 2 compatibility, fast synchronization, a small storage footprint, Nakamoto proof-of-work, post-quantum cryptography, and a rules-based disinflationary emission with a small constant tail.
The combined market cap of cryptocurrency networks numbers in the trillions of dollars. The industry's rapid expansion from Bitcoin's humble beginnings attests to the market demand for an alternative to fiat money.
The horizontal expansion of this industry indicates more than just cryptocurrencies' increasing share of the money and financial markets, it indicates that the innovators and market participants disagree about the most urgent problems to be solved. Three qualities at the center of this market debate are privacy, programmability, and scalability.
Privacy
Zero-knowledge proof systems enable a prover to run a program and prove to the verifier that it was executed correctly, even while all or part of the input remains secret. It is a tool seemingly tailor-made for blockchains, where network participants need to verify protocol contributions and where users need to protect cryptographic key material or other sensitive information.
The privacy-friendly coins ZCash and Monero achieve privacy by using zero-knowledge proofs to obfuscate the origins of transactions. This decoy strategy is fundamentally limited, it is never possible to prune the unspent transaction output (UTXO) set, because spent transaction outputs are useless as decoys. Storage requirements will grow linearly with the total number of transactions in all of the currency's history.
By using scalable transparent arguments of knowledge (STARKs), the same flexibility can be achieved without sacrificing non-interactivity. Proof-carrying data (PCD) allows network participants to generate STARKs that attest to the integral computation of a protocol contribution and the successful verification of a similar STARK received from a third party. Any transaction comes with a STARK proving its authenticity; coinjoin or cut-through operations come with corresponding operations on the component STARKs.
Nyks treats shielded transactions as the default baseline, strong fungibility starts with a uniform anonymity set, and pairs that baseline with compliance attestation: to satisfy a service provider's published policy, the holder answers through an accountable attestor, either by revealing the relevant transaction context or by proving that it satisfies the policy without revealing it. The provider receives a signed certificate, never the holder's data. Holders prove what they need to prove, and nothing more, without weakening the rest of the network.
Programmability
Ethereum paved the way towards a smart contract ecosystem. However, Ethereum's account model of transactions is incompatible with the private UTXO model. Rather than lifting privacy technologies to the account model, we lift programmability to the UTXO model, without sacrificing the privacy protections.
There are two criteria to be satisfied whenever a UTXO is spent:
- The lock script ensures the proper evolution of ownership. This script is satisfiable only by the owner of the coin, and only if the right criteria for transfer are met. Neither the lock script nor its satisfying witness appear on the blockchain.
- The type script ensures the correct evolution of state for all tokens involved in the transaction. Every token type has a unique type script. States of native currency tokens are just numbers; their type scripts ensure no inflation except in the coinbase transaction and only in accordance with monetary policy.
This model of programmable UTXOs has been shown to be functionally equivalent to Ethereum's account model, with the UTXO model being more conducive to scalability and more compatible with privacy-enhancing technologies.
The native-currency type script is live today. User-defined token types and the general smart-contract layer are on the roadmap, targeted for 2027.
Scalability
The Lightning Network provides the blueprint for achieving scalability in terms of transaction throughput. Transactions should take place off chain by default, with cryptographic commitments on the blockchain to enable dispute resolution.
Nyks leverages several technologies to lighten the workload of network nodes:
- STARKs establish that arbitrarily complex lock and type scripts have satisfying arguments
- STARKs establish correct mixing of output UTXOs by the miner
- Every block carries a STARK proving its validity; recursive proofs covering the whole chain are on the roadmap
Nodes represent the set of all UTXOs concisely by a Merkle Mountain Range Accumulator (MMRA) to reduce storage space. Spendable UTXOs are circulated with an authentication path attesting to their membership. This structure obviates the need to disseminate the entire Spendable UTXO set, meaning full nodes have a constant memory footprint.
Long-Term Value & Consensus Principles
The consensus mechanism is Nakamoto-style proof-of-work. The various proof-of-stake alternatives compromise on simplicity as well as security model and have not withstood the test of time. Alternatives based on proof-of-delay or proof-of-space benefit the faster miner out of proportion to his share of consumed energy, incentivizing centralization.
All cryptographic primitives offer post-quantum security. When large-scale quantum computers are built, they will undermine the security of other blockchain projects, but not Nyks Network. The mere threat posed by quantum computers hampers the capacity of any blockchain that is not quantum-secure to store value.
The monetary policy is fixed by protocol rule: a 30% premine allocated in the genesis block, a public schedule that declines about 4.55% per monthly generation from 12,800 NYKS per block, and a small constant tail of 256 NYKS per block thereafter.
Hard forks undermine the immutability of the blockchain history as well as the monetary policy. They set precedents for centralization and control. The only justification for an unanticipated hard fork is a cryptographic vulnerability or similar emergency.
Cryptographic Primitives
A proof system is a protocol between a prover and a verifier in which the prover convinces the verifier that a certain computational claim is correct. The claim is represented by a program, an input, and an output; it states that the output was obtained integrally from the input. Proof systems can be made non-interactive: the verifier has a fourth argument, which is a string of cryptographic data called the proof.
zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge) are proof systems that are both scalable (fast to verify) and transparent (no trusted setup). Nyks uses the Triton VM, a virtual machine purpose-built for generating efficient STARK proofs, with instructions optimized for common cryptographic operations.
The Tip5 hash function is designed specifically for the STARK proving context. It operates over a prime field and has optimized performance within the Triton VM, resulting in proofs that are significantly smaller and faster to generate than with general-purpose hash functions.
All cryptography relies only on hash functions and information-theoretic arguments, immune to Shor's algorithm. There are no elliptic curves. No RSA. The protocol is secure against quantum adversaries by design.
A transaction in Nyks consists of a public kernel and a proof. The kernel contains:
- inputs, the removal records that consume the spent UTXOs in the mutator set
- outputs, the addition records, cryptographic commitments to the newly created UTXOs
- announcements, public data payloads carried by the transaction, for example encrypted notifications that let recipients detect incoming funds without any out-of-band channel
- fee, the amount offered to the miner, half of which is time-locked for one generation
- coinbase, present only in the mining transaction
- timestamp, and the mutator set hash, a commitment to the UTXO-set accumulator state the transaction targets
- proof, a zk-STARK attesting to the validity of the entire transaction
UTXO Structure
Each UTXO contains a coins field (a map from token type to amount), a lock_script commitment, and a type_script commitment for each token type in coins. The script data and randomness are never revealed on-chain, only their cryptographic commitments are published, and a STARK proves that the scripts were executed correctly.
Transaction Validity
Base Case. A transaction is valid if its proof is a valid zk-STARK establishing that for all input UTXOs, the lock script accepts and each token type's type script accepts.
Merge Step (Coinjoin & Cut-Through). A transaction is also valid if its proof attests that it was formed by merging two other valid transactions. This captures coinjoin (combining transactions) as well as cut-through (eliminating intermediate UTXOs), and is how a block's transactions are folded into a single block transaction.
The mutator-set membership proofs of input UTXOs are intentionally not part of the transaction. This ensures the same transaction remains valid even if it is not confirmed while other transactions update the accumulator, and enables cut-through of unconfirmed chains of transactions.
Block Structure
A block in Nyks contains one confirmed transaction (the merger of all transactions in that block), the updated UTXO-set accumulator, and a STARK proving consensus-rule compliance. Key fields:
Block Parameter Adjustment
Producing a block requires computing STARKs. To avoid benefiting faster miners over more energy-efficient ones, Nyks fixes the expected block interval to a constant time sufficient to produce the STARKs. The variable parameter is the maximum block size, which increases as long as the orphan rate is below a target threshold. Difficulty adjusts to maintain the constant target expected block interval.
Fast Synchronization (Roadmap)
Recursive block proofs are on the roadmap: each block's proof will additionally establish that the previous block was valid and that the cumulative proof-of-work field is correct, allowing newcomers to synchronize in time independent of the age or popularity of the network by simply choosing the block with the largest cumulative proof-of-work. Until then, blocks carry individual validity proofs and nodes verify the chain block-by-block.
Two-Stage Mining
Nyks introduces a two-stage mining process that specializes economic roles:
Block Composers
Produce STARK proofs for transaction validity using the Triton VM. Composers decide unilaterally what proportion of the block reward to claim as composer fee, the remainder is left as guesser fee.
Proof Guessers
Contribute traditional proof-of-work computation to seal blocks produced by Composers. Both roles earn mining rewards, creating a competitive market that specializes hardware and skills.
Half of every mining reward is time-locked for one generation, approximately one month, aligning miner incentives with protocol health. The remaining 50% is spendable immediately.
A third role, the upgrader, raises the proof quality of pending transactions, merging and strengthening their STARKs so composers can assemble blocks efficiently. Upgraders are compensated from transaction fees. The upgrader is not the transaction prover; initial proving happens at the wallet or composer, and upgraders improve what already exists.
The Nyks native currency token type is the hash of a type script that enforces no inflation except in the coinbase transaction. The mining reward logic is as follows:
This logic references the following parameters:
- premine_total: the genesis block carries a single coinbase output of 1,260,000,000 NYKS (30%), assigned by protocol rule to the development multisig. The premine occupies no mined blocks.
- initial_reward / decay / generation_blocks: public mining starts at block 1 at 12,800 NYKS per block, declining about 4.55% per generation of roughly 6,848 blocks (one month at the 6.4-minute block target).
- tail_reward: from generation 84 the reward holds at a constant 256 NYKS per block, indefinitely. The main schedule references a total of 4,200,000,000 NYKS (30% premine, 70% mined); the tail then grows supply very gradually, so there is no absolute cap.
Representative points on the public mining schedule, in NYKS. The 1,260,000,000 premine is additional and not part of these figures:
After the main schedule, the constant tail of 256 NYKS per block continues indefinitely; there is no absolute supply cap.
The 30% premine (1,260,000,000 NYKS) is allocated in the genesis block to the development multisig and vests in two tranches with six-monthly unlocks: 15% of supply (630,000,000 NYKS) over two years and 15% (630,000,000 NYKS) over five years.
This section describes the planned programmability layer. Smart contracts, tokenization, and channel networks are on the roadmap, targeted for 2027, and are not live today.
Nyks provides the base layer. A lot of functionality will come from optional plugins or apps that form overlay networks whose communication typically takes place off-chain. Nyks clients will provide access to an app store. Apps will be written in Triton, the purpose-built language for the Triton VM, augmented with instructions for remote procedure calls into the base client.
The Triton VM provides containment for nefarious app exploits, hardware-independent execution, and free compilation to zk-STARK prover and verifier. Formal verification efforts on the Triton VM carry over to all deployed apps.
Tokenization & Non-Fungible Tokens
Nyks is designed to support tokenization natively as a consequence of the explicit type script. A token is a tradeable quantity of units that are an alternative to the native currency, but indistinguishable from them in terms of operational mechanics and privacy. Two type scripts can define distinct token types despite inducing identical evolutionary logic, the type script incorporates a unique identifier that has no effect on the logic.
A non-fungible token (NFT) can be implemented using a unique token type for every concrete NFT. NFTs are anchored to a central point which is itself a token of a special type, an anchor token whose state represents an integer incremented by one every time it is spent. The NFT inherits this state as a unique identifier that cannot be changed. Ownership is changed via ordinary lock scripts, making NFTs indistinguishable from other tokens on the network except by those who know the secret keys that unlock them.
Private Multi-Token Channel Networks
Payments can take place entirely off-chain between any pair of participants in a payment channel network, provided there is a path connecting them with sufficient capital committed. Any token type, native Nyks currency or any custom user-defined token, can be transferred over a supporting channel network.
Channels can be closed in three ways: mutual close (both parties consent, no restrictions), unilateral close (one party initiates, subject to a disputation period), or contested close (the other party disputes within the disputation window).
Hash time lock contracts (HTLCs) enable in-progress multi-hop payments across the network. The consensus mechanism is leveraged to solve the data availability problem: dispute transactions can be broadcast before a contested transaction is confirmed, and cut-through eliminates the intermediate UTXO while preserving all public data needed to ground the dispute.
Flash Arbitrage
An arbitrage opportunity occurs when a cycle of trades results in a net positive position without risk. In a multi-token channel network, the arbitrage trader does not need to take out a loan, instead they merely coordinate a cycle of balance updates and activate them all in one atomic off-chain trade. Every node becomes a high-frequency trading marketplace.
Cryptosecurities & Derivatives
Nyks enables complex financial instruments to be executed mechanically, disintermediating middlemen. Derivative contracts need parties, contract logic, and market data (typically provided through an oracle). These components have a straightforward translation into the logic of Nyks' smart contract ecosystem.
For mortgage-style cryptosecurities: ownership is tokenized as an NFT; the bank and borrower simultaneously publish transactions creating the loan and deposit account; the lock script on the house NFT constrains it to be spendable by Alice if all monthly payments were made, or by the bank if she missed a payment. Multiple lenders can participate without trusting each other through security tokens.
Dispute resolution happens chiefly through announcements, the public data payloads carried by transactions. One possible effect of a lock script is to require the passage of a certain amount of time before a UTXO can be spent after its generating transaction is confirmed. This time window gives the counterparty the opportunity to file a dispute by broadcasting another transaction.
The disputation transaction spends the same UTXO but avoids the temporal criterion by activating an alternate spending policy, for instance, one that involves a signature provided by the counterparty. If the disputation transaction is broadcast before the disputed transaction is confirmed, a cut-through operation can eliminate the intermediate UTXO. This operation does not eliminate announcements or their data, which provides the counterparty with cryptographic evidence needed to ground their dispute.
If the disputation transaction is itself disputable, there will be another time window and opportunity for dispute. In this way, the consensus mechanism is leveraged to solve the data availability problem.
The following summary is provided for informational purposes only, does not constitute legal, regulatory, or investment advice, and should not be relied upon as such. It contains forward-looking statements regarding functionality that remains under development. References to the regulatory framework of the European Union are illustrative and without prejudice to the determinations of competent authorities and supervised entities, which retain sole discretion over the treatment of any given crypto-asset. Prospective participants should obtain independent professional advice in their applicable jurisdiction.
Applicable Framework
Nyks has been architected with deliberate regard for the emerging European Union framework governing crypto-assets and the prevention of money laundering. Three instruments are of principal relevance to an asset of the nature of NYKS:
- Regulation (EU) 2023/1114 (MiCA), which governs the offering of crypto-assets and the authorisation and supervision of crypto-asset service providers (CASPs). For a crypto-asset that constitutes neither an asset-referenced token nor an e-money token, an offer to the public is effected by way of a notified white paper, and not by means of prior approval or the issuance of a certificate.
- Regulation (EU) 2024/1624 (the Anti-Money-Laundering Regulation), which, with effect from July 2027, prescribes the obligations of CASPs and financial institutions in respect of anonymity-enhancing crypto-assets and the conduct of customer due diligence.
- The Transfer of Funds Regulation (the "Travel Rule"), which requires that prescribed originator and beneficiary information accompany transfers of crypto-assets effected by CASPs.
Design Aligned With Supervisory Objectives
Nyks affords confidentiality by default through zk-STARKs, a transparent proving system that requires no trusted setup and thereby removes a recognised source of systemic risk. Critically, the protocol is engineered so that confidentiality and accountability are complementary rather than mutually exclusive. The mechanism by which this is achieved is the compliance-attestation framework.
Under the attestation framework, a holder satisfies a service provider's published screening policy through an accountable attestor drawn from a public registry: the holder either reveals the relevant transaction context to the attestor, or proves that the context satisfies the policy without revealing it. The attestor issues a signed, time-bound certificate bound to the policy; the provider verifies the certificate and receives nothing else. No balances, counterparties, or histories reach the provider. This is the primary means by which auditable privacy operates in Nyks: the holder demonstrates what the policy requires, and nothing more.
The attestation framework is complemented by, and independent of, per-wallet viewing keys, which a holder may grant to a designated auditor, counterparty, or regulated service provider to confer verifiable read access to a wallet's transaction history where a fuller disclosure is appropriate. Together these capabilities position Nyks to facilitate, rather than to frustrate, the compliance objectives that underpin the applicable regime.
Building upon the foregoing, the protocol roadmap contemplates the full realisation of the attestation framework, an attestor registry and compliance certificates, operating off-chain at the regulated boundary, namely, the juncture at which value enters or departs the custody of a CASP. This layer is intended to enable a regulated entity to verify, to the standard required of it, the facts its policy demands about the assets it services, while preserving the on-chain confidentiality to which ordinary users are entitled.
For policies that admit it, the holder's wallet can produce a zero-knowledge proof answering a narrow question, for example that funds were held for a required period, without opening any history; the attestor verifies the proof and certifies the result. A certificate may also reference an earlier certificate, so assurance can accumulate across transfers without any party exposing the underlying data. By design, a certificate is capable of being required at the on-ramp or off-ramp as a condition of service, affording supervised intermediaries a dependable basis on which to discharge their obligations.
The functionality described in this addendum is forward-looking and remains under development. It has not been finalised, specified, or deployed as at the date of this paper, and no representation is made as to its eventual form, timing, or regulatory sufficiency, which shall in all cases be subject to the assessment of competent authorities and qualified counsel.
Forward-Looking Compliance Posture
Nyks has been conceived from inception as an instrument of auditable privacy, in the conviction that confidentiality and regulatory accountability are reconcilable objectives. The attestation framework contemplated by the roadmap, together with the per-wallet viewing keys available today, is directed toward enabling supervised intermediaries to service the asset in a manner consistent with their obligations. The protocol advances no representation of present compliance or certification; rather, it sets out a considered and good-faith trajectory toward servicing by regulated entities, to be realised in cooperation with competent authorities and professional advisers as the framework matures.
Auditable privacy,
quantum-proof from day one.
Nyks Network resolves the three hard problems of blockchain, confidentiality, programmability, and scalability, simultaneously at the base layer. By integrating zk-STARKs natively, lifting programmability to the UTXO model, and using the Mutator Set (MMRA) for constant-footprint storage, Nyks delivers a protocol the post-quantum age demands: shielded by default, auditable on demand, programmable by design, and scalable forever.