Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the 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 the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-10-09

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union.
The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

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.

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.

FALSE

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.

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.

The Xsolla Gas Token (XLA) is a single crypto-asset with a fixed total supply of 1,000,000,000 units, issued as an ERC-20 token on Ethereum mainnet. XLA is also the base token of the Xsolla ZK Layer 2. Units of XLA locked on Ethereum are represented on Xsolla ZK as the network's native currency, which is used to pay transaction fees. The representation on Xsolla ZK is backed one-for-one by XLA held on Ethereum and does not increase total supply.Xsolla ZK is a blockchain-based project for the video-game industry. It is designed to support Web3-enabled gaming infrastructure, including the storage, management, transfer, and use of blockchain-based in-game items through a digital backpack and related developer tools.

Xsolla ZK is built using ZKsync technology and is intended to form part of an ecosystem of interconnected zero-knowledge chains. XLA has a total supply of 1,000,000,000 XLA.

At the date of this white paper, XLA is used to pay gas fees on Xsolla ZK. Staking, governance and incentive functions are planned and are not yet available. Governance of the Xsolla ZK chain is directed by the Xsolla ZK Foundation.

Not applicable

The Xsolla Gas Token is intended to be made available through two distinct channels.

First, the transferable form of the Xsolla Gas Token is intended for admission to trading on Kraken and Bitvavo. Tokens made available through the trading platform can be used within the Xsolla ecosystem and will be transferable between holders. The trading price will be determined by market conditions, including prevailing supply and demand.

Separately, a non-transferable form of the Xsolla Gas Token will be made available through Xsolla Pay Station at a fixed price of USD 1.00 per token. A total of 200,000,000 tokens, representing 20% of the fixed supply of 1,000,000,000 Xsolla Gas Tokens. This form is intended for use within the Xsolla ZK ecosystem and cannot be independently transferred, sold or traded by the holder. If the non-transferable token is not used within one year, it expires and is returned to the Xsolla USA treasury, where it may subsequently be made available for sale again.

Accordingly, the exchange-listed form and the Pay Station form differ in the manner in which holders may acquire and use them. The transferable form may be traded on the relevant trading platform at a market-determined price, whereas the non-transferable form acquired through Pay Station is offered to the public at a fixed price and can only be consumed for its intended network functionality but cannot be traded by the purchaser.

Xsolla ZK, Inc.

XTIQ

Delaware

US-DE

15260, Ventura Boulevard, Suite 2230, Sherman Oaks, CA 94103

US-CA

2024-08-19

877-987-9233

legal@xsolla.com

Xsolla Holding Company

Xsolla ZK, Inc. is engaged in the development and operation of blockchain infrastructure for the video game industry. Its business activities include the development and maintenance of the Xsolla ZK Layer 2 network, the XLA token ecosystem, blockchain-based developer tools and related software supporting digital asset management, gaming applications and Web3-enabled services.

Xsolla Holding Company is the holding company for entities within the Xsolla family. Xsolla Holding Company business activity includes game publishing, digital content distribution and sales, interactive services, news and media-related activities, narrative services, and other game-industry products and services.

FALSE

Not applicable

Xsolla ZK, Inc. is a recently established entity and therefore does not have 3 years of historical financial information available.

The entity operates within the broader Xsolla commercial ecosystem. Xsolla has operated in games commerce for more than 20 years and launched its first mobile Web Shop in 2021. Since then, it has launched more than 800 mobile Web Shops and reported that its Web Shops generated more than USD 1,000,000,000 in sales during H1 2026. These Web Shops are direct-to-consumer online storefronts through which game developers and publishers sell digital goods directly to players using Xsolla's commerce infrastructure.

As an indication of the scale and recurring commercial activity supported by the wider Xsolla platform, Xsolla further reported that 69.3% of players making a first Web Shop purchase returned for a second purchase, while repeat purchasers accounted for 97.8% of sales through the Web Shops, representing just under USD 1,000,000,000 during the period analysed.

These figures are presented as contextual information concerning the wider Xsolla commercial ecosystem and not as standalone financial information of Xsolla ZK, Inc. In the future, Xsolla ZK, Inc. is expected to generate income from Sequencer fees by operating it on the Xsolla ZK chain.

FALSE

Xsolla ZK

Xsolla Gas Token

XLA

Xsolla ZK is a Web3 infrastructure project for the video-game industry. It is designed to support blockchain-based game economies, including the creation, storage, management, transfer and use of compatible in-game items and other digital assets.

Xsolla ZK as a project built using ZKsync technology and intended to support the transition of gaming into Web3. The project is connected with Xsolla’s digital backpack concept, through which game developers may create and maintain in-game items that players can store on blockchain infrastructure.

XLA is the native currency of Xsolla ZK. It is issued on Ethereum as an ERC-20 token and is represented on Xsolla ZK as the base token of the network. The network is also intended to be accessible to game developers and decentralised application builders. Governance of the chain is directed by the Xsolla ZK Foundation, which is separate from Xsolla's product development and promotion.

The project is intended to provide infrastructure for developers, creators, gaming infrastructure providers and players. Its purpose is to support verifiable ownership, programmable transactions and interoperable systems across game environments, while reducing friction for players.

FALSE

Past milestones

Xsolla was founded in 2005 as a global video game commerce company providing payment, monetisation and distribution solutions for game developers and publishers.

Xsolla announced the Xsolla ZK project in October 2024. Xsolla ZK is an Ethereum Layer 2 zero-knowledge rollup built using ZKsync Elastic Chain technology. The project was introduced to provide blockchain infrastructure for the video game industry, with a focus on digital asset ownership, interoperability and Web3-enabled commerce.

Xsolla also announced the Backpack application, a digital inventory management solution incorporating an embedded smart wallet, together with plans to integrate blockchain functionality into the Xsolla Publisher Suite through products including Backpack and PayStation.

During 2025 and 2026, the project focused on development of the Xsolla ZK infrastructure, including deployment of the Layer 2 rollup, integration with the ZKsync Elastic Chain, implementation of the governance framework, development of ecosystem applications and preparation for the public distribution and admission to trading of XLA.

Future milestones

The current development roadmap is divided into 4 phases.

Phase 1 focuses on finalising the economic mechanisms for the XLA gas token, undertaking partnership and adviser discussions, and completing the technical, operational and commercial preparations required for subsequent phases.

Phase 2 includes the release of Backpack, a mainnet alpha test, community-building activities and the establishment of decentralised application (dApp) partnerships.

Phase 3 comprises discussions with exchanges and market makers, the announcement of strategic partnerships, the Token Generation Event (TGE), admission to trading on exchanges and the launch of the first adoption campaign.

Phase 4 is expected to focus on a second adoption campaign and the release of additional network features and enhancements.

The governance of the Xsolla ZK network is expected to transition progressively towards decentralisation.

During the initial centralised phase, expected to cover approximately months 0 to 36 following launch, chain governance authority, including authority over protocol upgrades, parameter changes and emergency response measures, is directed by the Xsolla ZK Foundation. Xsolla ZK, Inc. and ZKsync are expected to perform technical and operational functions under the governance framework established for the network. Sequencing is operated by the Xsolla team, while proving is managed by Xsolla and ZKsync proving services.

During this period, the Xsolla ZK protocol will not be decentralised. This initial phase is intended to prioritise operational stability, security hardening and performance optimisation to support rapid scaling.

During approximately months 36 to 48, the project intends to progress towards a more decentralised model involving decentralised sequencers and stakers, subject to the availability of the required technical functionality and the applicable protocol design.

In the long-term network governance phase, expected from month 48 onwards, governance authority is intended to transition towards a community-driven model involving the Security Council, the Token Council and the XLA Token Community, including delegates and token holders. At this stage, network governance is expected to be managed through the XLA token community in accordance with the applicable governance framework.

The milestones, development objectives and implementation timelines described in this section represent the current plans and intentions of the project as at the date of this crypto-asset white paper. They are indicative only and do not constitute guarantees, commitments or legally binding obligations.

XLA has a fixed total supply of 1,000,000,000 tokens, all of which were minted on the Ethereum mainnet. Of the total supply, 40% is allocated to the Xsolla ZK Foundation to support network and protocol development and to serve as a long-term reserve for the Xsolla ZK ecosystem.

A further 20% is allocated to the Agapitova Family Revocable Trust and is not intended for public sale. The founder has indicated a willingness to place this allocation with a qualified custodian, subject to a valuation-based unlock mechanism under which 10% of the total XLA supply would become available when XLA reaches a fully diluted valuation (FDV) of USD 10,000,000,000, and the remaining 10% would become available when XLA reaches an FDV of USD 100,000,000,000.

20% of the total supply is allocated to Xsolla ZK, Inc. and is intended to be sold to the public through centralised crypto-asset trading platforms.

The remaining 20% is allocated to Xsolla USA, Inc. for distribution to end users through Xsolla Pay Station and Gas Station in the form of XLA-NT, a non-transferable wrapped representation of XLA used to pay network gas fees. XLA-NT cannot be transferred or sold and is therefore not subject to vesting arrangements.

Not applicable

The XLA token is intended to be made available through both an offer to the public and an admission to trading, with each arrangement relating to a different form of the token.

