| [Table 2] Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens | |||||
| Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens [abstract] | |||||
| General information | |||||
| 00 Table of content | boolean true | ||||
| 01 Date of notification | date | ||||
| 02 Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 | boolean true | ||||
| 03 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 | boolean true | ||||
| 04 Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114 | boolean true | ||||
| 05 Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114 | boolean true | ||||
| 06 Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114 | boolean true | ||||
| SUMMARY | |||||
| 07 Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114 | boolean true | This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto –asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law. |
|||
| 08 Characteristics of the crypto-asset | textBlock | NYKS is a fungible utility-type native protocol asset. Each unit of NYKS is identical and interchangeable with another unit of NYKS. NYKS is used to pay transaction and network fees, to transfer confidential value on the Nyks Network and to reward miners who actively participate in proof-of-work mining. NYKS does not have an absolute maximum supply. The protocol has a main supply schedule of approximately 4,200,000,000 NYKS, followed by a constant tail emission of 256 NYKS per block. Accordingly, the supply of NYKS increases over time. NYKS' characteristics are the following: a. The token is transferable on-chain on the Nyks Network, subject to applicable law, protocol rules, wallet compatibility and any trading platform rules and fees. Admission to trading, if any, occurs on independent third-party platforms that VINU LTD does not operate or control. b. NYKS is non-interest bearing. Holders may bear network transaction fees when transferring or otherwise using NYKS on the Nyks Network. c. NYKS has no physical form and no intrinsic financial value or guaranteed pricing, and no person makes any representation or commitment regarding its value, price performance or liquidity. d. NYKS is non-refundable and not redeemable for any assets of VINU LTD, Rhinobob LLC or any other entity or organisation, and cannot be exchanged with VINU LTD for cash, crypto-assets or any payment obligation. e. Holding NYKS grants no rights in or to VINU LTD, Rhinobob LLC or any affiliate, or their revenues or assets, including, without limitation, any right to dividends, revenue, profit share, shares, ownership rights, securities, distributions, redemption, liquidation proceeds, proprietary rights, intellectual-property rights, accounts, financial statements, management rights, governance rights over VINU LTD, rights to appoint directors or any other financial, legal or equivalent right. f. NYKS does not represent a loan to, or debt of, VINU LTD or any affiliate; it is not intended to represent indebtedness, and there is no expectation of profit, interest or monetary yield from holding NYKS. g. Mining rewards, where received, require active proof-of-work mining and network-security contribution. They do not arise from mere holding of NYKS and do not constitute staking rewards, dividends, interest, profit participation, revenue sharing or guaranteed return. h. NYKS is not intended to represent rights under a contract for differences or any other contract designed to secure a profit or avoid a loss. i. NYKS is not electronic money or an e-money token, a payment instrument, a security, a commodity, a bond, a debt instrument, a unit in a collective investment undertaking or any other financial instrument or investment product. j. NYKS is not an asset-referenced token or stablecoin. It does not purport to maintain a stable value relative to any asset or currency; it is not pegged to, or backed by, any reserve of assets; it confers no redemption right or claim against VINU LTD or any affiliate; and it uses no stabilisation mechanism, whether algorithmic or otherwise. |
|||
| 09 Further information about utility tokens | textBlock | The main utilities of NYKS are the following: Network Fee and Transaction Utility: NYKS is required to pay transaction and network fees on the Nyks Network. Holders may use NYKS to submit valid transactions, subject to protocol rules, wallet compatibility and network conditions. Confidential Value Transfer: NYKS may be used to transfer value on the Nyks Network using confidential or shielded transaction functionality, subject to the technical limits of the protocol and compatible wallet software. Mining and Network-Security Participation: NYKS may be earned by miners who actively participate in proof-of-work mining and contribute to network security. Mining rewards are protocol-level rewards for active mining activity. They do not arise from mere holding of NYKS and do not constitute staking rewards, dividends, interest, profit-sharing, revenue-sharing or guaranteed return. No Other Goods or Services: Based on the information provided, NYKS does not provide access to any goods, services, features or benefits outside the Nyks Network. In particular, NYKS does not confer ownership, equity, creditor rights, governance rights over VINU LTD, redemption rights, profit participation, revenue-sharing rights, issuer-asset rights or treasury rights. Restrictions on Transferability: NYKS is generally transferable on the Nyks Network, subject to applicable law, protocol rules, wallet compatibility and any restrictions imposed by trading platforms on which NYKS may be admitted to trading. Trading platforms may impose KYC, AML, CFT, sanctions, jurisdictional or other access restrictions in accordance with applicable law and their internal policies. VINU LTD imposes no contractual transfer restrictions on holders of NYKS. |
|||
| 10 Key information about the offer to the public or admission to trading | textBlock | Any future offer of NYKS to the public by another person, or any separate application by another person for admission of NYKS to trading based on this crypto-asset white paper, would be distinct from the present admission-only structure. Such person may rely on this white paper only after VINU LTD has expressly provided its written consent to its use in accordance with Article 5(4) of Regulation (EU) 2023/1114. Unless and until such written consent is granted, no person is authorised by VINU LTD to use this white paper for an offer to the public or a separate application for admission to trading. |
|||
| Part A - Information about offeror or person seeking admission to trading | |||||
| A.1 Name | text | ||||
| A.2 Legal form | text | ||||
| A.3 Registered address | |||||
| Registered addess | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| A.4 Head office | |||||
| Head office | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| A.5 Registration date | date | ||||
| A.6 Legal entity identifier | LEI | ||||
| A.7 Another identifier required pursuant to applicable national law | text | ||||
| A.8 Contact telephone number | text | ||||
| A.9 E-mail address | text | ||||
| A.10 Response time (days) | integer | ||||
| A.11 Parent company | text | ||||
| A.12 Members of the management body | |||||
| Member #1 | id | 1 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| A.13 Business activity | textBlock | ||||
| A.14 Parent company business activity | textBlock | ||||
| A.15 Newly established | boolean | ||||
| A.16 Financial condition for the past three years | textBlock | ||||
| A.17 Financial condition since registration | textBlock | No audited financial statements or unaudited accounts are available or will be provided for the purposes of this white paper. As at the date of this white paper, VINU LTD has no material debts, liabilities, commitments or funding risks to disclose. Continued development, maintenance, legal, regulatory, audit and operational expenditure depends on funding provided by the founders and the resources available to VINU LTD. |
|||
| Part B - Information about issuer, if different from offeror or person seeking admission to trading | |||||
| B.1 Issuer different from offerror or person seeking admission to trading | boolean | ||||
| B.2 Name | N/A | . | |||
| B.3 Legal form | N/A | . | |||
| B.4 Registered address | |||||
| Registered addess | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| B.5 Head office | |||||
| Head office | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| B.6 Registration date | N/A | . | |||
| B.7 Legal entity identifier | N/A | . | |||
| B.8 Another identifier required pursuant to applicable national law | N/A | . | |||
| B.9 Parent company | N/A | . | |||
| B.10 Members of the management body | |||||
| Member #1 | N/A | . | |||
| Identity | N/A | . | |||
| Business address | N/A | . | |||
| Function | N/A | . | |||
| B.11 Business activity | N/A | . | |||
| B.12 Parent company business activity | N/A | . | |||
| Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | |||||
| C.1 Name | N/A | . | |||
| C.2 Legal form | N/A | . | |||
| C.3 Registered address | |||||
| Registered address | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| C.4 Head office | |||||
| Head office | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| C.5 Registration date | N/A | . | |||
| C.6 Legal entity identifier | N/A | . | |||
| C.7 Another identifier required pursuant to applicable national law | N/A | . | |||
| C.8 Parent company | N/A | . | |||
| C.9 Reason for crypto-asset white paper preparation | N/A | . | |||
| C.10 Members of the management body | |||||
| Member #1 | N/A | . | |||
| Identity | N/A | . | |||
| Business address | N/A | . | |||
| Function | N/A | . | |||
| C.11 Operator business activity | N/A | . | |||
| C.12 Parent company business activity | N/A | . | |||
| C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A | . | |||
| C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A | . | |||
| Part D - Information about other token project | |||||
| D.1 Crypto-asset project name | text | ||||
| D.2 Crypto-asset name | text | ||||
| D.3 Abbreviation | text | ||||
| D.4 Crypto-asset project description | textBlock | NYKS is the native crypto-asset of the Nyks Network. It is used to pay transaction and network fees, transfer confidential value within the network and reward miners who actively secure the network through proof-of-work mining. Confidential or shielded transactions, zk-STARK validity proofs and viewing keys are live features. Smart-contract functionality, optional time-locked insurance or recovery outputs and a privacy-preserving compliance-attestation framework are planned features. The planned compliance-attestation framework is intended to allow a holder to demonstrate compliance with a policy accepted by a crypto-asset service provider without providing the holder's underlying transaction data to that service provider. A public registry would identify admitted third-party attestors, which may be organisations or individuals admitted on an open and merit-based basis, together with their public keys, supported policies, jurisdiction, audit status and revocation status. A holder would select an attestor accepted by the relevant service provider and grant the attestor scoped access through a viewing key or answer a narrowly defined challenge program. The attestor would perform the relevant check and issue a signed, time-bound certificate identifying the applicable policy and policy version. The service provider would verify the certificate, the attestor's signature and registry status without receiving the holder's amounts, balances, counterparties, transaction history or viewing keys. The attestor registry, compliance certificates and related off-chain tooling are planned for Q1 2027 and are not yet live. Their effectiveness will depend on the availability of qualified attestors and acceptance by crypto-asset service providers. Earlier non-association-proof and off-chain per-coin provenance-tooling concepts have been removed from the current design and superseded by the planned third-party compliance-attestation framework. The scope, timing and availability of all planned features remain subject to technical implementation, testing, security review, regulatory developments and operational factors. No planned feature is guaranteed. |
|||
| D.5 Details of all natural or legal persons involved in implementation of crypto-asset project | |||||
| Person #1 | id | 1 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| D.6 Utility token classification | boolean | ||||
| D.7 Key features of goods or services for utility token projects | text | NYKS does not provide access to goods, services, features or benefits outside the Nyks Network. It does not confer staking, dividend, interest, profit-share, revenue-share, governance, redemption or issuer-claim rights. Mining rewards require active proof-of-work mining and do not arise from mere holding of NYKS. |
|||
| D.8 Plans for the token | |||||
| Description of past milestones | textBlock | The core Nyks protocol and its self-developed UTXO-based Layer-1 architecture were developed. The technical design includes Nakamoto-style proof-of-work, confidential or shielded transactions, zk-STARK validity proofs, viewing keys and the Tip5 hash function. Q2 2026 — Public testnet and core tooling The public testnet entered its implementation and testing phase. The codebase components were separated, and the Wallet SDK, CLI wallet and new address format were developed. Mempool changes intended to improve transaction-user experience were also implemented. Q2 2026 — Live protocol functionality Confidential or shielded transactions, zk-STARK validity proofs and holder-controlled per-address and per-wallet viewing keys were implemented as live protocol features. Q2 2026 — Tokenomics and issuance model The NYKS issuance model was defined. The main supply schedule is 4,200,000,000 NYKS, comprising a 1,260,000,000-NYKS premine allocated in a single coinbase output in the genesis block (block 0) to the development team's multisignature wallet and 2,940,000,000 NYKS issued through public proof-of-work mining from block 1. The mining reward begins at 12,800 NYKS per block and decreases by approximately 4.55% per monthly generation until it reaches a constant tail emission of 256 NYKS per block from generation 84. The tail emission then continues indefinitely. Q3 2026 — Upgrader and composer rework The upgrader and composer components were reworked.No public offer, ICO, presale or sale of NYKS by VINU LTD has been conducted. |
|||
| Description of future milestones | textBlock | Q3 2026 — Block explorer and additional CLI tooling The project intends to release a block explorer and additional CLI tools. Q3 2026 — Upgrader pools The project intends to introduce upgrader pools to improve work distribution. Q4 2026 — Mainnet launch The mainnet launch is targeted for Q4 2026. Q4 2026 — WASM SDK The project intends to release a WASM SDK. Q4 2026 — Prover optimisation The project intends to improve and optimise the network's proving implementation. Q4 2026 to Q1 2027 — Independent security and cryptography audit An independent security and cryptography audit is planned to commence in Q4 2026, with the audit report targeted for Q1 2027, ahead of the planned release of the compliance-attestation framework. Q1 2027 — Block-database schema optimisation The project intends to optimise the database schema used for blocks. Q1 2027 — Compliance-attestation framework The project intends to implement the attestor registry, compliance certificates and related off-chain attestor tooling. The framework will remain dependent on qualified attestors joining the registry and acceptance of the certificates by crypto-asset service providers. Q2 2027 — Additional account types The project intends to introduce additional account types, including multisignature functionality. H2 2027 — Optional insurance and recovery outputs The project intends to implement optional time-locked insurance or recovery outputs, subject to technical implementation, testing, security review and legal analysis. Q3 2027 — Issuance of native assets The project intends to enable the issuance of other native assets on the Nyks Network. This functionality does not create a wrapped, bridged or multi-chain representation of NYKS. 2027 — Smart-contract and programmability layer The project intends to develop base-layer smart-contract and programmability functionality. 2028 — Formal on-chain governance The project intends to implement a formal on-chain governance process following the planned introduction of the programmability layer. |
|||
| D.9 Resource allocation | text | a. 70% — Core protocol and software-client engineering, including prover optimisation, tooling and testnet-to-mainnet hardening; b. 15% — Infrastructure and network operations, including the public testnet, template producers and mainnet-launch readiness; c. 10% — Security and assurance, including internal review and preparation for the independent security and cryptography audit; and d. 5% — Legal, regulatory and administrative activities, including the MiCA notification process and trading-venue onboarding. |
|||
| D.10 Planned use of collected funds or other tokens | text | a. 50% — Protocol engineering, including the compliance-attestation framework, additional account types and the programmability layer; b. 20% — Security and assurance, including the independent security and cryptography audit and ongoing security reviews; c. 15% — Infrastructure and network operations; and d. 15% — Ecosystem and integration support, including the block explorer, SDKs, crypto-asset service provider integrations and related legal and administrative activities.ry compliance, operational infrastructure, admission-to-trading activities and ecosystem growth. |
|||
| Part E - Information about offer to public of other tokens or their admission to trading | |||||
| E.1 Public offering or admission to trading | enumeration | ||||
| E.2 Reasons for public offer or admission to trading | textBlock | No trading volume, liquidity, market demand, price stability or continued platform support is guaranteed. |
|||
| E.3 Fundraising target | |||||
| Target expressed in currency | monetary | EUR | |||
| Target expressed in units | decimal | ||||
| Target expressed in digital token identifier | text | ||||
| E.4 Minimum subscription goals | |||||
| Goals expressed in currency | monetary | EUR | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.5 Maximum subscription goals | |||||
| Goasl expressed in currency | monetary | EUR | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.6 Oversubscription acceptance | boolean | ||||
| E.7 Oversubscription allocation | text | ||||
| Issue price details | |||||
| E.8 Issue price | decimal | ||||
| E.9 Official currency determining issue price | enumeration | ||||
| E.9 Any other tokens determining issue price | text | ||||
| E.10 Subscription fee | |||||
| Fee expressed in currency | monetary | EUR | |||
| Fee expressed in units | decimal | ||||
| Fee expressed in digital token identifier | text | ||||
| E.11 Offer price determination method | text | ||||
| E.12 Total number of offered or traded other tokens | integer | ||||
| E.13 Targeted holders | enumeration | ||||
| E.14 Holder restrictions | text | ||||
| E.15 Reimbursement notice | boolean true | ||||
| E.16 Refund mechanism | textBlock | ||||
| E.17 Refund timeline | text | ||||
| E.18 Offer phases | textBlock | ||||
| E.19 Early purchase discount | textBlock | ||||
| E.20 Time-limited offer | boolean | ||||
| E.21 Subscription period beginning | date | ||||
| E.22 Subscription period end | date | ||||
| E.23 Safeguarding arrangements for offered funds or other tokens | textBlock | ||||
| E.24 Payment methods for other token purchase | textBlock | ||||
| E.25 Value transfer methods for reimbursement | textBlock | ||||
| E.26 Right of withdrawal | textBlock | ||||
| E.27 Transfer of purchased other tokens | textBlock | ||||
| E.28 Transfer time schedule | text | ||||
| E.29 Purchaser's technical requirements | textBlock | a. reliable internet access; b. a suitable device to manage a wallet, private keys and/or a trading platform account; c. where NYKS is accessed through a centralised trading platform, completion of the relevant onboarding, KYC/AML and account requirements; d. where NYKS is held in a self-custodial wallet, use of a wallet compatible with the Nyks network and the relevant address format; e. sufficient understanding of private-key management, irreversible transactions and network fees. |
|||
| Other token services provider characteristics | |||||
| E.30 Other token service provider (CASP) name | text | ||||
| E.31 CASP identifier | LEI | ||||
| E.32 Placement form | enumeration | ||||
| Trading platforms characteristics | |||||
| E.33 Trading platforms name | text | ||||
| E.34 Trading platforms market identifier code (MIC) | text | ||||
| E.35 Trading platforms access | text | Where self-custody is supported, holders must use a wallet compatible with the Nyks network and remain responsible for securing private keys and verifying addresses before transacting. |
|||
| E.36 Involved costs | textBlock | These fees are determined and set solely by the trading platforms and are not controlled, influenced, or governed by VINU LTD. All on-chain transactions involving NYKS are subject to network transaction fees ("gas fees").Transactions on the Nyks network may also involve transaction or network fees payable under the protocol rules. |
|||
| E.37 Offer expenses | textBlock | ||||
| E.38 Conflicts of interest | textBlock | ||||
| E.39 Applicable law | textBlock | The United Nations Convention on Contracts for the International Sale of Goods (CISG) is expressly excluded and shall not apply. |
|||
| E.40 Competent court | textBlock | ||||
| Part F - Information about other tokens | |||||
| F.1 Crypto-asset type | text | ||||
| F.2 Other token functionality | textBlock | NYKS does not confer staking rewards, dividends, interest, profit-sharing rights, revenue-sharing rights, governance rights over VINU LTD, redemption rights, claims against VINU LTD or any entitlement to future profits. Mining rewards require active proof-of-work mining and are not paid merely for holding NYKS. |
|||
| F.3 Planned application of functionalities | textBlock | ||||
| A description of the characteristics of the other token, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article | |||||
| F.4 Type of crypto-asset white paper | enumeration | ||||
| F.5 Type of submission | enumeration | ||||
| F.6 Other token characteristics | textBlock | a. NYKS is a fungible utility-type native protocol crypto-asset. Each unit of NYKS is identical and interchangeable with another unit of NYKS. b. NYKS exists solely as a native crypto-asset on the Nyks Network. There is no wrapped, bridged or multi-chain representation of NYKS. c. NYKS does not have an absolute maximum supply. The protocol has a main supply schedule of 4,200,000,000 NYKS, comprising a 1,260,000,000-NYKS premine and 2,940,000,000 NYKS issued through public proof-of-work mining. After the main supply schedule, a constant tail emission of 256 NYKS per block continues indefinitely. d. The 1,260,000,000-NYKS premine represents 30% of the main supply schedule and is allocated in a single coinbase output in the genesis block (block 0) to the development team's multisignature wallet. Of that amount, 630,000,000 NYKS vest over two years in four six-monthly unlocks, and 630,000,000 NYKS vest over five years in ten six-monthly unlocks.e. NYKS is issued and transferable on the Nyks Network, a self-developed UTXO-based Layer-1 blockchain secured by Nakamoto-style proof-of-work. f. NYKS is used to pay transaction and network fees, transfer confidential value and reward miners who actively secure the network through proof-of-work mining. g. Mining rewards require active proof-of-work mining and network-security participation. They do not arise merely from holding NYKS and do not constitute staking rewards, dividends, interest, profit participation, revenue sharing or a guaranteed return. h. NYKS is non-interest bearing. Holders may bear transaction or network fees when transferring or otherwise using NYKS. i. NYKS has no physical form, intrinsic financial value or guaranteed price. Its market value, if any, is determined by supply and demand. j. NYKS is non-refundable and is not redeemable for fiat currency, crypto-assets or other assets. k. Holding NYKS does not confer any rights in or to VINU LTD, Rhinobob LLC or any affiliate, or their revenues, treasury or assets. In particular, NYKS confers no equity, ownership, dividend, revenue, profit-share, distribution, liquidation, proprietary, intellectual-property, management, governance, voting, financial-statement or similar rights. l. NYKS does not represent a loan to, debt of or claim against VINU LTD or any affiliate. m. NYKS is not intended to represent rights under a contract for differences or any other derivative contract designed to secure a profit or avoid a loss. n. NYKS is not electronic money or an e-money token, a payment instrument, a security, a commodity, a bond, a debt instrument, a unit in a collective investment undertaking or any other financial instrument or investment product. o. NYKS is not an asset-referenced token or stablecoin. It does not purport to maintain a stable value relative to any asset or currency, is not pegged to or backed by a reserve of assets, confers no redemption right or claim against VINU LTD or any affiliate, and uses no stabilisation mechanism. p. NYKS is divisible to eight decimal places. The smallest unit is the nyx, where 1 NYKS equals 100,000,000 nyx. |
|||
| F.7 Commercial name or trading name | text | ||||
| F.8 Website of the issuer | text | ||||
| F.9 Starting date of offer to the public or admission to trading | date | ||||
| F.10 Publication date | date | ||||
| F.11 Any other services provided by the issuer | textBlock | ||||
| F.12 Language or languages of white paper | text | ||||
| F.13 Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available | text | ||||
| F.14 Functionally fungible group digital token identifier, where available | text | ||||
| F.15 Voluntary data flag | boolean | ||||
| F.16 Personal data flag | boolean | ||||
| F.17 LEI eligibility | boolean | ||||
| F.18 Home member state | enumeration | ||||
| F.19 Host member states #1 | enumerationSet | ||||
| F.19 Host member states #2 | enumerationSet | ||||
| F.19 Host member states #3 | enumerationSet | ||||
| F.19 Host member states #4 | enumerationSet | ||||
| F.19 Host member states #5 | enumerationSet | ||||
| F.19 Host member states #6 | enumerationSet | ||||
| F.19 Host member states #7 | enumerationSet | ||||
| F.19 Host member states #8 | enumerationSet | ||||
| F.19 Host member states #9 | enumerationSet | ||||
| F.19 Host member states #10 | enumerationSet | ||||
| F.19 Host member states #11 | enumerationSet | ||||
| F.19 Host member states #12 | enumerationSet | ||||
| F.19 Host member states #13 | enumerationSet | ||||
| F.19 Host member states #14 | enumerationSet | ||||
| F.19 Host member states #15 | enumerationSet | ||||
| F.19 Host member states #16 | enumerationSet | ||||
| F.19 Host member states #17 | enumerationSet | ||||
| F.19 Host member states #18 | enumerationSet | ||||
| F.19 Host member states #19 | enumerationSet | ||||
| F.19 Host member states #20 | enumerationSet | ||||
| F.19 Host member states #21 | enumerationSet | ||||
| F.19 Host member states #22 | enumerationSet | ||||
| F.19 Host member states #23 | enumerationSet | ||||
| F.19 Host member states #24 | enumerationSet | ||||
| F.19 Host member states #25 | enumerationSet | ||||
| F.19 Host member states #26 | enumerationSet | ||||
| F.19 Host member states #27 | enumerationSet | ||||
| F.19 Host member states #28 | enumerationSet | ||||
| F.19 Host member states #29 | enumerationSet | ||||
| Part G - Information on rights and obligations attached to other tokens | |||||
| G.1 Purchaser rights and obligations | textBlock | NYKS does not confer any claim against VINU LTD, any equity, ownership, dividend, interest, staking reward, profit-share, revenue-share, governance or voting right over VINU LTD or the protocol, redemption right, creditor right, claim over any treasury or assets, or entitlement to future profits. Mining rewards require active proof-of-work mining and do not arise from merely holding NYKS. Holders are responsible for securing their wallets, private keys and recovery information, paying applicable network fees, using compatible wallets and address formats, and complying with applicable law and any relevant trading-platform rules. The protocol operates a rules-based monetary policy comprising a decreasing proof-of-work mining-reward schedule followed by a constant tail emission of 256 NYKS per block. There is no absolute maximum supply. The project also applies an anti-fork policy under which it intends to recognise and support only the canonical upgraded chain, without being technically able to prevent third parties from forking the open-source software. |
|||
| G.2 Exercise of rights and obligations | textBlock | Rights and features are exercised by holding the relevant private keys and broadcasting valid transactions to the network. Mining rewards are obtained only through active proof-of-work mining in accordance with protocol rules. No minimum level of access, rewards, liquidity, market demand or benefit is promised or guaranteed. |
|||
| G.3 Conditions for modifications of rights and obligations | textBlock | The project's anti-fork policy means that the project recognises and supports only the canonical upgraded chain. However, because the software is open-source, the project cannot technically prevent third parties from forking the software or network. Protocol upgrades and material changes are expected to be announced through the project's public social and community channels. |
|||
| G.4 Future public offers | textBlock | ||||
| G.5 Issuer retained other token | integer | ||||
| G.6 Utility token classification | boolean | ||||
| G.7 Key features of goods or services utility tokens | text | NYKS does not provide access to any goods, services, features or benefits outside the Nyks Network. It does not confer staking, dividend, interest, profit-share, revenue-share, governance, redemption or issuer-claim rights. |
|||
| G.8 Utility tokens redemption | text | ||||
| G.9 Non-trading request | boolean | ||||
| G.10 Other tokens purchase or sale modalities | text | ||||
| G.11 Other tokens transfer restrictions | text | Third-party trading platforms may impose restrictions on buyers, sellers, deposits or withdrawals in accordance with applicable law and their own terms and internal policies. Such restrictions may include onboarding requirements, KYC, AML/CFT and sanctions checks, jurisdictional restrictions, transaction limits or suspension of services. The planned optional insurance or recovery-output functionality, if implemented and voluntarily used by a holder, would make a subsequent spend from the relevant output subject to an approximately 30-day recovery window, corresponding to approximately 6,750 blocks, during which the original holder could reclaim the funds using a pre-committed recovery key. This opt-in functionality would not affect the transferability or finality of standard transfers. |
|||
| G.12 Supply adjustment protocols | boolean | ||||
| G.13 Supply adjustment mechanisms | text | ||||
| Other token schemes details | |||||
| G.14 Token value protection schemes | boolean | ||||
| G.15 Token value protection schemes description | textBlock | ||||
| G.16 Compensation schemes | boolean | ||||
| G.17 Compensation schemes description | textBlock | ||||
| G.18 Applicable law | textBlock | The United Nations Convention on Contracts for the International Sale of Goods (CISG) is expressly excluded and shall not apply. |
|||
| G.19 Competent court | textBlock | ||||
| Part H – Information on underlying technology | |||||
| H.1 Distributed ledger technology (DTL) | text | NYKS exists solely as a native crypto-asset on the Nyks Network. It does not follow a token standard such as ERC-20, ERC-721, BEP-20 or SPL, and there is no wrapped, bridged or multi-chain representation of NYKS. |
|||
| H.2 Protocols and technical standards | text | The proof-of-work mechanism uses Tip5, a post-quantum, arithmetisation-oriented hash function operating over a 64-bit prime field. Tip5 is also used in the network's zk-STARK proving system. Post-quantum cryptography is used for the core signature and commitment scheme. Transparent zk-STARKs are used for confidentiality and transaction-validity proofs. The zk-STARK construction requires no trusted setup and is designed to provide security against classical and quantum adversaries. The proof-of-work mechanism is deliberately memory-hard. For each block, a miner constructs a Merkle tree, referred to as the guesser buffer, containing 2²⁷ or 134,217,728 leaves derived from the parent-block digest and occupying approximately 10 GB of RAM. Each nonce attempt involves 63 sequential Tip5 permutations, derives two leaf indices, opens two Merkle authentication paths of height 27 and calculates the block digest. These parameters are intended to support mining using commodity CPUs with sufficient memory and to resist ASIC and large-scale GPU optimisation. The target block time is approximately 6.4 minutes, or 384 seconds, and the minimum block time is 60 seconds. The mining target adjusts from a genesis difficulty in order to track observed block intervals. |
|||
| H.3 Technology used | textBlock | Live functionality includes confidential or shielded transactions, transparent zk-STARK validity proofs requiring no trusted setup, post-quantum cryptographic components and holder-controlled per-address and per-wallet viewing keys. Viewing keys enable a holder to provide a selected party with scoped, read-only access to relevant wallet or address information without making the information public on-chain. Planned functionality includes base-layer smart contracts, optional time-locked insurance or recovery outputs and a privacy-preserving compliance-attestation framework. The planned compliance-attestation framework would comprise: a. a public, open and merit-based registry of third-party attestors, which may be organisations or individuals, containing each attestor's public key, supported policies, jurisdiction, audit status and revocation status; b. policies published by crypto-asset service providers specifying the attestors and compliance policies they accept; c. holder-controlled attestations under which a holder grants an accepted attestor scoped viewing-key access or answers a narrowly defined challenge program, after which the attestor issues a signed, time-bound certificate identifying the relevant policy and policy version; and d. verification by the crypto-asset service provider of the certificate, the attestor's signature and the applicable registry status, without receiving the holder's balances, amounts, counterparties, transaction history or viewing keys. Attestor policies would be publicly available for review. Attestors may charge fees, and holders may prefer attestors that undertake not to retain records. Certificates may refer to an earlier attestation rather than requiring the same work to be repeated. The attestor registry, compliance certificates and related off-chain tooling are planned for Q1 2027 and are not yet live. Their effectiveness will depend on qualified attestors participating in the registry and acceptance by crypto-asset service providers. Earlier non-association-proof and off-chain per-coin provenance-tooling concepts have been removed from the current design and superseded by the planned third-party compliance-attestation framework. |
|||
| H.4 Consensus mechanism | text | For each block, a miner constructs a memory-hard Merkle tree, referred to as the guesser buffer, containing 2²⁷ or 134,217,728 leaves derived from the parent-block digest and occupying approximately 10 GB of RAM. This design is intended to favour commodity CPUs with sufficient memory and resist ASIC and large-scale GPU optimisation. For each nonce attempt, the miner derives two leaf indices through 63 sequential Tip5 permutations, opens two Merkle authentication paths of height 27 and calculates the block digest using approximately 37 further Tip5 permutations. A block is valid when the resulting digest is less than or equal to the current mining target. The target block time is approximately 384 seconds, or 6.4 minutes, and the minimum block time is 60 seconds. The mining target adjusts from a genesis difficulty in order to track observed block intervals. |
|||
| H.5 Incentive mechanisms and applicable fees | text | ||||
| H.6 Use of distributed ledger technology | boolean | ||||
| H.7 DLT functionality description | textBlock | Transactions are confidential by default. Amounts, balances, counterparties and transaction history are not publicly visible on-chain. Confidentiality and transaction validity are enforced using transparent zk-STARK proofs that require no trusted setup. Holders control per-address and per-wallet viewing keys. A holder may voluntarily provide a selected party, such as an auditor, attestor or regulated intermediary, with scoped and read-only access to the holder's own transaction information. The protocol does not perform automated network-level transaction monitoring. The protocol is designed to support an optional insurance or recovery-output type intended principally for custodial holders such as trading platforms and cold-wallet operators. If implemented, funds deliberately placed in such an output would, when subsequently spent, be subject to an approximately 30-day recovery window, corresponding to approximately 6,750 blocks. During that window, the original holder could reclaim the funds using a pre-committed recovery key. The mechanism would be opt-in and would not affect the finality of standard transfers. This functionality is planned and is not yet live. The protocol is also designed to support a privacy-preserving compliance-attestation framework with the following components: 1. Attestor registry. A public registry would list admitted attestors, which may be organisations or individuals admitted on an open and merit-based basis. Each registry entry would identify the attestor's public key, supported policies, jurisdiction, audit status and revocation status. Attestor policies would be published for public review. 2. Service-provider policy. Each crypto-asset service provider would independently identify the attestors and policies it accepts. 3. Holder attestation. A holder wishing to transact with a service provider would select an accepted attestor and either grant the attestor scoped access through a viewing key or answer a narrowly defined challenge program. A challenge program could, for example, prove that none of the coins controlled by the holder descend from a specified address without revealing the holder's complete transaction history, balances, origins or counterparties. The attestor would perform the relevant check and issue a signed, time-bound certificate identifying the applicable policy and policy version. A later attestation may refer to an earlier attestation rather than repeating the same work. 4. Verification. The service provider would verify the attestor's signature, the policy identifier, the policy version, the certificate-validity period and the attestor's audit and revocation status. It would not receive the holder's amounts, balances, counterparties, transaction history or viewing keys. Attestors may charge fees for their services. Holders would be free to prefer attestors that undertake not to retain records. Because multiple independent attestors may support the same policy and service providers select the attestors they accept, the framework is intended to avoid reliance on a single mandatory gatekeeper. The attestor registry, compliance certificates and related off-chain tooling are planned for Q1 2027 and are not yet live. Their effectiveness will depend on the availability of qualified attestors and acceptance by crypto-asset service providers. |
|||
| Other token audit details | |||||
| H.8 Audit | boolean | ||||
| H.9 Audit outcome | textBlock | An independent security and cryptography audit is planned to commence in Q4 2026, with the audit report targeted for Q1 2027, ahead of the planned release of the compliance-attestation framework. The audit provider will be an independent specialist blockchain-security firm with expertise in zero-knowledge proofs and cryptography. The selection process is in progress, and the provider will be identified in an updated disclosure once engaged. The intended audit scope comprises: a. the consensus and proof-of-work implementation; b. the zk-STARK proving system and circuits; c. the shielded UTXO transaction model; d. the node implementation and peer-to-peer networking; and e. the wallet SDK and key-management arrangements. The audit outcome will be disclosed once the audit has been completed and the report is available. |
|||
| Part I - Information on risks | |||||
| I.1 Offer-related risks | textBlock | Custodial risk: if NYKS is admitted to trading, holders may choose to hold NYKS through custodial wallets or accounts provided by trading platforms or other intermediaries. In such cases, there is a risk of loss of assets due to hacks, insolvency, fraud, operational failure or other malicious acts affecting the relevant intermediary. Protocol dependence: NYKS is dependent on the Nyks Network. Downtime, congestion, protocol failure, security vulnerabilities, chain reorganisations, low mining participation or other network-level issues may impair transfers, mining, trading or other functionality. Human error: blockchain transactions are generally irreversible. Use of an incorrect address, wallet, network, private key, prefix or transaction parameter may result in permanent loss of access to NYKS. Integration risk: admission to trading requires technical and operational integrations with third-party trading platforms. Connection downtime, faulty code, platform outages or integration failures may affect trading or transferability. b. Regulatory and Compliance Risks This white paper has been prepared with due care; however, regulatory requirements applicable to crypto-assets, proof-of-work networks, privacy-enhancing assets and admissions to trading may evolve. Future changes in law, regulatory practice or enforcement priorities may affect the legal status, tradability, functionality or availability of NYKS. c. Counterparty and Trading-Platform Risks Admission to trading involves reliance on third-party trading platforms and other intermediaries. Such entities may fail to operate to expected standards, may experience operational or security incidents, may become insolvent or may be subject to regulatory restrictions. Listing, suspension or delisting is subject to the internal processes and discretion of each trading platform. Delisting or refusal to list may materially affect the ability to trade NYKS. d. Market and Liquidity Risks NYKS may be subject to high volatility and market speculation. There is no guarantee that any trading platform will admit NYKS to trading, that any secondary market will develop, or that sufficient liquidity will exist. Low trading volumes may restrict the ability to buy or sell NYKS and may result in high slippage. |
|||
| I.2 Issuer-related risks | textBlock | VINU LTD and the Nyks project operate in an evolving regulatory environment. Requirements may differ between jurisdictions and may change materially over time. Non-compliance or alleged non-compliance may result in investigations, enforcement actions, fines, sanctions, restrictions, suspension or prohibition of trading, or private litigation. b. Limited Operating History and Financial Condition VINU LTD was incorporated on 6 October 2022 and has a limited operating and trading history in relation to the Nyks protocol. The project is founder-funded and has no external investors. No audited financial statements or unaudited accounts are available or will be provided for the purposes of this white paper. As at the date of this white paper, VINU LTD has confirmed that it has no material debts, liabilities, commitments or funding risks to disclose. Nevertheless, continued development and support depend on founder funding and the resources available to VINU LTD. A reduction or cessation of such support may adversely affect development, maintenance, regulatory work, audits or admission-to-trading efforts. c. Key-Person Dependency The project is founder-led, and Taylor Dexton Miller is the sole director, sole officer and sole member of the management body. Loss of key personnel, incapacity, disagreement between contributors or reduced availability of the core development team may delay or prevent development, maintenance, governance or admission-to-trading efforts. d. Insolvency or Project Abandonment As with any commercial or technical project, there is a risk that VINU LTD may become insolvent, cease supporting the project or abandon development. This may occur due to lack of funding, lack of adoption, regulatory restrictions, technical failure, market conditions, force majeure or other reasons. e. Competitive Ecosystem Other crypto-assets, privacy-related protocols, proof-of-work networks, smart-contract platforms and digital-asset projects may compete with Nyks. Competition may reduce adoption, liquidity, miner participation or perceived usefulness. f. Counterparty Dependency The project may depend on third-party service providers, software dependencies, trading platforms, wallet providers, infrastructure providers, auditors, legal advisers, technical contributors, prospective attestors and community channels. Failure or withdrawal of such counterparties may disrupt the project. g. Reputational Risk Negative publicity, including publicity arising from security incidents, privacy-related concerns, regulatory scrutiny, association with illicit activity or failure to deliver roadmap items, may damage the reputation of VINU LTD, Nyks and NYKS. h. Operational and Residual Risks Failure to develop or maintain effective internal controls, operational processes or public communications may harm the project. Other risks not currently foreseeable may also materialise. |
|||
| I.3 Other tokens-related risks | textBlock | NYKS may experience significant price volatility driven by market sentiment, liquidity, regulatory developments, technology changes, macroeconomic conditions, proof-of-work mining economics and the availability of trading platforms. Holders may lose part or all of the value of NYKS. b. Valuation and No Intrinsic Financial Value NYKS has no guaranteed or intrinsic financial value and does not confer ownership, dividends, revenue sharing, redemption rights or issuer claims. Its price, if any, is determined by supply and demand and may be materially affected by speculative trading, narrative, community interest and perceived utility. c. No Absolute Maximum Supply and Tail Emission NYKS does not have an absolute maximum supply. After the main supply schedule of 4,200,000,000 NYKS, the protocol provides for a constant tail emission of 256 NYKS per block. Tail emission may affect market expectations, scarcity assumptions, valuation and trading behaviour. d. Liquidity Constraints Liquidity may be limited or absent. There is no guarantee that NYKS will be admitted to trading, remain listed or have sufficient trading volume. Holders may be unable to sell NYKS at their desired time or price. e. Asset Security and Private-Key Risk Holders are responsible for securing wallets, private keys and recovery information. Loss, theft or compromise of private keys may result in permanent loss of NYKS. f. Scams and Fake Tokens Scammers may create fake NYKS tokens, websites, social-media accounts, wallets, giveaways or phishing campaigns. Holders should use only official sources and verify addresses, software and network parameters. g. Native Blockchain Dependency NYKS exists solely as a native crypto-asset on the Nyks Network. Any defect, outage, congestion, mining failure, protocol bug, chain reorganisation or security incident affecting the Nyks Network may impair transferability, mining or trading. There is no wrapped, bridged or multi-chain implementation through which holders could avoid a failure of the native network. h. Proof-of-Work and Network-Security Risks As a proof-of-work network, Nyks may be exposed to miner concentration, insufficient hashrate, 51% attacks, chain reorganisations, selfish mining, difficulty-adjustment issues and low-hashpower early-network risk. i. Smart-Contract and Future Programmability Risks Smart-contract functionality is planned but is not currently live. If implemented, it may introduce coding, execution, security, upgradeability, integration and user-error risks. j. Cryptographic and Implementation Risks The protocol relies on Tip5, zk-STARKs and other cryptographic components. These may contain design flaws, implementation bugs, incorrect assumptions or vulnerabilities. Descriptions such as "post-quantum" should not be understood as guarantees of immunity from future cryptographic developments or implementation failures. k. Privacy, Viewing-Key and Compliance-Attestation Risks Confidential transactions and viewing keys may support privacy and holder-controlled, scoped disclosure. However, privacy features may fail, be misused, be misunderstood, be restricted by regulation or be considered insufficient by trading platforms, regulators or other intermediaries. The compliance-attestation framework, including the attestor registry, challenge programs, compliance certificates and related off-chain tooling, is planned for Q1 2027 and is not yet live. Its effectiveness will depend on qualified attestors joining and remaining in the registry, the quality and auditability of their policies and systems, the accuracy and security of challenge programs, the proper operation of revocation mechanisms and acceptance by crypto-asset service providers. A service provider may reject an attestor, policy or certificate, require a new certificate, require additional information or demand direct access to transaction data notwithstanding the framework. Certificates are time-bound and may cease to be accepted following expiry, a policy change, an audit-status change or revocation of the relevant attestor. Attestors may charge fees and may retain information unless they undertake not to do so. A holder's selection of an attestor may therefore involve cost, confidentiality and counterparty risks. A compromised, negligent, dishonest or incorrectly configured attestor may issue an inaccurate certificate, fail to identify relevant activity or expose holder information. Viewing keys, challenge programs and compliance certificates do not guarantee AML/CFT, sanctions, Travel Rule or other regulatory compliance and do not guarantee admission to trading or continued platform support. l. Regulatory Uncertainty The regulatory treatment of crypto-assets, proof-of-work networks and privacy-enhancing assets is evolving. Regulators may impose restrictions or adopt interpretations that affect the use, holding, trading, custody or admission to trading of NYKS. m. AML/CFT and Sanctions Risk Wallet addresses interacting with NYKS may be associated with money laundering, terrorist financing, sanctions or other illicit activity. This may affect user access, trading-platform support, compliance review and reputational perception. n. Counterparty Risk Use of trading platforms, custodians, wallet providers, attestors or other intermediaries creates counterparty risk, including insolvency, fraud, regulatory failure, data exposure or operational disruption. o. Technological Innovation and Obsolescence New technologies, cryptographic attacks, quantum-computing developments, more efficient privacy protocols or competing Layer-1 networks may reduce the competitiveness or security assumptions of Nyks. p. Community and Narrative Risk Interest in NYKS may depend on community confidence, project communication, perceived technical usefulness, mining participation and broader market narrative. Declining interest may affect adoption, liquidity and value. q. Interest Rate and Macro Market Risk Changes in interest rates, foreign-exchange rates, inflation, macroeconomic conditions and overall market volatility may affect market sentiment and the price or liquidity of NYKS. r. Taxation Tax treatment depends on the holder's jurisdiction. Holders are responsible for complying with applicable tax laws and reporting and payment obligations. s. Market Abuse NYKS may be exposed to market abuse, including front-running, spoofing, pump-and-dump schemes, wash trading, misinformation or manipulative behaviour, particularly if liquidity is low. t. Timeline and Milestones The execution of the project roadmap remains subject to uncertainty. Future regulations, policies and court decisions in the European Union or other jurisdictions may evolve unpredictably and change the anticipated timing, feasibility or completion of technical developments, platform features, admissions to trading or integrations. Delays or deviations from planned milestones may occur due to technical, operational, market or regulatory factors and could materially affect the usability, adoption or value of NYKS. |
|||
| I.4 Project implementation-related risks | textBlock | From the project side, roadmap features may be delayed, modified, scaled back or not delivered. In particular, smart-contract functionality, the compliance-attestation framework and optional insurance or recovery outputs are planned features and are not guaranteed to be implemented in any particular form or timeframe. The attestor registry, compliance certificates and related off-chain tooling are roadmapped for Q1 2027 and are not yet live. Their implementation and practical effectiveness will depend on the completion and security of the relevant protocol and off-chain tooling, the availability of qualified attestors, the publication of appropriate policies, the operation of audit and revocation processes and acceptance by crypto-asset service providers. Even if technically implemented, the framework may not be accepted by any particular trading platform or regulator. No independent security audit, cryptography review or public bug-bounty programme has been completed as at the date of this white paper. Earlier non-association-proof and off-chain per-coin provenance-tooling concepts have been removed from the current design and superseded by the planned third-party compliance-attestation framework. Holders should not rely on those removed concepts as current or planned features. |
|||
| I.5 Technology-related risks | textBlock | The technological components supporting NYKS, including wallet software, protocol interfaces, trading-platform integrations, mining software, future smart-contract functionality and planned attestation tooling, may be vulnerable to cyberattacks, malware, phishing, denial-of-service attacks or exploitation of vulnerabilities. b. Nyks Network Dependency NYKS is dependent on the Nyks Network. Outages, congestion, protocol failure, chain reorganisations, difficulty-adjustment issues or security incidents may interrupt transfers, mining, trading or other functions. c. Proof-of-Work Risks The network may face proof-of-work-specific risks, including mining concentration, low hashrate, 51% attacks, selfish mining, block withholding, chain reorganisations and increased energy or hardware costs. d. Wallet and Storage Risks Holders must securely manage private keys, recovery information and compatible wallets. Incompatibility, incorrect address formats, software bugs or loss of keys may result in permanent loss of NYKS. e. Cryptography Risks The protocol uses Tip5, zk-STARKs and other cryptographic components. These may be affected by implementation errors, incorrect assumptions, undiscovered vulnerabilities, future cryptographic advances or quantum-computing-related developments. f. Viewing-Key and Privacy Risks Viewing keys and confidential transactions may not function as intended, may be misused or may be insufficient for regulatory or platform-compliance requirements. Disclosure of a viewing key to the wrong party, use of an excessively broad viewing key or compromise of the relevant software may expose confidential holder information. Privacy features may also attract additional scrutiny from regulators or intermediaries. g. Planned Compliance-Attestation Framework Risks The planned compliance-attestation framework, including the attestor registry, challenge programs, compliance certificates and related off-chain tooling, may be delayed, modified, not implemented or not accepted by trading platforms, regulators or other market participants. The framework will depend on the accuracy and security of attestor software, challenge programs, public keys, registry information, policy identifiers, certificate signatures, validity periods, audit information and revocation status. Defects, outdated information, incorrect policy implementation, private-key compromise or failure to publish or process a revocation may cause an invalid certificate to be accepted or a valid certificate to be rejected. Attestors may be negligent, dishonest, compromised, insufficiently qualified or subject to conflicting legal obligations. They may retain holder information or charge fees. No assurance can be given that a sufficient number of qualified attestors will participate, that any attestor will support a required policy or jurisdiction, or that any crypto-asset service provider will accept the resulting certificate. A challenge program may be incorrectly designed or implemented and may prove something narrower or different from the policy expected by the service provider. A certificate may also become outdated because it is time-bound or because the applicable policy, registry entry, audit status or revocation status changes. h. Future Smart-Contract Risks Smart-contract functionality is planned. If implemented, smart contracts may contain bugs, vulnerabilities, upgradeability risks or unintended consequences. i. Optional Insurance or Recovery-Output Risks The planned optional insurance or recovery outputs may contain design or implementation defects. A holder may lose or compromise the pre-committed recovery key, misunderstand the recovery period or fail to act within the applicable window. The functionality may also create operational or integration complexity for wallets and trading platforms. j. Open-Source Fork Risks The project's anti-fork policy cannot technically prevent third parties from forking the open-source software. Forks may confuse users, dilute community attention or create competing versions of the network. k. Technological Obsolescence Technological developments may make the Nyks protocol less competitive, less secure or less attractive to users, miners or trading platforms. |
|||
| I.6 Mitigation measures | textBlock | The protocol uses memory-hard proof-of-work parameters intended to reduce ASIC and large-scale GPU optimisation and support broader CPU-mining participation. These measures may reduce certain concentration risks but do not eliminate proof-of-work or network-security risks. b. Time-locked mining rewards Approximately 50% of each mining reward is time-locked for one generation, corresponding to approximately one month. This mechanism may reduce immediate supply pressure but does not guarantee price stability, liquidity or market demand. c. Premine vesting The premine vests in two tranches. A tranche of 630,000,000 NYKS vests over two years in four six-monthly unlocks, and a tranche of 630,000,000 NYKS vests over five years in ten six-monthly unlocks. Vesting may reduce immediate supply pressure but does not eliminate market, liquidity or concentration risks. d. Rules-based issuance and anti-fork policy Issuance follows a predetermined protocol schedule comprising a decreasing mining-reward phase followed by a constant tail emission of 256 NYKS per block. The project intends to recognise and support only the canonical upgraded chain. However, because the software is open-source, the anti-fork policy cannot technically prevent third-party forks. e. Viewing keys and planned compliance-attestation framework Viewing keys enable voluntary, scoped disclosure of holder information to a selected party. The planned compliance-attestation framework is intended to allow an accepted attestor to perform a defined compliance check and issue a signed, time-bound certificate without providing the crypto-asset service provider with the holder's underlying transaction data. These mechanisms do not guarantee regulatory acceptance, AML/CFT compliance, sanctions compliance, admission to trading or continued trading-platform support. The compliance-attestation framework is planned for Q1 2027 and is not yet live. f. Optional insurance and recovery outputs The optional insurance or recovery-output functionality planned for H2 2027 is intended to allow the holder who created the relevant output to recover an unauthorised transfer during an approximately 30-day recovery window by using a pre-committed recovery key. The functionality will be optional and does not eliminate theft, key-management or implementation risks. g. Independent security and cryptography audit An independent security and cryptography audit is planned to commence in Q4 2026, with the audit report targeted for Q1 2027. The intended scope includes the consensus and proof-of-work implementation, zk-STARK proving system and circuits, shielded UTXO transaction model, node implementation and peer-to-peer networking, wallet SDK and key management. The provider-selection process is ongoing. Until the audit is completed, no assurance can be given regarding its findings or the successful remediation of any issues identified. h. Public communications Protocol upgrades and material changes are expected to be announced through the project's public website and social or community channels. i. Limitations The measures described above are intended to reduce risk only. They do not eliminate the risks disclosed in this white paper or constitute a warranty, guarantee or right to compensation, redemption, refund or value maintenance. |
|||
| Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts | |||||
| J.1 Adverse impacts on climate and other environment-related adverse impacts | textBlock | The sustainability information is based on a good-faith, bottom-up estimate comprising two components. First, proof-of-work mining is assumed to involve 10 reference CPU mining units operating continuously at approximately 145 W at-wall each, resulting in estimated annual energy consumption of approximately 12,702 kWh. Second, block production is assumed to involve three high-end producer nodes whose aggregate consumption is approximately 0.1 kWh per block, resulting in approximately 8,213 kWh per year based on approximately 82,125 blocks. Total estimated annual energy consumption is therefore approximately 20,915 kWh. Scope 1 emissions are estimated at approximately zero because no direct on-site fuel combustion is assumed. Scope 2 emissions are estimated at approximately 9.1 tCO2e per year using a global-average grid-emission factor of 0.436 kgCO2e/kWh. Mining participation is permissionless, and miner geography is not fixed to a single jurisdiction. The figures are forward-looking estimates and will be refined using observed mainnet data. A third-party sustainability assessment may also be commissioned |
|||
| Mandatory information on principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism | |||||
| General information about adverse impacts | |||||
| S.1 Name | text | ||||
| S.2 Relevant legal entity identifier | text | ||||
| S.3 Name of the crypto-asset | text | ||||
| S.4 Consensus mechanism | text | ||||
| S.5 Incentive mechanisms and applicable fees | text | ||||
| S.6 Beginning of period to which disclosed information relates | date | ||||
| S.7 End of period to which disclosed information relates | date | ||||
| Mandatory key indicator | |||||
| S.8 Energy consumption | energy (kWh) | ||||
| Sources and methodologies | |||||
| S.9 Energy consumption sources and methodologies | textBlock | Proof-of-work consensus: approximately 10 reference mining units operating continuously at approximately 0.145 kW each for 8,760 hours per year, resulting in estimated annual energy consumption of approximately 12,702 kWh. Block and transaction production: approximately three high-end producer nodes assembling blocks and proofs at approximately 0.1 kWh per block. Based on approximately 82,125 blocks per year, this results in estimated annual energy consumption of approximately 8,212 kWh. The estimated total annual energy consumption is therefore approximately 20,915 kWh. Grid electricity is assumed, with no on-site generation. Actual consumption will depend on the number and configuration of active miners and producer nodes and will be refined using observed mainnet data. |
|||
| Supplementary information on principal adverse impacts on climate and other environment-related adverse impacts of consensus mechanism | |||||
| Supplementary key indicators | |||||
| S.10 Renewable energy consumption | percent | ||||
| S.11 Energy intensity | energy (kWh) | ||||
| S.12 Scope 1 DLT GHG emissions - controlled | GHG emissions (tCO2e) | ||||
| S.13 Scope 2 DLT GHG emissions - purchased | GHG emissions (tCO2e) | ||||
| S.14 GHG intensity | GHG emissions (tCO2e) | ||||
| Sources and methodologies | |||||
| S.15 Key energy sources and methodologies | textBlock | Estimated network energy consumption is approximately 0.25 kWh per validated block, comprising approximately 0.15 kWh for proof-of-work consensus and approximately 0.1 kWh for block and transaction production. On the illustrative assumption of approximately 10 transactions per block, estimated energy intensity is approximately 0.025 kWh per validated transaction. The transaction-throughput assumption will be updated using observed mainnet data. |
|||
| S.16 Key GHG sources and methodologies | textBlock | Scope 2 emissions are estimated at approximately 9.1 tCO2e per year, calculated by applying a global-average grid-emission factor of 0.436 kgCO2e/kWh to estimated annual electricity consumption of 20,915 kWh. On the illustrative assumption of approximately 10 transactions per block, estimated GHG intensity is approximately 0.000011 tCO2e per validated transaction, equivalent to approximately 0.011 kgCO2e or 11 g. |
|||
| Optional information on principal adverse impacts on the climate and on other environment-related adverse impacts of the consensus mechanism | |||||
| Optional indicators | |||||
| S. 17 Energy mix | percent | ||||
| S.18 Energy use reduction | |||||
| Energy use reduction target (absolute value) | energy (kWh) | ||||
| Energy use reduction target (percentage) | percent | ||||
| S.19 Carbon intensity (kgCO2e/kWh) | decimal | ||||
| S.20 Scope 3 DLT GHG emissions - value chain | GHG emissions (tCO2e) | ||||
| S.21 GHG emissions reduction targets or commitments | textBlock | ||||
| S.22 Generation of waste electrical and electronic equipment (WEEE) | mass (tonnes) | ||||
| S.23 Non-recycled WEEE ratio | percent | ||||
| S.24 Generation of hazardous waste | mass (tonnes) | ||||
| S.25 Generation of waste (all types) | mass (tonnes) | ||||
| S.26 Non-recycled waste ratio (all types) | percent | ||||
| S.27 Waste intensity (all types) | mass (tonnes) | ||||
| S.28 Waste reduction targets or commitments (all types) | textBlock | ||||
| S.29 Impact of use of equipment on natural resources | textBlock | ||||
| S.30 Natural resources use reduction targets or commitments | textBlock | ||||
| S.31 Water use | volume (m3) | ||||
| S.32 Non recycled water ratio | percent | ||||
| Sources and methodologies | |||||
| S.33 Other energy sources and methodologies | textBlock | ||||
| S.34 Other GHG sources and methodologies | textBlock | ||||
| S.35 Waste sources and methodologies | textBlock | ||||
| S.36 Natural resources sources and methodologies | textBlock | ||||