Virtuals Protocol(VIRTUAL) Whitepaper

CRYPTO-ASSET WHITE PAPER - [VIRTUAL]

Version Number: 1.0

Document Type: White Paper

Document Author Offeror: OKX Europe Limited

Document Status: APPROVED

Language: English

TABLE OF CONTENTS

I. DATE OF NOTIFICATION II. STATEMENTS III. WARNING IV. INFORMATION ON RISKS

1. Offer-Related Risks

2. Issuer-Related Risks

3. Crypto-Assets-Related Risks

4. Project Implementation-Related Risks

5. Technology-Related Risks

6. Mitigation Measures V. GENERAL INFORMATION A. Information of the Offeror or the Person Seeking Admission to Trading B. Information of the Issuer C. Information about OKX Europe Limited ("OKX") VI. INFORMATION ABOUT THE CRYPTO-ASSET D. Information about the Crypto-Asset Project E. Information about the Offer to the Public of the Crypto-Asset or Its Admission to Trading F. Information about the Crypto-Assets G. Information about the Rights and Obligations Attached to the Crypto-Asset H. Information about the Underlying Technology I. Information on the Principal Adverse Impacts on the Climate and Other Environmental-Related Adverse Impacts of the Consensus Mechanism Used to Issue the Crypto-Asset. VII. GLOSSARY

I. DATE OF NOTIFICATION

The Date of Notification of this Crypto-Asset White Paper is 2025-11-20.

II. STATEMENTS

A. This Crypto-Asset White Paper has not been approved by any Competent Authority in any Member State of the European Union. OKX Europe Limited is solely responsible for the content of this Crypto-Asset White Paper.

B. This Crypto-Asset White Paper complies with Title II of the Regulation (EU) 2923/1114, to the best of the knowledge of the management body, the information presented in the Crypto-Asset White Paper is fair, clear, and not misleading and the Crypto-Asset White Paper makes no omission likely to affect its import.

C. The Crypto-Asset White Paper provides that VIRTUAL may not be transferable, or liquid, or lose its value, in part or in full.

D. The Utility Token referred to in this Crypto-Asset White Paper may not be exchangeable against the good or service promised in the Crypto-Asset White Paper, especially in the case of a failure or discontinuation of the Crypto-Asset Project. This statement is TRUE.

E. The Crypto-Asset referred to in this Crypto-Asset White Paper is not covered by the investor compensation schemes under the Directive 97/9/EC of the European Parliament and of the Council.

F. The Crypto-Asset referred to in this Crypto-Asset White Paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

III. WARNING

A. The summary should be read in conjunction with the content of the Crypto-Asset White Paper.

B. 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.

C. The offer to the public of the Crypto-Asset does not constitute an offer or solicitation to purchase financial instruments and that any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable National Law.

D. This Crypto-Asset White Paper does not constitute a prospectus as referred to in the Regulation (EU) 2017/1129 of the European Parliament and the Council or any other offer document pursuant to the European Union or National Law.

E. VIRTUAL is a utility token based on the ERC-20 standard, deployed on the Ethereum and Base blockchains, alongside a SPL standard token on the Solana blockchain, with a fixed total supply of one (1) billion tokens. It functions as the core utility, payment, and governance token for the Virtuals Protocol, a platform designed for the creation, tokenization, and monetization of autonomous AI agents. Purchasers of the VIRTUAL token acquire the right to participate in the protocol's governance. Holders can lock their tokens to receive veVIRTUAL, which grants them the ability to propose and vote on protocol upgrades, treasury allocations, and other key decisions shaping the ecosystem's future. There are no obligations attached to holding the token. The exercise of governance rights is conducted on-chain through the protocol's governance portal, and voting power is proportional to the amount of veVIRTUAL held. The rights associated with the token may be modified only through the established governance process, which requires a community vote to pass.

F. The VIRTUAL token provides holders with access to the governance mechanisms of the Virtuals Protocol. The primary service is the ability to influence the protocol's development and strategic direction. Token holders can participate in decisions regarding technical upgrades, treasury management, and adjustments to the protocol's economic parameters by locking their tokens for veVIRTUAL voting power. The quantity of this access is proportional to the number of tokens locked and the duration of the lock-up period. The token also serves as the primary medium of exchange within the protocol for paying AI agent services (per-inference payments), establishing liquidity for new AI agent tokens, and distributing revenue generated by AI agents to their respective token holders. The VIRTUAL token is freely and instantly transferable, utilising the underlying blockchain network's standard processes.

G. This whitepaper is published solely in connection with the admission to trading of the VIRTUAL token on OKX Europe Limited's trading platform. There has been no offer of the crypto-asset to the public, and the crypto-asset has not been made available in exchange for fiat currency or other crypto-assets prior to its listing. The crypto-asset will be admitted to trading via OKX Europe Limited, an authorised crypto-asset service provider ("CASP") operating within the European Union. The trading admission does not involve any subscription, sale, or fundraising process. The purpose of this document is to provide key information regarding the characteristics of the crypto-asset, its governance, rights, and associated risks, to enable informed decision-making by users and market participants in the context of its admission to trading. Access to the crypto-asset on the trading platform may be subject to user verification, platform conditions, or applicable legal restrictions depending on the jurisdiction.

IV. INFORMATION ON RISKS

1. Offer-Related Risks

This whitepaper is submitted by OKX Europe Limited solely for the purpose of the assets admission to trading. No public offer of VIRTUAL tokens is being made by the issuer or OKX Europe Limited.

Risks associated with the admission to trading include:

• Service-related Interruption: Holders may be unable to access the utility due to technical, operation, or regulatory disruptions.

• Jurisdictional limitations: VIRTUAL services or token utility may not be available in all jurisdictions, potentially restricting access.

• Platform Reliance: Access depends on third-party infrastructure (wallets, platforms) and service interruptions or failures may affect token utility.