The offer to the public is intended to enable users to acquire XLA directly through the Xsolla Pay Station for use within the Xsolla ZK ecosystem. Tokens offered through Pay Station will be made available in a non-transferable form.

Separately, the project intends to seek the admission to trading of the transferable form of XLA. The purpose of seeking admission to trading is to make the transferable form of XLA available for trading. XLA is currently intended to be listed on Kraken and Bitvavo, subject to the applicable listing arrangements, the requirements and rules of the trading platform, and relevant market and regulatory conditions.

Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal provided for in Article 13 of Regulation (EU) 2023/1114 of the European Parliament and of the Council or if the offer is cancelled.

The refund mechanism is only applicable in cases of purchaser withdrawal, as there is no minimum target subscription goal or offer cancellation option.

If a purchaser decides to exercise their right of withdrawal, as provided in Article 13 of Regulation (EU) 2023/1114, he may request a full or partial refund through the Xsolla refund process, subject to the applicable terms and conditions. Depending on the payment method used for the purchase, refunds may be processed through one of the following routes:

• Refund to the original payment method: where supported, the full or partial refund is processed automatically to the payment account used for the original purchase.
• Manual refund: for certain payment methods, a full or partial refund may be processed manually by Xsolla customer support.
• Alternative refund method: where the original payment method does not support refunds, Xsolla may provide an alternative refund method, such as another supported payment method or Xsolla balance.

The applicable refund route and processing time depend on the payment method used and the applicable Xsolla refund policy. Where a refund is approved, the corresponding XLA balance credited to the purchaser’s Xsolla ID wallet will be reversed or otherwise deducted, as applicable.

The refund will be processed within 5 to 10 days of the issuer’s receipt of the withdrawal notice.

The non-transferable crypto-assets will be available for purchase through Xsolla Pay Station in predefined bundles, currently comprising 1, 5 and 15 tokens.Purchases may be made using the payment methods supported by Xsolla Pay Station including credit and debit cards, Apple Pay, Google Pay, PayPal and other local or regional electronic payment methods. If the non-transferable token is not used within one year, it expires and is returned to the Xsolla USA treasury, where it may subsequently be made available for sale again.

The applicable reimbursement route and processing time depend on the payment method used and the applicable Xsolla refund policy. Where a refund is approved, the corresponding XLA balance credited to the purchaser’s Xsolla ID wallet will be reversed or otherwise deducted, as applicable.

Purchasers of the non-transferable form of XLA have the right to withdraw from their purchase agreement in accordance with Article 13 of Regulation (EU) 2023/1114. This right allows them to cancel their purchase within 14 calendar days from the date of the agreement, without incurring any fees, costs, or the need to provide a reason.

To exercise this right, purchasers must send a withdrawal notice before the 14th day following the agreement date.

If the right of withdrawal is validly exercised, all payments received, including any applicable fees, will be reimbursed within 14 days from the date the Xsolla ZK Inc. receives the withdrawal notice. Reimbursement will be made using the same payment method used for the initial transaction, unless otherwise agreed by the purchaser, and without any additional charges.

The corresponding token balance will be credited to the purchaser’s wallet associated with their Xsolla ID.

Payward Global Solutions Limited (Kraken), Bitvavo B.V.

PGSL, VAVO

Access to trading, if admission is granted, will be provided through trading platforms, including websites and mobile applications, in accordance with the trading platforms’ terms of use and applicable regulatory requirements.

Access to trading of the XLA crypto-asset on Kraken and Bitvavo, if admission is granted, may involve costs charged by the trading platform. Such costs may include trading fees, deposit or withdrawal fees, custody-related fees, or other charges applied in accordance with trading platforms’ fee schedule and terms of use.

Xsolla Pay Station does not impose any additional charges on purchasers in connection with the purchase of XLA. However, depending on the jurisdiction and the purchaser’s chosen payment method or applicable payment service provider, purchasers may be subject to additional costs, including applicable currency conversion fees, transaction fees, and taxes.

As the crypto-asset is intended to be admitted to trading on Kraken and Bitvavo, a potential conflict of interest may arise in connection with the admission to trading.

Kraken has identified this type of potential conflict in its MiCAR Conflicts of Interest Disclosure, published on its MiCAR Policies and Disclosures webpage pursuant to Article 72 of MiCA. In the section concerning Asset Listing, Kraken identifies a potential conflict between Payward Global Solutions Limited and project teams where Kraken receives direct or indirect benefits associated with providing support to project teams in relation to crypto-assets listed or seeking listing on its platform.

Kraken states that it maintains arrangements and internal controls for the identification, prevention, management and, where appropriate, disclosure of conflicts of interest.

Bitvavo may receive fees or other economic benefits in connection with the provision of its services and may generate transaction-fee revenue from trading activity in XLA following its admission to trading. These circumstances may give rise to an actual or potential conflict of interest between Bitvavo’s commercial interests and the interests of holders or prospective holders of XLA.

Bitvavo maintains policies and procedures for the identification, prevention, management and disclosure of conflicts of interest. Its publicly disclosed framework includes an Admission to Trading Policy and compliance controls applicable to decisions concerning the admission and continued trading of crypto-assets.

Potential conflicts of interest may arise from the role of the issuer and other project participants in the development and governance of the Xsolla ZK network. In particular, the Xsolla ZK Foundation currently directs Chain governance, including authority over protocol upgrades, network parameters and emergency measures, while Xsolla ZK, Inc. and Matter Labs perform technical and operational functions under the Foundation's direction. As governance develops, the relevant governance bodies may also influence matters affecting the XLA token and the network, including gas-fee parameters, token-related economic parameters and ecosystem incentive programs.

The interests of such persons may not always be aligned with those of XLA holders or other network participants. Further information on the associated issuer- and governance-related risks is provided in Sections I.2 and I.4.

Ireland

Ireland

Crypto-assets other than asset-referenced tokens or e-money tokens

XLA's primary function is to pay transaction fees for transactions executed on the Xsolla ZK network, including transactions involving in-game digital assets, decentralised applications and other supported services. XLA is the base token of the Xsolla ZK network. It is the network's native currency and the only asset in which gas fees are paid.

XLA exists on two layers. On Ethereum, XLA is an ERC-20 token with proxy contract address 0xa24C70209C857cb5a5a0ff0758a6F50000233D2F and implementation contract address 0x7aaCBc456D517c8EB10Cd534Bde3E688e899A93E. On Xsolla ZK, XLA is the native currency, accessed through the system contract at address 0x000000000000000000000000000000000000800A. Units on Xsolla ZK are created only when the same number of units are locked in the network bridge on Ethereum, and are removed when units are withdrawn to Ethereum. The two layers hold one asset, and the ERC-20 on Ethereum is the form made available for trading.

The XLA crypto-asset is also intended to support the broader economic operation of the Xsolla ZK ecosystem. Users, game publishers, developers and other participants may use XLA in connection with applications and services deployed on the network. Developers may also choose to fund transaction fees on behalf of their users or otherwise incorporate XLA into the operation of their applications.

As the network develops, XLA is intended to support staking and network decentralisation. The project plans to transition toward a decentralised sequencing model in which XLA may be staked by sequencers or delegated to sequencers as part of the network's Proof-of-Stake-based consensus arrangements. XLA is also intended to support incentive mechanisms for infrastructure participants, including sequencers and provers, and may be used in reward programmes for developers, game publishers and other ecosystem participants.

XLA is intended to provide ecosystem incentive and loyalty mechanisms, including milestone-based rewards, developer incentives, community reward programmes and staking-related benefits. The precise operation of these mechanisms may evolve as the network develops.

XLA is further intended to support participation in the governance of the Xsolla ZK ecosystem as the network progressively decentralises. Eligible token holders may participate in governance processes in accordance with the applicable governance framework.

The governance framework is expected to distribute authority among the following governance bodies: the security council, the token council and the token community. The security council is expected to oversee protocol governance, including the review and approval of protocol upgrades and the implementation of emergency measures where necessary to address security risks.

At the date of this white paper, the XLA token contract on Ethereum is administered through its proxy administrator and role-based access control. The token council described in this white paper is a planned governance body and does not currently hold administrative control of the contract.

The token community is expected to consist of XLA token holders who may delegate voting power to delegates. Those delegates may vote on governance proposals relating to matters such as token-distribution programmes, developer grants, partnership incentives and community reward programmes.

At the date of this white paper, the function of XLA is the payment of gas fees on Xsolla ZK. Staking, governance and incentive functions are planned and are not yet available.

The functionalities of the XLA gas token are expected to evolve progressively alongside the development and decentralisation of the Xsolla ZK ecosystem.

Following the TGE, the initial phase is expected to extend from month 0 to month 36 after launch. This is intended to be followed by a governance iteration phase from months 36 to 48, during which the role and functionality of XLA are expected to expand as the network moves towards greater decentralisation.

From month 48 onwards, the network is intended to transition towards its long-term community-driven governance model, with XLA expected to play an increasingly developed role in network governance.

XLA is the native gas crypto-asset for the Xsolla ZK Layer 2, a blockchain-based project for the video-game industry.

