MiCA Whitepaper Inline XBRL

N	Field	Content
00	Table of contents	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
01	Date of notification	2026-05-13
02	Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114	This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
03	Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114	This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
04	Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114	The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.
05	Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114	FALSE
06	Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114	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.
07	Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114	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 documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.
08	Characteristics of the crypto-asset	ZRO is the native crypto-asset associated with the LayerZero protocol, which is designed to enable communication between different blockchain networks. The LayerZero protocol allows applications deployed on separate blockchains to exchange messages and data, thereby supporting cross-chain functionality and interoperability. The project aims to provide infrastructure that enables decentralised applications to operate across multiple blockchain environments rather than being limited to a single network. The ZRO token is intended to play a role within the LayerZero ecosystem. It is used in connection with governance mechanisms, coordination of participants, and alignment of incentives within the protocol. The ZRO supply is fixed at 1 billion tokens. ZRO holders may vote in the LayerZero Fee Switch Referendum, which determines whether to activate the LayerZero Protocol fee. If activated, the protocol fee may apply a fee up to the cost of verification and execution of each LayerZero Message. LayerZero states that collected fees would be converted to ZRO and burned. The Fee Switch governance function is operational, with prior votes having taken place in December 2024 and June 2025. Holders of ZRO may be able to participate in certain ecosystem functions, which may include governance-related activities such as voting on protocol parameters or proposals, where such mechanisms are implemented. Participation in these activities, where applicable, is subject to the technical conditions defined by the protocol and may require the holder to interact with smart contracts or compatible interfaces. There is no guarantee that such rights will be available, nor that they will confer any enforceable legal entitlement. The token does not inherently represent ownership in any legal entity, nor does it provide a claim on assets, profits or revenues generated by the project.
09		Not applicable
10	Key information about the offer to the public or admission to trading	The token has been admitted to trading to the trading platform operated by Bitstamp Europe S.A. on its own initiative.

N	Field	Content
A.1	Name	N/A
A.2	Legal form	N/A
A.3	Registered address	N/A
A.4	Head office	N/A
A.5	Registration date	N/A
A.6	Legal entity identifier	N/A
A.7	Another identifier required pursuant to applicable national law	N/A
A.8	Contact telephone number	N/A
A.9	E-mail address	N/A
A.10	Response time (Days)	N/A
A.11	Parent company	N/A
A.12	Members of the management body	N/A
A.13	Business activity	N/A
A.14	Parent company business activity	N/A
A.15	Newly established	N/A
A.16	Financial condition for the past three years	N/A
A.17	Financial condition since registration	N/A

N	Field	Content
E.1	Public offering or admission to trading	ATTR
E.2	Reasons for public offer or admission to trading	By admitting the ZRO asset to trading, holders of the token will gain transparent price discovery and improved liquidity. This enables the project’s community and ecosystem participants to more easily enter and exit positions, supporting a dynamic and efficient market.
E.3	Fundraising target	N/A
E.4	Minimum subscription goals	N/A
E.5	Maximum subscription goals	N/A
E.6	Oversubscription acceptance	N/A
E.7	Oversubscription allocation	N/A
E.8	Issue price	N/A
E.9	Official currency or any other crypto-assets determining the issue price	N/A
E.10	Subscription fee	N/A
E.11	Offer price determination method	N/A
E.12	Total number of offered/traded crypto-assets	319633539 The total supply of ZRO is fixed at 1,000,000,000 tokens, and no additional tokens are created beyond this maximum amount. Not all tokens are in circulation, as a significant portion of the supply is subject to vesting schedules and allocation structures. The circulating supply of ZRO is therefore lower than the total supply and increases over time as tokens are released in accordance with predefined allocation categories, including distributions to the community, strategic partners and core contributors. Tokens allocated to certain categories, such as strategic partners and core contributors, are subject to vesting arrangements that include an initial lock-up period followed by gradual release over time. At the time of writing, the circulating supply is approximately 319,633,539 ZRO.
E.13	Targeted holders	ALL
E.14	Holder restrictions	N/A
E.15	Reimbursement notice	N/A
E.16	Refund mechanism	N/A
E.17	Refund timeline	N/A
E.18	Offer phases	N/A
E.19	Early purchase discount	N/A
E.20	Time-limited offer	N/A
E.21	Subscription period beginning	N/A
E.22	Subscription period end	N/A
E.23	Safeguarding arrangements for offered funds/crypto-Assets	N/A
E.24	Payment methods for crypto-asset purchase	N/A
E.25	Value transfer methods for reimbursement	N/A
E.26	Right of withdrawal	N/A
E.27	Transfer of purchased crypto-assets	When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.
E.28	Transfer time schedule	N/A
E.29	Purchaser's technical requirements	When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.
E.30	Crypto-asset service provider (CASP) name	N/A
E.31	CASP identifier	N/A
E.32	Placement form	N/A
E.33	Trading platforms name	Bitstamp Europe S.A.
E.34	Trading platforms Market identifier code (MIC)	BESA
E.35	Trading platforms access	Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.
E.36	Involved costs	There are no costs involved in creating an account on the trading platform, however trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.
E.37	Offer expenses	Not applicable
E.38	Conflicts of interest	There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest. In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.
E.39	Applicable law	Not applicable, as this point pertains to an "offer to the public", whereas this white paper relates to admission to trading.
E.40	Competent court	Not applicable, as this point pertains to an "offer to the public", whereas this white paper relates to admission to trading.