• Limited Liability: OKX Europe Limited assumes no responsibility for the issuers project continuation, and token ownership does not confer contractual rights or guarantees.

• Unexpected Risks: Beyond the risks outlined in this whitepaper, there may be additional risks that are currently unforeseen. It is imperative to note that certain risks may emerge from unforeseen events, changes, or interactions among factors that are difficult to predict. These unexpected risks may significantly and negatively impact the crypto-asset, the project, or the parties involved.

2. Issuer-Related Risks

• Operational Risks: There is a risk that the issuer may face financial or operational difficulties, including insolvency, which could impact the continued development or availability of the services associated with the VIRTUAL token.

• Counterparty Risks: Counterparty risks may arise where the issuer relies on third-party service providers or technology partners.

• Reputational Risks: Adverse media and/or damage or loss of key personnel could negatively affect the ecosystem that the VIRTUAL token lives on.

• Competition Risk: The issuer may face increased competition or changes in market conditions that affect its ability to carry out its objectives.

• Regulatory Risks: The issuer may be subject to investigations, enforcement actions, or change in regulation that affect the tokens legal status in certain jurisdictions.

• Disclosure Risks: The issuer may not be required to provide financial statements, limiting VIRTUAL token holders visibility into the financial health status of the issuer/project.

• Issuer Risks: The information provided is based solely on publicly available sources and does not constitute any form of guarantee or warranty as to its accuracy or completeness.

• Key Person Risk: The project and/or token's success may rely on a small number of individuals or core team. If these individuals depart from the project, the direction and continuity of the project may be negatively affected in the future.

3. Crypto-Assets-Related Risks

• Market Volatility: The VIRTUAL token may be subject to significant volatility and could lose value rapidly, either due to market conditions or otherwise (issuer-related/technology/project implementation risks)

• Utility Risk: The VIRTUAL tokens utility depends on access to certain services, and any modification or discontinuation of those services could reduce the associated utility of the token.

• Smart Contract Risk: The VIRTUAL token may operate through smart contracts that may contain vulnerabilities, even if audited, and upgrades to the protocol or governance changes may affect functionality.

• Liquidity Risk: Periods of low/limited liquidity may occur, particularly if the demand for the token or its use case decreases, which could have adverse effects on the VIRTUAL tokens price and future use cases.

4. Project Implementation-Related Risks

• Scalability Issues: There is a risk that the project may not be implemented or scaled as intended. Technical limitations or infrastructure bottlenecks could hinder the expected scalability of the project, especially if user demand exceeds network or protocol capacity.

• Governance Risk: The project may be subject to governance processes that involve on-chain voting or community proposals. Misaligned incentives, low participation, or malicious actors may affect the outcome of governance decisions and disrupt the project's roadmap.

• Centralisation Risk: Similar to governance risks outlined above, centralisation within the governance process, or validator centralisation could lead to a lack of decentralization within the network, which carries future risks in terms of trust within the project, and also in regards to future roadmaps where plans may not reflect the interests of the broader user base.

5. Technology-Related Risks

• Blockchain Performance Risk: The Ethereum and Solana blockchains (Layer-1s), as well as the Base network (a Layer-2), on which the token is issued, may experience downtime, high transaction fees, or network congestion. This could delay or prevent token transfers or utility usage. Performance on Base is also dependent on the congestion and data availability of the underlying Ethereum network for final settlement.

• Consensus Failure Risk: A failure in the consensus mechanisms of the Layer-1 blockchains (Ethereum's Proof-of-Stake or Solana's PoS/PoH hybrid) could result in halted transactions, reorganisations, or a loss of network integrity. As the Base network settles on Ethereum, its security is directly dependent on the integrity of Ethereum's consensus.

• Smart Contract Vulnerabilities: Although the token uses standard smart contract makeups (ERC-20 on Ethereum/Base and SPL on Solana), undetected bugs, exploits, or implementation errors in any of the three separate token contracts could compromise functionality or security.

• Upgradeability Risk: The VIRTUAL token exists as three separate contracts on Ethereum, Base, and Solana. If any of these contracts are upgradeable (e.g., via proxy patterns) and controlled by designated "owner" addresses, this introduces central points of failure. Such privileges could be misused by malicious actors or compromised, leading to unilateral changes or loss of funds on that specific network.

• Third-party Infrastructure Dependency: Interaction with the token or the VIRTUAL project relies on external infrastructure. This includes, but is not limited to, wallet services (for both EVM and Solana chains), RPC nodes for Ethereum, Base, and Solana, and project-specific APIs. Outages, attacks, or deprecation of these third-party services may interrupt access to token-related services.

• Interoperability Risk: As the token exists on three separate networks (Ethereum, Base, Solana), moving the token between these chains requires the use of token bridges. These bridges, whether official (like the Base bridge) or third-party, are complex smart contracts that are frequent targets for exploits. A failure, hack, or exploit of a bridge used to transfer VIRTUAL could result in a significant loss of assets and potentially de-peg the token's value on different chains.

• Protocol-level Risk: Major protocol-level upgrades, hard forks, or other significant changes to the underlying Ethereum, Base, or Solana blockchains may affect the token. Such events could lead to temporary network instability, compatibility issues with the token contracts, or unexpected token behaviour.

• Emerging Technology Risk: Advances in computing or undiscovered vulnerabilities in cryptographic algorithms may pose long-term security risks to the blockchains or associated smart contracts.

• Sequencing Risk: The version of the token on the Base network relies on a centralised sequencer to process and order transactions before they are submitted to the Ethereum Layer-1. If this sequencer experiences downtime, censors transactions, or is otherwise misused, the ordering, processing, and availability of VIRTUAL transactions on the Base network may be adversely affected.

6. Mitigation Measures