Xsolla ZK is built using ZKsync technology and is intended to form part of an ecosystem of interconnected zero-knowledge chains.

XLA has a total supply of 1,000,000,000 assets. The entire token supply was minted at deployment, and no additional tokens are issued on an ongoing basis. The full supply was minted at deployment on 29 August 2026 on Ethereum mainnet at 0xa24c70209c857cb5a5a0ff0758a6f50000233d2f. XLA is also supported on the Xsolla ZK Chain as its base token. The XLA available on the Xsolla ZK Chain represents the same XLA originally issued on Ethereum Mainnet, with the corresponding XLA locked on Ethereum Mainnet.

XLA is intended to be used to pay transaction fees on the network and supports staking, network incentive mechanisms and governance participation as the network progressively decentralises.

Xsolla

https://xsolla.org/

2026-11-10

2026-11-09

Not applicable

English

ERC-20: DGZVR1P69, Xsolla ZK: XD7S4RNB7

MC9P0SP20

FALSE

TRUE

TRUE

Not applicable, holders do not, solely by acquiring or holding XLA, acquire any ownership interest, equity interest, entitlement to profits, repayment rights, redemption rights, or compensation rights against Xsolla, Matter Labs, the Xsolla ZK network, or any other natural or legal person. Holding XLA does not create any contractual claim against the issuer or any other person.

XLA holders are only granted non-contractual functionalities and utilities, including the potential ability to pay network transaction fees, participate in staking mechanisms, access governance participation as the network progressively decentralises, and become eligible for ecosystem incentive programs and other protocol functionalities, where applicable and when operational. These functionalities are further described in Section F.2.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable

FALSE

Not applicable

TRUE

The transferable form of the XLA token is intended to be admitted to trading on Kraken and Bitvavo. Following admission to trading, holders will be able to purchase and sell the transferable XLA token in accordance with the platforms’ applicable trading rules, account requirements and supported trading pairs. The trading price of XLA on trading platforms will be determined by market supply and demand.

The non-transferable form of XLA made available through Xsolla Pay Station cannot be sold, transferred or traded by the holder and is therefore not capable of secondary-market trading. It may only be held and used for its intended functionality within the Xsolla ZK ecosystem.

The XLA token contract on Ethereum does not restrict transfers between holders. The non-transferable form of XLA made available through Xsolla Pay Station cannot be transferred, sold or traded by the purchaser.

FALSE

Not applicable

FALSE

Not applicable

FALSE

Not applicable

There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

Xsolla ZK is a sovereign Layer 2 zero-knowledge rollup built on Ethereum. It is a permissionless blockchain designed as gaming-focused infrastructure in which player reputation, rewards and asset ownership operate across multiple games and publishers rather than remaining confined to separate game economies. The network is built with ZK Stack, a modular framework for deploying EVM-compatible zero-knowledge rollups, and is powered by ZKsync OS the operating system of the ZK Stack introduced in the Atlas upgrade. Xsolla ZK forms part of the Elastic Chain, the expanding cluster of interconnected ZK rollups powered by ZKsync.

The ecosystem comprises three tightly connected components: the ZK-rollup layer, the application layer and the XLA token. The ZK-rollup layer provides the blockchain infrastructure, covering transaction execution, proof generation, data availability and Ethereum settlement.The application layer provides developer-facing and player-facing tools, principally the Xsolla Publisher Suite, whose Web3-enabled products include Backpack, a universal gaming inventory management system with an embedded smart wallet, and PayStation, a payment processing solution handling fiat-to-crypto and crypto-to-fiat conversion. XLA, the third component, ties the ecosystem together as the base token of the network, used to pay gas fees, and intended to support staking, network incentives and governance through separate contracts as the network develops. This structure places the blockchain layer below a set of user-facing services, so that game developers can integrate blockchain functionality while users interact through interfaces closer to traditional gaming and payment products.

As a sovereign zk-rollup, Xsolla ZK maintains its own governance and token economy while retaining native connectivity with other ZK Stack rollups for asset and data transfers. All rollup state transitions are expressed as zero-knowledge proofs, providing cryptographic evidence that each transaction sequence was executed correctly. Ethereum smart contracts verify those state transitions, so the rollup inherits Ethereum security and finality for verified rollup history: any attempt to revert the rollup's history would require reverting Ethereum's history itself. Data availability is anchored on Ethereum, where the information necessary to reconstruct the rollup state is published, allowing any participant to rebuild the Layer 2 state and verify correctness without relying on a central operator. The data-availability model is described in H.2.

Networking, transport and session

Xsolla ZK uses a rollup networking model in which users submit transactions to a sequencer, the sequencer orders and executes those transactions in the Layer 2 virtual machine, and compact batch data is posted to Ethereum. The sequencer therefore acts as the main transaction-ingress and ordering component at the rollup level. For censorship resistance, users can also submit transactions directly through Ethereum Layer 1, which provides an alternative inclusion path if direct Layer 2 submission is unavailable or blocked.

The sequencer processes and orders incoming transactions using the x86 runtime of ZKsync OS. It is optimised for low latency and high throughput, with a documented performance profile above 15,000 transactions per second on ERC-20 benchmarks and sub-second confirmation latency, typically around 500 milliseconds. The sequencer's modular design separates execution, API and proving layers, allowing future upgrades such as decentralised sequencing and dynamic fee models.

Serialisation

Xsolla ZK executes within ZKsync OS execution environments that are initially fully EVM-equivalent, providing developer compatibility with standard EVM tooling, including Foundry, Hardhat and solc. The available materials therefore support an EVM-equivalent execution description, but they do not provide a transaction-envelope specification, ABI encoding statement, receipt schema or event-log serialisation rule specific to Xsolla ZK.

Cryptography and key formats

Xsolla ZK relies on zero-knowledge proofs to verify rollup execution. Rollup state transitions are expressed as succinct cryptographic proofs of correct computation, and additional events, including Layer 2 to Layer 1 messages and asset withdrawals, are derived from verified state transitions. The cryptographic foundation comprises STARKs, meaning scalable transparent arguments of knowledge, and SNARKs, meaning succinct non-interactive arguments of knowledge. These proof systems provide compact, efficiently verifiable evidence that off-chain execution followed the required rules.

The proving module generates zero-knowledge proofs of transaction correctness using the RISC-V build of ZKsync OS within the Airbender prover. Proofs are submitted to the Layer 1 verifier contract, which checks validity and finalises the corresponding state transition. Verification is binary: a valid proof finalises the state and an invalid proof is rejected, so no trust in sequencers, provers or validators is required beyond mathematical soundness.

Ledger

The Xsolla ZK ledger is implemented as an Ethereum zk-rollup. Transactions execute off Ethereum, compact data is submitted back to Ethereum, and validity proofs mathematically verify that off-chain computations were correct before finalisation on Ethereum. This reduces transaction cost while maintaining Ethereum-level trust and verifiability for finalised rollup state.

Data availability is ensured by publishing all information necessary to reconstruct the rollup state directly on Ethereum. Rather than posting every raw transaction, ZK Stack employs a state-diff model in which only the minimal changes to the rollup's Merkle state tree are published. This design reduces calldata costs while allowing any participant to independently rebuild the full Layer 2 state from Layer 1 data alone, eliminating data-withholding risks.

The rollup connects to Ethereum through Layer 1 smart contracts. The DiamondProxy, also referred to as the ZKsync Chain contract, is the central coordination contract between Ethereum and Xsolla ZK: it verifies validity proofs, checks data availability, finalises Layer 2 state transitions and manages Layer 2 to Layer 1 messaging and token bridging lifecycle operations. The ValidatorTimelock implements a security delay before batch execution finalises on Layer 1, providing a time buffer for potential challenges or interventions in case of malicious activity. The SharedBridge stores Ether and ERC-20 tokens for all ZKsync chains and enables communication and asset transfers between rollups built with ZK Stack.

Execution

ZKsync OS defines the state transition logic for Xsolla ZK and executes transactions within modular execution environments. Its core components are the bootloader, which initialises the system and orchestrates transaction execution; the execution environments, interpreters that run smart contracts and system logic and are initially fully EVM-equivalent; and the system layer, which handles memory management, input and output operations, and Layer 1 messaging between Ethereum and the rollup.

Execution and proof generation share a single Rust codebase compiled to two targets: x86 for transaction execution within the sequencer runtime and RISC-V for proof generation within the Airbender prover. This single-codebase design guarantees that what is executed is precisely what is proven, eliminating discrepancies between runtime behaviour and proof generation.

Token standards

XLA is the native gas token for the Xsolla ZK Layer 2 blockchain. It is required for all network transactions, used in reward flows and expected to support governance participation as the network decentralises and to be used for staking. XLA is therefore a native and coordination asset for the Xsolla ZK network rather than a separate application-only reward point.

The Xsolla ZK smart-contract repository also includes ERC-7579-compliant ZKsync single sign-on contracts for modular smart accounts, extending the ERC-7579 reference implementation with Xsolla-specific enhancements. These contracts integrate with Xsolla Web3 product contracts and are designed for authentication, session management and transaction processing in gaming and digital commerce applications. ERC-7579 is used here as a modular smart-account standard, not as the native XLA token standard.

