| [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 | Holders of $VERFI may exercise the following rights within the Inference Network: (a) Governance participation – Holders of $VERFI may stake their tokens to receive a non-transferable representation token that may be used to participate in protocol governance processes, including voting on proposals related to protocol parameters, upgrades, and governance structures, in accordance with the applicable governance phase; (b) Protocol participation – Depending on their chosen role, $VERFI holders may use their tokens to: operate infrastructure components within the network; delegate tokens to other participants who perform operational roles; or register and make available models for use within the network; (c) Fee-based utility – $VERFI may be used as a means of payment for services provided through the Inference Network. $VERFI is not intended to represent ownership, equity, or claims over the assets, revenues, or profits of any legal entity. The token is used as a functional unit within the protocol to enable participation, align incentives among network participants, and support the operation and integrity of the Inference Network. The maximum supply of $VERFI is fixed and capped at 1,000,000,000 tokens. No mechanism exists to increase this maximum supply. |
|||
| 09 Further information about utility tokens | textBlock | ||||
| 10 Key information about the offer to the public or admission to trading | textBlock | ||||
| 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 | British Virgin Islands |
|||
| 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 | George Town, Grand Cayman, Cayman Islands |
|||
| 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 | The offeror has not engaged in lending, borrowing, or any form of external financing, nor has it issued debt instruments or entered into credit arrangements. Its operations to date have been funded exclusively through internal resources made available at the time of establishment. As of the latest reporting period, the offeror's available budget amounts to approximately USD $200,000 per month. These resources are allocated to operational expenses related to software development, security audits, regulatory and compliance needs, partnership coordination, and administrative functions necessary for the maintenance of the $VERFI token framework. |
|||
| 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 | The Inference Network brings together different categories of participants who perform distinct functions within the protocol. These participants include infrastructure operators who execute computational tasks, validators who review and challenge outputs, contributors who make models available for use within the network, and users who request verified inference services. The protocol is designed to operate without reliance on a central operator once fully deployed. The crypto-asset $VERFI is used within the project as a functional component to coordinate participation, secure network activity, and support governance processes. It is used to enable staking, delegation, fee payments, and participation in protocol decision-making. The token also supports incentive mechanisms intended to encourage compliant behavior and long-term participation by network contributors. The project follows a progressive approach to decentralization. In its initial phase, certain governance and operational parameters are overseen by a designated governance body to support stability and security. Over time, governance is intended to transition to a decentralized model in which decisions are made through protocol-defined voting mechanisms involving tokenholders. The crypto-asset project does not involve the issuance of financial instruments, confer ownership rights in any entity, or provide guarantees of value or return. The development and operation of the project are subject to technical, economic, and regulatory risks, which are described in other sections of this white paper. |
|||
| 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 | Hamilon, ON, L8L 6N4 Canada |
|||
| Domicile of company | enumeration | ||||
| D.6 Utility token classification | boolean | ||||
| D.7 Key features of goods or services for utility token projects | text | ||||
| D.8 Plans for the token | |||||
| Description of past milestones | textBlock | Past milestones Prior to the preparation of this white paper, the crypto-asset project has completed the following high-level milestones: - Conceptual design of the Inference Network, including definition of participant roles and incentive mechanisms. - Development of the core protocol architecture supporting inference verification, staking, delegation, and challenge mechanisms. - Design of the $VERFI tokenomics framework, including fixed maximum supply, staking functionality, governance participation. - Establishment of an initial governance structure to oversee protocol security, parameter setting, and early-stage decision making. |
|||
| Description of future milestones | textBlock | - Protocol deployment and scaling: Progressive deployment of the Inference Network's core smart contracts and supporting infrastructure, with ongoing optimization for performance, security, and reliability. - Activation of token utilities: Gradual activation of $VERFI use cases, including staking, delegation and governance participation, in line with protocol maturity. - Governance transition: Progressive transfer of governance responsibilities from an initial governance body to decentralized governance mechanisms involving eligible tokenholders, subject to predefined conditions and safeguards. - Ecosystem development: Expansion of network participation, including additional infrastructure operators, model contributors, and service consumers, supported by incentive and partnership programs. - Protocol upgrades: Ongoing upgrades to protocol functionality and security, implemented through governance-approved processes. |
|||
| 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 | ||||
| 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 | ||||
| E.34 Trading platforms market identifier code (MIC) | text | ||||
| E.35 Trading platforms access | text | ||||
| 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 | The value of the crypto-asset is entirely determined by market forces – specifically, the dynamics of supply and demand – and is not supported by any stabilization mechanism. It is neither pegged to a fiat currency nor backed by external assets, which differentiates it from EMTs and ARTs. Moreover, the crypto-asset does not qualify as a financial instrument, deposit, insurance policy, pension product, or any other regulated financial product under EU law. It does not confer any financial entitlements contractual claims on its holders, thereby placing it outside the regulatory scope governing traditional financial instruments. |
|||
| F.2 Other token functionality | textBlock | $VERFI does not represent shares, equity, debt, ownership interests, or a right to receive profits or redemption at a guaranteed value. It is intended solely for protocol-related functions and does not create any contractual claim against the issuer or any affiliated entity. VERFI tokens are freely transferable ERC-20 assets on the Ethereum blockchain, providing holders with flexibility to delegate governance rights or engage in ecosystem activities. |
|||
| 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 | ||||
| Part G - Information on rights and obligations attached to other tokens | |||||
| G.1 Purchaser rights and obligations | textBlock | VERFI holders retain full control and ownership of their tokens, which are freely transferable on the Ethereum network in accordance with the ERC-20 token standard. Ownership of VERFI does not confer any rights of equity, profit-sharing, debt, or repayment in DROP TABLE CAPITAL LTD. nor in any affiliated entity. |
|||
| G.2 Exercise of rights and obligations | textBlock | ||||
| 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 | ||||
| H.3 Technology used | textBlock | The project is designed around a modular system architecture. Rather than relying on a single, monolithic AI system, the network supports the participation of multiple independent components, including infrastructure operators, model providers, and verification participants. This modular approach is intended to reduce concentration of control and allow a broad range of participants to contribute to and interact with the system. The technology is designed to support interoperability between decentralized systems and autonomous software agents. By using distributed ledger technology as a neutral coordination and settlement layer, the protocol enables automated agents and human users to interact under predefined rules, with transparent verification of outcomes and value transfers. The system leverages Web3 infrastructure to embed value transfer, verification, and governance directly at the protocol level. Ethereum smart contracts are used to enable programmatic trust, auditable execution of rules, and transparent participation without reliance on centralized intermediaries. The technology stack may evolve over time to reflect advances in blockchain standards, cryptographic techniques, artificial intelligence tooling, or security practices. Any material changes to the technology used by the project are expected to be implemented through defined upgrade or governance processes and may affect how the crypto-asset functions within the protocol. Additional information may be found in the official documentation of the project: https://docs.inferencelabs.com/ |
|||
| H.4 Consensus mechanism | text | This system was introduced in 2022, replacing the previous Proof-of-Work model to enhance security, energy efficiency, and scalability. Under Proof-of-Stake, network integrity is maintained by validators rather than miners. Validators are participants who stake 32 ETH as collateral within a smart contract to become eligible to verify transactions and propose new blocks. In each 12-second slot, one validator is randomly selected to propose a block, while a committee of other validators attests to its validity. Ethereum organizes time into epochs, each consisting of 32 slots. Once a sufficient majority of validators have attested to consecutive checkpoints within these epochs, a block is considered finalized, meaning it cannot be reversed without significant economic penalty. This consensus design achieves Byzantine fault tolerance, ensuring that the network reaches agreement on a single valid state even in the presence of faulty or malicious actors. Additionally, Proof-of-Stake significantly reduces Ethereum's energy consumption compared to mining-based systems and enables more efficient scaling solutions. |
|||
| H.5 Incentive mechanisms and applicable fees | text | Validator Rewards Validators are responsible for proposing new blocks and attesting to the validity of blocks proposed by others. In return for performing these duties correctly and consistently, validators earn rewards denominated in ETH, which are automatically added to their staked balance. • Block Proposal Rewards: Granted to validators selected to create new blocks. • Attestation Rewards: Distributed to validators who confirm that proposed blocks are valid. • Sync Committee Rewards: Periodic incentives for participating in specialized committees that help propagate finalized states across the network. • Inclusion and Participation Bonuses: Additional rewards are given to validators who participate promptly, maintaining high uptime and responsiveness. These rewards encourage validators to remain active, properly configured, and connected, thereby ensuring the liveness and stability of the network. Penalties and Slashing To maintain integrity, Ethereum enforces penalties for non-performance or dishonest behavior: • Inactivity Penalties: Validators who fail to perform their duties, for instance due to downtime or misconfiguration, lose a small portion of their stake over time. • Slashing: Validators who act maliciously—such as by proposing conflicting blocks or submitting contradictory attestations—can be slashed, meaning part of their staked ETH is destroyed, and the validator is forcibly removed from the network. The severity of slashing depends on the correlation of infractions: isolated errors incur minor penalties, while coordinated or mass misconduct can lead to the loss of up to 100% of the validator's stake. Finality and Economic Security Ethereum's PoS finality mechanism ensures that once two-thirds of the total staked ETH agrees on a checkpoint, it becomes finalized and irreversible without severe financial loss. To revert a finalized block, an attacker would have to destroy at least one-third of all staked ETH – making attacks economically irrational and self-destructive. Incentive Alignment This mechanism creates a self-reinforcing equilibrium: • Honest validators are financially rewarded for securing the network. • Dishonest actors are economically penalized for undermining it. • The high capital requirement for validation (32 ETH) ensures that participants have substantial economic exposure to the network's long-term success. |
|||
| H.6 Use of distributed ledger technology | boolean | ||||
| H.7 DLT functionality description | textBlock | ||||
| Other token audit details | |||||
| H.8 Audit | boolean | ||||
| H.9 Audit outcome | textBlock | Audit reports for the production smart contracts are available here: https://github.com/inference-labs-inc/subnet-2-contracts/tree/latest/audits AS DEVELOPMENT OF THE INFERENCE NETWORK CONTINUES, AUDIT COVERAGE WILL BE EXPANDED TO INCLUDE ADDITIONAL REPOSITORIES AND FUNCTIONALITY. |
|||
| Part I - Information on risks | |||||
| I.1 Offer-related risks | textBlock | Market Risk. VERFI can be subject to significant price fluctuations based on supply-demand dynamics, market sentiment, and external macroeconomic factors. These may result in financial losses for token holders. Liquidity Risk. While admission to trading increases accessibility, liquidity is not guaranteed. Low trading volumes may result in high slippage or the inability to exit positions efficiently. Counterparty Risk. The exchanges or trading platforms where VERFI tokens are listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or VERFI. Integration with third-party trading platforms involves dependencies on their internal policies and stability. Delisting, insolvency, or technical failures at such platforms could adversely impact tradability. Issuer Non-Involvement in Trading. When VERFI is traded on exchanges, the issuer does not act as a contractual party to these transactions. All legal relationships regarding these trading platforms are subject to their respective terms and conditions, with no responsibility assumed by the issuer for their operations and services. |
|||
| I.2 Issuer-related risks | textBlock | Operational Dependency Risk. The issuer relies on various infrastructure providers – including cloud services, validators, and custodial partners – to support its operations. Any interruption, failure, or termination of these relationships could adversely affect the functioning of the protocol or associated services. Reputational Risk. Negative publicity stemming from operational incidents, security breaches, or perceived associations with illicit activities could harm the issuer's public image, potentially reducing confidence in and demand for VERFI tokens. Internal Operations Risk. Weaknesses in the issuer's internal processes, human resources, or technology systems could impair the effective management of token operations. Failures in operational integrity may result in service disruptions, financial losses, or reputational harm. Legal and Regulatory Risk. Evolving legal frameworks, regulatory changes, or adverse legal proceedings may create uncertainty around the legality, usability, or valuation of VERFI tokens, potentially restricting their circulation or acceptance. Competitive Market Risk. The Inference Network operates in a highly dynamic and competitive market. Emerging innovative or better-capitalized competitors may offer alternative solutions that diminish user adoption or the market position of the Inference Network. |
|||
| I.3 Other tokens-related risks | textBlock | Volatility Risk. As with most crypto-assets, VERFI is subject to substantial short- and long-term price fluctuations. Market sentiment, liquidity shifts, and macroeconomic trends can all cause significant volatility, potentially resulting in financial losses for holders. Liquidity Risk. Market depth and trading activity for VERFI may vary over time. Limited order book participation could lead to price slippage or difficulty executing trades efficiently, particularly during periods of market stress. Technological Obsolescence Risk. The blockchain and crypto-asset sectors evolve rapidly. Innovations or competing protocols could surpass or replace the Inference Network's functionality, reducing VERFI's utility, adoption, or relevance. Speculative Nature Risk. The value of VERFI is highly speculative and depends on market demand, protocol adoption, validator participation, and community engagement. There are no guarantees of future value, performance, or rewards associated with the token. Blockchain Dependency Risk. VERFI operates on public blockchains such as Ethereum. Changes to their infrastructure, governance, consensus mechanisms, or transaction fees could affect VERFI's usability, transferability, and cost efficiency. Malicious Model Embedding Risk. Sophisticated adversaries developing AI models for deployment on VERFY could embed covert adversarial triggers within their inference logic. These hidden mechanisms might induce unintended or harmful outputs (e.g., biased decisions, data manipulation, or malicious actions) under specific conditions. Since zk-proofs obscure the inner workings of inferences, such exploits could evade traditional detection methods and be cryptographically validated as "legitimate," thereby bypassing security safeguards. Security Risks. a) Smart Contract Vulnerabilities: Despite comprehensive audits, unforeseen bugs or vulnerabilities could compromise smart contract functionality, impacting token security, staking, or governance. b) Private Key Management: Token holders are solely responsible for safeguarding their wallets and private keys. Loss or compromise of credentials will irreversibly result in the loss of tokens. c) Cryptographic Proof System Maturity Risk: The zk-proof systems underpinning VERFY are built on experimental or emerging cryptographic constructs. These systems may lack rigorous formal verification, long-term empirical validation, or standardized security guarantees, creating the potential for latent vulnerabilities in soundness (the inability to prove false statements) or correctness (failure to validate true statements). Such flaws could be exploited post-deployment, compromising the integrity of verified AI inferences and undermining trust in the network's foundational mechanisms. Fraud and Scam Risks. Holders face exposure to scams, phishing, impersonation, counterfeit tokens, and fake airdrops. Interacting with unverified platforms or unofficial channels significantly increases the risk of fraud or asset loss. Cybercrime and Theft Risks. Blockchain assets may be targeted by cyberattacks, including hacking, malware, or phishing. Breaches affecting wallets, exchanges, or smart contracts could lead to theft, loss of assets, or service disruption. Data Integrity Risk. Software bugs, human error, or malicious tampering could corrupt blockchain data, impacting transaction records, network reliability, and user confidence. Wallet and Storage Risk. Access to VERFI requires compatible wallets. Incompatibility, network errors, or the shutdown of wallet providers may restrict users' ability to access, store, or transfer tokens. Regulatory and Compliance Risks. a) Evolving Legal Frameworks: Regulatory regimes governing digital assets are changing rapidly, potentially impacting VERFI's classification, availability, or functionality. b) Jurisdictional Restrictions: Certain jurisdictions may limit or prohibit VERFI trading or use, restricting accessibility for some users. c) Enforcement Actions: Regulators could take action if VERFI were reclassified as an unregistered security or other regulated financial instrument. d) AML & CTF Risks: Transactions involving crypto-assets may be scrutinized for compliance with anti–money laundering and counter–terrorism financing laws, potentially affecting users' ability to trade or transfer VERFI. |
|||
| I.4 Project implementation-related risks | textBlock | Resource Constraint Risk. The successful development of the Inference Network depends on the availability of adequate financial and human resources. Budget limitations, difficulties in attracting or retaining qualified technical personnel, or reliance on external or volunteer contributors could impede progress and delay protocol improvements. Interoperability and Technical Failure Risk. The Inference Network operates across multiple blockchain networks. Interoperability challenges, software bugs, or technical failures affecting one or more of these networks could disrupt transaction execution, cross-chain functionality, or other core operations, potentially undermining user confidence and protocol reliability. Competitive Risk. The Inference Network operates in a rapidly evolving market. The emergence of more advanced, better-capitalized, or innovative competitors could reduce network adoption and negatively impact VERFI's market position and value. |
|||
| I.5 Technology-related risks | textBlock | Smart Contract Vulnerability Risk. Although the Inference Network smart contracts have undergone extensive security audits, there remains a possibility of undetected bugs or exploitation through novel attack vectors. Such vulnerabilities could compromise token integrity, staking mechanisms, or governance processes. Fault-Tolerance and Incentive Mechanism Risk. VERFI's operational model relies partly on user participation and incentive structures. Misconfigurations, design flaws, or unexpected failures in these mechanisms could lead to inconsistent performance or temporary instability in protocol operations. Private Key Management Risk. Token holders are solely responsible for the secure management of their private keys and recovery credentials. Loss, theft, or compromise of wallet access will irreversibly result in the loss of VERFI tokens, as blockchain transactions cannot be reversed. External Infrastructure Dependency Risk. The protocol depends on third-party infrastructure providers, including RPC services, decentralized storage solutions, and agent orchestration frameworks. Downtime, cyberattacks, or incompatibility issues within these components could impact data availability, performance, or verification processes across the network. Technological and Coordination Failure Risk. Participants should be aware that technological malfunctions, software errors, or coordination breakdowns among validators, developers, or governance participants could impair the availability, security, or functionality of both the VERFI token and the Inference Network. Maintenance and Upgrade Risk. Ongoing network maintenance, software updates, or protocol upgrades introduce a residual risk of unexpected bugs or compatibility issues. Additionally, the governance structure, while also intended to ensure stability and due diligence, may occasionally delay critical updates due to its consensus-based decision-making process. |
|||
| I.6 Mitigation measures | textBlock | a) A dedicated team of experts evaluates risk exposures, asset allocations, and protocol parameters to ensure prudent management. b) Transparent Governance: All major protocol and token-related decisions are made through community governance, supported by public documentation and auditable voting records. c) Entity Stewardship: Entities surrounding the Inference Network provide strategic guidance and ensures the project's adherence to sustainability and compliance standards. Technical Security. a) Independent Smart Contract Audits: All smart contracts are subjected to multiple third-party security audits prior to deployment and after major upgrades. b) Bug Bounty Programs: Continuous bounty initiatives incentivize community reporting of vulnerabilities. Operational Resilience. a) Infrastructure Diversification: Multiple RPC providers, storage networks, and validator partners are employed to reduce reliance on any single provider. b) Incident Response Procedures: A structured monitoring and response framework enables rapid detection, containment, and resolution of potential security or operational incidents. c) Periodic Stress Testing: Protocol systems undergo regular performance and load testing to evaluate resilience under adverse conditions. Regulatory and Compliance Measures. a) Regulatory Monitoring: The issuer and foundation actively monitor evolving EU and international regulations, including MiCAR developments, to ensure continuous compliance. b) Legal Reviews: Ongoing external legal assessments help ensure that token operations remain consistent with applicable laws and regulatory classifications. Market and Financial Controls. a) Treasury Management Policies: Treasury operations follow internal governance controls to ensure transparent use of funds and responsible liquidity management. b) Diversification of Assets: The treasury maintains a balanced composition of VERFI and stablecoins to maintain liquidity. Community and Transparency. a) Clear Documentation: documentation and informative materials are publicly accessible, enabling independent review. b) Continuous Communication: Regular updates through governance forums, community calls, and transparency reports ensure ongoing stakeholder engagement. |
|||
| 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 | Under Proof-of-Stake, network integrity is maintained by validators rather than miners. Validators are participants who stake 32 ETH as collateral within a smart contract to become eligible to verify transactions and propose new blocks. In each 12-second slot, one validator is randomly selected to propose a block, while a committee of other validators attests to its validity. Ethereum organizes time into epochs, each consisting of 32 slots. Once a sufficient majority of validators have attested to consecutive checkpoints within these epochs, a block is considered finalized, meaning it cannot be reversed without significant economic penalty. |
|||
| S.5 Incentive mechanisms and applicable fees | text | Validator Rewards Validators are responsible for proposing new blocks and attesting to the validity of blocks proposed by others. In return for performing these duties correctly and consistently, validators earn rewards denominated in ETH, which are automatically added to their staked balance. • Block Proposal Rewards: Granted to validators selected to create new blocks. • Attestation Rewards: Distributed to validators who confirm that proposed blocks are valid. • Sync Committee Rewards: Periodic incentives for participating in specialized committees that help propagate finalized states across the network. • Inclusion and Participation Bonuses: Additional rewards are given to validators who participate promptly, maintaining high uptime and responsiveness. These rewards encourage validators to remain active, properly configured, and connected, thereby ensuring the liveness and stability of the network. |
|||
| 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 | ||||
| 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 | https://ethereum.org/energy-consumption/. |
|||
| S.16 Key GHG sources and methodologies | textBlock | https://ethereum.org/energy-consumption/. |
|||
| 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 | ||||