• Blockchain Performance Risk: The blockchains on which the token is deployed have distinct architectures to manage performance. The Ethereum blockchain has adopted a Proof-of-Stake consensus mechanism, and ongoing upgrades are designed to enhance throughput; gas fees help prioritise transactions under load. The Solana blockchain is a high-performance Layer-1 designed for high throughput and low latency, using Proof-of-History (PoH) and parallel processing to handle large volumes of transactions at low cost. The Base network, as a Layer-2 optimistic rollup, processes transactions off-chain at high speed and bundles them for settlement on Ethereum, significantly reducing fees and confirmation times for users.

• Consensus Failure Risk: Each Layer-1 protocol has robust consensus mechanisms. Ethereum's Proof-of-Stake includes validator incentives, slashing penalties for malicious actors, and finality checkpoints. Its large, globally distributed validator set reinforces decentralisation. Solana's hybrid PoH/PoS mechanism is also secured by a large, global validator set, which is incentivised to act honestly through staking rewards and slashing penalties. The Base network mitigates this risk by relying on the consensus and security of the Ethereum blockchain for the final settlement and integrity of its transactions.

• Smart Contract Vulnerabilities: The token leverages standardised, widely-used contract models on all networks. On Ethereum and Base, it uses the ERC-20 standard, and the ecosystem encourages open-source code, independent audits, and the use of tested libraries (e.g., OpenZeppelin) to reduce errors. On Solana, it uses the SPL token standard, which is a rigorously audited and standardised framework. Solana smart contracts (programs) are often written in Rust, a language that provides memory safety features, further mitigating common vulnerabilities.

• Upgradeability Risk: The networks support, but do not enforce, upgradeable contracts. Risks related to upgradeability on all three platforms (Ethereum, Base, and Solana) can be mitigated through standard practices such as implementing time-delay triggers for changes, requiring multi-signature wallet approval for upgrades, or placing contract ownership under the control of a decentralised governance process.

• Third-party Infrastructure Dependency: The ecosystems of Ethereum, Base, and Solana all support a competitive and decentralised market of infrastructure providers. This includes numerous independent RPC providers, node operators, and decentralised indexing protocols, which reduces reliance on any single third-party data service and mitigates the risk of a central point of failure.

• Interoperability Risk: Mitigations for cross-chain risk vary by the connection. For transfers between Ethereum and Base, the official Base Bridge provides a native, protocol-secured mechanism. For transfers between EVM chains (Ethereum/Base) and Solana, mitigation relies on using third-party bridges. Best practices involve selecting established, independently audited bridge providers that utilise secure token locking mechanisms and have robust security monitoring.

• Protocol-level Risk: All three protocols maintain public roadmaps and follow structured governance and update processes. Ethereum's core updates undergo extensive testing and community review. Solana's network upgrades are developed and tested by core developers and the community before being activated by the validator network. Base's development is aligned with the public, open-source OP Stack roadmap, ensuring its evolution is transparent and tied to community-driven standards.

• Emerging Technology Risk: The core development communities for both Ethereum and Solana actively monitor potential emerging technology threats, including advances in quantum computing. Both ecosystems are actively researching and developing quantum-resistant solutions, and the modular designs of the networks may allow for future cryptographic upgrades if required.

V. GENERAL INFORMATION

A. Information of the Offeror or the Person Seeking Admission to Trading

• A.1 Name: N/A

• A.2 Legal Entity Identifier (LEI): N/A

• A.3 Legal Form, if applicable: N/A

• A.4 Registered Office, if applicable: N/A

• A.5 Head Office, if applicable: N/A

• A.6 Date of Registration [YYYY-MM-DD]: N/A

• A.7 Legal Entity Number: N/A

• A.8 Contact Telephone Number: N/A

• A.9 E-Mail Address: N/A

• A.10 Response Time (days): N/A

• A.11 Members of Management Body: N/A

• A.12 Business Activity: N/A

• A.13 Newly Established: N/A

• A.14 Financial Condition for the past Three Years: N/A

• A.15 Financial Condition since Registration: N/A

• A.16 Parent Company, if applicable: N/A

• A.17 Parent Company Business Activity, if applicable: N/A

B. Information of the Issuer

This section shall ONLY be completed if the information is different to that listed in section 1, above.

• B.1 Is the Issuer different from an offeror or person seeking admission to trading?: TRUE

• B.2 Name: Virtuals Protocol

• B.3 Legal Entity Identifier (LEI): No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.4 Legal Form, if applicable: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.5 Registered Office, if applicable: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.6 Head Office, if applicable: Damansara, Kuala Lumpur, Malaysia

• B.7 Date of Registration [YYYY-MM-DD]: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.8 Legal Entity Number: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.9 Members of the Management Body:

  • Line ID: 1

  • Identity: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Function: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.10 Business Activity: Virtuals Protocol operates as a platform for the creation and deployment of AI agents and their associated crypto-assets.

• B.11 Parent Company: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.12 Parent Company Business Activity: No information could be identified in regards to this field at the time of drafting this whitepaper.

C. Information about OKX Europe Limited ("OKX")

This section shall ONLY be completed if OKX draws up the Crypto-Asset White Paper.

• C.1 Name: OKX Europe Limited

• C.2 Legal Entity Identifier: 54930069NLWEIGLHXU42

• C.3 Legal Form, if applicable: Private Limited Company

• C.4 Registered Office, if applicable: Piazzetta Business Plaza, Office Number 4, Floor 2, Triq Ghar il-Lembi, Sliema SLM1562, Malta

• C.5 Head Office, if applicable: See C.4

• C.6 Date of Registration: 2018-09-07

• C.7 Legal Entity Registration Number: C 88193

• C.8 Members of Management Body:

  • Line ID: 1 | Identity: Erald Henri J. Ghoos | Business Address: See C.4 | Function: Director

  • Line ID: 2 | Identity: Fang Hong | Business Address: See C.4 | Function: Director

  • Line ID: 3 | Identity: Joseph Portelli | Business Address: See C.4 | Function: Director

  • Line ID: 4 | Identity: Wei Man Cheung | Business Address: See C.4 | Function: Director