Permits, approvals and compliance

XLA is intended to be used for gas, staking, rewards and governance, and that the modular smart-account contracts support account abstraction, single sign-on authentication, session management, and validator and executor modules. PayStation embeds know-your-customer and anti-money-laundering compliance mechanisms where required at the application layer, and Backpack supports both custodial and non-custodial configurations to fit different compliance and user-experience needs.

External APIs

The application layer exposes developer-facing and player-facing services, principally through the Xsolla Publisher Suite. Xsolla ID provides a unified identity system connecting user accounts across Web2 and Web3 environments and is positioned as the gateway for access to Xsolla products, including Backpack, PayStation and Webshop. The Item Game Store is an Xsolla-managed database of game-item data that serves as the source of truth for the other Publisher Suite applications; ecosystem developers can use its APIs to manage digital assets, offers and purchases. The Backpack SDK allows game developers to embed inventory and wallet functionality directly into game clients, and further developer SDKs simplify integration of blockchain functions such as minting, transfers and rewards into existing game backends.

Third-party developers can build and deploy their own decentralised applications on the permissionless network and integrate with Xsolla services such as Xsolla ID and PayStation. All blockchain interactions, including those of third-party applications, require gas payments in XLA, but developers retain flexibility in how these costs are handled: users can pay gas directly, applications can subsidise gas up to configurable limits, or applications can accept other supported tokens and internally convert them to XLA to cover transaction fees. A grants program is planned to support projects built on the network. These interfaces form the application and ecosystem access layer; they do not replace the rollup consensus, proof-generation or Ethereum settlement processes.

Implementation and architecture

Xsolla ZK is an Ethereum zk-rollup with application-layer services and Web2-facing interfaces built on top. The main actor groups are ecosystem developers, application users, sequencers and provers. Ecosystem developers build tooling or applications on Xsolla ZK, including the Xsolla product teams as developers of the Publisher Suite applications. Users interact with those applications and tools, including game developers and publishers as users of the Publisher Suite. Sequencers and provers maintain the core zk-rollup by ordering, processing and batching transactions and by computing and submitting zero-knowledge proofs.

The ZK-rollup layer supplies the EVM-compatible blockchain infrastructure for scalability, data availability and security. The application layer contains the developer and player tools described in H.2, including reward distribution systems, Backpack asset management and payment rails connected to fiat infrastructure. XLA creates value flows from publishers and users to sequencers and provers and intends to support gas payment, staking and network incentives.

Runtime and build parameters

ZKsync OS supplies EVM-equivalence, consistent logic across sequencer and prover through the single-codebase model described in H.2, and developer compatibility with standard EVM tooling. The sequencer executes transactions using the x86 runtime, while the prover generates proofs using the RISC-V build. The prover is designed for efficient proof generation on a single consumer-grade graphics processing unit, an extremely low proof cost per transaction of as little as 0.00013 United States dollars per ERC-20 transfer, and recursive aggregation enabling batch-level and block-level proofs.The time to Ethereum finality varies with batch formation, proof generation, the execution delay and network activity, and may be several hours. The execution delay enforced by the ValidatorTimelock contract on Ethereum, which is set by the owner of that contract and may change. Withdrawals to Ethereum cannot complete until the delay has elapsed.

The Xsolla smart-account implementation is primarily Solidity-based and uses Foundry tooling in the repository workflow. The repository identifies ERC-7579-compliant ZKsync single sign-on contracts, modular smart-account functionality, validator and executor modules, account abstraction, and Xsolla Web3 product integration. The same repository states that the factory and module interfaces are not yet stable and that the code is currently under audit.

Dependencies

Xsolla ZK depends on ZK Stack, ZKsync OS, the Airbender prover, Ethereum Layer 1 smart contracts and Xsolla application services. ZK Stack provides the modular framework for EVM-compatible zero-knowledge rollups. ZKsync OS defines execution and proving logic. The Ethereum smart contracts verify proofs, finalise rollup state transitions, manage asset transfers and message passing, and enforce data availability and fraud prevention rules.

The interoperability and proving roadmap includes the ZKsync Gateway and the Lagrange Prover Network. The Gateway is a shared proof and communication layer that aggregates proofs from multiple rollups into a single batched proof submitted to Ethereum, substantially reducing Layer 1 gas costs while keeping assets and deposits secured on Ethereum and preserving direct Layer 1 to Layer 2 interactions through Ethereum smart contracts. Proof aggregation through the Gateway adds a slightly longer Ethereum-level finality, but interoperability finality between Gateway-connected chains is achieved faster, since chains can mutually recognise state as finalised once a proof is verified within the shared Gateway environment.

Layer 2 proving and data availability

Proving in Xsolla ZK follows the standard ZK Stack pipeline. Provers receive transaction batches from sequencers, execute batch computations, derive the resulting state and generate SNARK proofs. These proofs are submitted to the Layer 1 verifier contract, which checks validity and finalises the corresponding state transition, and provers receive rewards when their proof is accepted by the smart contract. Data availability follows the Ethereum-anchored state-diff model described in H.2.

Token deployment and addresses

XLA is deployed on Ethereum mainnet as an ERC-20 token behind a transparent upgradeable proxy. The proxy contract address is 0xa24C70209C857cb5a5a0ff0758a6F50000233D2F and the implementation contract address is 0x7aaCBc456D517c8EB10Cd534Bde3E688e899A93E. The ChainAdmin contract for Xsolla ZK is at 0xA93e761C72223d0A548c30f18Dc71d3A7de61c81. The full supply of 1,000,000,000 XLA was minted at deployment. On Xsolla ZK, XLA is the base token and is accessed as the native currency at 0x000000000000000000000000000000000000800A. Under the ZK Stack design, the choice of base token is made when the network is created and cannot be changed afterwards. A custom base token must be added to an allowlist held in the Bridgehub contract on Ethereum before a network can use it, and XLA was added to that allowlist for Xsolla ZK. Units of the base token on Xsolla ZK must be backed by the same number of units locked on Ethereum. The Xsolla ZK block explorer is https://zksync-os-mainnet-xsolla.explorer.zksync.dev. XLA is required to pay gas fees for all transactions on Xsolla ZK.

Client interfaces and SDKs

The Publisher Suite connects Web2 game ecosystems with blockchain infrastructure and is designed to let developers use blockchain features without sacrificing user experience. Backpack operates as a multi-asset wallet that stores in-game items, currencies and non-fungible tokens under one interface, supports both custodial and non-custodial configurations, and integrates with PayStation for fiat on-ramps and off-ramps. Open software development kits are expected to support developer integration with Xsolla ZK, and the gas-payment flexibility described in H.2 keeps gas demand tied to XLA while preserving design freedom at the application layer.

Xsolla ZK will launch as a ZK-rollup with sequencing operated by the Xsolla team and proving managed by Xsolla and ZKsync proving services. This early model prioritises performance, compliance and user-experience quality during network bootstrap and allows efficient upgrades and rapid iteration. During this initial period, Chain governance, including authority over protocol upgrades, parameter changes and emergency response, is directed by the Xsolla ZK Foundation. Sequencing is operated by the Xsolla team and proving is managed by Xsolla and ZKsync proving services, as technical functions performed under the Foundation's direction; the network is not decentralised at the technical level during this phase.

The long-term consensus roadmap is based on ChonkyBFT, a proof-of-stake, committee-based Byzantine Fault Tolerant protocol with a single round of voting and single-slot finality, which is currently under active development. In this model, sequencers participate in consensus through stake and committee selection. Sequencers with larger stakes have greater participation in consensus and earn a higher share of rewards, misbehaving sequencers can be penalised through stake slashing, and the protocol may enforce a minimum staking threshold to become an active sequencer as well as limit the total number of active sequencers.

The planned decentralised sequencing model uses XLA as the staking asset. Token holders will be able to stake XLA to become sequencers or delegate to other sequencers. Decentralised sequencing employs a consensus algorithm to determine transaction inclusion and ordering, which may introduce additional latency compared with a centralised setup but significantly strengthens censorship resistance, liveness, trust minimisation and operational resilience.

Final settlement remains anchored to Ethereum through the rollup proof path. Provers generate zero-knowledge proofs of transaction correctness, and Ethereum smart contracts verify those proofs and finalise the related state transitions. Once a proof is accepted by the rollup smart contract on Ethereum, the corresponding state transition becomes final and immutable.

Network-level execution fees

Because Xsolla ZK uses a base token other than ETH, the fee charged in XLA for the Ethereum settlement cost of each batch is derived from a ratio between the price of ETH and the price of XLA. That ratio is held on Ethereum and set through the ChainAdmin contract, by its owner or by an address it nominates, and is updated periodically by the network operator. A ratio that is out of date can cause fees to be set too high or too low relative to the cost of posting data to Ethereum.

XLA is the sole native currency required to pay gas fees for all transactions on Xsolla ZK. Gas fees are therefore the principal network-level fee mechanism and create transaction-linked utility for the token. Ecosystem developers may decide whether the end user pays gas directly, whether the application subsidises gas up to configurable limits, or whether the application accepts another supported token and converts internally to XLA to cover transaction fees.