N	Field	Content
F.1	Crypto-asset type	Crypto-assets other than asset-referenced tokens or e-money tokens
F.2	Crypto-asset functionality	ZRO is the native asset of LayerZero. Its functionality includes use as the LayerZero protocol token for quoting and paying the service fees required to send cross-chain messages through LayerZero omnichain applications, in addition to payment in the relevant native chain token. The relevant fee quote is designed to cover the gas and service-worker costs associated with the cross-chain transaction, including Decentralised Verifier Networks and Executors. ZRO also provides governance functionality in relation to the LayerZero protocol fee switch. ZRO holders are able to participate in an on-chain referendum to determine whether the LayerZero protocol fee is activated or deactivated. If activated, the protocol may charge a fee up to the aggregate cost of verification and execution of a LayerZero message, and collected fees are converted to ZRO and burned. EigenZero, a Decentralised Verifier Network built with EigenCloud, is backed by USD 5 million in slashable ZRO and adds financial accountability to message verification. EigenZero uses an optimistic verification model: messages are assumed correct unless challenged within an 11-day window following chain-level finality. Where a message is found to have been verified incorrectly, affected parties may submit a claim through a slashing portal. Claims are reviewed by a five-member Security Council operated by EigenCloud, Chaos Labs, Zellic and others; where a claim is valid and approved, compensation may be paid from the slashed ZRO stake up to the value of the affected transaction. Only transactions with demonstrable economic impact and confirmed chain-level finality are eligible for slashing. EigenZero is currently live on Avalanche, BNB Chain and Ethereum.
F.3	Planned application of functionalities	Not applicable, as all functionalities described in F.2 have already been implemented.
F.4	Type of crypto-asset white paper	OTHR
F.5	The type of submission	NEWT
F.6	Crypto-asset characteristics	ZRO is the native crypto-asset associated with the LayerZero protocol and is intended to play a role within the LayerZero ecosystem. ZRO holders may vote in the LayerZero Fee Switch Referendum, which determines whether to activate the LayerZero Protocol fee. Holders of ZRO may also be able to participate in certain ecosystem functions, which may include governance-related activities such as voting on protocol parameters or proposals, where such mechanisms are implemented. There is no guarantee that such rights will be available, nor that they will confer any enforceable legal entitlement. The crypto-asset does not inherently represent ownership in any legal entity, nor does it provide a claim on assets, profits or revenues generated by the project.
F.7	Commercial name or trading name	N/A as DTI is provided in F.13
F.8	Website of the issuer	https://layerzero.foundation/
F.9	Starting date of offer to the public or admission to trading	2026-06-16
F.10	Publication date	2026-06-15
F.11	Any other services provided by the issuer	Not applicable
F.12	Language or languages of the crypto-asset white paper	English
F.13	Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available	RWM9LFCCR; 17CNX2KXX
F.14	Functionally fungible group digital token identifier, where available	C0HH6QTBN
F.15	Voluntary data flag	FALSE
F.16	Personal data flag	TRUE
F.17	LEI eligibility	TRUE
F.18	Home Member State	Luxembourg
F.19	Host Member States	Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden

N	Field	Content
G.1	Purchaser rights and obligations	Not applicable as the ZRO crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the LayerZero project. Holding ZRO does not give rise to contractual claims or entitlements against any natural or legal person. Holders of ZRO may participate in the on-chain fee-switch referendum, which is held every six months. This referendum allows ZRO holders to vote on whether to activate a protocol fee on LayerZero cross-chain messages. If activated, protocol fees are converted to ZRO and burned. Participation is on a non-contractual basis, requires interaction with the official governance interface and is subject to the applicable quorum and majority thresholds. These rights do not constitute an enforceable legal claim.
G.2	Exercise of rights and obligations	Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.
G.3	Conditions for modifications of rights and obligations	Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.
G.4	Future public offers	Not applicable
G.5	Issuer retained crypto-assets	255000000
G.6	Utility Token Classification	FALSE
G.7	Key features of goods/services of utility tokens	Not applicable
G.8	Utility tokens redemption	Not applicable
G.9	Non-trading request	TRUE
G.10	Crypto-assets purchase or sale modalities	Not applicable
G.11	Crypto-assets transfer restrictions	Not applicable
G.12	Supply adjustment protocols	FALSE
G.13	Supply adjustment mechanisms	Not applicable
G.14	Token value protection schemes	FALSE
G.15	Token value protection schemes description	Not applicable
G.16	Compensation schemes	FALSE
G.17	Compensation schemes description	Not applicable
G.18	Applicable law	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.
G.19	Competent court	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.