• C.9 Business Activity: OKX Europe Limited is licensed as a Crypto-Asset Service Provider by the Malta Financial Services Authority, bearing licence number OEUR-24352, to provide crypto services under the Markets in Crypto-Assets Act, Chapter 647, Laws of Malta and is the operator of a Trading Platform for Crypto Assets, in accordance with Article 3(1)(18) of Regulation (EU) 2023/1114 (MiCA).

• C.10 Reason for Crypto-Asset White Paper Preparation: This crypto-asset whitepaper has been prepared in accordance with Regulation (EU) 2023/1114 (MiCA) for the purpose of: The admission to trading of VIRTUAL on regulated platforms, starting with the OKX Exchange. OKX Europe Limited as a result of being a licenced CASP endeavours to fulfill the obligations established under MiCA and the respective MFSA guidelines to: Notify this whitepaper to the MFSA; Publish the whitepaper publicly; And ensure its registration in the MiCA register maintained by the European Securities and Markets Authority (ESMA). This whitepaper has been prepared to provide transparent, accurate, and fair information to prospective token holders and regulatory authorities in line with the principles of MiCA.

• C.11 Parent Company: OKC International Holding Company Limited

• C.12 Parent Company Business Activity: The primary business activity of the parent company is holding of investments.

Other Information *This section shall ONLY be completed if someone, other those referenced in Section 1 to 3, compile and complete the Crypto-Asset White Paper.*

• C.13 Other Persons drawing up the Crypto-Asset White Paper: N/A

• C.14 Reason for Crypto-Asset White Paper Preparation: N/A

VI. INFORMATION ABOUT THE CRYPTO-ASSET

D. Information about the Crypto-Asset Project

• D.1 Project Name: Virtuals Protocol

• D.2 Crypto-Assets Name: See F.14

• D.3 Abbreviation: See F.14

• D.4 Crypto-Asset Project Description: Virtuals Protocol is a decentralized platform built on Ethereum's Layer 2 solution, Base, that enables users to create, own, and monetize autonomous AI agents. The protocol provides infrastructure for tokenizing AI agents, allowing them to become community-owned, revenue-generating assets. These agents can be deployed across various platforms like games, social media, and virtual environments, performing tasks for a fee. The protocol aims to build an "agentic economy" by providing the rails for AI agents to transact on-chain, own assets, and deliver services.

• D.5 Details of all natural or legal persons involved in the implementation of the Crypto-Asset Project:

  • Name: Jansen Teng | Role: Co-Founder & Core Contributor at Virtuals Protocol | Business Address: Kuala Lumpur, Malaysia

  • Name: Wee Kee | Role: Core Contributor at Virtuals Protocol | Business Address: Kuala Lumpur, Malaysia

  • Name: Bryan Lim | Role: AI Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Brianna Chang | Role: Engineering Core Contributor & Founding Member at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Weixiong Tay | Role: Engineering Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Khoon Kheng Teh | Role: COO & Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Jae-Sonn | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Celeste Ang | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Sally Wang | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Hanan N. | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Sean Kyu Won Kim | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Viktor Anchutin | Role: AI Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Wei Zhe (Javier) Yeoh | Role: AI Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Harry | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Xie Ong | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Yifei You | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Stefano Bury | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Shi Khai WEI | Role: Ventures Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Yujie Chuah | Role: Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Koo Huang | Role: Engineering Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Kahwai Chooi | Role: Engineering Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Name: Matthew T | Role: Ecosystem Core Contributor at Virtuals Protocol | Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

• D.6 Utility Token Classification: TRUE

• D.7 Key Features of Goods/Services for Utility Token Projects, if applicable: The Virtuals Protocol provides a suite of services centered around the creation and monetization of AI agents. The VIRTUAL token grants access to key functions within this ecosystem, including: Governance Participation: The ability to propose and vote on protocol parameters, upgrades, and treasury fund allocations. Liquidity Provision: VIRTUAL is the universal base pair for all AI agent token liquidity pools on the platform, facilitating trading and price discovery. Transaction Medium: It is used for payments within the ecosystem, such as fees for AI agent services (per-inference payments) and for creating new AI agents through Initial Agent Offerings (IAOs).

• D.8 Plans for the Token: Past Milestones: The project originated from PathDAO, founded in 2021, and executed a significant rebrand to Virtuals Protocol, which included a token migration and airdrop for previous PATH holders in December 2023 and January 2024. The protocol and its VIRTUAL token launched on the Base mainnet in March 2024. The project has established a governance process and has seen numerous proposals submitted via its portal. Future Milestones: The project has outlined a long-term vision described as a "1000-year master plan". Key future developments include building a permissionless marketplace for AI agents, enhancing agent-to-agent communication, and introducing "hyperfinancialization" mechanisms to increase adoption and accrue value within the ecosystem. Further development of governance processes and liquidity integrations are also core to the roadmap.

• D.9 Resource Allocation, if applicable: The initial token allocation for the 1,000,000,000 VIRTUAL supply is as follows: Public: 60% (600,000,000 tokens) are designated for public circulation. Liquidity Pool: 5% (50,000,000 tokens) are allocated for liquidity. Ecosystem Treasury: 35% (350,000,000 tokens) are allocated to the ecosystem treasury, intended for community incentives, grants, and other growth initiatives. Emissions from the treasury are subject to governance approval and are capped at 10% per year for the first three years. All VIRTUAL tokens are fully unlocked as of the time of writing.

• D.10 Planned Use of Collected Funds or Crypto-Assets, if applicable: The project features an Ecosystem Treasury that received 35% of the total token supply at the Token Generation Event. These funds are controlled by the protocol's decentralized governance structure. VIRTUAL token holders, through the veVIRTUAL voting mechanism, decide on the allocation of these treasury assets. The intended use is to fund community initiatives, strategic partnerships, ecosystem development, and other proposals that aim to promote the growth and adoption of the Virtuals Protocol. All treasury fund deployments are subject to community proposals and votes, ensuring transparent and community-led oversight.