The fee model links network demand to sequencers, provers and the Xsolla ZK Treasury. In a mature zk-rollup system, sequencer rewards are expected to derive primarily from gas fees collected from users minus prover-related costs. While Xsolla operates the single sequencer during the initial phase, the Treasury receives the net of gas fees collected minus the Layer 1 fees paid for posting transaction data to Ethereum. During the early stages, gas-fee revenue alone is not expected to compensate a robust and geographically distributed sequencer set, so Xsolla ZK adds a temporary sequencer reward allocation funded by a dedicated token-emission schedule.

Protocol-level fees and economic flows

XLA is intended to be used for transaction gas, developer tiering, incentive rewards, loyalty, decentralised sequencer staking and governance participation. Game developers can stake XLA to access tiered infrastructure services with commercial benefits, including increased API rate limits on the Publisher Suite and reduced platform fees. XLA also operates as the rewards engine for users and game developers, incentivising behaviours such as transaction volume and active gameplay, and supports value flows to sequencers and provers.

The XLA buyback mechanism is programmatic and performance-based. A predetermined share of net revenue generated from the platform's proprietary advertising technology is allocated to systematic open-market purchases of XLA. The percentage allocated to buybacks adjusts dynamically by comparing the actual XLA price, calculated as a time-weighted average, against a predefined target token price, within programmatic maximum, minimum and default percentage boundaries. The initial parameters are set by the founding team, and ongoing changes to the buyback policy are subject to an annual governance vote. Purchased tokens are not immediately burned: they are collected and programmatically redistributed to users, developers and sequencers, with the community retaining the collective power to adopt a different long-term strategy, including a potential decision to burn tokens once the ecosystem reaches maturity, estimated around the four-to-five-year mark.

Sequencer and prover incentives

Sequencer incentives combine standard gas-fee-based revenues with additional XLA emissions during the network's early growth phase. A fixed amount of XLA is allocated for sequencer rewards in each epoch, independent of gas fees. Sequencer rewards are funded from a dedicated allocation of the existing 1,000,000,000 XLA supply. No new XLA is issued.

Sequencer rewards are stake-weighted and activity-adjusted. A sequencer's maximum possible reward in an epoch is proportional to its stake relative to the total stake of all active sequencers. To receive the full stake-weighted reward, the sequencer must propose blocks when selected as leader, attest to blocks when part of the committee, and remain online and responsive; imperfect participation reduces the reward proportionally. Missed rewards are not redistributed to other sequencers, a design choice that prevents perverse incentives such as collusion to ignore attestations or strategic exclusion of committee members. Undistributed rewards are returned to the Xsolla ZK Treasury, where they may be reused for future incentive programs through a governance decision.

Provers receive XLA rewards when their zero-knowledge proof is accepted by the smart contract. The proving layer starts with Xsolla and ZKsync proving services and later moves toward decentralised proving in which independent prover nodes compete to generate proofs. That transition depends on protocol development by Matter Labs, a third party, and has no fixed timetable.

Parameter governance and disclosure

Governance is organised around three bodies. The Security Council evaluates and approves protocol upgrades, initiates emergency upgrades and can implement graduated freeze mechanisms in the event of security threats; it is also mandated to commission regular, independent security and IT audits of the protocol and supporting infrastructure. The Token Council manages the XLA token contract and the economic levers of the Xsolla ZK chain, including monetary policies, token supply management, treasury optimisation, protocol gas-fee settings and other token-related parameters. The Token Community consists of XLA tokenholders who delegate voting power to XLA Delegates for proposals related to token-distribution programs and ecosystem incentives, and holds veto rights over Council decisions.

Proposal and voting parameters are published: submitting a proposal will require staking 10,000 XLA and advancing a proposal to a formal vote requires 100,000 XLA, with thresholds denominated solely in XLA, reviewed annually and modifiable through governance. The process follows a bias-to-action model in which Council proposals pass by default unless vetoed within a predetermined period; a veto requires a minimum quorum of 15% of delegated XLA and a 66% majority of participating votes, and a subsequent appeal to overturn a veto requires a 20% quorum and a 75% supermajority.

Governance decentralisation is phased. From launch to month 36, Chain governance authority, including direction of the Security Council and the Token Council, is held by the Xsolla ZK Foundation. Xsolla ZK, Inc. and Matter Labs perform sequencing, proving and operational functions during this period under the Foundation's direction; sequencing and proving are not decentralised at the technical level.. Between months 36 and 48, the roadmap introduces the transition to ChonkyBFT consensus for multi-operator sequencing secured by XLA staking, the transition of proving workloads toward independent operators through the Lagrange Prover Network, and iteration of the proposal and voting processes. After month 48, governance authority is intended to move to a community-driven model through the Security Council, Token Council and XLA Token Community.

TRUE

XLA is recorded on two ledgers. Issuance, transfer and storage on Ethereum are governed by Ethereum consensus and by the code of the XLA token contract. Issuance, transfer and storage on Xsolla ZK are governed by the Xsolla ZK rollup, which is operated by or on behalf of the issuer as described below.

Issuance

XLA is the native gas token for the Xsolla ZK Layer 2 blockchain, and the Token Council oversees ongoing management of the XLA token contract and the economic levers of the Xsolla ZK chain. Chain governance is directed by the Xsolla ZK Foundation, with Xsolla ZK, Inc. and Matter Labs performing the technical function described under the Foundation's direction.. Issuance and token-contract stewardship therefore occur within a DLT and governance framework operated by the issuer or appointed technical counterparties during the initial phase.

Transfer

XLA is required for all transactions and interactions with the blockchain as gas payment, and Xsolla ZK transactions are submitted to the sequencer, executed within the Layer 2 virtual machine, aggregated into batches and posted to Ethereum. Initially, sequencing is operated by the Xsolla team and proving is managed by Xsolla and ZKsync proving services, so transfers occur through a DLT stack operated by the issuer and an appointed technical counterparty during the initial phase.

Storage

XLA holdings exist as entries in the Xsolla ZK rollup state, and storage of that state occurs on infrastructure operated by the issuer and its appointed technical counterparties during the initial phase. The Layer 2 state is maintained and updated by the sequencer operated by the Xsolla team, finalised through validity proofs generated by Xsolla and ZKsync proving services, and anchored on Ethereum, where all information necessary to reconstruct the rollup state is published. The Ethereum contracts through which storage is finalised — the DiamondProxy, which verifies validity proofs, checks data availability and finalises Layer 2 state transitions, and the SharedBridge, which stores Ether and ERC-20 tokens for ZKsync chains — operate under a governance framework in which upgrade and emergency authority is exercised primarily by Xsolla and Matter Labs during the initial phase. Storage of holdings therefore occurs within a DLT stack operated by the issuer and appointed third parties before progressive decentralisation.

The Xsolla ZK DLT operates as a ZK-rollup built on Ethereum, with sequencing, proving and governance during the initial phase operated by the Xsolla team, Xsolla and ZKsync proving services, and Xsolla together with Matter Labs, as described in H.4.

Every transaction follows the same lifecycle. The user submits the transaction to the sequencer, which orders and executes it within the Layer 2 virtual machine using the x86 ZKsync OS runtime, computes the new state and provides soft confirmation to the user for near-instant feedback. The sequencer then aggregates transactions into a batch and posts compact batch data, comprising state diffs and state commitments, to Ethereum. The prover executes the batch off-chain, computes the resulting Layer 2 state and generates a zero-knowledge proof attesting to its correctness. The proof is submitted to the rollup smart contract on Ethereum, which verifies it, confirms the completeness of the batch data and finalises the new Layer 2 state, sealing the transaction outcome. For censorship resistance, users can alternatively submit transactions directly via Ethereum, guaranteeing inclusion.

The Ethereum smart-contract layer coordinates finality, data availability, proof verification and cross-rollup communication through the DiamondProxy, ValidatorTimelock and SharedBridge contracts described in H.2, with Ethereum serving as the public data-availability anchor under the state-diff model. Cross-chain interoperability with other ZK Stack chains is provided through the ZKsync Gateway, which enables trustless message passing, asset transfers and data exchange between ZKsync OS chains while retaining Ethereum as the ultimate security and settlement layer.

The decentralisation roadmap set out in H.4 and H.5 transitions sequencing to ChonkyBFT-based multi-operator consensus secured by XLA staking. Emergency and upgrade controls sit within the governance framework described in H.5, under which the Security Council holds protocol-upgrade, emergency-upgrade and graduated freeze powers, the Token Council manages the XLA token contract and economic parameters, and the Token Community provides delegated voting and veto oversight. Initial operational control is therefore centralised, with authority intended to move progressively toward XLA tokenholders and delegates.

FALSE

No independent security audit of the Xsolla Gas Token smart contract has been published at the date of this white paper. The audits referred to below relate to the underlying ZKsync protocol and not to the token contract. Audits and security reviews exist for the underlying ZKsync technology stack used by Xsolla ZK, including the ZKsync Gateway, ZKsync OS, the ZKsync protocol contracts and the Airbender prover. These reviews cover bridging, chain migration, protocol contracts, the ZKsync OS implementation and proof-related infrastructure, and the ZKsync OS repository maintains a series of successive security reviews across versions by multiple independent firms. The Xsolla-specific smart-account contract repository remains under audit and carries an express caution that the factory and module interfaces are not yet stable and may need to be updated in the final version.

