Aixbt(AIXBT) Whitepaper

CRYPTO-ASSET WHITE PAPER - [AIXBT]

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

DATE OF NOTIFICATION

The Date of Notification of this Crypto-Asset White Paper is 2025-10-30.

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

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. AIXBT is a utility token deployed across multiple blockchains: as an ERC-20 token on the Ethereum mainnet, as an ERC-20 token on the Base Layer-2 network, and as an SPL token on the Solana blockchain. The token's primary characteristic is to function as an access key to the premium features of the AIXBT crypto market intelligence platform. There are no obligations attached to the purchaser. The primary right afforded to holders is the ability to unlock the platform's "Ultimate Plan" by either holding 600,000 AIXBT or staking 500,000 AIXBT in a compatible crypto-asset wallet. These rights are exercised by connecting the user's wallet to the AIXBT application. The conditions for exercising these rights, including the token thresholds and the features offered, may be modified unilaterally by the project developer, as the project does not have a formal community-led governance process.

F. The AIXBT token grants access to a suite of digital services focused on crypto market intelligence. The quality of these services includes comprehensive project analysis, unlimited chat functionality with an AI agent, market alerts, custom daily reports, and integrations with third-party platforms such as Discord and Telegram. The quantity of service is not determined on a per-token basis; rather, meeting the minimum holding or staking threshold grants full access to all features included in the "Ultimate Plan". The AIXBT 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 AIXBT 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.

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 AIXBT 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; AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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.

• AI Associated Risks: This token integrates AI technology which may result in imperfect or biased outputs due to data and model limitations. AI-driven features inherently involve risks including errors, security vulnerabilities, and regulatory uncertainties, thus users should exercise caution, and conduct independent checks.

• 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 AIXBT 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.

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.5 Head Office, if applicable: Damansara, Kuala Lumpur, Malaysia

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

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

• B.8 Members of the Management Body:

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

  • 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.9 Business Activity: Virtuals Protocol operates as a platform for the creation and deployment of AI agents and their associated crypto-assets.

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

• B.11 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: Erald Henri J. Ghoos, Nationality: Belgian, Business Address: See C.4, Function: Director

  • Line ID 2: Fang Hong, Nationality: American, Business Address: See C.4, Function: Director

  • Line ID 3: Joseph Portelli, Nationality: Maltese, Business Address: See C.4, Function: Director

  • Line ID 4: Wei Man Cheung, Nationality: Dutch, 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 AIXBT 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

INFORMATION ABOUT THE CRYPTO-ASSET

D. Information about the Crypto-Asset Project

• D.1 Project Name: AIXBT

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

• D.3 Abbreviation: See F.14

• D.4 Crypto-Asset Project Description: AIXBT is an AI-driven crypto market intelligence platform designed to provide users with strategic analysis of market trends. The project leverages an AI agent to automate the tracking and interpretation of market data, narrative detection, and alpha-focused analysis to generate actionable insights for users.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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 AIXBT project provides access to a crypto market intelligence platform featuring an AI agent. Its key services, available through the "Ultimate Plan," include comprehensive project analysis, unlimited chat interactions with the AI agent, integrations with third-party platforms such as Discord and Telegram, market alerts, and the generation of custom daily reports.

• D.8 Plans for the Token: As of the date of this white paper, the project has not published a formal public roadmap outlining future milestones or development plans.

• D.9 Resource Allocation, if applicable: N/A

• D.10 Planned Use of Collected Funds or Crypto-Assets, if applicable: N/A

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 AIXBT is fixed at one (1) billion 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 AIXBT 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 AIXBT token's primary function is to provide access to the premium features of the AIXBT market intelligence platform. Users can unlock these services by holding a minimum of 600,000 AIXBT or staking 500,000 AIXBT. Additionally, tokens may be staked on the Virtuals protocol to earn points.

• F.3 Planned Application of Functionalities: All contemplated features of the token are live and available to users who meet the holding or staking requirements.

• F.4 Type of White Paper: OTHR

• F.5 Type of Submission: NEWT

• F.6 Crypto-Asset Characteristics: AIXBT is an ERC-20 utility token deployed on the Base and Ethereum blockchains, as well as an SPL token deployed on the Solana blockchain. It has a fixed total supply of one (1) billion tokens and serves exclusively to grant access to the services offered by the AIXBT platform.

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

• F.8 Website of the Issuer: https://aixbt.tech/

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

• F.10 Publication Date [YYYY-MM-DD]: 2025-11-27

• 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: 7QSZW6RFQ, 1RNFH04Q7, 12M3MG1JR

• F.15 Functionally Fungible Group Digital Token Identifier, where available: 8762TQWQ6

• 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 for the purchaser. Purchasers of the AIXBT token obtain the right to access the premium features of the AIXBT platform, provided they meet the minimum holding or staking thresholds. Token holders do not have any claims on capital, voting rights in a governance process, share of profits, or other legal rights in the issuer or project.

• G.2 Exercise of Rights and Obligations: As the token does not grant obligations, there is no conceivable way to exercise such obligations. Purchasers can exercise their right to access platform services by connecting a compatible crypto-asset wallet containing the requisite number of AIXBT tokens to the AIXBT application.

• G.3 Conditions for Modifications of Rights and Obligations: As the token does not grant obligations, there are no conditions under which obligations may be modified. Rights associated with the AIXBT token, including the features of the "Ultimate Plan" and the thresholds for access, may be modified unilaterally by the project developer, as there is no formal community governance process in place.

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

• G.5 Issuer Retained Crypto-Assets, if applicable: N/A

• G.6 Utility Token Classification: TRUE

• G.7 Key Features of Goods/Services of Utility Tokens: The AIXBT token provides access to a suite of digital services on its market intelligence platform. The quantity and quality of these services are defined by the platform's "Ultimate Plan," which includes features such as advanced project analysis, unlimited AI agent chat, alerts, and custom reports. Access is granted to any user who holds or stakes the required amount of tokens.

• G.8 Utility Tokens Redemption, if applicable: AIXBT tokens are not redeemed or consumed to access services. Instead, utility is derived from holding or staking the tokens in a user's wallet, which acts as a key to unlock premium platform features. The tokens remain in the user's possession and are not transferred to the project.

• 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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 AIXBT 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: FALSE

• H.9 Audit Outcome, if applicable: N/A

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: aixbt by Virtuals

• I.4 Consensus Mechanism: aixbt by Virtuals 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: aixbt by Virtuals 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. Transactions on base are bundled by a, so called, sequencer and the result is regularly submitted as a Layer-1 (L1) transaction. 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-10-12

• I.7 End of the period to which the disclosure relates: 2025-10-12

• I.8 Energy consumption: 20.25025 (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.

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.