E. Information about the Offer to the Public of the Crypto-Asset or Its Admission to Trading

• E.1 Public Offering or Admission to Trading: ATTR

• E.2 Reasons for Public Offer or Admission to Trade: Facilitating secondary trading for users on the OKX Trading platform in compliance with the MiCA regulatory framework.

• E.3 Fundraising Target, if applicable: N/A

• E.4 Minimum Subscription Goals, if applicable: N/A

• E.5 Maximum Subscription Goals, if applicable: N/A

• E.6 Oversubscription Acceptance: N/A

• E.7 Oversubscription Allocation, if applicable: N/A

• E.8 Issue Price: N/A

• E.9 Official Currency or Any Other Crypto-Assets determining the Issue Price: N/A

• E.10 Subscription Fee: N/A

• E.11 Offer Price Determination Method: N/A

• E.12 Total Number of Offered/Traded Crypto-Assets, if applicable: The total supply of VIRTUAL is fixed at 1,000,000,000 tokens.

• E.13 Targeted Holders: N/A

• E.14 Holder Restrictions: N/A

• E.15 Reimbursement Notice: N/A

• E.16 Refund Mechanism: N/A

• E.17 Refund Timeline: N/A

• E.18 Offer Phases: N/A

• E.19 Early Purchase Discount: N/A

• E.20 Time-Limited Offer: N/A

• E.21 Subscription Period, beginning [YYYY-MM-DD]: N/A

• E.22 Subscription Period, end [YYYY-MM-DD]: N/A

• E.23 Safeguarding Arrangement for Offered Funds/Crypto-Assets: N/A

• E.24 Payment Methods for Crypto-Asset Purchase: In line with OKX current payment method offering.

• E.25 Value Transfer Methods for Reimbursement: N/A

• E.26 Right of Withdrawal, if applicable: N/A

• E.27 Transfer of Purchased Crypto-Assets: In line with OKX current Terms of Service.

• E.28 Transfer Time Schedule [YYYY-MM-DD]: N/A

• E.29 Purchaser's Technical Requirements: In line with OKX current Terms of Service.

• E.30 Crypto-Asset Service Provider (CASP) name, if applicable: OKX Europe Limited

• E.31 CASP identifier, if applicable: 54930069NLWEIGLHXU42

• E.32 Placement Form: NTAV

• E.33 Trading Platforms Name, if applicable: OKX

• E.34 Trading Platforms Market Identifier Code (MIC): n/a

• E.35 Trading Platforms Access, if applicable: Users may access VIRTUAL through the OKX Trading Platform via the Application Program Interface ("API"), the Application Software ("OKX App"), as well as the official OKX website as follows; www.okx.com.

• E.36 Involved Costs, if applicable: In line with the OKX current Terms of Service.

• E.37 Offer Expenses: n/a

• E.38 Conflicts of Interest: A crypto-asset is listed following a decision rendered independently by the Listing Committee in line with the internal policies of OKX Europe Limited. Any potential disclosures that may arise of conflicts of interest are published on the OKX website.

• E.39 Applicable Law: Malta

• E.40 Competent Court: Malta

F. Information about the Crypto-Assets

• F.1 Crypto-Asset Type: Other Crypto-Asset

• F.2 Crypto-Asset Functionality: The VIRTUAL token has three primary functions: Governance: Holders can lock VIRTUAL for veVIRTUAL to vote on proposals related to the protocol's development, upgrades, and treasury management. Utility: It serves as the primary currency for transactions within the Virtuals ecosystem, including per-inference payments to AI agents for their services. Liquidity & Staking: VIRTUAL is the base asset for liquidity pools of all AI agent tokens launched on the protocol, facilitating their trade and valuation. Creators must also lock VIRTUAL to launch a new agent's token.

• F.3 Planned Application of Functionalities: All functionalities from the above-specified list apply as of the writing of this whitepaper.

• F.4 Type of White Paper: OTHR

• F.5 Type of Submission: NEWT

• F.6 Crypto-Asset Characteristics: VIRTUAL is a fungible utility token implemented as an ERC-20 contract on the Ethereum and Base blockchains, and as an SPL Token Standard on the Solana blockchain. It has a fixed maximum supply of 1,000,000,000 tokens, with no future inflation mechanisms. Its primary purpose is to enable governance and economic activity within the Virtuals Protocol's ecosystem of AI agents.

• F.7 Commercial Name or Trading Name, if applicable: See F.14

• F.8 Website of the Issuer: https://virtuals.io/

• F.9 Starting Date of Offer to the Public or Admission to Trading [YYYY-MM-DD]: 2025-10-28

• F.10 Publication Date [YYYY-MM-DD]: 2025-12-18

• F.11 Any Other Services Provided by the Issuer: N/A

• F.12 Identifier of Operator of the Trading Platform: N/A

• F.13 Language/s of the White Paper: English

• F.14 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: 4MRQJ9KZX, N8DL4NDHC, FPRDP6XFW

• F.15 Functionally Fungible Group Digital Token Identifier, where available: 7WMBV0R29

• F.16 Voluntary Data Flag: FALSE

• F.17 Personal Data Flag: TRUE

• F.18 LEI Eligibility: N/A

• F.19 Home Member State: Malta

• F.20 Host Member States: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Ireland, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden

G. Information about the Rights and Obligations Attached to the Crypto-Asset

• G.1 Purchaser Rights and Obligations: There are no obligations attached to the purchase or holding of the VIRTUAL token. Purchasers obtain on-chain governance rights, enabling them to participate in the decision-making process of the Virtuals Protocol DAO by locking tokens for veVIRTUAL. These rights include submitting and voting on proposals concerning protocol upgrades, treasury spending, and parameter changes. Ownership of the token does not grant any claim to profits, dividends, or assets of the issuer or supporting entities.