The Security Council governance design also mandates regular, independent security and IT audits of the protocol and supporting infrastructure, with findings formally addressed by the Security Council under a clear action plan and remediation timeline. This establishes an ongoing audit requirement for the Xsolla ZK governance framework in addition to the completed ZKsync-stack audits already available.

Audit outcome

Audittens – ZKsync Gateway Audit – December 2024

• Object: The audit, commissioned by the ZKsync Security Council Foundation, reviewed ZKsync's bridging and chain-migration protocol. The reviewed codebase was the Matter Labs era-contracts repository at commit 7198b54fbcba37aa7a1dd75fc3067391af33e03e. The scope included data-availability contracts, bridge contracts, asset-router components, native-token-vault components, bridgehub contracts, governance restrictions, state-transition contracts and Layer 2 data-availability validators.
• Results: The report recorded 62 findings in total, consisting of 1 critical, 7 high, 3 medium, 11 low and 40 informational findings. The status table recorded 51 fixed findings, 1 partially fixed finding and 10 acknowledged findings.
• Actions: The audit was finalised after the ZKsync team completed a fix period and after Audittens reviewed the corresponding commits. The critical, high and medium findings were recorded as fixed. Certain low and informational findings were acknowledged or partially fixed.

OpenZeppelin – ZKsync Protocol Defense Audit – September 2024

• Object: The audit covered Layer 2 Solidity and Yul code in Pull Request 524 of the Matter Labs era-contracts repository at commit 1957571. The scope included bridge, bridgehub, governance, state-transition, upgrade, Layer 2 contract and system-contract components, with an additional diff audit of later repository changes.
• Results: The report recorded 27 total issues. No critical, high or medium severity issues were identified. Three low-severity issues were recorded, with two resolved and one partially resolved. 24 notes and additional-information items were recorded, with 18 resolved and two partially resolved.
• Actions: The final audited state of the codebase was identified at commit 874bc6b. The report concluded that the reviewed changes were well written, straightforward to follow and well documented.

Hexens – Security Review Report for ZKsync (Airbender) – August 2025

• Object: The review covered the ZKsync Airbender resources in the Matter Labs zksync-airbender repository audit branch at commit a10cb1d4e38652eac4fcb4593bfc261d26527a98. Airbender is the prover used in the ZKsync OS proving architecture.
• Results: The review recorded one informational finding and no critical, high, medium or low findings. The identified issue concerned a redundant assertion in the add-constraint function.
• Actions: The issue was acknowledged.

OpenZeppelin – ZKsync OS Audit – September 2025

• Object: The audit assessed the Matter Labs zksync-os repository in a two-part engagement, first at commit 96d9d37 and subsequently at commit 0563213, covering the Rust implementation of the ZKsync OS state transition function, including the bootloader and system components.
• Results: The report recorded 22 total issues, consisting of 3 critical, 1 high, 3 medium and 9 low severity issues plus 6 notes and additional-information items. All critical and high severity issues were resolved; overall, 16 issues were resolved and 1 partially resolved.
• Actions: Fixes were implemented by the Matter Labs team and verified by the auditors in the corresponding pull requests and commits recorded in the report.

Audittens – ZKsync OS Security Review – May 2026

• Object: The review covered components of the ZKsync OS implementation and the changes introduced between versions 0.1.0 and 0.3.0, excluding changes related to the Ethereum state-transition function. A team of three security researchers reviewed the code over eleven weeks between December 2025 and May 2026. ZKsync OS is the system-level implementation that defines the state-transition function for ZKsync's architecture.
• Results: The report recorded 72 findings in total, consisting of 1 critical, 4 high, 5 medium, 17 low and 45 informational findings. The status table recorded 60 fixed findings and 12 acknowledged findings.
• Actions: The review was finalised after the fix period by reviewing the corresponding commits. The limitations section notes that later changes may introduce new vulnerabilities and require separate review. Links: ZKsync OS Security Review (v0.1.0 to v0.3.0) PDF.

Market volatility and liquidity

The transferable form of XLA, admitted to trading on Kraken and Bitvavo, may experience significant price volatility due to market sentiment, technological developments, governance outcomes, macroeconomic conditions and broader digital-asset market conditions. Limited liquidity or the absence of active secondary markets may make it difficult to buy or sell the transferable form at desired times or prices and may increase price volatility. Price volatility may occur independently of protocol performance. The non-transferable form of XLA acquired through Xsolla Pay Station is not subject to this risk: it is fixed at USD 1.00 per token and cannot be traded, so its nominal value does not fluctuate with market conditions.

Exchange access and listing risk

The admission of XLA to trading on Kraken is expected following publication of this white paper and is subject to Kraken's listing arrangements and rules. Admission to trading on any other trading platform has not been confirmed. There is no guarantee that an active secondary market will develop or be sustained. Listing timing, venue policies, exchange onboarding and liquidity arrangements may affect access, market depth and price discovery.

Large unlock and initial liquidity risk

The entire XLA token supply is unlocked and freely transferable or distributable from the token generation event, with no allocation category, including the Foundation allocation, the Family Trust allocation, and the allocations associated with the public offer and admission to trading, currently subject to any lock-up or vesting schedule. The absence of any lock-up across the full supply materially increases the risk of concentrated selling pressure immediately following launch, rapid simultaneous market entry of supply, and resulting price volatility and reduced market stability, with no phased-release mechanism to offset it.

Transaction finality and irreversibility

Xsolla ZK transactions are finalised when the relevant proof is submitted to the Ethereum rollup smart contract, verified, and the new Layer 2 state is finalised on Ethereum. Once the transaction outcome is finalised through this process, erroneous or fraudulent transfers cannot be reversed at protocol level, and any corrective outcome requires a separate transaction controlled by the relevant private keys. Finality on Ethereum is reached only after batch commitment, proof verification and the execution delay, which can take several hours. Until then, a transaction has been confirmed by the sequencer but is not final on Ethereum.

Wallet and key custody risk

Interaction with Xsolla ZK requires a compatible wallet, and Backpack operates as a multi-asset smart wallet supporting both custodial and non-custodial configurations. In non-custodial configurations, loss or compromise of private keys or recovery credentials results in permanent loss of control over XLA and associated digital assets, as protocol rules cannot restore access. In custodial configurations, holders bear counterparty and operational dependence on the custody provider. Errors in wallet use, transaction signing or account access may equally impair a holder's ability to manage XLA. In addition to Backpack, the issuer intends to host a web interface allowing users and developers to connect third-party self-custodial wallets directly to the Xsolla ZK network. This functionality is not yet live. Where holders interact with the network through such third-party wallets, the same non-custodial key-loss risks described above apply, and Xsolla has no ability to restore access to funds held in a wallet it does not control.

Centralised bootstrap and governance concentration

During the bootstrap and initial governance phases, governance authority is exercised primarily by the Xsolla ZK Foundation, and key governance decisions, council appointments and emergency powers are centrally coordinated. The Foundation’s sole director is also the sole owner of Xsolla ZK, Inc. The protocol is not decentralised during this period, which limits the practical influence of token holders and creates dependency on a limited number of actors for governance continuity and security oversight.

Emergency intervention and freeze powers

During the initial phase, emergency powers sit within a governance framework in which authority and council appointments are coordinated primarily directed by the Foundation; the Security Council that holds these powers is constituted under that framework rather than independently of the Foundation or the issuer. The Security Council can initiate emergency upgrades and graduated freeze mechanisms in response to critical vulnerabilities, bugs or severe security threats. These powers may temporarily restrict protocol operations, limit access to certain functions, affect user activity and token utility, or delay governance processes during the intervention period.

Token Council economic discretion

The Token Council oversees the XLA token contract, monetary policies, token supply management, treasury optimisation, protocol gas-fee settings and other token-related parameters. During the initial phase this body is run centrally by the Foundation and the Xsolla team, creating a risk that economic settings material to holders may be adjusted by a concentrated governance body before full decentralisation.

Governance capture and delegation concentration

XLA governance is token-weighted, and the Xsolla ZK Foundation holds the largest single position, representing 40% of the total supply, and directs governance of the chain during the initial phase.. The Foundation's holding and its direction of council appointments may therefore exert disproportionate influence over protocol upgrades, parameter changes, treasury allocations and council composition. More broadly, significant holders, coordinated voting blocs or influential delegates may produce outcomes that primarily benefit large holders, voting power may concentrate among a small number of delegates, and delegates may not act in line with the preferences of their delegators, so effective oversight requires active monitoring by token holders.

Conflicts of interest and accountability risk

Council members, delegates and core team members may hold financial, advisory or operational interests in entities that interact with or are affected by Xsolla ZK decisions. Failure to disclose or manage such conflicts could undermine objective decision-making, proposal fairness and token-holder confidence.

Regulatory and multi-jurisdictional exposure

