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-07
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	ZK is the native crypto-asset of the zkSync network, a settlement network designed to provide privacy, institutional control, cryptographic enforcement, and Ethereum finality. The total maximum supply is fixed at 21,000,000,000 tokens, with no inflation. Tokens are distributed through capped minters rather than a pre-minted treasury. ZK powers governance and is designed with a flexible structure whereby governance may expand its economic function as the network evolves. Holders may participate in governance by voting on protocol upgrades, fee structures, and economic parameters. Governance is conducted through a three-body model comprising the Token Assembly (holder voting), the Security Council (technical review of upgrades), and the Guardians (emergency safeguard). No single body controls the protocol. ZK is used for protocol fees across the zkSync network. Institutional transactions within the Prividium architecture use ZK for protocol fees, which are routed according to governance-defined mechanisms.
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 ZK 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	9755003900 The number of ZK crypto-assets in circulation may vary over time due to the token’s issuance model and distribution mechanisms. While the protocol defines a maximum supply of 21,000,000,000 tokens, not all tokens are minted at launch. Instead, tokens are created progressively through capped minter contracts, which mint tokens on a “just-in-time” basis within predefined limits. As a result, the circulating supply is lower than the maximum supply and increases over time as tokens are minted and released in accordance with allocation schedules, governance decisions, and vesting arrangements applicable to certain categories such as team members and investors. At the time of writing, the circulating supply is approximately 9755003900 ZK.
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	N/A
E.28	Transfer time schedule	N/A
E.29	Purchaser's technical requirements	N/A
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	Admission to trading of the ZK crypto-asset is sought on Bitstamp. Access to trading, once admission is granted, will be provided through Bitstamp’s trading platform, including its website and mobile applications, in accordance with Bitstamp’s terms of use and applicable regulatory requirements. 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.36	Involved costs	Admission to trading of the ZK crypto-asset is sought on Bitstamp. Access to trading, once admission is granted, will be provided through Bitstamp’s trading platform, including its website and mobile applications, in accordance with Bitstamp’s terms of use and applicable regulatory requirements. 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	ZK is the native crypto-asset of the zkSync network and is used in connection with governance, network operations, and protocol-level economic functions. ZK enables participation in governance. Holders may vote on network-level decisions, including protocol upgrades, fee structures, and economic parameters. Governance is implemented through a multi-body structure comprising the Token Assembly, the Security Council, and the Guardians, with decision-making processes distributed across these bodies. Decision-making authority is distributed among them, and no single body has unilateral control over the protocol. Governance processes, including proposal submission, review, and execution, are defined through formal procedures and implemented via smart contracts and associated infrastructure. These proposals may relate to protocol changes, parameter adjustments, and allocation of resources. Voting is conducted through defined procedures, and outcomes are implemented through protocol mechanisms following the applicable governance process. ZK is also used for protocol fees. Transactions within the zkSync network, including those conducted within specific execution environments, may require the payment of fees denominated in ZK. The allocation and routing of such fees are determined through governance mechanisms.
F.3	Planned application of functionalities	Not applicable
F.4	Type of crypto-asset white paper	OTHR
F.5	The type of submission	NEWT
F.6	Crypto-asset characteristics	ZK is the native crypto-asset of the zkSync network. The total maximum supply is fixed at 21,000,000,000 tokens, with no inflation. Tokens are distributed through capped minters rather than a pre-minted treasury. ZK powers governance and is designed with a flexible structure whereby governance may expand its economic function as the network evolves. Holders may participate in governance by voting on protocol upgrades, fee structures, and economic parameters. Governance is conducted through a three-body model comprising the Token Assembly (holder voting), the Security Council (technical review of upgrades), and the Guardians (emergency safeguard). No single body controls the protocol. ZK is used for protocol fees across the zkSync network. Institutional transactions within the Prividium architecture use ZK for protocol fees, which are routed according to governance-defined mechanisms.
F.7	Commercial name or trading name	N/A as DTI is provided in F.13
F.8	Website of the issuer	https://zknation.io
F.9	Starting date of offer to the public or admission to trading	2026-06-11
F.10	Publication date	2026-06-10
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	HKL2NKLD8
F.14	Functionally fungible group digital token identifier, where available	BCBLPFRBX
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 ZK crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the ZK project. Holding ZK does not give rise to contractual claims or entitlements against any natural or legal person. At the time of this white paper, holders of ZK are granted only governance non-contractual rights within the ZK network. These functionalities are further described in field F.2.
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	200000
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 (to the extent that can be identified) 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 that competent court will depend on the location of the issuer and the given token-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset holder.