• G.2 Exercise of Rights and Obligations: As the token confers no obligations, there is no method for their exercise. The governance rights afforded to holders can be exercised by connecting a compatible wallet to the Virtuals Protocol governance portal (gov.virtuals.io) and participating in the voting process for active proposals. These rights do not confer any legal ownership, claim to treasury assets, or enforceable contractual rights against the project or its contributors.

• G.3 Conditions for Modifications of Rights and Obligations: As the token grants no obligations, there are no conditions under which they may be modified. The rights associated with the VIRTUAL token, particularly governance rights, are determined by the protocol's smart contracts. Any modification to these rights would require a formal governance proposal to be submitted and approved by a vote of veVIRTUAL holders, in accordance with the established on-chain governance rules.

• G.4 Future Public Offers, if applicable: N/A

• G.5 Issuer Retained Crypto-Assets, if applicable: At the Token Generation Event, 35% of the total VIRTUAL supply (350,000,000 tokens) was allocated to the Ecosystem Treasury. These tokens are not retained by a single legal issuer but are held in a treasury controlled by the decentralized governance of the VIRTUAL token holders. The use and distribution of these tokens are subject to community proposals and voting.

• G.6 Utility Token Classification: TRUE

• G.7 Key Features of Goods/Services of Utility Tokens: The VIRTUAL token provides access to participating in and directing the Virtuals Protocol ecosystem. Key features include the right to vote on governance proposals that determine the protocol's future, the ability to use the token as a payment method for AI agent services, and its function as the required asset for creating and providing liquidity to new AI agents on the platform.

• G.8 Utility Tokens Redemption, if applicable: The VIRTUAL token does not grant redemption rights for any off-chain goods, services, or fiat currency. Its function is to provide access to on-chain governance and facilitate economic activity within the Virtuals Protocol. The utility is realized through its use in voting, payments, and liquidity provision directly within the protocol's ecosystem.

• G.9 Non-Trading Request: TRUE

• G.10 Crypto-Assets Purchase or Sale Modalities: N/A

• G.11 Crypto-Assets Transfer Restrictions: In line with OKX current Terms of Service.

• G.12 Supply Adjustment Protocols: N/A

• G.13 Supply Adjustments Mechanisms: N/A

• G.14 Token Value Protection Schemes: FALSE

• G.15 Token Value Protection Schemes Description: N/A

• G.16 Compensation Schemes: FALSE

• G.17 Compensation Schemes Description, if applicable: N/A

• G.18 Applicable Law: Malta

• G.19 Competent Court: Malta

H. Information about the Underlying Technology

• H.1 Distributed Ledger Technology, if applicable: See F.14

• H.2 Protocols and Technical Standards: The VIRTUAL token is implemented using two distinct protocols and technical standards depending on the network: Ethereum and Base: On these networks, the token adheres to the ERC-20 standard. ERC-20 is the most widely adopted technical standard for fungible tokens on the Ethereum blockchain and EVM-compatible networks like Base. It defines a common set of rules and functions that a token contract must implement, ensuring interoperability with wallets, decentralised exchanges, and other applications within the ecosystem. Solana: On this network, the token is implemented using the Solana Program Library (SPL) Token standard. This is the official and authorised standard for creating and managing fungible and non-fungible tokens on the Solana blockchain. SPL tokens are managed via smart contracts (known as "programs" in Solana) and are designed to leverage Solana's high-throughput, low-latency infrastructure.

• H.3 Technology Used, if relevant: The VIRTUAL token leverages the distinct technology stacks of three different blockchains: Ethereum: A general-purpose Layer-1 blockchain that supports smart contract execution via the Ethereum Virtual Machine (EVM). The VIRTUAL token contract is written in Solidity and interacts with the decentralised network of nodes that maintain the ledger. Base: A Layer-2 protocol built using the OP Stack that operates as an optimistic rollup. It processes transactions off-chain in a separate execution environment and then posts compressed transaction data to the Ethereum mainnet. This architecture is designed to provide users with significantly lower transaction fees and faster confirmation times while inheriting the security guarantees of the underlying Ethereum network. Solana: A high-performance Layer-1 blockchain designed for scalability. Its architecture uses Rust-based smart contracts and features a hybrid consensus mechanism that includes Proof-of-History (PoH) to create a verifiable sequence of events, enabling high transaction throughput and sub-second block times.

• H.4 Consensus Mechanism, if applicable: The security and finality of VIRTUAL transactions are ensured by two different consensus models: Ethereum and Base: The Ethereum blockchain uses a Proof-of-Stake (PoS) consensus mechanism. In this system, validators are chosen to propose and attest to new blocks based on the amount of ETH they have staked as collateral. This model provides high security and energy efficiency. As a Layer-2, Base does not have its own consensus mechanism; it relies on a centralized sequencer to order transactions but ultimately inherits its security and finality from the Ethereum PoS consensus once transaction data is settled on the Layer-1. Solana: The Solana blockchain uses a hybrid consensus mechanism that combines Proof-of-History (PoH) with Proof-of-Stake (PoS). PoH is not a consensus mechanism itself, but a cryptographic technique that creates a verifiable, time-stamped record of all transactions. This ordered sequence is then passed to the PoS mechanism, where a decentralised network of validators vote to confirm blocks, allowing the network to achieve high throughput while maintaining security.

• H.5 Incentive Mechanisms and Applicable Fees: Incentive mechanisms and transaction fees are specific to each network: Ethereum: Validators are incentivised to secure the network by earning rewards in ETH, which are composed of newly issued tokens and priority fees (tips) from users. Users must pay a transaction fee, known as "gas," in ETH to execute any transaction involving the VIRTUAL token. Base: Users pay transaction fees to the network's sequencer for processing and bundling transactions. These fees are significantly lower than on the Ethereum mainnet. The underlying security is provided by Ethereum's validators, who are incentivised through the PoS mechanism. Solana: Validators are incentivised through a PoS system where they earn rewards in the native token (SOL) for validating transactions and producing blocks. Users must pay a small transaction fee in SOL to transfer VIRTUAL tokens or interact with related smart contracts.