The issuer is incorporated in the United States while seeking admission to trading of XLA in the European Economic Area, and the ecosystem it operates spans multiple jurisdictions, including payment and fiat-conversion services provided through the application layer. The legal and regulatory treatment of crypto-assets remains uncertain and continues to evolve across these jurisdictions. Future legislation, regulatory guidance or enforcement action, including any divergent classification of XLA under non-EU regimes, may restrict or affect the issuance, distribution, trading or governance utility of XLA and may impose operational constraints, compliance obligations or additional costs directly on the issuer.

Utility and demand dependency

XLA is required as the native gas token for all transactions on the Xsolla ZK network, and demand for XLA therefore depends materially on actual usage by players, game developers, sequencers, provers and applications. Weaker adoption than anticipated would reduce transaction volume, token utility and organic market demand. The network is at an early stage and current usage is limited. Demand for XLA as gas is at present small relative to its total supply and depends on future adoption.

Supply, allocation and unlock dynamics

XLA has a total supply of 1,000,000,000 tokens, fully minted at deployment with no ongoing issuance. The full supply is unlocked from the token generation event, and no allocation is subject to a lock-up or vesting schedule. Holdings are concentrated: the Xsolla ZK Foundation, Xsolla ZK, Inc. and a trust of the founder's family together hold the largest allocations. The unrestricted availability of the supply increases the risk of concentrated selling pressure immediately following launch.

Token rights limitations

Holding XLA grants the ability to participate in governance processes but does not grant ownership of protocol assets, claims over treasury reserves, rights to protocol revenue, entitlement to gas-fee distributions, redemption rights against the issuer, liquidation preference or equity participation. Holders may therefore lose all economic value without any residual claim against the issuer or protocol assets, and governance participation creates no fiduciary duties between token holders or between token holders and the issuer.

Staking and slashing exposure

Under the planned proof-of-stake model, sequencers participate in a mechanism in which larger stakes confer greater consensus participation and reward share, and misbehaving sequencers can be penalised through stake slashing. Stakers, sequencers and delegators may therefore suffer reduced rewards for imperfect participation or loss of staked value if protocol rules are breached.

Dual representation and bridge backing risk

XLA exists as an ERC-20 token on Ethereum and as the base token of Xsolla ZK. Units on Xsolla ZK exist only while the same number of units remain locked in the bridge contracts on Ethereum. A vulnerability, malfunction or upgrade affecting the bridge contracts, the Ethereum token contract or the Layer 2 base-token system contract could prevent deposits or withdrawals, separate the two representations or cause units on Xsolla ZK to lose their backing. Withdrawals are finalised only after the relevant proof is verified on Ethereum and the batch execution delay has elapsed, so holders cannot exit immediately. A suspension of transfers of the Ethereum token contract would also prevent the bridge from receiving or releasing XLA. The choice of XLA as the base token is made at network creation and cannot be reversed.

Pre-launch network status

The XLA token contract has been deployed on Ethereum mainnet and the Xsolla ZK mainnet has been deployed with XLA as its base token. Public operation, the first adoption campaign and the admission of XLA to trading remain future events. The network is newly deployed and has limited operating history. Testnet behaviour may not be representative of mainnet conditions. The offer therefore depends on the successful operation of infrastructure that has not yet operated at scale.

Roadmap and delivery risk

The project roadmap includes phases for the Backpack release, the ZK-rollup alpha test, the token generation event, exchange listings, adoption campaigns and application targets. Except for XLA's core function as the native network token for payment of transaction fees, the roadmap is indicative only and does not constitute a representation or guarantee of future functionality, adoption or development beyond network launch.

Adoption and network-effect risk

The economic design depends on player activity, game-developer adoption, transaction volume and application development, with onboarding driven through Xsolla's existing payments and publisher infrastructure. If adoption by publishers, developers or players is weaker than projected, the network may generate fewer transactions and less organic demand for XLA.

Sequencer and prover decentralisation risk

Xsolla ZK launches with sequencing and proving managed by Xsolla in collaboration with ZKsync, under the Foundation's direction and oversight, with a later transition toward independent sequencers under ChonkyBFT consensus and independent provers. ChonkyBFT remains under active development, and any delay or failure in the transition may prolong operational concentration and affect censorship resistance, liveness and fairness.

Gas-fee calibration risk

The network faces a balancing act in setting gas fees: higher fees increase network revenue but risk deterring users and developers, while fees that are too low may undermine the economic sustainability of the network and sustainable demand for XLA. Miscalibration of this equilibrium may impair adoption or economic viability.

Buyback and rewards program dependency

The buyback mechanism relies on a predetermined share of net advertising-technology revenue and adjusts dynamically against target-price parameters, with purchased tokens redistributed to users, developers and sequencers rather than immediately burned. If revenue, program parameters or governance decisions differ from expectations, buyback activity and redistributed rewards may not provide the anticipated support for token demand.

Third-party and ecosystem dependency risk

Xsolla ZK depends on ZK Stack and ZKsync technology, Ethereum settlement, the Xsolla Publisher Suite, Backpack, PayStation, payment partners and planned proving infrastructure including the Lagrange Prover Network. Failures, delays, policy changes or integration issues affecting these dependencies may impair onboarding, transaction processing, user access or network growth.

Governance implementation risk

The governance model depends on council formation, delegate selection, proposal thresholds, veto mechanisms, council charters and phased decentralisation. Low participation, delayed council formalisation or concentrated delegate activity may affect the timing and quality of governance decisions.

Smart-contract vulnerabilities

Xsolla ZK relies on smart contracts and blockchain infrastructure that may contain vulnerabilities, coding errors, design flaws or unforeseen interactions, and exploits or failures could result in disruption of protocol functionality, governance manipulation or loss of digital assets. The Xsolla ZK smart-account contracts remain under audit, their factory and module interfaces are not yet stable, and the latest code may contain security vulnerabilities.

Ethereum Layer 1 dependency

Xsolla ZK is an Ethereum Layer 2 that uses Ethereum for proof verification, data availability, settlement and Layer 1 to Layer 2 messaging. Ethereum congestion, gas-cost increases, client issues or settlement-layer disruption may delay transactions, increase costs or affect finality for Xsolla ZK users.

Sequencer and prover operational risk

Sequencing is initially operated by the Xsolla team and proving is managed by Xsolla and ZKsync proving services. Outages, misconfiguration or performance degradation in these operators may affect transaction ordering, soft confirmations, proof generation and network liveness during the centralised phase.

Bridge and interoperability risk

Xsolla ZK uses the ZKsync Gateway for interoperability with other ZK Stack chains and the SharedBridge for asset transfers across ZKsync chains. Bridge, gateway, message-passing or proof-aggregation faults may delay transfers, create inconsistent state visibility or extend Ethereum-level finality timing.

Upgrade and admin-contract risk

The network is governed through Ethereum Layer 1 contracts, including the DiamondProxy, ValidatorTimelock and SharedBridge, while the governance framework grants the Security Council powers for protocol upgrades, emergency upgrades and freezes. Incorrect upgrades, misconfigured permissions or misuse of emergency powers may disrupt Layer 2 state transitions, bridging or protocol operations. The XLA token contract on Ethereum is upgradeable. The proxy administrator can replace the token's logic without holder consent, and the pauser role can suspend all transfers. At deployment these powers sat with an externally owned account whose keys are held by a single custodian. Misuse, compromise or loss of the relevant keys, or an incorrect upgrade, could change the rules of the token, freeze transfers or cause loss of value.

Data availability and proof-system risk

The state-diff model publishes minimal changes to the rollup Merkle state tree and allows participants to reconstruct Layer 2 state from Layer 1 data. Defects in state-diff publication, proof generation, proof verification or reconstruction assumptions may impair independent verification or delay finality.

Chain metadata and replay risk

Chain identifiers must remain unique, as duplicate chain identifiers open the door to replay attacks in which a transaction signed for one network is validly re-executed on another. Incorrect chain metadata, reused chain identifiers or wallet configuration errors may expose users to transaction confusion or unsafe cross-network interactions.

Quantum computing risk

Xsolla ZK accounts follow the EVM-equivalent Ethereum account model, in which transactions are signed using the elliptic curve digital signature algorithm over the secp256k1 curve, and the public key of any account that has sent a transaction is exposed on-chain. A sufficiently powerful quantum computer running Shor's algorithm could derive private keys from exposed public keys, enabling forged signatures, theft and impersonation. No quantum computer capable of breaking this cryptography exists today, but the United States National Institute of Standards and Technology anticipates deprecating the algorithm by 2030 and disallowing it by 2035. The exposure extends to the wider stack: Ethereum's validator signatures and certain commitment schemes rely on elliptic-curve constructions vulnerable to quantum attack, and proof systems that depend on elliptic-curve cryptography could require migration, whereas hash-based STARK components used in the cryptographic foundation are considered more resistant. Any transition to post-quantum cryptography across Ethereum, the ZKsync stack and Xsolla ZK involves migration complexity, and holders who fail to migrate keys under an eventual transition framework may face residual exposure.

Offer-Related Risks

• Wallet and key custody risk: Backpack supports both custodial and non-custodial configurations, allowing holders to select the custody model that fits their operational capability and compliance needs, and integrates identity and payment flows through established Xsolla infrastructure. This mitigates operational access risk by providing managed alternatives to direct key handling, without eliminating the underlying custody trade-offs of either configuration.