N	Field	Content
H.1	Distributed ledger technology	Not applicable as DTI is provided in F.13
H.2	Protocols and technical standards	Networking ZKsync Era is a Layer 2 zero-knowledge rollup built on Ethereum that executes transactions off-chain, aggregates them into batches and submits cryptographic validity proofs to Ethereum for settlement. ZKsync Era exposes Ethereum-compatible JSON-RPC and ZKsync-specific JSON-RPC interfaces for transaction submission, state queries and event monitoring. Submitted transactions enter the sequencer for execution and preliminary confirmation before proceeding to proof generation and Ethereum Layer 1 verification. ZKsync Era does not publicly specify its peer discovery mechanism, peer-to-peer overlay, transport encryption or session hardening rules. Serialisation ZKsync Era supports Ethereum legacy and EIP-1559 transaction formats alongside a ZKsync-specific EIP-712 typed transaction format. The ZKsync format introduces a gas-per-pubdata-byte limit, a per-byte cap on what a transaction pays for data published to Ethereum. This parameter applies to all transactions in the ZKsync Era environment, including ZK transfers, permit authorisations, voting delegation and governance interactions. Cryptography and key formats ZKsync Era uses zero-knowledge proofs to verify execution correctness on Ethereum. Accounts use secp256k1 key pairs and Keccak-256 address derivation, consistent with Ethereum. The ZK token contract additionally uses EIP-712 typed structured data signing for off-chain permit authorisations. Ledger The ZK token is maintained through smart contracts on ZKsync Era. Token state, comprising ERC-20 balances, delegated voting power and minting permissions, forms part of the ZKsync Era state, which is committed to Ethereum via state diffs. Execution ZKsync Era executes transactions in EraVM, a register-based virtual machine optimised for zero-knowledge proof generation. Ethereum smart contract bytecode is supported through an EVM Bytecode Interpreter. Privileged system contracts handle transaction processing, deployment, bridging and fee management; they may only be changed through upgrades initiated from Ethereum Layer 1. Token standards ZK is an ERC-20 governance token with EIP-2612 permit functionality and EIP-5805 voting delegation. Permit enables approvals via off-chain signed messages. Voting delegation allows a holder to assign governance voting power to any address, including themselves, whilst retaining beneficial token ownership. When tokens transfer, voting power moves between the respective delegates accordingly. The ZK token is implemented through ZkTokenV1, which is the smart contract that constitutes the ZK token on ZKsync Era, and is deployed as a transparent upgradeable proxy with role-based access control. The token admin role is held by the ProtocolUpgradeHandler; minting roles are held by the Token Governor timelock. Prior administrative roles were revoked following governance bootstrapping. Token distribution uses capped minters and a Merkle distributor. Each capped minter allows a designated role to mint ZK up to a specified maximum, enabling just-in-time minting rather than pre-minting the full 21,000,000,000 programmed supply cap at launch. The Merkle distributor controls airdrop claims through an immutable Merkle root representing eligible accounts and amounts.
H.3	Technology used	Architecture ZK uses a smart contract architecture on ZKsync Era comprising ZkTokenV1 as the core token contract, ZkCappedMinterV3 contracts for governed minting and a Merkle distributor for airdrop claims. The broader ZKsync Era system, sequencer, proving pipeline, Layer 1 verification contracts and data publication to Ethereum, provides ZK's execution environment, bridge context and finality model. Proof system and data availability ZKsync Era uses a SNARK-based proof system. After each batch is executed, a proof of the state transition is generated and submitted to Ethereum alongside compressed state diffs, Layer 2 to Layer 1 messages, logs and bytecodes. The Layer 1 verifier confirms proof validity and data availability before a batch is finalised. ZK state can therefore be reconstructed independently from Ethereum without relying on the sequencer Token deployment ZK is deployed at 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E on ZKsync Era. The ZkCappedMinterV3Factory is deployed at 0xABF70d9a1fe52ca5e9339A6Ef76759614C1b5eE9 on ZKsync Era. Active capped minters cover allocations for the airdrop (three successive distributor contracts), Matter Labs, the ZKsync Foundation, the Guardians, the Security Council and the ZKsync Association. New capped minters require at least one security review before deployment. The governance infrastructure comprises three governor and timelock pairs on ZKsync Era, the Protocol Governor, Token Governor and GovOps Governor, alongside a ProtocolUpgradeHandler and Emergency Upgrade Board on Ethereum. Governance contract addresses were updated following ZIP-5; current addresses are published in the ZK Nation documentation. Dependencies Token and governance contracts are written in Solidity using OpenZeppelin's upgradeable library for the proxy pattern, ERC-20 implementation, permit and access control. Governance contracts use Foundry for Layer 1 testing and Hardhat with ZKsync plugins for Layer 2 deployment. Both the standard Solidity compiler and the ZKsync-specific EraVM compiler are used.
H.4	Consensus Mechanism	ZK does not operate an independent consensus mechanism. It is a smart contract token on ZKsync Era and inherits the ordering, execution and finality characteristics of the ZKsync Era rollup and its Ethereum settlement layer. ZKsync Era sequences and executes transactions through the sequencer. Executed transactions are grouped into batches committed to Ethereum, proven by zero-knowledge proofs and then finalised by Ethereum Layer 1 verification. Preliminary confirmations from the sequencer are available ahead of on-chain finalisation, but economic finality is contingent on the relevant proof being accepted by Ethereum. The Layer 1 contracts verify proof validity, confirm data availability and process any Layer 2 to Layer 1 messages before a batch is considered final. Ethereum's proof-of-stake consensus secures the settlement layer on which ZKsync Era depends for finality. Validators stake ETH and are assigned responsibilities for block proposals and attestations. Ethereum time is divided into 12-second slots and 32-slot epochs. One validator is randomly selected as block proposer per slot; committees of validators attest to the proposed block. Finality is established when a supermajority link between two consecutive checkpoint epochs receives attestations representing at least two-thirds of total staked ETH. Reverting a finalised block requires the destruction of relevant validator stakes through slashing, making such reversion economically prohibitive.
H.5	Incentive Mechanisms and Applicable Fees	Network-level fees ZKsync Era fees reflect Layer 2 execution costs and Ethereum data publication costs. Layer 2 costs cover execution in EraVM and zero-knowledge proof generation for the batch. Since EIP-4844, ZKsync Era publishes data to Ethereum using blob-carrying transactions, reducing publication costs relative to calldata. The gas-per-pubdata-byte limit introduced in the ZKsync-specific transaction format (described in H.2) caps what any single transaction pays for that published data. A batch-level base fee is calculated from the prevailing Ethereum gas price, incorporating proof generation overhead and the cost of committing and verifying the batch on Ethereum. Protocol-level fees The ZK token contract imposes no transfer surcharge, burn fee or protocol fee. For ZK bridged to Ethereum, a deposit locks tokens in the Layer 1 shared bridge; a withdrawal returns the Layer 2 tokens and releases the locked balance. Validator incentives ZK is not an Ethereum validator reward asset. Ethereum validators receive ETH rewards for block proposals and attestations and are slashed for equivocation or other provably dishonest behaviour. These incentives secure the settlement layer described in H.4. Within the ZKsync Era, transaction fees are directed to a designated fee recipient; fee parameters and validator settings are governed by the ZKsync governance process. Governance of fee parameters ZK token voting power governs changes to protocol rules, token supply and operational parameters through the governance structure described in H.3. The Security Council and Guardians hold review, veto, freeze and emergency upgrade powers. Emergency procedures allow temporary freezes of Ethereum Layer 1 contracts. Protocol and token parameter changes require Token Assembly approval; the governance system is not controlled by any single entity.
H.6	Use of distributed ledger technology	FALSE
H.7	DLT functionality description	Not applicable
H.8	Audit	TRUE
H.9	Audit outcome	ZKsync maintains a continuous security review programme. All code undergoes internal review before external audit engagement. Critical releases receive multiple independent reviews and, where appropriate, public competitive auditing contests. The completed audits most directly relevant to ZK and its underlying protocol are listed below. ZK Token, Capped Minter and Merkle Distributor Audit: OpenZeppelin, March 2024 Object: ZkTokenV1, ZkCappedMinter and ZkMerkleDistributor contracts in the zksync-association/zk-governance repository, covering ERC-20 governance token mechanics, permit and voting delegation, the transparent upgradeable proxy structure, access control and Merkle-based airdrop distribution. Results: 13 issues identified, no critical, no high, no medium, 6 low severity, 7 informational notes. Actions: 10 issues resolved, 1 partially resolved. Deployment tooling was subsequently adjusted to use Hardhat with ZKsync plugins and OpenZeppelin Contracts version 4.9 for EraVM compatibility. Decentralised Governance Audit: OpenZeppelin, April 2024 Object: Three successive scopes covering the zksync-association/zk-governance repository. Guardians, Multisig, ProtocolUpgradeHandler, SecurityCouncil and EmergencyUpgradeBoard, and differential audits of era-contracts covering state-transition facets, ValidatorTimelock, L1SharedBridge and Bridgehub. Results: 27 issues identified. 1 critical, 0 high, 3 medium, 11 low, 12 informational notes. The critical finding identified an immutable variable left uninitialised in the ProtocolUpgradeHandler constructor, rendering the contract unable to process protocol upgrades. Actions: 18 issues resolved, 2 partially resolved. All resolutions are confirmed at the referenced governance repository commit. ZKsync Protocol Security Review: Spearbit, March–April 2025 Object: The zksync-protocol repository at a fixed commit, focused on BN254 elliptic curve circuit implementations used in proof generation, specifically scalar decomposition, G2 point manipulation functions and pairing logic. Results: 5 informational findings. No critical, high, medium or low severity issues. Findings covered redundant negation code in scalar multiplication, unsupported edge cases in G2 point functions, documentation gaps and a multipairing implementation limitation for configurations beyond a single pairing. Actions: The redundant scalar negation code was fixed. Remaining findings were acknowledged; documentation improvements were deferred. ZKsync V29 Release Audit: OpenZeppelin, May–June 2025 Object: Differential audit of the matter-labs/era-contracts repository across two feature releases — Reduced Interoperability, enabling cross-chain message passing between ZK Chains settling on Gateway, and Fast Finality, providing a pre-commitment mechanism for third-party finality verification on Ethereum Layer 1 — covering Layer 1 contracts, system contracts and the bootloader in Solidity and Yul. Results: 22 issues identified. 0 critical, 3 high, 2 medium, 8 low, 8 informational notes. The three high severity findings all related to bootloader logic for interop root handling, including absent validation of initialisation values, a design flaw enabling an operator to forge arbitrary interop roots, and an indexing inconsistency when iterating over interop roots. Actions: All 22 issues fully resolved prior to release. The broader ZKsync audit programme includes further completed reviews covering the fee model and token bridge, Layer 1 and Layer 2 governance diffs, ZKsync OS, state transition contracts, the shared bridge, EIP-4844 support and the SNARK proof wrapper. Public competitive auditing contests were conducted through Code4rena (March 2024) and CodeHawks/Cyfrin (October 2024). The full list of published reports is maintained at https://docs.zksync.io/zksync-protocol/security/audits. An ongoing bug bounty programme provides continuous coverage.