Part H – Information on underlying technology

N	Field	Content
H.1	Distributed ledger technology	Not applicable as DTI is provided in F.13
H.2	Protocols and technical standards	Protocols and technical standards ZRO is the native asset of the LayerZero protocol, an omnichain interoperability protocol that uses immutable smart contracts called Endpoints to transmit cross-chain messages. ZRO is not the native coin of a single Layer 1 blockchain; it exists across seven public blockchains, which are Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain and Avalanche, each of which provides its own ledger, execution environment and validator set for ZRO-related activity. Cross-chain transfers of ZRO between those seven chains are routed through Stargate using the Omnichain Fungible Token (OFT) standard, which maintains a single global supply by debiting the sender's balance on the source chain and crediting the recipient's balance on the destination chain after message verification and delivery. Deployment requires OFT contracts on every supported network, together with directional channel configuration and peer pairing so that each deployment recognises its counterpart. Networking, transport and session LayerZero's network model is structured around message channels defined by four components: a source application contract, a source Endpoint identifier, a destination Endpoint identifier and a destination application contract. Each channel maintains ordered delivery through nonce tracking, which prevents duplicate delivery and preserves message sequencing on a given pathway. The protocol separates message verification from message execution. DVNs verify packet data across blockchains, and Executors deliver packets to the receiving application following verification. Once a packet is verified by the configured security stack, execution is permissionless for any party willing to pay the destination gas cost. This design reduces the amount of security-critical code and permits recovery if a specific Executor fails. Serialisation LayerZero messages are serialised into packets before transmission. Each packet consists of a header and a body: the header contains the packet version, nonce, source and destination Endpoint identifiers, sender and receiver path fields, and a globally unique packet identifier while the body carries the message payload. DVNs and Executors use this structure to track message status and act on the correct packet. Message options are serialised as a byte array interpreted by MessageLib. They carry worker identifiers and arguments used by DVNs, Executors and other off-chain workers. The format is intentionally extensible, supporting compatibility across MessageLib versions and different execution environments. Cryptography and key formats DVNs verify cross-chain packet data and may use a range of underlying verification mechanisms, including zero-knowledge methods, side-chains, threshold-style consensus and native bridges. Applications configure their security stack based on the risk and cost profile of a specific cross-chain pathway. The packet identifier is computed by assigning a nonce to a packet, concatenating that nonce with the pathway and hashing the result to obtain a globally unique identifier. This links the verification process to a specific packet and allows workers to track message status across source and destination chains. Cryptography, address derivation and wallet key formats on each supported chain are governed by that chain's own specifications. Ethereum addresses and transaction signatures use the secp256k1 elliptic curve and Keccak-256 hashing. The EVM-compatible chains in the supported set, Arbitrum, Optimism, Base, Polygon and the Avalanche C-Chain, follow the same address and signature conventions. BNB Smart Chain is likewise EVM-compatible and uses the same scheme. Ledger ZRO balances and transfer state are recorded on the supported public blockchains. On any cross-chain transfer, the source chain records the debit and the destination chain records the credit following message verification and delivery. The LayerZero protocol coordinates between paired contracts through its messaging layer but does not maintain its own ledger or replace the canonical state of any supported chain. User assets remain under self-custody; the LayerZero Foundation and its website do not take possession, custody or control of user assets. Execution LayerZero execution is handled through four components: Endpoints, MessageLibs, DVNs and Executors. The Endpoint provides the stable application-facing interface and enforces lossless, exactly-once message delivery. MessageLibs handle packet encoding and verification. DVNs verify the packet against the configured security stack. Executors deliver verified packets to the receiving application on the destination chain. The OApp standard provides a generic interface for encoding and routing arbitrary data through the protocol. The OFT standard extends the OApp pattern with token-specific debit and credit logic, enabling ZRO to transfer across chains as described above.
H.3	Technology used	Implementation and architecture LayerZero's architecture is modular by design. Endpoints are immutable and cannot be upgraded, ensuring that the application-facing contract interface cannot be altered once deployed. The MessageLib registry is append-only, meaning new message libraries can be added but existing ones cannot be removed or overwritten. Executors are permissionless, allowing any party to deliver a verified message by paying the destination gas cost. This separation of message validity from message delivery allows the security-critical verification layer to be maintained independently from the delivery and application-convenience functions of the system. ZRO is deployed as an OFT contract on each of the seven supported chains. For transfers within a single chain, the transaction settles on that chain directly with no LayerZero message required. For cross-chain transfers, the paired OFT contracts on the source and destination chains coordinate through the LayerZero messaging layer as described in H.2. Where ZRO is held or transacted on Arbitrum, the sequencer processes most transactions, and users may also submit through the delayed inbox on Ethereum for censorship resistance. Where ZRO is held or transacted on Optimism or Base, those rollups post transaction data to Ethereum for data availability and derive their ordering and finality from Ethereum in their standard configurations. Base currently operates with a single active sequencer and posts sufficient information to Ethereum to allow reconstruction of L2 blocks. Dependencies Security assessments have been conducted for LayerZero protocol components relevant to ZRO, including Endpoint V2 contracts, OApp and OFT contracts, the Solana OFT implementation and the ZRO claim and donation contracts. The audit pack covers assessments by Zellic, Paladin Blockchain Security, OtterSec, ChainSecurity, Halborn, Pashov Audit Group and Hexens. ChainSecurity's assessment of OApp and OFT smart contracts treated Endpoints, Message Library Manager and DVN components as outside the scope of that particular review. Client interfaces and SDKs The OFT API is the primary non-consensus tooling supporting interface and wallet integration. It enables OFT discovery across chains, contract-address lookup, chain availability checks and generation of transaction data for direct OFT transfers. Settlement remains entirely on-chain through the supported blockchains and the LayerZero messaging route; the API assists discovery and transaction construction only and does not participate in consensus or state transition.
H.4	Consensus Mechanism	ZRO does not operate a ZRO-native consensus mechanism. Each supported public blockchain provides its own consensus protocol, which orders and finalises ZRO-related transactions on that chain. The LayerZero protocol provides the cross-chain messaging infrastructure and does not replace or supplement the base-chain consensus of any supported network. Ethereum uses proof of stake. Validators stake ETH, propose blocks and attest to proposals from other validators. Time is divided into 12-second slots and 32-slot epochs. A validator is selected as block proposer for each slot through a randomised mechanism, and committees of validators attest to proposed blocks. Finality is achieved through checkpoint voting: when validators representing at least two-thirds of total staked ETH vote in favour of a pair of checkpoints, those blocks and all preceding transactions become irreversible. Arbitrum processes most transactions through its sequencer on a first-come, first-served basis. Transactions may also be submitted through the delayed inbox on Ethereum, providing censorship resistance and an availability route when the sequencer is unresponsive. If the sequencer does not process a delayed-inbox transaction within the applicable period, force inclusion permits direct L1 submission to guarantee finality. Optimism is an OP Stack rollup that inherits Ethereum's ordering and finality properties in its standard configuration, with sequencer data posted to Ethereum for data availability. Base is an OP Stack rollup built on Ethereum. L2 transaction data is posted to Ethereum for data availability. Base currently operates with a single active sequencer that accepts transactions, orders L2 blocks and submits sufficient information to Ethereum to allow reconstruction of those blocks. Polygon PoS uses a two-layer architecture. Heimdall-v2 operates as the consensus and validation layer; Bor handles block production. Heimdall-v2 validates Bor block data and submits checkpoints to Ethereum at regular intervals to support asset withdrawals through the bridge. Deterministic on-chain finality is achieved through milestones, the primary finality mechanism since the Heimdall v2 upgrade of July 2025, which typically confirm transactions within two to five seconds, independently of checkpoint submission to Ethereum. BNB Smart Chain uses Proof of Staked Authority. Validators are selected through staking-based governance and take turns producing blocks. The active validator pool is re-elected every 24 hours, selecting the top 45 validators by stake: 21 Cabinet validators and 24 Candidates. For each block-production epoch (every 200 blocks), 18 Cabinet validators and 3 Candidate validators are randomly selected to produce blocks, forming the working set of 21 consensus validators. Avalanche C-Chain implements the Ethereum Virtual Machine and supports Solidity smart contracts. Primary Network validators stake at least 2,000 AVAX. Snowman consensus reaches agreement through repeated random sampling and quorum thresholds; once an honest validator accepts a transaction, all honest validators converge on the same conclusion, providing probabilistic finality with strong guarantees.
H.5	Incentive Mechanisms and Applicable Fees	Network-level fees ZRO-related transactions require users to pay the native transaction fees of the chain on which the transaction is submitted. Gas costs and fee denominations differ across the supported chains. On Ethereum, gas measures the computational effort required to execute operations and is paid in ETH. The EIP-1559 fee model burns the base fee and directs priority fees to validators. On Arbitrum, fees include the L2 gas component and the cost of publishing transaction data to Ethereum. The sequencer processes transactions primarily in order of submission; priority fees do not affect sequencing in the same way as on Ethereum. On Optimism and Base, each transaction includes an Ethereum data-availability cost because sequencer data is posted to Ethereum as calldata or blob data, in addition to the L2 execution fee. Polygon PoS uses an EIP-1559-style fee structure in which a network-determined base fee is burned and an optional priority fee may be offered to the block producer. BNB Smart Chain uses BNB as the gas token for all smart contract execution. On the Avalanche C-Chain, non-atomic transaction fees use an EIP-1559-style dynamic fee model. Both the base fee and the priority fee are burned rather than paid to validators. Protocol-level fees The OApp standard supports dynamic fee estimation for cross-chain messages. The fee quote can be denominated in the source chain's native token or in ZRO, and covers the source-chain gas cost together with fees for the DVNs and executors handling delivery on the destination chain. ZRO holders govern protocol fee accrual through an immutable on-chain referendum mechanism that runs every six months. The referendum determines whether to activate a LayerZero protocol fee of up to the cost of verification and execution per message. If activated, collected fees would be converted to ZRO and burned. As of the date of this white paper, both Vote #1 and Vote #2 are recorded as Off, meaning the protocol fee switch is inactive. Validator incentives Validator and block-producer incentives are provided by each supported base chain and are independent of ZRO. Ethereum validators earn ETH rewards for block proposal and attestation and face slashing penalties for dishonest behaviour. Polygon validators stake POL tokens, earn staking rewards and transaction fees, with delegators receiving rewards proportional to delegated stake after commission. BNB Smart Chain validators earn BNB rewards for block production. On Avalanche's C-Chain, transaction fees are burned and are not distributed to validators. Arbitrum and OP Stack sequencer and validator rewards operate under the fee structures of their respective networks. ZRO does not create or supplement a separate validator incentive system. Governance of parameters ZRO governance is confined to LayerZero protocol fee accrual. The fee switch referendum, enforced by an immutable voting contract, runs every six months and allows ZRO holders to vote on activating or deactivating the protocol fee. Governance of underlying chain parameters, including Polygon's staking contracts, BNB Smart Chain's epoch-based validator rotation and Ethereum-derived finality on OP Stack chains, is specific to each network and is not subject to ZRO governance.
H.6	Use of distributed ledger technology	False
H.7	DLT functionality description	Not applicable
H.8	Audit	TRUE
H.9	Audit outcome	Security assessments of LayerZero protocol components relevant to ZRO have been conducted by Zellic, Paladin Blockchain Security, OtterSec, ChainSecurity, Halborn, Pashov Audit Group and Hexens. Reviews collectively cover Endpoint V2 contracts, OApp and OFT contracts, the Solana OFT implementation and the ZRO claim and donation contracts. Zellic — Endpoint V2 Smart Contract Security Assessment — December 2023 Object: Endpoint V2 contracts, including EndpointV2, MessageLibManager, MessagingChannel, MessagingComposer, MessagingContext, SafeCall, PacketV1Codec, UltraLightNode components, MultiSig, UlnConfig and VerifierNetwork. Methodology covered manual review, automated testing, business-logic review, integration-risk analysis and code-maturity review. Results: Twelve findings were identified, comprising one critical, two medium, seven low and two informational findings. The critical finding concerned zero confirmations enabling arbitrary payload execution. Actions: LayerZero Labs acknowledged all findings. The critical issue and several medium and low findings were fixed as recorded in the report. Paladin Blockchain Security — LayerZero V2 Smart Contract Security Assessment — December 2023 Object: LayerZero V2 contracts across Ethereum and multiple EVM chains, including EndpointV2 and its dependencies. Results: Thirty-three findings were recorded, comprising three medium, ten low and twenty informational findings. Actions: Twenty-one findings were resolved, two were partially resolved and ten were acknowledged without change. Resolved items included safeguards for recipient initialisation and a requirement preventing the governance owner from setting the LayerZero token equal to an alternative fee token. OtterSec — LayerZero V2 Audit — 2023 Object: LayerZero V2 endpoint, ultralight node, treasury, verifier network and executor components, with additional reviews of later modifications. Results: Ten findings were reported, comprising three medium, one low and six informational findings. Medium findings included a fee-handler theft-of-funds risk, verifier-network signature replay and incorrect multisig replay protection. Actions: The medium and low findings shown in the findings table were marked resolved. ChainSecurity — OFT/OApp Smart Contracts Code Assessment — January 2024 Object: OApp and OFT smart contracts in the execution layer of LayerZero infrastructure. Methodology covered source-code assessment against provided documentation, specifications, threat model and trust assumptions; Endpoints, Message Library Manager and DVN components were treated as outside scope. Results: The codebase provided a satisfactory level of security. Zero critical and zero high findings were identified; two medium findings and six low findings were recorded. One medium finding was corrected in code and one was acknowledged; three low findings were corrected in code and three were acknowledged. Actions: Corrected findings were moved to the resolved section; acknowledged findings remain as identified constraints or design considerations. Zellic — OApp and OFT Smart Contract Security Assessment — June 2024 Object: OApp and OFT contracts, including OAppCore, OAppReceiver, OAppSender, OFT, OFTAdapter and OFTCore. Methodology covered manual review, automated testing, business-logic review, integration-risk review and code-maturity review. Results: No security vulnerabilities were identified in the scoped contracts. The report additionally recorded developer cautions covering receiving-function override requirements, message-ordering considerations and cross-chain decimal dust truncation. Actions: No security remediation was required. Developer cautions were noted for integrators. Halborn — LayerZero OFT Solana Programme Security Assessment — May 2024 Object: Solana OFT implementation adapted from Ethereum-compatible OFT contracts. Methodology covered manual review and security testing, with attention to Solana-specific constraints and common Solana programme vulnerabilities. Results: One low and three informational findings were identified. Actions: All four findings were accepted or acknowledged by the LayerZero team. Pashov Audit Group — LayerZero Solana OFT Security Review — September 2024 Object: Solana OFT programme files, including initialisation, receive, quote, send, peer configuration, pause configuration, fee withdrawal and message codec components. Results: Twelve findings were identified, comprising one medium and eleven low findings. The medium finding concerned mint decimal manipulation. Actions: All findings were acknowledged, including issues covering message-size validation, peer-address validation, fee-withdrawal threshold, rate-limiter and decimal-handling. Pashov Audit Group — ZRO Claim Security Review — June 2024 Object: ZROClaimCore, ZROClaimHub, ZROClaimSpoke and related claim interfaces. Methodology was a time-boxed smart contract review focused on application security. Results: Ten issues were identified, comprising two critical, two high, three medium and three low findings. Critical findings concerned off-by-one numerator handling and remote donations becoming stuck. High findings concerned donation withdrawal slippage and receive-path reversion on fee refunds. Actions: The report includes a fixes-review commit hash. Critical and high issues were required to be fixed before or as soon as possible after deployment. Hexens — ZRO Claim Contract Security Review — June 2024 Object: Donate and Claim contracts used to distribute ZRO through Merkle proofs and a donation mechanism. Full review of seven smart contracts over two days. Results: Two high-severity vulnerabilities, four medium-severity issues, one low-severity issue and one informational issue were identified. The two high-severity issues could cause users to lose donation tokens without being able to claim ZRO in return. Actions: All reported issues were fixed or acknowledged and subsequently validated by Hexens. Paladin Blockchain Security — ZRO Claim Smart Contract Security Assessment — June 2024 Object: DonateAndClaim, ClaimCore, ClaimLocal, ClaimRemote, DonateCore, DonateLocal and DonateRemote contracts. Results: Ten findings were identified, comprising one high, three low and six informational findings. Actions: Nine findings were resolved and one was partially resolved.

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

