| [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 | ZKJ is an ERC-20 token. The total supply is 1,000,000,000 ZKJ tokens. The above described functionalities are live and accessible at the time of writing (2025-10-30). ZKJ token does not confer any legal or ownership rights in the issuer and does not entitle holders to profits. All protocol-level functionality is governed and may evolve through decentralised governance processes. Purchasers of ZKJ utility tokens gain specific usage rights within the Polyhedra Network ecosystem. Upon acquiring ZKJ, holders have the right to exchange these tokens for on-chain services provided by Polyhedra Network (e.g. consuming ZKJ as gas for transaction fees, accessing cross-chain messaging, or utilizing zero-knowledge proof computations), skBridge cross-chain transaction fees. Fees represent the consumption of computational resources rather than payments between users. Users also have the right to stake tokens to support network operations and participate in on-chain governance decisions. Beyond these usage rights, holding or staking ZKJ does not confer any legal, equity, or ownership rights in any company or entity; it provides no entitlement to profits, dividends, or corporate governance. All governance influence is strictly at the protocol level (e.g. voting on network upgrades or community proposals) and carries no enforceable claim outside the decentralised network framework. Holders are expected to use their tokens in accordance with the network's rules and applicable laws. ZKJ token holders can exercise their utility rights through straightforward on-chain actions, using a compatible digital wallet. Accessing services and network usage: to utilize ZKJ for services (such as consuming tokens for transaction fees or cross-chain messaging), the holder simply uses their wallet to interact with Polyhedra Network's applications or smart contracts. For example, a holder can execute transactions on the EXPchain blockchain (Polyhedra's Network) by using ZKJ tokens as the required gas, or initiate a zkBridge cross-chain interaction by submitting a transaction that consumes the corresponding ZKJ as a protocol feeAll such interactions are done on-chain, meaning the token is spent or locked via smart contracts to invoke the desired service. The only technical conditions to exercise these rights are that the user must have a Web3-enabled wallet (e.g. a crypto wallet app) holding their ZKJ, and access to the Polyhedra Network or associated dApps. No special permission from the issuer is required; ownership of the token itself is sufficient to use it for its intended utilities. Staking and earning network rewards: To exercise the right to stake ZKJ, holders follow the on-chain staking procedure provided by the Polyhedra Network. This typically involves sending the desired amount of ZKJ to a designated staking smart contract or using an official staking interface. Once staked, the tokens become locked (non-transferable) for the duration of the staking period. The holder then begins participating in network support roles (for instance, helping to validate transactions or generate zero-knowledge proofs, depending on the staking program) and becomes eligible for network rewards. It is important to note that any such rewards (e.g. additional tokens or fees earned) are not guaranteed; they are variable and depend on network conditions, the holder's level of participation, and overall protocol performance. The procedure to claim or receive rewards, if earned, is usually automated or available through the same staking interface. To unstake, a holder must initiate an unstaking request on-chain, after which a predefined cool-down period will apply. Once this period ends, the staked tokens are released back to the holder's wallet and become transferable again. The conditions for staking (such as minimum stake amounts or lock-up durations) and unstaking (cool-down time) are transparently programmed into the smart contract and communicated beforehand. While staking is in effect, the holder continues to have all other rights (like voting) attached to their staked tokens, but they cannot transfer or spend those particular tokens until unstaking is complete. Staking does not grant any additional ownership rights or entitle participants to profits of the issuing entity. Rather, it is an opt‐in mechanism for contributing to network functions, with potential incentives reflecting the participant's level of engagement and the protocol's performance. By choosing to stake, users acknowledge that rewards can vary and are contingent upon the network's actual activity and the successful operation of the staking process. Governance participation: ZKJ token holders can participate in a decentralized governance process strictly limited to technical protocol parameters of the Polyhedra Network. Token holders may propose or vote on: - Technical network configuration (e.g., gas fee parameters, cross-chain bridge settings, transaction throughput limits); - Adoption of new cryptographic protocol features (e.g., integrating new zero-knowledge proof mechanisms, consensus algorithm updates); and - Protocol-level incentive parameters (e.g., validator reward rates, staking requirements, proof generation subsidies). IMPORTANT LIMITATIONS: Governance does NOT include and token holders have NO rights to: - Corporate decisions of Proof Space Pte. Ltd. or its affiliates; - Company treasury, assets, or revenues; - Appointment or removal of directors or management; - Business strategy, partnerships, or commercial agreements; - Distribution of company profits or dividends; - Any decisions affecting the issuer as a legal entity. Protocol governance operates independently from corporate governance. Any resources allocated through protocol governance (such as network rewards or incentive pools) are strictly protocol-level mechanisms funded by transaction fees and do not involve distribution of company assets or profits. Participation in governance is voluntary and requires token holders to either stake or otherwise use their ZKJ tokens in the relevant voting mechanisms. If a proposal passes governance thresholds and is technically feasible, it may be implemented in the protocol. However, neither the community nor the issuer is obligated to implement proposals that violate legal or regulatory requirements, risk network security, or fall outside the stated scope of protocol governance. By exercising these governance rights, token holders can help shape the future of the Polyhedra Network's infrastructure and ecosystem. They remain free at any point to hold, transfer, stake, or abstain from governance participation without losing ownership of their tokens. In sum, governance through ZKJ tokens is limited to decentralized, protocol-level decisions and does not confer voting power over corporate matters or entitle token holders to any dividends, profits, or other financial interests. In all cases, exercising any of the above rights requires adherence to the conditions set by the network protocols and legal terms. For instance, the net |
|||
| 09 Further information about utility tokens | textBlock | In terms of the quantity of access provided, the amount of network service a token holder can consume is proportional to the amount of tokens they possess and are willing to allocate as gas.Each ZKJ token (and even fractions of a token) corresponds to a unit of computational or transactional work on the network. There is no fixed cap on the services one token can ultimately procure; instead, the network uses a metered model where usage is debited in tokens according to the cost of the service utilized. This model scales with the holder's needs: if more network usage is required, more tokens would be consumed as gas.. Crucially, ZKJ is already live and functional as of the date of this white paper (2025-10-30), which means it provides access to current goods and services on the Polyhedra Network, not merely a promise of future utility. Holders can immediately use their tokens for the aforementioned purposes, and the quality of these services is maintained by the network's robust technical design (e.g. its consensus mechanism and smart contract infrastructure). ZKJ tokens are intended to be freely transferable. Holders can send or receive ZKJ tokens using standard blockchain transactions, peer-to-peer or via exchanges, without seeking permission from the issuer. Once ZKJ token is in a holder's wallet, the protocol imposes no inherent restrictions on transferring it to another address: it can be traded, gifted, or transferred between wallets for utility access purposes on the network. This flexibility facilitates a liquid market and broad accessibility, allowing both retail users and institutions to manage their tokens as needed for their use cases. At the time of this white paper (2025-10-30), there are no special lock-up periods or contractual transfer restrictions in effect on circulating tokens; all purchasers are free to move or exchange their ZKJ tokens at will. Certain practical or legal conditions may limit transferability in specific circumstances (these are external to the token's design). In compliance, ZKJ token can be restricted to transfer if that would violate laws – for instance, transfers to or from individuals or entities in sanctioned jurisdictions may be blocked, and participants may be required to undergo standard anti-money laundering (AML) and know-your-customer (KYC) checks when transacting on regulated exchanges or platforms. Such measures ensure that ZKJ token remains a compliant and legitimate asset in all jurisdictions where it is offered. Additionally, crypto asset service providers might impose their own temporary limits (for example, withdrawal holding periods or daily transfer limits) for security or compliance reasons. These forms of transferability conditions are not built into the token's smart contract, but rather arise from external agreements or laws. In normal peer-to-peer use on the network, ZKJ can be transferred seamlessly, and ownership can change hands simply by executing on-chain transactions. This means a holder has control over their tokens and can deploy them in decentralized finance (DeFi) applications, move them between wallets, or sell them on open markets, subject only to the standard network fees and confirmations. If any changes to transferability were ever proposed (for example, introducing a transfer gating mechanism due to future regulatory changes), they would be carried out with the same transparency and governance oversight described above for modifications of rights. As of now, ZKJ tokens are fully transferable within the ecosystem, enabling a fluid and open participation in the Polyhedra Network's economy while adhering to all relevant legal restrictions in the background. |
|||
| 10 Key information about the offer to the public or admission to trading | textBlock | The total supply of ZKJ tokens is capped at 1,000,000,000 (one billion). Any trading prices are determined by supply and demand on secondary markets. The ZKJ tokens are offered to both retail and institutional participants interested in Polyhedra Network's identity and services. No preference or category of targeted holder is specified – any eligible person may acquire ZKJ on a trading venue, subject to standard legal requirements. Transfers of ZKJ may be restricted to ensure compliance with anti-money laundering and sanctions regulations. |
|||
| 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 | ||||
| Member #2 | id | 2 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| A.13 Business activity | textBlock | Principal target users include: Blockchain developers and infrastructure providers requiring cross-chain messaging and secure data transfer; Institutional users and DeFi protocols seeking to bridge assets across chains including Ethereum, BNB Chain, Bitcoin, and permissioned ledgers; AI and compute-intensive users seeking verifiable off-chain computations for machine learning and zero-knowledge-based proofs. Principal markets for these services include: European Union member states; Southeast Asia (notably Singapore where PROOF SPACE PTE. LTD. is incorporated); North America, specifically jurisdictions where utility tokens are legally permitted for use (excluding restricted U.S. states where applicable); Middle East and Africa, where cross-chain infrastructure demand is growing. The issuer operates as a protocol-layer innovator with global relevance, supporting interoperability and decentralized computation across major public and enterprise blockchains. |
|||
| 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 | (Singapore dollars) PROFIT/LOSS STATEMENTS 16-Jun-2023 to 30-June-2024 Revenue: 813,137 Cost of services: (2,323,397) Gross loss: (1,510,260) Employee benefits expenses: (607,874) Other expenses: (200,790) Loss before tax: (2,310,475) Income tax expense – Loss for the financial year, representing total comprehensive loss for the financial year (2,310,475) 1-Jul-2024 to 30-Jun-2025 Revenue: 813,137 Cost of services: (2,323,397) Gross loss: (1,510,260) Other income: 8,449 Gain/Loss on investment: – Employee benefits expenses: (607,874) Other expenses: (200,790) Loss before tax: (2,310,475) Income tax expense: – Loss for the financial year: (2,310,475) 1-Jul-2025 to 30-Sep-2025 Revenue: 63,336 Cost of services: 8,426 Gross profit: 54,910 Other income: 3 Gain/Loss on investment: 1,950,000 Employee benefits expenses: (79,308) Other expenses: (9,705) Loss before tax: 1,915,900 Income tax expense: 325,703 Profit for the period: 1,590,197 BALANCE SHEETS: As at 30 June 2024 ASSETS Bank balances 860,193 Due from a shareholder 201,778 Total current assets 1,061,971 Total assets 1,061,971 EQUITY AND LIABILITIES Share capital 400,000 Accumulated loss (69,977) Total equity 330,023 Accrued operating expenses 176 Deferred revenue 731,772 Total current liabilities 731,948 Total equity and liabilities 1,061,971 As at 30 June 2025 ASSETS Bank balances 56,281 Inventory – Due from a shareholder – Total current assets 56,281 Total assets 56,281 EQUITY AND LIABILITIES Share capital 1,000,000 Accumulated loss (2,380,452) Total equity (1,380,452) Accrued operating expenses 105,265 Deferred revenue – Due to a shareholder 1,331,468 Total current liabilities 1,436,733 Total equity and liabilities 56,281 As at 30 September 2025 ASSETS Bank balances 22,181 Inventory 1,950,000 Due from a shareholder – Total current assets 1,972,181 Total assets 1,972,181 EQUITY AND LIABILITIES Share capital 2,300,000 Accumulated loss (464,552) Total equity 1,835,448 Accrued operating expenses 105,265 Deferred revenue – Due to a shareholder 31,468 Total current liabilities 136,733 Total equity and liabilities 1,972,181 The Company plans to continue to allocate its financial resources primarily to support product development. |
|||
| 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 | This design enhances both security and interoperability by ensuring each cross‐chain transfer is cryptographically validated. The same zero-knowledge architecture also supports on-chain verification of off-chain computation, enabling services such as delegated proof generation and verifiable AI computation. Polyhedra Network's infrastructure is further described in Section 08 (Characteristics of the crypto-asset), where the functionality of the ZKJ token—used to pay for these services—is detailed. For additional technical information, see Part H (information on the underlying technology). |
|||
| 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 | ||||
| Person #2 | id | 2 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #3 | id | 3 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #4 | id | 4 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #5 | id | 5 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #6 | id | 6 | |||
| 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 | The ZKJ token functions as the native utility resource consumed when accessing services within the Polyhedra Network ecosystem. These services include: • Cross-chain bridging: ZKJ is required as the resource cost for secure, trustless transfers of assets and data across supported blockchains via the zkBridge protocol. • Verifiable computation: Users consume ZKJ tokens as the computational requirement of generating and verifying zero-knowledge proofs for computations executed off-chain but validated on-chain. • On-chain transaction fees: ZKJ is consumed as gas for transactions on EXPchain, Polyhedra's dedicated layer-1 blockchain. • Staking and governance: ZKJ can also be staked to support network security and operations, and used for voting in protocol-level governance decisions. These services are already live and available to ZKJ holders as of the publication date of this whitepaper. |
|||
| D.8 Plans for the token | |||||
| Description of past milestones | textBlock | Q2 2023: Product launches for cross-chain bridges and cross-chain messaging protocols Q3 2023: full-consensus verification for Ethereum Q4 2023: improved finality on the cross-chain protocols Q1 2024: Token generation event for Polyhedra Network Tokens Q2 2024: delegated proof generation services, in collaboration with Google Cloud Q3 2024: cross-chain bridges with Bitcoin and other verifiable computation related to machine learning. Q4 2024: cross-chain bridges with consortium / permissioned blockchain Q1 2025: GPU acceleration for delegated proof generation services and its offering to traditional institutional customers Q2 2025: GPU accelerated delegated proof generation and products around verifiable machine learning on-chain |
|||
| Description of future milestones | textBlock | Q4 2025: Consensus improvement to on-chain computation verification system with faster finality and decentralization. |
|||
| D.9 Resource allocation | text | ||||
| D.10 Planned use of collected funds or other tokens | text | ||||
| 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 | ZKJ token has not yet been offered to the public in the European Union according to MICA regulation. Accordingly, the company has taken steps to draw up this white paper to comply with the applicable provisions of the MICA Regulation in order to enable the admission to trading of the ZKJ token within the European Union. Admission to trading improves accessibility of ZKJ token and enables ZKJ's use in DeFi protocols. Admitting ZKJ to trading on compliant platforms is intended to facilitate broad market access and liquidity for the token. By enabling ZKJ to be traded on regulated exchanges, the Polyhedra network project aims to reach a wide audience of users and investors. Widespread trading also allows ZKJ's value to be discovered via market forces, supporting transparency. |
|||
| 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 | ||||
| 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 | Outside the European Union, ZKJ is also listed on the following trading platforms: PancakeSwap, BinanceAlpha, Bitget, MEXC, Gate, KuCoin, Crypto.com Exchange, BingX, BitMart, Deepcoin, KCEX, Bitunix, Hotcoin, DigiFinex, TruBit Pro Exchange, BloFin, Ourbit, OrangeX, HashKey Global, Uniswap, BitKan, AscendEX, CoinEx, Bitrue, Coinone, Tothemoon, BVOX, LATOKEN, Niza.io, ZebPay, Indodax, BiKing, BTCC, GroveX, BlockFin, SuperEx, TRIV, SpireX, TGEX, and ZKE. |
|||
| E.34 Trading platforms market identifier code (MIC) | text | ||||
| E.35 Trading platforms access | text | Once registered and funded, investors can search for the ZKJ token trading pair and place buy or sell orders directly through the platform's trading interface. Many exchanges also offer mobile apps and advanced trading platforms to assist investors with navigating and using their services. |
|||
| E.36 Involved costs | textBlock | ||||
| E.37 Offer expenses | textBlock | ||||
| E.38 Conflicts of interest | textBlock | ||||
| E.39 Applicable law | textBlock | ||||
| E.40 Competent court | textBlock | ||||
| Part F - Information about other tokens | |||||
| F.1 Crypto-asset type | text | It is neither pegged to any fiat currency nor backed by any external assets, distinguishing it clearly from EMTs and ARTs. |
|||
| F.2 Other token functionality | textBlock | governance (limited to protocol parameters only, excluding any corporate governance rights). Token holders can access premium features, participate in network validation, and contribute to ecosystem development. The token serves as a coordination mechanism for network participants and stakeholders. |
|||
| 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 | ||||
| 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 | ||||
| F.19 Host member states #30 | enumerationSet | ||||
| Part G - Information on rights and obligations attached to other tokens | |||||
| G.1 Purchaser rights and obligations | textBlock | Holders of ZKJ token have the right to claim full liability from the token issuer - PROOF SPACE PTE. LTD., its members of administrative, management and/or supervisory bodies under Article 15 of Regulation (EU) 2023/1114 for any loss incurred to holders of the crypto-asset due to any infringement of Article 6 where PROOF SPACE PTE. LTD. provide information in this crypto-asset white paper or any modified crypto-asset white paper that is not complete, fair, clear, or that is misleading. |
|||
| G.2 Exercise of rights and obligations | textBlock | All rights and obligations must be exercised in compliance with applicable laws and the provisions outlined in this whitepaper. Changes or new information will be regularly published on the Polyhedra Network website, social media and/or through the newspaper. Holders are responsible for keeping their own wallet keys secure and for conducting transactions on the correct network. |
|||
| G.3 Conditions for modifications of rights and obligations | textBlock | ||||
| 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 | ||||
| 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 | ||||
| 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 | ||||
| G.19 Competent court | textBlock | ||||
| Part H – Information on underlying technology | |||||
| H.1 Distributed ledger technology (DTL) | text | ||||
| H.2 Protocols and technical standards | text | Network Layer Protocols and Transport Standards • For validator and node communication on supported blockchains, protocols such as libp2p (used in Ethereum and other modern PoS networks) and QUIC are employed depending on the specific chain. • Polyhedra's zkBridge does not introduce its own P2P layer but leverages the messaging and propagation standards native to each integrated chain. • For its in-development Layer-1 chain (EXPchain), the network is expected to follow libp2p-based networking similar to Ethereum, enabling robust peer discovery and block propagation. Consensus Mechanisms • Polyhedra does not alter the consensus of the underlying chains it integrates with. It validates finality proofs based on the source chain's existing consensus mechanism: o Ethereum: Proof-of-Stake (Casper FFG, LMD-GHOST). o BNB Chain: Delegated Proof-of-Stake with Authority Validators. o Bitcoin (future support): Proof-of-Work with block confirmation thresholds. • EXPchain (Polyhedra's L1): Inherits the Ethereum PoS design, using validator staking and slashing logic. Finality is achieved through slot-based epochs and attestation aggregation (mirroring Ethereum post-Merge). Data Structures and Transaction Formats • Merkle Trees and Sparse Merkle Trees are used for block receipts, transaction inclusion proofs, and account state validation. • zkSNARK and Plonkish circuits (e.g., PLONK, Groth16) are used for generating zero-knowledge proofs of computation, state, and cross-chain events. • Blocks follow a typical structure: header, body, receipts, and ZK proof attachments, depending on the chain. • State changes are encoded via Ethereum-compatible state trie updates, with root hashes updated and verified on-chain via ZK circuits. Address Schemes and Transaction Types • Polyhedra supports EIP-55 checksummed Ethereum addresses and BIP-44 HD wallet derivations for multi-chain compatibility. • On Ethereum-compatible networks, EIP-1559, EIP-2930, and legacy transaction formats are all supported. • For zkBridge operations, transaction payloads include bundled proof data, verification hashes, and optionally a message payload for inter-chain communication. Protocol Upgrade and Circuit Evolution • Protocol upgrades, including zkCircuit changes or parameter updates, are governed by on-chain governance using ZKJ token voting. • Circuit versioning is enforced at the contract level to ensure backward compatibility. • If a trusted setup is used (e.g., for Groth16), any update requires a new ceremony. Updates are announced via governance proposals and executed via upgradeable smart contracts or rollup code paths. |
|||
| H.3 Technology used | textBlock | Users interact with the network through Web3-enabled wallets that rely on private key cryptography. Each wallet is secured by a unique private key that enables transaction signing and identity verification. The security model ensures that only the private key holder can authorize token transfers or interactions with smart contracts. Private keys must be safeguarded by the user or securely managed by custodial providers when used via centralized platforms. To ensure cryptographic integrity, Polyhedra employs industry-standard zero-knowledge proof systems (e.g., Groth16, PLONK), which allow transactions and cross-chain messages to be validated without exposing sensitive data. All state changes and computation results are committed to the blockchain via verifiable proofs, preserving data integrity and ensuring correctness of execution. These proofs are generated off-chain and verified on-chain, ensuring that trust is placed in cryptographic computation rather than intermediaries. |
|||
| H.4 Consensus mechanism | text | Ethereum uses the following consensus mechanism: the crypto-asset's Proof-of-Stake (PoS) consensus mechanism, introduced with The Merge in 2022, replaces mining with validator staking. Validators must stake 32 ETH every block a validator is randomly chosen to propose the next block. Once proposed the other validators verify the blocks integrity. The network operates on a slot and epoch system, where a new block is proposed every 12 seconds, and finalization occurs after two epochs (~12.8 minutes) using Casper-FFG. The Beacon Chain coordinates validators, while the fork-choice rule (LMD-GHOST) ensures the chain follows the heaviest accumulated validator votes. Validators earn rewards for proposing and verifying blocks, but face slashing for malicious behavior or inactivity. PoS aims to improve energy efficiency, security, and scalability, with future upgrades like ProtoDanksharding enhancing transaction efficiency. As for Polyhedra's layer-1 chain (EXPchain) used for on-chain verification of off-chain computation, the consensus mechanism is designed to follow the same Proof-of-Stake model as Ethereum. At the time of writing, this chain is under development, with testnet functionality in progress. |
|||
| H.5 Incentive mechanisms and applicable fees | text | Additionally, participants who stake ZKJ tokens to support network operations—such as zero-knowledge proof generation or governance validation—may receive protocol-level rewards. These are distributed either automatically through smart contracts or periodically based on contribution metrics, such as proof volume or uptime. While the precise reward schedule (e.g., per block or epoch) may be refined during mainnet rollout, the incentive system is already in place for staking and will mirror models used in existing PoS ecosystems. |
|||
| H.6 Use of distributed ledger technology | boolean | ||||
| H.7 DLT functionality description | textBlock | All accounts' balances are recorded and updated in an immutable and verifiable manner. The underlying DLT technology that Polyhedra uses is similar to and based on the technologies used in Ethereum blockchain. |
|||
| Other token audit details | |||||
| H.8 Audit | boolean | ||||
| H.9 Audit outcome | textBlock | ||||
| Part I - Information on risks | |||||
| I.1 Offer-related risks | textBlock | • According to the current evaluation ZKJ tokens are not deemed securities and no law prohibits their sale in the European Union. However, future changes in law or interpretation could impose restrictions on the token, possibly affecting its legality or trading. • The admission of the ZKJ token to trading will be carried out by trading platforms or crypto-asset service providers (CASPs) that are neither operated, controlled, nor supervised by Proof Space Pte. Ltd and its branch. • Proof Space Pte. Ltd and its branch do not assume any responsibility for the governance or functioning of such platforms. Regulatory authorities may intervene or suspend admission to trading in cases of non-compliance with applicable legal or regulatory standards. Any legal relationship between ZKJ token holders and the relevant trading platforms or CASPs shall be exclusively governed by the respective terms and conditions established at the sole discretion of each platform. • Proof Space Pte. Ltd and its branch make no representations or warranties in relation to any trading platform or crypto-asset service provider (CASP), and disclaim any responsibility or liability for regulatory, compliance, operational, financial, technical, or reputational failures on the part of such entities. This includes, without limitation, any failures that may lead to service disruptions, trading restrictions, or the suspension or termination of operations by the relevant trading platform or CASP, whether due to sanctions, insolvency, or similar events. Such circumstances may result in significant and potentially total losses to holders of the ZKJ token. 2. Distribution and Operational Risk: • The ZKJ token is entirely dependent on the blockchain the crypto asset is issued upon. Any issues, such as downtime, congestion, or security vulnerabilities within the blockchain, could adversely affect the token's functionality. • Smart contracts governing the token may contain hidden vulnerabilities or bugs that could disrupt the token offering or distribution processes. • As the trading of the token involves different trading venues, technical risks such as downtime of the connection or faulty code are also possible. • Due to the irrevocability of blockchain-transactions, approving wrong transactions or using incorrect networks/addresses will most likely result in tokens not being accessible anymore. • When admitting the token to trading, the risk of losing clients' assets due to hacks or other malicious acts is given. This is due to the fact that the token is held in custodial wallets for the customers. Market Volatility and Liquidity Risk: Crypto asset markets are highly volatile and subject to rapid fluctuations in price and demand. Liquidity may initially be limited, which could exacerbate price volatility. It is common in the crypto industry for token prices to experience sharp declines. 3. Failure of one or more Counterparties: the internal operational processes of the counterparties used may be risky. As there is no specific oversight other than the typical due diligence check, it cannot be guaranteed that all counterparties adhere to the best market standards. Counterparties could go bankrupt, possibly resulting in a total loss for the clients assets hold at that counterparty. |
|||
| I.2 Issuer-related risks | textBlock | ZKJ is issued by a company incorporated in Singapore, governed by Singapore law for corporate matters. For the purposes of this white paper and any offer within the EU/EEA, the person seeking admission is the Singaporean entity that carries out the admission-to-trading related actions under EU law (including MiCA) and Lithuanian law. Operational and Business Risk of the Issuer: Polyhedra Network is an emerging technology project subject to typical startup risks: financial shortfalls, inability to secure additional funding, delays in product development, or lack of adoption. If the issuer cannot sustain operations or maintain its services (e.g., staking, governance, zkBridge), the fundamental value proposition of ZKJ would be undermined. Technology Development and Integration Risk: Polyhedra's services (such as the zkBridge protocol and cross-chain interoperability tools) involve complex and nascent technologies, including zero-knowledge proofs and interactions with multiple blockchains. There is a risk that the issuer may face technical challenges in fully realizing these innovations at scale. Integration with various blockchain platforms inherently carries risk: if a targeted blockchain changes its protocol or experiences performance issues, Polyhedra's cross-chain solution might need rework or could suffer downtime. Any failures or delays in achieving the stated technological milestones would directly affect the usefulness of ZKJ (since the token is meant to enable access to these very services). Dependence on Issuer's Services for Token Utility: The ZKJ token's value is strongly tied to the health and usage of the Polyhedra ecosystem. ZKJ is a utility token conferring governance rights and access to services, but it does not represent equity, profits, or claims on tangible assets of the issuer. Therefore, the economic value of ZKJ is dependent on the continued relevance and quality of the issuer's services (e.g. staking rewards, cross-chain transactions via zkBridge, and gas fee subsidies). If the issuer fails to maintain an attractive platform – for instance, if competitors offer better cross-chain solutions or if users do not perceive sufficient benefit in using ZKJ for fees/governance – then the token's utility (and thus market demand) could decline. Additionally, since the issuer's services span multiple external blockchains, any negative development in those external networks (for example, a major security failure on a supported chain or a regulatory ban on a certain chain) could indirectly reduce the functionality of Polyhedra's services and thus the appeal of ZKJ. Governance and Control Risk: While ZKJ token holders are intended to participate in governance, actual decentralization of control may be limited, especially in early stages. Insiders or early backers holding significant portions of tokens could exert outsized influence. Weak participation, apathy, or governance attacks could hinder decision-making and negatively impact the project. Reputation and Execution Risk: Negative publicity, operational failures, or association with illicit activities could harm the reputation of the issuer and reduce the market value and acceptance of ZKJ token. Competition: there are numerous other crypto-asset projects in the same realm, which could have an effect on the crypto-asset in question. Unanticipated Risk: In addition to the risks included in this section, there might be other risks that cannot be foreseen. Additional risks may also materialise as unanticipated variations or combinations of the risks discussed. |
|||
| I.3 Other tokens-related risks | textBlock | Crypto-assets face unique security threats, including the risk of theft from exchanges or digital wallets, loss of private keys, and potential failures of custodial services. Since crypto transactions are generally irreversible, a security breach or mismanagement can result in the permanent loss of assets, emphasizing the importance of strong security measures and practices. Any issues with the blockchain used, such as network downtime, congestion, or security vulnerabilities, could disrupt the transfer, trading, or functionality of the crypto-asset. The ZKJ token and its associated functions (staking, governance, cross-chain transfers) are implemented through smart contracts and cryptographic protocols. Technical vulnerabilities in any of these components pose a direct risk to token holders. Despite security audits and testing, smart contracts may contain bugs or unforeseen interactions. A security breach could result in theft, unauthorized minting of tokens, or permanent loss of token functionality (e.g., tokens locked in a contract). The broader Polyhedra protocol – particularly the zkBridge cross-chain system – also carries security risks: cross-chain bridges have historically been a top target for hackers. Should any vulnerability exist in Polyhedra's zkBridge or related ZK proof systems, an exploit could lead to loss or theft of assets being bridged or staked, including ZKJ tokens and other linked assets. Additionally, zero-knowledge proof systems are cutting-edge; while they offer strong security in theory, a flaw in the implementation of the ZKJ proofs or cryptography could potentially compromise the integrity of cross-chain messages or allow falsification of transactions. Token holders are exposed to the risk that a critical bug or attack on the Polyhedra Network's contracts could severely impair the value and utility of ZKJ. Although the project will employ rigorous security audits and monitoring, the technological complexity inherently means some risk will always remain. Cross-Chain and Interoperability Risk: By design, ZKJ and the Polyhedra Network operate across multiple distributed ledger environments (Ethereum, BNB Chain, Polyhedra's own EXPchain, and potentially others). This multi-chain presence means that the token's utility and custody can shift between chains via bridging. Interoperability risk refers to the danger that something goes wrong in the transfer or recognition of the token across different networks. If the bridging mechanism fails on one chain (for example, if the bridge smart contract on Ethereum were paused or compromised), ZKJ tokens could become temporarily non-transferable or permanently lost on that chain. Users holding ZKJ on one chain may find that they cannot move it to the chain where they need to use it, undermining the token's usefulness. Additionally, differences in network conditions – such as one chain experiencing congestion or a fork – could create inconsistent states for the token supply. The project's reliance on an innovative zkBridge (zero-knowledge bridge) aims to minimize trust in third parties, but it also introduces novel failure modes (e.g., if the validity proofs are not generated or verified correctly under certain conditions, cross-chain transfers might halt). Each connected blockchain also brings its own risks. Holders must recognize that using ZKJ "across DLTs" means accepting the compounded risks of all those networks and the bridging links between them. Staking and Slashing Risk: A key utility of ZKJ token is to enable staking within the Polyhedra ecosystem – users can stake tokens to participate in network functions (like being a zkProof provider or validator) and earn rewards. With staking comes the possibility of "slashing" or penalties. In many proof-of-stake based systems, staked tokens can be partially or fully confiscated if the validator behaves maliciously or even due to accidental faults (e.g., double signing or prolonged downtime). While slashing is generally rare and intended as a deterrent, the possibility cannot be ignored. A bug in the staking mechanism or an unexpected network failure could erroneously trigger slashing of honest participants. Additionally, staking often requires locking tokens for a certain period; during this time, staked ZKJ cannot be traded or used elsewhere, which means stakers are exposed to price risk and liquidity risk on their locked tokens. If a large portion of ZKJ is staked, any slashing event or fear thereof could impact market confidence in the token. Furthermore, operating a node or staking service may involve trusting third-party infrastructure or delegation. If users delegate their ZKJ to a staking service provider (or use the issuer's staking service), they also take on counterparty risk: the provider could mismanage keys or act negligently. Governance Abuse and Insider Control: ZKJ token holders are entitled to participate in the governance of the Polyhedra Network's protocols and ecosystem decisions. However, this feature carries governance-related risks. One risk is governance attack, where an attacker accumulates a large amount of tokens (possibly through purchase, or temporarily via borrowing mechanisms like flash loans) to influence or pass a proposal that benefits the attacker at the expense of the community. While Polyhedra's governance may have safeguards (e.g., timelocks on proposals, quorum requirements) to mitigate such attacks, the risk cannot be fully eliminated, especially in a nascent governance system where participation might be low. Another aspect is insider governance manipulation: the core team or early investors might hold significant token quantities, allowing them to sway decisions or block proposals that would otherwise be supported by the majority of smaller holders. This could entrench the issuer's control despite a nominally decentralized governance, potentially leading to decisions that favor insiders (such as altering token economics, redirecting treasury funds, or changing fee structures) but hurt the broader token holder base. Additionally, there is a risk that governance processes could be ineffective – for example, critical decisions could be delayed or unresolved due to voter apathy or indecision, hindering the project's ability to respond to emerging challenges (like upgrading the protocol to patch a security issue). Investors in ZKJ should weigh the fact that governance rights, while potentially valuable, also introduce new vectors for things to go wrong, and that robust community engagement and security measures are needed for governance to be a net positive. Market Behavior and Token Value Risk: Beyond utility, the ZKJ token will trade in the open market, and its value will be influenced by myriad factors that are often unpredictable (including market sentiment, regulatory changes, technological advancements, and macroeconomic conditions, including interest rates). These fluctuations can result in significant financial losses within short periods, making the market highly unpredictable and challenging for investors. Speculative trading can lead to extreme volatility, but also phenomena such as price bubbles or flash crashes. This is especially true for crypto-assets without any intrinsic value, and investors should be prepared to lose the complete amount of money invested in the respective crypto-assets. There is also concentration risk: if a few large holders (whales) possess a big share of the circulating tokens, their trading decisions (e.g., selling a large block of tokens) could materially impact the market price. New participants in the market should also be aware that market manipulation is a known concern in crypto markets – although market abuse is prohibited and MiCA extends certain market integrity rules to crypto trading, enforcement is challenging across jurisdictions. Crypto-assets may be particularly susceptible to heightened market abuse risks, given that their underlying infrastructure can be exploited for manipulative practices such as front-running, spoofing, pump-and-dump schemes, and cross-platform or cross-border fr |
|||
| I.4 Project implementation-related risks | textBlock | ||||
| I.5 Technology-related risks | textBlock | • Blockchain dependency is managed by designing the zkBridge to gracefully handle delays or reorgs on integrated chains, and by relying only on finalized states when relaying proofs. • Blockchain Dependency Risks: The functionality of the ZKJ token and the Polyhedra Network is inherently dependent on the stability, performance, and security of underlying blockchain networks (e.g. Ethereum, BNB Chain, etc.). Any downtime, network fork, consensus failure, or congestion in these networks can impair services such as cross-chain transfers, transaction verification, and staking. In extreme scenarios, smart contract execution may be halted or delayed, resulting in loss of functionality or user trust. • Wallet and storage risks are mitigated by supporting widely adopted Web3 wallet standards with strong encryption, and encouraging users to follow best practices for private key management. Future support for multi-signature and hardware wallet integrations is planned. • Wallet and storage vulnerabilities: Users must manage their own keys through Web3 wallets. Loss of private keys, phishing, or compatibility errors can lead to permanent token loss. Custodial wallet services may also face technical or security failures. • Network security risks are actively addressed through comprehensive third-party audits of all smart contracts and zk circuits. An ongoing bug bounty program and internal fuzz testing are also employed to surface potential vulnerabilities early. • Network and smart contract security: Despite audits, vulnerabilities may still exist in core contracts or relay mechanisms (e.g., zkBridge). Exploits, front-running, or denial-of-service attacks could lead to service outages or loss of funds • Centralization concerns are mitigated by transitioning validator operations and zk-proof generation toward a decentralized participant base over time, supported by community governance of protocol upgrades and staking incentives. • Centralization concerns: Although designed to become decentralized, parts of the protocol (e.g., governance, oracle relayers, contract upgrades) may remain under the control of the core team or a small group in the early stages, which may pose governance or trust risks. • Evolving technology risks (such as zk-SNARK parameter changes or trusted setup updates) are addressed through versioned circuit design, transparent governance for upgrades, and fallback mechanisms to ensure continuity of proof generation and verification. • Technology evolution: Zero-knowledge proofs and decentralized infrastructure are still rapidly evolving. There is a risk that current implementations may be surpassed, deprecated, or require significant re-engineering to remain secure and effective. • Regulatory compliance adaptability is built into the protocol governance framework, enabling timely updates in response to changing legal or technical requirements, including those affecting proof systems or interoperability mechanisms. These measures are complemented by ongoing research, internal quality assurance, and close monitoring of both technical infrastructure and the regulatory landscape. Together, they provide a proactive framework for minimizing risk while maintaining innovation and performance. |
|||
| I.6 Mitigation measures | textBlock | ||||
| 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 | ||||
| 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 | Ethereum uses the following consensus mechanism: the crypto-asset's Proof-of-Stake (PoS) consensus mechanism, introduced with The Merge in 2022, replaces mining with validator staking. Validators who stake 32 ETH become eligible to propose blocks. For each block, one validator is randomly chosen to propose the next block. Once proposed the other validators verify the blocks integrity. The network operates on a slot and epoch system, where a new block is proposed every 12 seconds, and finalization occurs after two epochs (~12.8 minutes) using Casper-FFG. The Beacon Chain coordinates validators, while the fork-choice rule (LMD-GHOST) ensures the chain follows the heaviest accumulated validator votes. Validators earn rewards for proposing and verifying blocks, but face slashing for malicious behavior or inactivity. PoS aims to improve energy efficiency, security, and scalability, with future upgrades like ProtoDanksharding enhancing transaction efficiency. As for Polyhedra's layer-1 chain used for on-chain verification of off-chain computation, the consensus mechanism will be the same design that Ethereum uses. |
|||
| S.5 Incentive mechanisms and applicable fees | text | • Staking Rewards: ZKJ token holders can stake tokens via smart contracts on the Polyhedra Network. Participants who stake help secure the network (e.g., by supporting zk-proof generation or transaction validation) and may earn rewards in ZKJ, depending on participation level, duration, and network activity. This functionality is live and accessible. • Service-Based Fees: Users consume ZKJ as gas fees for using services such as EXPchain transactions and zkBridge cross-chain messaging. These fees contribute to the reward pool for network participants, including validators or provers. • Validator Compensation: While Polyhedra's Layer-1 chain (EXPchain) is under development, the planned consensus model will compensate validators with transaction fees, similar to Ethereum's PoS design. These mechanisms are governed by on-chain smart contracts and protocol parameters, and may evolve through community governance. Full details on the current staking process and fee usage are available in Section H.5. |
|||
| 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 | Energy usage arises primarily from: • Validators participating in PoS networks (external chains) • Delegated zk-SNARK and PLONK proof generation (episodic, off-chain workloads) Internal infrastructure does not operate continuous, high-throughput mining or consensus servers. Based on current transaction volumes and typical zk prover compute profiles, estimated annual energy consumption remains significantly below the 500,000 kWh/year threshold for mandatory extended disclosure under Annex II of Commission Implementing Regulation (EU) 2024/2984. |
|||
| 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 | ||||
| S.16 Key GHG sources and methodologies | textBlock | ||||
| 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 | ||||