Issuer-Related Risks

• Centralised bootstrap and governance concentration: Governance of the chain is directed by the Xsolla ZK Foundation under the Chain Governance and Wallet Agreement, with Xsolla ZK, Inc. and Matter Labs performing technical functions under that direction during the initial phase. The Foundation intends to transition to Token Community participation and council iteration between months 36 and 48, and to a community-driven governance model after month 48. This mitigates concentration risk through a staged, published governance transition, subject to successful execution.
• Emergency intervention and freeze powers: Emergency freeze powers are limited to objectively verifiable security threat scenarios, comprising active exploit, smart-contract vulnerability, consensus failure or material systemic risk. Any emergency action must be publicly disclosed within 24 hours, include written justification, specify its scope and duration, and undergo post-event governance review, with intervention powers limited to the minimum necessary to mitigate the risk.
• Governance capture and delegation concentration: The Token Community holds veto rights over Council decisions, exercisable through XLA Delegates within a defined veto period at a 15% quorum of delegated XLA and a 66% majority, with a higher-threshold appeal process requiring a 20% quorum and 75% supermajority. A formal mechanism for the election, rotation and removal of delegates is disclosed, creating a documented check-and-balance on both Councils and on delegate conduct.
• Conflicts of interest and accountability risk: Council members and delegates must disclose actual, potential or perceived conflicts at onboarding and quarterly thereafter, and conflicted members are recused from debate, voting and access to non-public information on the relevant matter, with recusals formally recorded. Non-compliance is grounds for review, suspension or removal subject to Token Community vote, and the conflict policy undergoes annual independent review.

Crypto-Assets-Related Risks

• Staking and slashing exposure: Sequencer rewards are stake-weighted and adjusted by participation, undistributed rewards from inactive sequencers are not redistributed to other sequencers, and unearned amounts return to the Xsolla ZK Treasury. This links reward outcomes to uptime, responsiveness and protocol-compliant behaviour while removing collusion incentives such as strategic exclusion of committee members.

Project Implementation-Related Risks

• Roadmap and delivery risk: Binding token utility is expressly limited to XLA's core function as the native network token for payment of transaction fees, with all further roadmap items designated indicative and speculative. This mitigates over-reliance on future features by contractually distinguishing core functionality from indicative development.
• Sequencer and prover decentralisation risk: The decentralisation roadmap specifies the transition from centralised sequencing and proving to ChonkyBFT-based multi-operator sequencing secured by XLA staking and to independent prover participation, including distribution of up to 75% of proving workloads through the Lagrange Prover Network. This mitigates operator concentration risk if the transition is executed as specified.
• Buyback and rewards program dependency: The buyback mechanism operates under predefined programmatic parameters, including maximum, minimum and default revenue-allocation percentages tied to a time-weighted average price against a target price, with ongoing policy changes subject to an annual governance vote. This mitigates discretionary buyback risk by setting rule-based boundaries and governance oversight for program operation.
• Governance implementation risk: Council charters, fit-and-proper assessments covering expertise, integrity and independence at initial, annual, semi-annual and quarterly review frequencies, conflict-management procedures, published proposal thresholds, and formalised veto and appeal processes are defined in the governance framework. These controls mitigate implementation risk by specifying council responsibilities, member standards and escalation procedures in advance of decentralisation.

Technology-Related Risks

• Smart-contract vulnerabilities: The underlying ZKsync stack has undergone successive independent security reviews, including audits of the Gateway bridging and chain-migration protocol, the protocol contracts, the ZKsync OS implementation and the Airbender prover, in which the identified critical and high-severity findings were remediated and re-verified. Vulnerability reporting for the Xsolla ZK smart-account contracts is routed to the ZKsync bug bounty and security contact, Xsolla operates its own bounty program with defined submission and safe-harbour terms, and the Security Council is mandated to commission regular, independent security and IT audits of the protocol with formally tracked remediation.
• Ethereum Layer 1 dependency: The DiamondProxy verifies validity proofs, checks data availability and finalises Layer 2 state transitions on Ethereum, while the ValidatorTimelock provides a delay before batch execution finalises on Layer 1. These controls mitigate settlement risk by placing proof verification and final state transition on Ethereum and adding a time buffer for potential intervention.
• Bridge and interoperability risk: The SharedBridge stores Ether and ERC-20 tokens for ZKsync chains, and the ZKsync Gateway keeps assets and deposits secured on Ethereum while Layer 1 to Layer 2 interactions continue to execute directly from Ethereum smart contracts. This mitigates additional custody risk in interoperability by retaining Ethereum as the settlement and asset-security layer without adding new trust assumptions.
• Data availability and proof-system risk: All information necessary to reconstruct the rollup state is published on Ethereum under the state-diff model, allowing any participant to independently rebuild and verify the Layer 2 state from Layer 1 data alone. This mitigates data-withholding risk by tying rollup integrity to Ethereum-published data and independent reconstruction.
• Quantum computing risk: The Xsolla ZK smart-account architecture is built on the modular ERC-7579 standard with upgradeable validator modules, enabling signature-verification logic to be replaced at account level without protocol-wide intervention, which is the migration path contemplated for adopting post-quantum signature schemes. Protocol upgrades approved through the Security Council provide the mechanism to adopt post-quantum primitives as the underlying Ethereum and ZKsync stacks implement their post-quantum transitions, with Ethereum targeting core post-quantum infrastructure by approximately 2029. These pathways mitigate transition risk without eliminating the underlying cryptographic exposure prior to migration.

Xsolla ZK, Inc.

Xsolla ZK Token

Xsolla ZK will launch as a ZK-rollup with sequencing operated by the Xsolla team and proving managed by Xsolla and ZKsync proving services. This early model prioritises performance, compliance and user-experience quality during network bootstrap and allows efficient upgrades and rapid iteration. During this initial period, Chain governance, including authority over protocol upgrades, parameter changes and emergency response, is directed by the Xsolla ZK Foundation. Sequencing is operated by the Xsolla team and proving is managed by Xsolla and ZKsync proving services, as technical functions performed under the Foundation's direction; the network is not decentralised at the technical level during this phase.

The long-term consensus roadmap is based on ChonkyBFT, a proof-of-stake, committee-based Byzantine Fault Tolerant protocol with a single round of voting and single-slot finality, which is currently under active development. In this model, sequencers participate in consensus through stake and committee selection. Sequencers with larger stakes have greater participation in consensus and earn a higher share of rewards, misbehaving sequencers can be penalised through stake slashing, and the protocol may enforce a minimum staking threshold to become an active sequencer as well as limit the total number of active sequencers.

The planned decentralised sequencing model uses XLA as the staking asset. Token holders will be able to stake XLA to become sequencers or delegate to other sequencers. Decentralised sequencing employs a consensus algorithm to determine transaction inclusion and ordering, which may introduce additional latency compared with a centralised setup but significantly strengthens censorship resistance, liveness, trust minimisation and operational resilience.

Final settlement remains anchored to Ethereum through the rollup proof path. Provers generate zero-knowledge proofs of transaction correctness, and Ethereum smart contracts verify those proofs and finalise the related state transitions. Once a proof is accepted by the rollup smart contract on Ethereum, the corresponding state transition becomes final and immutable.

See H.5

2026-01-01

2026-10-08

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at:https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).

As the token studied does not have activity at the time of the study, its energy intensity is approximated through the calculation of a market cap-weighted average of the peer crypto asset activities, compared to the Xsolla's market capitalisation estimated through the product of its issue price and total supply. The peer group is defined as other native tokens of blockchains whose market capitalisation falls within ±25% of Xsolla's market cap at issue are included, to ensure only similar peers are used for estimations.

Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).

Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Land use: 29.82040 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).

Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).

As the token studied does not have activity at the time of the study, its carbon intensity per transaction is approximated through the calculation of a market cap-weighted average of the peer crypto asset activities, compared to the Xsolla's market capitalisation estimated through the product of its issue price and total supply. The peer group is defined as other native tokens of blockchains whose market capitalisation falls within ±25% of Xsolla's market cap at issue are included, to ensure only similar peers are used for estimations.

Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). As the base layer is a decentralised network, estimates on individual node weight, hazardous components and depreciation rate are used.

As the token studied does not have activity at the time of the study, its waste intensity is approximated through the calculation of a market cap-weighted average of the peer crypto asset activities, compared to the Xsolla's market capitalisation estimated through the product of its issue price and total supply. The peer group is defined as other native tokens of blockchains whose market capitalisation falls within ±25% of Xsolla's market cap at issue are included, to ensure only similar peers are used for estimations.

Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates.

As the token studied does not have activity at the time of the study, its land intensity and waste intensity are approximated through the calculation of a market cap-weighted average of the peer crypto asset activities, compared to the Xsolla's market capitalisation estimated through the product of its issue price and total supply. The peer group is defined as other native tokens of blockchains whose market capitalisation falls within ±25% of Xsolla's market cap at issue are included, to ensure only similar peers are used for estimations.

Full methodology available at: https://www.micacryptoalliance.com/methodologies/esg