N	Field	Content
I.1	Offer-related risks	Volatility and liquidity ZRO may experience sudden price volatility and variable liquidity across venues and chains. Market depth constraints, cross-chain routing and concentrated orders can materially affect execution quality. Future distribution and access risk Approximately 15.3% of total ZRO supply is reserved for future distribution events. Each event may involve eligibility criteria, gas requirements and claiming mechanics that introduce execution delays, phishing exposure and access risks. Third-party venue and service access ZRO access depends on wallets, bridges, exchanges and explorers that operate under their own terms. Listing changes, geographic restrictions, regulatory actions or service outages can impair access without constituting a defect in ZRO. Regulatory and tax responsibility Users are solely responsible for compliance with applicable law, including tax, sanctions and financial regulations, in every jurisdiction in which they hold or transact ZRO. ZRO's seven-chain distribution and multi-venue availability create varying regulatory treatment that may change without notice. Market abuse ZRO's simultaneous presence across seven blockchains and multiple centralised and decentralised venues creates conditions in which wash trading, spoofing, front-running and other manipulation may occur across fragmented liquidity. Holders cannot influence the trading behaviour of other participants or the enforcement practices of individual venues. Delisting Risks Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.
I.2	Issuer-related risks	Protocol development concentration LayerZero Labs Ltd. is the primary development entity for the LayerZero protocol. ZRO's utility as a messaging fee and governance token is directly dependent on the protocol's continued maintenance and evolution. Disruptions to LayerZero Labs' operations, whether from regulatory action, funding shortfalls or key-person dependency, could materially affect the protocol's development trajectory and ZRO's utility. Core contributor supply risk LayerZero Labs' employees and contributors collectively hold 25.5% of total ZRO supply (255 million tokens) subject to three-year vesting arrangements with one-year locks and monthly releases thereafter. Sequential releases attributable to the issuer's team create foreseeable supply additions that may affect market conditions, independent of whether those releases are permitted under the vesting schedule. Issuer architectural and product decisions LayerZero Labs determines the direction of protocol upgrades, supported chain expansions, new product launches and DVN framework development. Decisions that alter the protocol's architecture, including the planned launch of the Zero L1 blockchain, directly affect the scope and character of ZRO's utility without requiring holder consent.
I.3	Crypto-assets-related risks	Omnichain token and supply consistency ZRO cross-chain transfers debit the source chain and credit the destination via LayerZero messaging. Misconfigured pathways, failed delivery or delayed DVN verification can leave the supply representation temporarily inconsistent across chains until the message is resolved. Supply allocation and unlock risk Ecosystem and growth (14.5%), strategic partner (32.2%) and core contributor (25.5%) allocations create scheduled and discretionary supply events. Vesting releases and Foundation ecosystem deployments may affect market supply and pricing conditions. Utility and demand dependency ZRO utility depends on LayerZero protocol adoption and governance over the fee switch. Declining message volume, competing interoperability protocols or fee-switch activation may reduce ZRO demand. Large-holder concentration Strategic partners, core contributors and the Foundation collectively control a majority of total supply. Large or sequenced transfers within vesting schedules can affect market liquidity. Concentrated voting power may influence governance outcomes. Irreversibility and source-chain debit A ZRO cross-chain transfer debits the source chain before destination-chain credit is confirmed. A failed or blocked message leaves the debit committed with no protocol-level reversal. Recovery requires manual monitoring and intervention by the holder. Governance and fee-switch risk If the six-monthly on-chain fee-switch referendum is activated, every LayerZero message incurs an additional fee up to the full cost of verification and execution, effectively doubling per-message cost and potentially reducing protocol usage and ZRO demand. Voter concentration could allow a minority to determine outcomes. If the switch remains inactive, ZRO demand depends on revenue-driven buybacks funded by Stargate activity. Public ledger privacy ZRO transfers on public blockchains expose transaction amounts, timing and addresses permanently. Wallet activity can be aggregated and linked to off-chain identifiers by third parties without holder consent. Key custody and operational security ZRO balances depend entirely on private key control. Key compromise, interaction with fraudulent interfaces, broad token approvals or mis-sent transfers cause permanent, irreversible loss. No freeze, recovery or balance-rewrite function exists at the issuer or protocol level.
I.4	Project implementation-related risks	Cross-chain configuration risk Message verification depends on correct DVN selection, threshold settings, Executor assignment and peer pairing by application developers. A single-DVN pathway is a single point of verification failure. Weak configuration can allow unverified messages or cause delivery failures on affected pathways. Third-party dependency risk ZRO transfers rely on Stargate, LayerZero Scan, the Value Transfer API, wallets, RPC providers and base-chain infrastructure. Failures, policy changes or service discontinuation at any of these layers can affect execution, monitoring and recovery independently of the core protocol. Related-party operational risk The LayerZero Foundation, a separate legal entity from LayerZero Labs Ltd., administers the ecosystem allocation (14.5% of total supply), operates the official website and maintains access to governance resources. Changes to Foundation operations, website interfaces, or programme commitments can affect holders' access to governance tooling and ecosystem information, independently of the issuer. Related-party data collection The Foundation collects personal and behavioural data from users of the official website. Data held by the Foundation may be subject to legal process, regulatory disclosure obligations or security incidents. Quality assurance and release risk Audits of Endpoint V2, OFT, OApp and ZRO Claim contracts cover code at the time of review and do not guarantee the absence of subsequent vulnerabilities. The Immunefi bug bounty offers up to USD 15 million for critical Endpoint V2 vulnerabilities, but expressly classifies all OFT and ONFT contract vulnerabilities as low severity regardless of impact, limiting the effective external security incentive for ZRO's own token contracts. Adoption and integration risk Incorrect receiving logic, nonce handling, pathway settings or execution assumptions by third-party integrators can affect ZRO cross-chain transfer reliability independently of the core protocol. Multi-chain deployment risk ZRO's existence across seven networks creates cumulative exposure to each chain's operational conditions, fee environments and infrastructure reliability. A disruption on any supported chain affects ZRO holders on that chain independently of the others.
I.5	Technology-related risks	Endpoint and message-library risk Applications relying on protocol default library assignments are exposed to changes in those defaults by the MessageLibManager. A malicious or misconfigured library set by an OApp owner or delegate could expose the application to fabricated or adjusted packets. DVN verification and collusion risk Message verification depends on the configured DVN threshold being met. A single-DVN pathway presents a single verification failure point. Collusion among a threshold-sized group of DVN operators can enable delivery of fraudulent messages on the affected pathway. Admin and configuration privilege risk Owner and delegate privileges allow library assignments, pathway configuration and fee-token changes. Compromise of these privileges can alter security-stack settings without holder consent. No ZRO balance freeze or rewrite function exists at this layer. Message execution and observability risk A delivered message may remain unexecuted if the Executor transaction reverts or destination application logic fails. Separately, a blocked message on a pathway prevents all subsequent messages on that pathway from being delivered until the blockage is resolved, creating a potential transfer deadlock. Explorer and API status data may lag on-chain state, making it difficult to distinguish delayed from failed transfers. Smart-contract defect risk Pre-remediation audits identified critical findings including arbitrary payload execution and message forgery. Similar defects introduced by subsequent code changes, new libraries or integrations could affect cross-chain execution, cause financial loss or leave ZRO unrecoverable while in-flight. OFT integration risk The OFT model depends on correct deployment across all networks, accurate peer configuration and supply-preserving debit-credit logic. OFT audit scope excluded infrastructure components and key custody. Separate OFT audit materials identify concerns around rate limiting, mint-setting parameters and decimal handling that integrators must address independently. Base-chain and L2 inherited risk ZRO transfers inherit operational conditions from each supported chain, including Ethereum gas spikes, BNB Smart Chain validator rotation, Polygon milestone finality, Avalanche consensus behaviour and sequencer availability on Arbitrum, Optimism and Base. These conditions cannot be mitigated at the token layer.
I.6	Mitigation measures	Offer-Related Risks Future distribution and access risk: Future distributions are expected to be announced through official Foundation channels with defined eligibility criteria and contract addresses, allowing users to verify official interfaces before interacting. Issuer-Related Risks Core contributor supply risk: Core contributor and team vesting contracts are governed by on-chain three-year vesting schedules with publicly disclosed lock-and-release timelines. These schedules are publicly verifiable, providing market participants with advance notice of foreseeable supply release events attributable to the issuer's team. Crypto-Assets-Related Risks Governance and fee-switch risk: The fee-switch referendum is governed by an immutable on-chain voting contract on a fixed six-month cycle. The fee ceiling, conversion-and-burn mechanism and historical vote outcomes are publicly observable, making the economic consequences of each vote deterministic in advance. Omnichain token and supply consistency: The OFT standard requires source-chain debit to match destination-chain credit one-to-one, preserving global supply invariance and eliminating supply inflation risk from parallel chain representations when pathways are correctly configured. Supply allocation and unlock risk: On-chain vesting contracts with disclosed schedules provide advance notice of release windows to market participants. Irreversibility and source-chain debit: LayerZero Scan and its API expose real-time message status (including failed, blocked and manually executable states),providing an official monitoring path for incomplete transfers. Project Implementation-Related Risks Cross-chain configuration risk: The official integration checklist requires explicit DVN assignments, Executor settings, bidirectional peer configuration, enforced options and an ownership review before production deployment, reducing the risk of single-DVN and unverified-path configurations. Third-party dependency risk: LayerZero Scan, its API and the Value Transfer API expose cross-chain message status and transaction data, providing a monitoring and recovery path independent of third-party routing services. Quality assurance and release risk: A public audit repository covers core protocol and token contracts. The Immunefi bug bounty is active with maximum rewards up to USD 15 million for Group 1 Endpoint V2 critical vulnerabilities; OFT and ONFT vulnerabilities are classified as low severity under current programme terms. Adoption and integration risk: Official developer documentation provides pathway configuration guidance, deployed contract references and an integration checklist to support integrator readiness. Technology-Related Risks Endpoint and message-library risk: OApp contracts can specify explicit send and receive library assignments rather than relying on protocol defaults. An allowInitializePath safeguard requires path initialisation before the first message on any pathway is accepted. DVN verification and collusion risk: Required and optional DVN configurations with threshold verification allow applications to require confirmation from multiple independent verifiers, raising the threshold for collusion-based attacks on any pathway. Admin and configuration privilege risk: OApp contracts support owner and delegate role separation, and the integration checklist requires an ownership and configuration review before production activation. Message execution and observability risk: Manual execution is available through LayerZero Scan or direct on-chain calls. The API exposes failed, blocked and manually executable statuses. For blocked pathways, the application's nonce-ordering configuration determines whether a blocked message can be skipped to restore downstream delivery. Smart-contract defect risk: Core protocol, OApp and OFT contracts were audited by multiple independent firms with documented remediation across material findings. The Immunefi bug bounty provides an active external reporting channel, subject to the OFT scope limitation noted in I.4. OFT integration risk: The OFT standard's requirements for network-wide deployment, peer configuration and supply-preserving debit-credit logic reduce fragmentation and minting-discrepancy risks when implementation follows the official standard and integration checklist.

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 underlying technology

Part I - Information on risks

Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts