White Paper Report



	White paper for crypto-assets other than asset-referenced tokens or e-money tokens

	Digital Token Identifier:	7QSZW6RFQ, 1RNFH04Q7, 12M3MG1JR
	Operator of the trading platform:	54930069NLWEIGLHXU42 - OKX Europe Limited
	Type of submission:	Modify

Table of content
General information
SUMMARY
Part A - Information about offeror or person seeking admission to trading
Part B - Information about issuer, if different from offeror or person seeking admission to trading
Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D - Information about other token project
Part E - Information about offer to public of other tokens or their admission to trading
Part F - Information about other tokens
Part G - Information on rights and obligations attached to other tokens
Part H – Information on underlying technology
Part I - Information on risks
Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts




[Table 2] Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens

Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens [abstract]
General information
00 Table of content	boolean true	true
01 Date of notification	date	2026-09-02
02 Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114	boolean true	This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
03 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114	boolean true	This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, 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.
04 Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114	boolean true	The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid
05 Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114	boolean true	The utility token referred to in this white paper may not be exchangeable against the good or service promised in this white paper, especially in the case of a failure or discontinuation of the crypto-asset project.
06 Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114	boolean true	The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
SUMMARY
07 Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114	boolean true	Warning This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto –asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.
08 Characteristics of the crypto-asset	textBlock	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 premium tier by holding 600,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.
09 Further information about utility tokens	textBlock	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 threshold grants full access to all features included in that premium tier. The AIXBT token is freely and instantly transferable, utilising the underlying blockchain network's standard processes.
10 Key information about the offer to the public or admission to trading	textBlock	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.
Part A - Information about offeror or person seeking admission to trading
A.1 Name	N/A		.
A.2 Legal form	N/A		.
A.3 Registered address
Registered addess	N/A		.
Country	N/A		.
Sub-division	N/A		.
A.4 Head office
Head office	N/A		.
Country	N/A		.
Sub-division	N/A		.
A.5 Registration date	N/A		.
A.6 Legal entity identifier	N/A		.
A.7 Another identifier required pursuant to applicable national law	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 Parent company	N/A		.
A.12 Members of the management body
Member #1	N/A		.
Identity	N/A		.
Business address	N/A		.
Function	N/A		.
A.13 Business activity	N/A		.
A.14 Parent company business activity	N/A		.
A.15 Newly established	N/A		.
A.16 Financial condition for the past three years	N/A		.
A.17 Financial condition since registration	N/A		.
Part B - Information about issuer, if different from offeror or person seeking admission to trading
B.1 Issuer different from offerror or person seeking admission to trading	boolean	true
B.2 Name	text	Virtuals Protocol
B.3 Legal form	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
B.4 Registered address
Registered addess	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Country	enumeration
Sub-division	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
B.5 Head office
Head office	text	Damansara, Kuala Lumpur
Country	enumeration	Malaysia
Sub-division	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
B.6 Registration date	date
B.7 Legal entity identifier	LEI
B.8 Another identifier required pursuant to applicable national law	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
B.9 Parent company	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
B.10 Members of the management body
Member #1	id	1
Identity	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Business address	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Function	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
B.11 Business activity	textBlock	Virtuals Protocol operates as a platform for the creation and deployment of AI agents and their associated crypto-assets.
B.12 Parent company business activity	textBlock	No information could be identified in regards to this field at the time of drafting this whitepaper.
Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
C.1 Name	text	OKX Europe Limited
C.2 Legal form	text	Limited Liability Company
C.3 Registered address
Registered address	text	Piazzetta Business Plaza, Office Number 4, Floor 2, Triq Ghar il-Lembi, Sliema SLM1562, Malta
Country	enumeration	Malta
Sub-division	text	N/A
C.4 Head office
Head office	text	See C.4
Country	enumeration	Malta
Sub-division	text	N/A
C.5 Registration date	date	2018-09-07
C.6 Legal entity identifier	LEI	54930069NLWEIGLHXU42
C.7 Another identifier required pursuant to applicable national law	text	C 88193
C.8 Parent company	text	OKC International Holding Company Limited
C.9 Reason for crypto-asset white paper preparation	textBlock	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.10 Members of the management body
Member #1	id	1
Identity	text	Erald Henri J. Ghoos
Business address	text	See C.4
Function	text	Director
Member #2	id	2
Identity	text	Fang Hong
Business address	text	See C.4
Function	text	Director
Member #3	id	3
Identity	text	Joseph Portelli
Business address	text	See C.4
Function	text	Director
Member #4	id	4
Identity	text	Wei Man Cheung
Business address	text	See C.4
Function	text	Director
C.11 Operator business activity	textBlock	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.12 Parent company business activity	textBlock	N/A
C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	text	N/A
C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	text	N/A
Member #2	id	2
C.12 Parent company business activity	N/A		.
C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	N/A		.
C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	N/A		.
Member #3	id	3
C.12 Parent company business activity	N/A		.
C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	N/A		.
C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	N/A		.
Member #4	id	4
C.12 Parent company business activity	N/A		.
C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	N/A		.
C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	N/A		.
Part D - Information about other token project
D.1 Crypto-asset project name	text	AIXBT
D.2 Crypto-asset name	text	See F.13
D.3 Abbreviation	text	See F.13
D.4 Crypto-asset project description	textBlock	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 implementation of crypto-asset project
Person #1	id	1
Type of person	enumeration	Development team
Name of person	text	Jansen Teng
Business address of person	text	Kuala Lumpur, Malaysia
Domicile of company	enumeration
Person #2	id	2
Type of person	enumeration	Development team
Name of person	text	Wee Kee
Business address of person	text	Kuala Lumpur, Malaysia
Domicile of company	enumeration
Person #3	id	3
Type of person	enumeration	Development team
Name of person	text	Bryan Lim
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #4	id	4
Type of person	enumeration	Development team
Name of person	text	Brianna Chang
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #5	id	5
Type of person	enumeration	Development team
Name of person	text	Weixiong Tay
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #6	id	6
Type of person	enumeration	Development team
Name of person	text	Khoon Kheng Teh
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #7	id	7
Type of person	enumeration	Development team
Name of person	text	Jae-Sonn
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #8	id	8
Type of person	enumeration	Development team
Name of person	text	Celeste Ang
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #9	id	9
Type of person	enumeration	Development team
Name of person	text	Sally Wang
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #10	id	10
Type of person	enumeration	Development team
Name of person	text	Hanan N.
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #11	id	11
Type of person	enumeration	Development team
Name of person	text	Sean Kyu Won Kim
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #12	id	12
Type of person	enumeration	Development team
Name of person	text	Viktor Anchutin
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #13	id	13
Type of person	enumeration	Development team
Name of person	text	Wei Zhe (Javier) Yeoh
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #14	id	14
Type of person	enumeration	Development team
Name of person	text	Harry
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #15	id	15
Type of person	enumeration	Development team
Name of person	text	Xie Ong
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #16	id	16
Type of person	enumeration	Development team
Name of person	text	Yifei You
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #17	id	17
Type of person	enumeration	Development team
Name of person	text	Stefano Bury
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #18	id	18
Type of person	enumeration	Development team
Name of person	text	Shi Khai WEI
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #19	id	19
Type of person	enumeration	Development team
Name of person	text	Yujie Chuah
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #20	id	20
Type of person	enumeration	Development team
Name of person	text	Koo Huang
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #21	id	21
Type of person	enumeration	Development team
Name of person	text	Kahwai Chooi
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #22	id	22
Type of person	enumeration	Development team
Name of person	text	Matthew T
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #23	id	23
Type of person	enumeration	Development team
Name of person	text	Rxbt (pseudonym)
Business address of person	text	No information could be identified in regards to this field at the time of drafting this whitepaper.
Domicile of company	enumeration
Person #24	id	24
Type of person	enumeration	Development team
Name of person	text	Virtuals Protocol
Business address of person	text	Damansara, Kuala Lumpur
Domicile of company	enumeration	Malaysia
D.6 Utility token classification	boolean	true
D.7 Key features of goods or services for utility token projects	text	The AIXBT project provides access to a crypto market intelligence platform featuring an AI agent. Its key services, available through the platform's premium tier, 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
Description of past milestones	textBlock	The AIXBT token was launched on the Base network in November 2024 with a fixed total supply of one billion tokens. The token was subsequently made available on the Solana blockchain as a bridged SPL token, and a LayerZero omnichain representation was deployed on the Ethereum mainnet in July 2025.
Description of future milestones	textBlock	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	text	N/A
D.10 Planned use of collected funds or other tokens	text	N/A
Part E - Information about offer to public of other tokens or their admission to trading
E.1 Public offering or admission to trading	enumeration	Admission to trading
E.2 Reasons for public offer or admission to trading	textBlock	Facilitating secondary trading for users on the OKX Trading platform in compliance with the MiCA regulatory framework.
E.3 Fundraising target
Target expressed in currency	monetary	0	EUR
Target expressed in units	decimal	0
Target expressed in digital token identifier	text	N/A
E.4 Minimum subscription goals
Goals expressed in currency	monetary	0	EUR
Goals expressed in units	decimal	0
Goals expressed in digital token identifier	text	N/A
E.5 Maximum subscription goals
Goasl expressed in currency	monetary	0	EUR
Goals expressed in units	decimal	0
Goals expressed in digital token identifier	text	N/A
E.6 Oversubscription acceptance	boolean	false
E.7 Oversubscription allocation	text
Issue price details
E.8 Issue price	decimal
E.9 Official currency determining issue price	enumeration
E.9 Any other tokens determining issue price	text
E.10 Subscription fee
Fee expressed in currency	monetary	0	EUR
Fee expressed in units	decimal	0
Fee expressed in digital token identifier	text	N/A
E.11 Offer price determination method	text	N/A
E.12 Total number of offered or traded other tokens	integer	1000000000
E.13 Targeted holders	enumeration	All types of investors
E.14 Holder restrictions	text	N/A
E.15 Reimbursement notice	boolean true	N/A
E.16 Refund mechanism	textBlock	N/A
E.17 Refund timeline	text	N/A
E.18 Offer phases	textBlock	N/A
E.19 Early purchase discount	textBlock	N/A
E.20 Time-limited offer	boolean	false
E.21 Subscription period beginning	date
E.22 Subscription period end	date
E.23 Safeguarding arrangements for offered funds or other tokens	textBlock	N/A
E.24 Payment methods for other token purchase	textBlock	In line with OKX current payment method offering.
E.25 Value transfer methods for reimbursement	textBlock	N/A
E.26 Right of withdrawal	textBlock	N/A
E.27 Transfer of purchased other tokens	textBlock	In line with OKX current Terms of Service.
E.28 Transfer time schedule	text	N/A
E.29 Purchaser's technical requirements	textBlock	In line with OKX current Terms of Service.
Other token services provider characteristics
E.30 Other token service provider (CASP) name	text	OKX Europe Limited
E.31 CASP identifier	LEI	54930069NLWEIGLHXU42
E.32 Placement form	enumeration	Not applicable
Trading platforms characteristics
E.33 Trading platforms name	text	OKX
E.34 Trading platforms market identifier code (MIC)	text	N/A
E.35 Trading platforms access	text	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	textBlock	In line with the OKX current Terms of Service.
E.37 Offer expenses	textBlock	N/A
E.38 Conflicts of interest	textBlock	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	textBlock	Malta
E.40 Competent court	textBlock	Malta
Part F - Information about other tokens
F.1 Crypto-asset type	text	Other Crypto-Asset.
F.2 Other token functionality	textBlock	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. Additionally, tokens may be staked on the Virtuals protocol to earn points.
F.3 Planned application of functionalities	textBlock	All contemplated features of the token are live and available to users who meet the holding requirements.
A description of the characteristics of the other token, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article
F.4 Type of crypto-asset white paper	enumeration	Other crypto-asset token white paper
F.5 Type of submission	enumeration	Modify
F.6 Other token characteristics	textBlock	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	text	See F.13
F.8 Website of the issuer	text	https://aixbt.tech/
F.9 Starting date of offer to the public or admission to trading	date	2025-02-20
F.10 Publication date	date	2026-09-14
F.11 Any other services provided by the issuer	textBlock	N/A
F.12 Language or languages of white paper	text	English
F.13 Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available	text	7QSZW6RFQ, 1RNFH04Q7, 12M3MG1JR
F.14 Functionally fungible group digital token identifier, where available	text	8762TQWQ6
F.15 Voluntary data flag	boolean	false
F.16 Personal data flag	boolean	true
F.17 LEI eligibility	boolean	true
F.18 Home member state	enumeration	Malta
F.19 Host member states #1	enumerationSet	Austria
F.19 Host member states #2	enumerationSet	Belgium
F.19 Host member states #3	enumerationSet	Bulgaria
F.19 Host member states #4	enumerationSet	Croatia
F.19 Host member states #5	enumerationSet	Cyprus
F.19 Host member states #6	enumerationSet	Czechia
F.19 Host member states #7	enumerationSet	Denmark
F.19 Host member states #8	enumerationSet	Estonia
F.19 Host member states #9	enumerationSet	Finland
F.19 Host member states #10	enumerationSet	France
F.19 Host member states #11	enumerationSet	Germany
F.19 Host member states #12	enumerationSet	Greece
F.19 Host member states #13	enumerationSet	Hungary
F.19 Host member states #14	enumerationSet	Iceland
F.19 Host member states #15	enumerationSet	Ireland
F.19 Host member states #16	enumerationSet	Italy
F.19 Host member states #17	enumerationSet	Latvia
F.19 Host member states #18	enumerationSet	Liechtenstein
F.19 Host member states #19	enumerationSet	Lithuania
F.19 Host member states #20	enumerationSet	Luxembourg
F.19 Host member states #21	enumerationSet	Malta
F.19 Host member states #22	enumerationSet	Netherlands
F.19 Host member states #23	enumerationSet	Norway
F.19 Host member states #24	enumerationSet	Poland
F.19 Host member states #25	enumerationSet	Portugal
F.19 Host member states #26	enumerationSet	Romania
F.19 Host member states #27	enumerationSet	Slovakia
F.19 Host member states #28	enumerationSet	Slovenia
F.19 Host member states #29	enumerationSet	Spain
F.19 Host member states #30	enumerationSet	Sweden
Part G - Information on rights and obligations attached to other tokens
G.1 Purchaser rights and obligations	textBlock	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 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	textBlock	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	textBlock	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 premium tier 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	textBlock	N/A
G.5 Issuer retained other token	integer	0
G.6 Utility token classification	boolean	true
G.7 Key features of goods or services utility tokens	text	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 premium tier, which includes features such as advanced project analysis, unlimited AI agent chat, alerts, and custom reports. Access is granted to any user who holds the required amount of tokens.
G.8 Utility tokens redemption	text	AIXBT tokens are not redeemed or consumed to access services. Instead, utility is derived from holding 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	boolean	true
G.10 Other tokens purchase or sale modalities	text	N/A
G.11 Other tokens transfer restrictions	text	In line with OKX current Terms of Service.
G.12 Supply adjustment protocols	boolean	false
G.13 Supply adjustment mechanisms	text	N/A
Other token schemes details
G.14 Token value protection schemes	boolean	false
G.15 Token value protection schemes description	textBlock	N/A
G.16 Compensation schemes	boolean	false
G.17 Compensation schemes description	textBlock	N/A
G.18 Applicable law	textBlock	Malta
G.19 Competent court	textBlock	Malta
Part H – Information on underlying technology
H.1 Distributed ledger technology (DTL)	text	See F.13
H.2 Protocols and technical standards	text	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	textBlock	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	text	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	text	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	boolean	false
H.7 DLT functionality description	textBlock	N/A
Other token audit details
H.8 Audit	boolean	true
H.9 Audit outcome	textBlock	A public competitive audit of the Virtuals Protocol framework contracts, which provide the agent framework through which the AIXBT token is deployed, was conducted between 17 April and 7 May 2025. The audit reported six high-severity and twenty-six medium-severity findings, including in the bonding contract's unwrapToken function and in AgentNftV2 validator access control. No audit of the AIXBT token contract itself has been published.
Part I - Information on risks
I.1 Offer-related risks	textBlock	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.
I.2 Issuer-related risks	textBlock	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.
I.3 Other tokens-related risks	textBlock	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.
I.4 Project implementation-related risks	textBlock	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.
I.5 Technology-related risks	textBlock	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.
I.6 Mitigation measures	textBlock	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.
Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
J.1 Adverse impacts on climate and other environment-related adverse impacts	textBlock
Mandatory information on principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism
General information about adverse impacts
S.1 Name	text	OKX Europe Limited
S.2 Relevant legal entity identifier	text	54930069NLWEIGLHXU42
S.3 Name of the crypto-asset	text	aixbt by Virtuals
S.4 Consensus mechanism	text	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.
S.5 Incentive mechanisms and applicable fees	text	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.
S.6 Beginning of period to which disclosed information relates	date	2025-08-04
S.7 End of period to which disclosed information relates	date	2026-08-04
Mandatory key indicator
S.8 Energy consumption	energy (kWh)	26.19521
Sources and methodologies
S.9 Energy consumption sources and methodologies	textBlock	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.
Supplementary information on principal adverse impacts on climate and other environment-related adverse impacts of consensus mechanism
Supplementary key indicators
S.10 Renewable energy consumption	percent
S.11 Energy intensity	energy (kWh)
S.12 Scope 1 DLT GHG emissions - controlled	GHG emissions (tCO2e)
S.13 Scope 2 DLT GHG emissions - purchased	GHG emissions (tCO2e)
S.14 GHG intensity	GHG emissions (tCO2e)
Sources and methodologies
S.15 Key energy sources and methodologies	textBlock
S.16 Key GHG sources and methodologies	textBlock
Optional information on principal adverse impacts on the climate and on other environment-related adverse impacts of the consensus mechanism
Optional indicators
S. 17 Energy mix	percent
S.18 Energy use reduction
Energy use reduction target (absolute value)	energy (kWh)
Energy use reduction target (percentage)	percent
S.19 Carbon intensity (kgCO2e/kWh)	decimal
S.20 Scope 3 DLT GHG emissions - value chain	GHG emissions (tCO2e)
S.21 GHG emissions reduction targets or commitments	textBlock
S.22 Generation of waste electrical and electronic equipment (WEEE)	mass (tonnes)
S.23 Non-recycled WEEE ratio	percent
S.24 Generation of hazardous waste	mass (tonnes)
S.25 Generation of waste (all types)	mass (tonnes)
S.26 Non-recycled waste ratio (all types)	percent
S.27 Waste intensity (all types)	mass (tonnes)
S.28 Waste reduction targets or commitments (all types)	textBlock
S.29 Impact of use of equipment on natural resources	textBlock
S.30 Natural resources use reduction targets or commitments	textBlock
S.31 Water use	volume (m3)
S.32 Non recycled water ratio	percent
Sources and methodologies
S.33 Other energy sources and methodologies	textBlock
S.34 Other GHG sources and methodologies	textBlock
S.35 Waste sources and methodologies	textBlock
S.36 Natural resources sources and methodologies	textBlock