Part I - Information on risks

N	Field	Content
I.1	Offer-related risks	Market volatility and liquidity The market value of ZK can fluctuate and execution quality may vary across trading venues and liquidity conditions. Large-holder and allocation concentration ZK allocations include approximately 33% for investors, advisers and team members, 19.9% for the ZKsync Foundation, 29.3% for ZKsync Governance and 17.5% for the airdrop. Large or closely sequenced disposals by significant holders may affect execution quality, liquidity and price formation. Access, eligibility and interface dependence Access to ZKsync-related services may depend on official interfaces, including bridge, portal, documentation, explorer and checkout sites. Eligibility restrictions, sanctions controls or interface unavailability may affect the ability to access, bridge or use ZK. Withdrawal delay and capital mobility Withdrawing ZK from ZKsync Era to Ethereum involves a minimum three-hour delay, with actual timing dependent on network activity and proof generation. This may constrain a holder's ability to move assets rapidly between layers during periods of market stress. Misleading asset and address-selection risk Third parties may create digital assets with misleading names or fake contract addresses. Bridged ZK token addresses on Layer 2 differ from Layer 1 addresses, so mistaken asset selection may affect users interacting with venues, wallets or bridges. Transaction finality and custody Once a transaction has reached the relevant finality point, recovery requires a further authorised transaction rather than protocol-level reversal. Loss or compromise of private keys can make on-chain recovery impracticable. Delisting Risks Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.
I.2	Issuer-related risks	Governance and delegation concentration The Token Assembly is made up of ZK tokenholders who may delegate voting power. Concentrated delegation, low participation or co-ordinated voting may influence the Protocol Governor, Token Governor or GovOps Governor. The ZKsync Association does not control these governance bodies and cannot direct their outcomes. Once governance bootstrapping was completed, all three admin roles were transferred to on-chain governance contracts, and the Association's privileged roles were revoked. Admin-key and privileged-configuration risk In April 2025, an admin key administered by the ZKsync Association was compromised, enabling approximately 111,000,000 ZK tokens to be minted from three Merkle Distributor contracts via the sweepUnclaimed function. The key did not control the ZK token contract, governance contracts or any active capped minters, and user funds were not affected. The attacker returned approximately 90% of the stolen tokens under a safe harbour arrangement. Scoped admin permissions retained by the issuer entity can create token-specific operational risk even after broader governance decentralisation.
I.3	Crypto-assets-related risks	Supply mechanics ZK has a stated 21,000,000,000 total maximum supply with no inflation, and distribution uses capped minters rather than a pre-minted treasury. Errors, misconfiguration or governance decisions affecting minting, burning or allocation contracts may affect effective supply dynamics within the stated design. Governance utility and demand dependency ZK is used to vote on protocol upgrades and initiatives, and its economic function may be expanded through governance. Demand for ZK therefore depends on governance participation and adoption of ZKsync network functions. Token economics change risk Protocol fee structure, fee collection, allocation and token burns are subject to governance. Changes to economic parameters may affect perceived value, utility and holder expectations. Mint and burn authority risk The Token Governor can process proposals assigning minting and burning rights, and the November 2025 upgrade added permissionless burning and a BURNER_ROLE. Misuse or defective configuration of these powers may affect holder balances or circulating supply within the maximum-supply constraint. Address and bridged-token representation risk Tokens bridged between Layer 1 and Layer 2 have different addresses, and default bridge support is limited to standard ERC-20 functionality. Incorrect address selection or unsupported token behaviour can cause mistaken operations or failed integration assumptions.
I.4	Project implementation-related risks	Upgrade and migration execution risk ZKsync has an active upgrade and migration path covering governance contracts, bridge architecture, Gateway, interop messaging, ZKsync OS and token burn changes. Breaking changes or testing issues may affect implementation schedules and user operations. Governance execution dependency Protocol, token and governance operations proposals are handled through separate governors, timelocks and governance procedures. Proposal delay, rejection, veto or emergency procedure activation can alter delivery timelines and implementation outcomes. Emergency governance and freeze powers The Security Council can freeze the ZKsync protocol in emergencies, and emergency upgrades require approvals involving the Security Council, Guardians and the ZKsync Foundation. These powers support urgent response but create concentrated authority during emergency conditions. Guardian veto discretion Guardians have an independent power to veto proposals considered abusive, malicious or adverse. This discretion may prevent harmful proposals but can also delay or block changes that otherwise have tokenholder support. Supporting-entity dependence Matter Labs operates ZKsync sites and is one participant in the ZKsync ecosystem, while the ZKsync Foundation provides grants and enters into ecosystem agreements, and the ZKsync Association deployed the initial governance and token contracts. Disruption to these supporting roles may affect interfaces, governance operations or ecosystem support. Bridge implementation The ZKsync bridge operates through Ethereum Layer 1 smart contracts that process lock-and-mint deposits, burn-and-release withdrawals and cross-chain message finality. Defects in bridge contract logic, failed cross-chain messages or breaking changes introduced during bridge upgrades may cause misrouted assets, failed withdrawals or reconciliation failures between Layer 1 and Layer 2 balances. Third-party and interface dependency User operations may depend on the Portal, block explorer, APIs, wallets and service providers for bridging, transaction history, contract verification and visibility. Outages, inaccurate indexing, stale contract address data or interface restrictions can impair practical access even where protocol settlement remains available. Custom data availability and multi-chain configuration risk ZKsync supports custom data availability layers, and chains outside the official Chain Type Manager may carry different security guarantees. Incorrect configuration or weaker dependency assumptions may affect chain-specific risk profiles. Incident response coordination risk The April 2025 admin-key incident required coordination among Matter Labs, SEAL 911, the ZKsync Association, the ZKsync Foundation and the Token Assembly. Response quality and speed depend on clear authority, evidence gathering and governance follow-through. Regulatory and eligibility exposure Access to ZKsync-related interfaces and services is controlled by Matter Labs. Changes in the legal or regulatory framework, or in the implementation of compliance controls, may affect users’ ability to access such interfaces, participate in governance, or use related services. Data handling and privacy exposure Personal information may be processed for security, fraud prevention, legal compliance and service provision, and may be shared with service providers or transferred internationally. These practices create privacy, cross-border transfer and third-party processing risk for users interacting with official interfaces.
I.5	Technology-related risks	Smart-contract and protocol logic defects ZKsync relies on Layer 1 and Layer 2 contracts for bridging, governance, state-transition management and protocol operation. Defects in these contracts can affect deposits, withdrawals, upgrades, token mechanics or state verification. Upgradeable mechanisms and admin hooks ZKsync protocol contracts are upgradeable through an on-chain governance process administered by the Protocol Governor and timelock. Emergency situations may be handled through the Emergency Upgrade Board, which can bypass the standard proposal and delay the process to execute an upgrade immediately. Whilst this mechanism provides necessary response capability, emergency upgrades involve concentrated authority and accelerated execution, increasing the risk that an upgrade affecting protocol contracts or bridge operations is not fully reviewed before taking effect. Misconfiguration or a compromised governance participant during such a process could affect contract behaviour across the protocol. Sequencer ordering and censorship risk ZK rollups may rely on a sequencer or operator for batch production and transaction ordering, and centralised operators can influence ordering or exclude users. ZKsync's stack includes a sequencer component, creating an operational concentration point for transaction ordering and inclusion. Sequencer and prover operational dependency ZKsync OS Server is the sequencer and Airbender is the ZK proof generator. Availability or performance issues in sequencing or proving may delay transaction inclusion, proof production or settlement workflows. Prover and validity-proof risk ZKsync OS execution is decoupled from proving and Airbender generates validity proofs. Proof-generation resource constraints, prover defects or verification failures can delay settlement or weaken confidence in state-transition correctness. Bridge and interoperability risk Defects in bridge contract logic, token representation or cross-chain message handling can delay withdrawals, misroute assets or create reconciliation issues between Layer 1 and Layer 2 balances. Data availability and settlement dependency ZK rollups depend on published data and validity proofs so that state can be reconstructed and verified. Custom data availability support and settlement choices may change the security assumptions of particular ZKsync chains. Ethereum Layer 1 consensus and finality dependency ZKsync inherits Ethereum settlement-layer risks, including validator operation, execution and consensus client operation, and proof-of-stake finality assumptions. Severe Ethereum client, consensus, network or validator events may delay or impair final settlement and visibility for ZKsync operations. Resource accounting and execution constraint risk ZKsync OS tracks EVM-equivalent gas and native proving resources. Incorrect resource pricing, demand spikes or proving-resource bottlenecks can increase costs, delay transactions or cause execution failures.
I.6	Mitigation measures	Offer-related risks Market volatility and liquidity: ZK is listed on multiple centralised and decentralised trading venues. Token allocation vesting schedules impose lock-up periods on investor and team allocations through June 2028, with monthly unlock limits thereafter, reducing the risk of large, immediate disposals. Large-holder and allocation concentration: Token allocations by category, such as governance, foundation, airdrop, investor, and team, are disclosed in the official ZK Nation documentation and publicly verifiable through on-chain capped minter contracts. This supports supply transparency for prospective holders assessing concentration and distribution risk. Access and eligibility restrictions: Official terms impose prohibited-use and sanctions restrictions on site access. These disclosures allow holders and service providers to assess their eligibility before acquiring or offering services related to ZK. Withdrawal delay and capital mobility: Withdrawal finalisation on the Layer 1 bridge can be completed by any party once proof of inclusion is confirmed, reducing reliance on a single finalising party for the withdrawal step. Misleading asset and address risk: The official ZK token contract address is 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E on ZKsync Era and is published in the ZK Nation governance documentation. Ethereum Layer 1 addresses differ and are also published. These disclosures support address verification. Issuer-related risks Governance and delegation concentration: Governance is separated across the Token Assembly, Security Council and Guardians, and no single governance body controls the protocol. Production governance contract addresses are publicly listed, supporting external verification of governance infrastructure. Emergency governance and freeze powers: Emergency procedures require involvement of the Security Council, Guardians and the ZKsync Foundation, and include defined actions such as freezing Layer 1 contracts or executing emergency upgrades. Guardian veto discretion: Guardian veto authority is limited to proposals considered abusive, malicious or adverse, providing an explicit governance guardrail. Admin-key and privileged-configuration risk: The compromised airdrop admin key was scoped to the three Merkle Distributor contracts and did not control other contracts. The attacker returned approximately 90% of the stolen tokens to the ZKsync Security Council within 72 hours under a safe harbour arrangement; compromised admin keys were invalidated following the incident. These measures reduced the scope and financial impact of the specific incident but did not eliminate future key-management risk. Crypto-asset related risks Supply mechanics: ZK has a stated 21,000,000,000 total maximum supply with no inflation. The token contract enforces the public maximum supply. Token economics change risk: Changes to fee structure, allocation, burns and expanded economic functions are subject to governance. Governance-based change control reduces unilateral alteration risk but does not eliminate governance-outcome risk. Mint and burn authority risk: Minting and burning rights are handled through Token Governor proposals, and capped minter and governance contract addresses are publicly listed, supporting traceability of token-supply authority. Address and bridged-token representation risk: Layer 2 token addresses are deterministic from the Layer 1 address, name and symbol, and default bridge limitations are stated, supporting predictable asset representation. Project implementation-related risks Upgrade and migration execution risk: Upgrade and migration records link governance proposals, changelog entries and releases, while audit processes begin before deployment and include internal and external reviews. Governance execution dependency: Protocol, Token and GovOps Governors are separated, and timelock and governor contract addresses are publicly listed, supporting external monitoring of governance execution pathways. Bridge implementation: The standard bridge process defines lock-and-mint deposits, burn-and-release withdrawals and permissionless withdrawal finalisation after proof, reducing reliance on a single party to complete finalisation. Sequencer and prover operational dependence: ZKsync OS decouples execution from proving. Separation of sequencing and proof-generation workflows supports clearer operational boundaries between the two functions. Incident response coordination risk: The April 2025 incident report records timeline, scope assessment, temporary filtering, fund recovery and governance follow-up, providing an implemented incident-response record. Data handling and privacy exposure: The privacy policy identifies use cases for personal information, data-sharing categories, international transfer safeguards and complaint routes, reducing opacity around interface-level personal-data processing. Technology-related risks Smart-contract and protocol logic defects: Critical protocol parts have undergone multiple audits, with internal audits followed by independent external audits and public audit contests where applicable. Completed audits cover governance, token, shared bridge, Gateway, protocol and ZKsync OS scope. Upgradeable mechanisms and admin hooks: Upgrade authority was transferred to on-chain governance, and production governance, timelock, emergency upgrade and protocol-upgrade-handler addresses are publicly listed, supporting transparency over upgrade pathways. Sequencer ordering and censorship risk: An Layer 1 forced inclusion queue exists, enabling users to submit transactions directly to Ethereum as a censorship-resistance mechanism. This partially mitigates operator censorship risk but does not remove sequencing dependency. Prover and validity-proof risk: ZKsync OS produces validity proofs through Airbender, and state-transition correctness is verified on the settlement layer, mitigating invalid state-transition risk by requiring proof-based verification before finalisation. Bridge and interoperability risk: Bridgehub, SharedBridge, AssetRouter and NativeTokenVault addresses are published, and bridge-related audits include Shared Bridge and Gateway reviews, supporting bridge monitoring and defect reduction. Data availability and settlement dependency: Published rollup data allows independent state reconstruction, and ZKsync OS Layer 1 integration includes data availability validation. Ethereum Layer 1 consensus and finality dependency: Ethereum proof-of-stake finality is supported by validator economics and slashing, making reversion of finalised blocks economically prohibitive. Resource accounting and execution constraint risk: ZKsync OS tracks both EVM-equivalent gas and native proving resources, explicitly accounting for both execution and proof-generation costs.

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

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