• H.6 Use of Distributed Ledger Technology: FALSE

• H.7 DLT Functionality Description: N/A

• H.8 Audit of the Technology Used: TRUE

• H.9 Audit Outcome, if applicable: The protocol's smart contracts have undergone security audits by PeckShield on March 10, 2024, and October 31, 2024. According to the project's documentation, all identified issues have been acknowledged and mitigated. The project also maintains an active bug bounty program with Immunefi to encourage ongoing security review by the community.

I. Information on the Principal Adverse Impacts on the Climate and Other Environmental-Related Adverse Impacts of the Consensus Mechanism Used to Issue the Crypto-Asset.

• I.1 Name: OKX Europe Limited

• I.2 Relevant legal entity identifier: 54930069NLWEIGLHXU42

• I.3 Name of the crypto-asset: Virtual Protocol

• I.4 Consensus Mechanism: Virtual Protocol is present on the following networks: Base, Ethereum, Solana. Base is a Layer-2 (L2) solution on Ethereum that was introduced by Coinbase and developed using Optimism's OP Stack. L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-stake) thus indirectly secures all L2 transactions as soon as they are written to L1. The crypto-asset's Proof-of-Stake (PoS) consensus mechanism, introduced with The Merge in 2022, replaces mining with validator staking. Validators must stake at least 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 Proto-Danksharding enhancing transaction efficiency. Solana uses a unique combination of Proof of History (PoH) and Proof of Stake (PoS) to achieve high throughput, low latency, and robust security. Here's a detailed explanation of how these mechanisms work: Core Concepts 1. Proof of History (PoH): Time-Stamped Transactions: PoH is a cryptographic technique that timestamps transactions, creating a historical record that proves that an event has occurred at a specific moment in time. Verifiable Delay Function: PoH uses a Verifiable Delay Function (VDF) to generate a unique hash that includes the transaction and the time it was processed. This sequence of hashes provides a verifiable order of events, enabling the network to efficiently agree on the sequence of transactions. 2. Proof of Stake (PoS): Validator Selection: Validators are chosen to produce new blocks based on the number of SOL tokens they have staked. The more tokens staked, the higher the chance of being selected to validate transactions and produce new blocks. Delegation: Token holders can delegate their SOL tokens to validators, earning rewards proportional to their stake while enhancing the network's security. Consensus Process 1. Transaction Validation: Transactions are broadcast to the network and collected by validators. Each transaction is validated to ensure it meets the network's criteria, such as having correct signatures and sufficient funds. 2. PoH Sequence Generation: A validator generates a sequence of hashes using PoH, each containing a timestamp and the previous hash. This process creates a historical record of transactions, establishing a cryptographic clock for the network. 3. Block Production: The network uses PoS to select a leader validator based on their stake. The leader is responsible for bundling the validated transactions into a block. The leader validator uses the PoH sequence to order transactions within the block, ensuring that all transactions are processed in the correct order. 4. Consensus and Finalization: Other validators verify the block produced by the leader validator. They check the correctness of the PoH sequence and validate the transactions within the block. Once the block is verified, it is added to the blockchain. Validators sign off on the block, and it is considered finalized. Security and Economic Incentives 1. Incentives for Validators: Block Rewards: Validators earn rewards for producing and validating blocks. These rewards are distributed in SOL tokens and are proportional to the validator's stake and performance. Transaction Fees: Validators also earn transaction fees from the transactions included in the blocks they produce. These fees provide an additional incentive for validators to process transactions efficiently. 2. Security: Staking: Validators must stake SOL tokens to participate in the consensus process. This staking acts as collateral, incentivizing validators to act honestly. If a validator behaves maliciously or fails to perform, they risk losing their staked tokens. Delegated Staking: Token holders can delegate their SOL tokens to validators, enhancing network security and decentralization. Delegators share in the rewards and are incentivized to choose reliable validators. 3. Economic Penalties: Slashing: Validators can be penalized for malicious behavior, such as double-signing or producing invalid blocks. This penalty, known as slashing, results in the loss of a portion of the staked tokens, discouraging dishonest actions.

• I.5 Incentive Mechanisms and Applicable Fees: Virtual Protocol is present on the following networks: Base, Ethereum, Solana. Base is a Layer-2 (L2) solution on Ethereum that uses optimistic rollups provided by the OP Stack on which it was developed. Transaction on base are bundled by a, so called, sequencer and the result is regularly submitted as an Layer-1 (L1) transactions. This way many L2 transactions get combined into a single L1 transaction. This lowers the average transaction cost per transaction, because many L2 transactions together fund the transaction cost for the single L1 transaction. This creates incentives to use base rather than the L1, i.e. Ethereum, itself. To get crypto-assets in and out of base, a special smart contract on Ethereum is used. Since there is no consensus mechanism on L2 an additional mechanism ensures that only existing funds can be withdrawn from L2. When a user wants to withdraw funds, that user needs to submit a withdrawal request on L1. If this request remains unchallenged for a period of time the funds can be withdrawn. During this time period any other user can submit a fault proof, which will start a dispute resolution process. This process is designed with economic incentives for correct behaviour. The crypto-asset's PoS system secures transactions through validator incentives and economic penalties. Validators stake at least 32 ETH and earn rewards for proposing blocks, attesting to valid ones, and participating in sync committees. Rewards are paid in newly issued ETH and transaction fees. Under EIP-1559, transaction fees consist of a base fee, which is burned to reduce supply, and an optional priority fee (tip) paid to validators. Validators face slashing if they act maliciously and incur penalties for inactivity. This system aims to increase security by aligning incentives while making the crypto-asset's fee structure more predictable and deflationary during high network activity. Solana uses a combination of Proof of History (PoH) and Proof of Stake (PoS) to secure its network and validate transactions. Here's a detailed explanation of the incentive mechanisms and applicable fees: Incentive Mechanisms 4. Validators: Staking Rewards: Validators are chosen based on the number of SOL tokens they have staked. They earn rewards for producing and validating blocks, which are distributed in SOL. The more tokens staked, the higher the chances of being selected to validate transactions and produce new blocks. Transaction Fees: Validators earn a portion of the transaction fees paid by users for the transactions they include in the blocks. This provides an additional financial incentive for validators to process transactions efficiently and maintain the network's integrity. 5. Delegators: Delegated Staking: Token holders who do not wish to run a validator node can delegate their SOL tokens to a validator. In return, delegators share in the rewards earned by the validators. This encourages widespread participation in securing the network and ensures decentralization. 6. Economic Security: Slashing: Validators can be penalized for malicious behavior, such as producing invalid blocks or being frequently offline. This penalty, known as slashing, involves the loss of a portion of their staked tokens. Slashing deters dishonest actions and ensures that validators act in the best interest of the network. Opportunity Cost: By staking SOL tokens, validators and delegators lock up their tokens, which could otherwise be used or sold. This opportunity cost incentivizes participants to act honestly to earn rewards and avoid penalties. Fees Applicable on the Solana Blockchain 7. Transaction Fees: Low and Predictable Fees: Solana is designed to handle a high throughput of transactions, which helps keep fees low and predictable. The average transaction fee on Solana is significantly lower compared to other blockchains like Ethereum. Fee Structure: Fees are paid in SOL and are used to compensate validators for the resources they expend to process transactions. This includes computational power and network bandwidth. 8. Rent Fees: State Storage: Solana charges rent fees for storing data on the blockchain. These fees are designed to discourage inefficient use of state storage and encourage developers to clean up unused state. Rent fees help maintain the efficiency and performance of the network. 9. Smart Contract Fees: Execution Costs: Similar to transaction fees, fees for deploying and interacting with smart contracts on Solana are based on the computational resources required. This ensures that users are charged proportionally for the resources they consume.

• I.6 Beginning of the period to which the disclosure relates: 2024-11-06

• I.7 End of the period to which the disclosure relates: 2025-11-06

• I.8 Energy consumption: 2555.37617 (kWh/a)

• I.9 Energy consumption sources and methodologies: The energy consumption of this asset is aggregated across multiple components: To determine the energy consumption of a token, the energy consumption of the network(s) base, ethereum, solana is calculated first. For the energy consumption of the token, a fraction of the energy consumption of the network is attributed to the token, which is determined based on the activity of the crypto-asset within the network. When calculating the energy consumption, the Functionally Fungible Group Digital Token Identifier (FFG DTI) is used - if available - to determine all implementations of the asset in scope. The mappings are updated regularly, based on data of the Digital Token Identifier Foundation. The information regarding the hardware used and the number of participants in the network is based on assumptions that are verified with best effort using empirical data. In general, participants are assumed to be largely economically rational. As a precautionary principle, we make assumptions on the conservative side when in doubt, i.e. making higher estimates for the adverse impacts.

VII. GLOSSARY

• Consensus Mechanism: Shall mean the rules and procedures by which an agreement is reached, among the DLT network nodes, that a transaction is validated.

• Crypto-Asset: Shall mean a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology.

• Distributed Ledger Technology or DLT: shall mean the technology that enables the operation and use of distributed ledgers.

• Home Member State: Shall mean either (a) where the offeror or person seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens has its registered office in the Union, the Member State where that offeror or person has its registered office; or (b) where the offeror or person seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens has no registered office in the Union but does have one or more branches in the Union, the Member State chosen by that offeror or person from among the Member States where it has branches; or (c) where the offeror or person seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens is established in a third country and has no branch in the Union, either the Member State where the crypto-assets are intended to be offered to the public for the first time or, at the choice of the offeror or person seeking admission to trading, the Member State where the first application for admission to trading of those crypto-assets is made; or (d) in the case of an Issuer of asset-referenced tokens, the Member State where the Issuer of asset-referenced tokens has its registered office; or (e) in the case of an Issuer of e-money tokens, the Member State where the Issuer of e-money tokens is authorised as a credit institution under Directive 2013/36/EU or as an electronic money institution under Directive 2009/110/EC; or (f) in the case of crypto-asset service providers, the Member State where the crypto-asset service provider has its registered office.

• Host Member State: Shall mean the Member State where an Offeror or Person Seeking Admission to Trading has made an offer to the Public of Crypto-Assets or is seeking admission to trading, or where a Crypto-Asset Service Provider provides crypto-asset services, where different from the Home Member State.

• Issuer: Shall mean a natural or legal person, or other undertaking, who issues crypto-assets.

• Management Body: Shall mean the body or bodies of an Issuer, Offeror, Person Seeking Admission to Trading, or of a Crypto-Asset Service Provider, which are appointed in accordance with National Law, which are empowered to set the entity's strategy, objectives and overall direction, and which oversee and monitor management decision-making in the entity and include the persons who effectively direct the business of the entity.

• Offer to the Public: Shall mean a communication to persons in any form, and by any means, presenting sufficient information on the terms of the offer and the crypto-assets to be offered so as to enable prospective holders to decide whether to purchase those crypto-assets.

• Offeror: Shall mean a natural or legal person, or other undertaking, or the Issuer, who offers crypto-assets to the public.

• Operator: Shall mean the entity that runs a trading platform for crypto-assets.

• Qualified Investors: Shall mean persons or entities that are listed in Section I, points (1) to (4), of Annex II to Directive 2014/65/EU.

• Retail Investor/Holder: Shall means any natural person who is acting for purposes which are outside that person's trade, business, craft or profession.

• Utility Token: Shall mean a type of crypto-asset that is only intended to provide access to a good or a service supplied by its Issuer.