# Welcome to ZK Nation **ZK Nation unites chains, builders, and operators to govern and grow the ZKsync Protocol—connecting public and private ledgers in a single scalable trust network.** In these docs you can find information about ZK Nation, the ZK token, ZKsync Governance System, and frequently asked questions. ### Ecosystem Overview This ecosystem overview highlights the key players within ZK Nation and illustrates how they interact and collaborate to support one another. Discover the governance bodies, supporting entities, and the governance procedures on the [ZKsync Governance Procedures: Overview](https://docs.zknation.io/zksync-governance/zksync-governance-procedures-overview) page.
### ZK Nation Links * View the ZK token contract at [0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E](https://era.zksync.network/token/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E) * Delegate ZK token voting power at [delegate.zknation.io](http://delegate.zknation.io) * Explore the ZKsync Governance contract code at * Visit the ZK Nation homepage at [zknation.io](http://zknation.io) * Read ZK Nation announcements at [blog.zknation.io](http://blog.zknation.io) > For other information about the ZKsync protocol, visit the homepage at [zksync.io](http://zksync.io) ### **Key Terminology** * **ZK Nation:** ZK Nation is a community driven by a shared purpose to govern, defend, and grow the ZKsync protocol. It is an inclusive term used to describe the individuals, organizations, and technologies to realize the [ZK Credo](https://docs.zknation.io/zk-nation/mission-zk-credo), expand freedom and accelerate intentional innovation. * **ZKsync Chain:** Fully customizable autonomous rollups, validiums, or volitions, built using the [ZK Stack framework](http://zkstack.io/). They operate fully independently, while interconnected through the L1 smart contracts. * **ZKsync Stack:** ZKsync Stack is a modular developer-friendly framework used to customize & deploy interoperable ZK-powered blockchains. All ZKsync Chains are built using the ZK Stack toolkit and share users & liquidity. * **Elastic Network:** A network of ZKsync Chains built on the [ZK Stack framework](http://zkstack.io/), all connected through a single Bridgehub and natively interoperable at the protocol level—creating a zone of seamless movement for users and assets. # Mission — ZK Credo ### Freedom → Progress → Prosperity
History shows us how technology can expand personal freedoms, unleashing creativity and innovation, leading to progress and prosperity. Early civilizations used bookkeeping and ledgers to track transactions, empowering individuals and communities to manage their finances and cooperate. The printing press democratized knowledge by making information affordable, sparking critical thinking and scientific advancement. The Industrial Revolution, powered by the technological breakthroughs of the steam engine and mechanization, propelled unprecedented economic and societal prosperity. In the twentieth century, the rise of cryptography and the Internet transformed communication and information access. This expansion of personal freedoms created economic opportunities for billions of people. Today, we're at the dawn of a new era with blockchains and Web3. Like the Internet once did for information, Web3 is changing the landscape for digital ownership and value exchange. It offers promising new forms of societal organization, e.g. "network states" . The journey through the waves of the cryptographic revolution is ongoing. With public-key cryptography and blockchains marking the first and second waves, we now face the third: the ZK Revolution. Coupled with Web3, the ZK Revolution is set to redefine our collective future, standing as testament to technology's power to unlock personal freedom. ### The ZK Revolution
"ZK" is a term with two meanings. Initially, it stood for "Zero-Knowledge (Proofs)", or, if you insist, "Zipped by Kryptography" . Today, "ZK" embodies a certain bigger idea, encapsulated in three properties: Integrity, Privacy, and Magic. #### Integrity *“Integrity is doing the right thing... even when no one else is looking or will ever know.”* ZK echoes the "don't trust, verify" ethos foundational to mathematics, open source, and blockchains. Computational integrity, enabled at any scale by recursive ZK proofs, is the cornerstone of this element. #### Privacy “*Privacy is necessary for an open society in the electronic age.”* In the blockchain sphere, privacy, viewed as a fundamental right, poses challenges uniquely addressed by ZK. Privacy shouldn't be a gift given to us; it's a fundamental right we must assert and defend together. #### Magic *“Any sufficiently advanced technology is indistinguishable from magic.”* ZK, endearingly dubbed "Magic Moon Math," is a marvel of technology. It makes the cumbersome simple, converting intricate operations into effortless clicks. It enables integrated systems, where components seamlessly synchronize. Above all, it weaves these wonders while honoring user privacy and control. ### The ZK Principles
We believe that to serve as the foundation of the Internet of Value, decentralized networks must adhere to the following principles: > **Trustlessness.** Users must be able to verify the integrity of transactions and the network state independently, without relying on others. > > **Security.** An attack on any individual user must be as difficult and expensive as attacking the entire network, even for the world’s most powerful actors. > > **Reliability.** The network must consistently and correctly perform its function without failure. > > **Censorship-Resistance.** Users must have the ability to transact on the network without needing permission from anyone. > > **Privacy.** Users must be able to protect their identities and transaction details. Sensitive information is not shared with others in the network without the consent of users. > > **Hyperscalability.** The network must have the capacity to grow with no upper bound while preserving all other critical properties. > > **Accessibility.** Applications and services on the network must be as affordable, easy-to-use and safe as state-of-the-art centralized alternatives. > > **Sovereignty.** Any group of users, even a minority, must have the right to exit — i.e., fork away from the network, while taking their assets with them at a minimal cost. At present, Ethereum comes closest to realizing the vision of a blockchain network forming the backbone of the Internet of Value. It stands as a trustless, secure, reliable, censorship-resistant, and sovereign network. However, it currently does not meet the remaining prerequisites: privacy, hyperscalability, and accessibility. Through ZK magic, Web3 on Ethereum can become a stronghold for privacy and achieve limitless scalability while maintaining integrity. In this transformative state, it will be an accessible and affordable sanctuary for digital self-ownership. It aligns with the ZK vision and will empower individuals globally, regardless of location. By unlocking these capabilities, a new wave of freedom, progress, and prosperity, will impact lives globally. ### The Collective Action
ZK Principles empower a network where trust in operators is not needed to secure users' assets and control. Even if the Lord Voldemort had access to our servers, they couldn't harm users' ownership or control their assets. However, technology evolves and so do blockchains. The ZK Principles can’t be fully safeguarded through technology alone. To ensure lasting protection, the community must deeply embrace the elusive concept of decentralization. If a network possesses all the mentioned attributes but its governance falls into the hands of a privileged few, it is destined to fail. Such few will tweak the rules for personal gain, eroding network value. The Internet’s history serves as a cautionary tale. Its inception promised decentralization, but over time user data and traffic fell into the control of a few tech giants, shaping the digital landscape to their advantage. To avoid this fate, we believe that the ZK community must be fiercely sovereign by elevating the right to exit into a moral obligation. When the network deviates from its principles, the community must unite and uphold these values by migrating to a new network. Identifying such an erosion of values is not trivial: oppression is often subtle, slowly chipping away at freedom. Oppressors may also publicly punish dissenters to instill fear and encourage *collective inaction*. Against these tactics, *collective action* is essential. The community must protect minorities and celebrate those who bravely defy oppression. To embed this collective commitment deeply in the community is vital to preserving freedom in the Internet of Value. Realizing these principles requires time and perseverance. A steady, pragmatic approach to decentralization is needed. While short-term compromises might be made, the unwavering long-term vision remains: advancing personal freedom for all. Let us remain resolute in championing digital self-ownership. Onward. # ZKsync Governance System North Star ## The Purpose of the ZKsync Governance System ZKsync Governance System —composed of smart-contracts, interfaces like the delegation portal, and the three governance bodies— has two purposes: 1. Secure the ZKsync protocol by decentralizing control of protocol changes and improvements 2. Activate programs in service of the ZK Credo vision: Freedom —> Progress —> Prosperity ## Evaluating the Impact of ZKsync Governance Proposals Proposals should aim to achieve goals supporting the vision of the ZK Credo. In turn, Delegates and other governance system participants should define and evaluate the impact of proposals based on each proposal’s goals and corresponding KPIs. Each KPI should be clearly related to the proposal goals, and to the purposes of the ZKsync governance system. ### ***Primary Goals and KPIs:*** * **Secure the Protocol**: The ZKsync protocol and its assets, builders, and community, are protected from adversarial actors seeking to control the protocol for their own interests. * Example KPI: Number of Incidents (Objective = 0) * **Expand Onchain Assets**: The ZKsync protocol has accessible, valuable, and diverse assets onchain, enabling a dynamic economy within and across ZK Chains. * Example KPI: Total value of assets available on ZKsync Chains * **Increase Active Builders**: The ZKsync protocol has a talented, diverse, and well-funded network of active builders, accelerating the development of blockchain and ZK related solutions. * Example KPI: Number of projects with an FDV > $100M * **Strengthen ZK Community**: The ZKsync protocol has an engaged, interconnected, and knowledgeable community of participants (incl. users, artists, developers, and partners). The community uses and advocates for ZKsync and ZK-technologies. * Example KPI: Weekly Active Addresses # ZKsync Governance Contract Addresses ## **ZKsync Governance System: Production Contracts** ### L2 Contracts * Token: * ZK Token: [0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E](https://explorer.zksync.io/address/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E) * ZkProtocolGovernor * Governor: [0x76705327e682F2d96943280D99464Ab61219e34f](https://explorer.zksync.io/address/0x76705327e682F2d96943280D99464Ab61219e34f) * Timelock: [0x085b8B6407f150D62adB1EF926F7f304600ec714](https://explorer.zksync.io/address/0x085b8B6407f150D62adB1EF926F7f304600ec714) * ZkTokenGovernor * Governor: [0xb83FF6501214ddF40C91C9565d095400f3F45746](https://explorer.zksync.io/address/0xb83FF6501214ddF40C91C9565d095400f3F45746) * Timelock: [0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d](https://explorer.zksync.io/address/0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d) * ZkGovOpsGovernor * Governor: [0xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160](https://explorer.zksync.io/address/0xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160) * Timelock: [0xC9E442574958f96C026DeF9a50C3236cab17428a](https://explorer.zksync.io/address/0xC9E442574958f96C026DeF9a50C3236cab17428a) * Capped Minter Deployment * [ZkCappedMinterV3.sol](https://github.com/zksync-association/zkminters/blob/main/src/ZkCappedMinterV3.sol) * [ZkCappedMinterV3Factory.sol](https://github.com/zksync-association/zkminters/blob/main/src/ZkCappedMinterV3Factory.sol) * ZkCappedMinterV3Factory: [0xABF70d9a1fe52ca5e9339A6Ef76759614C1b5eE9](https://explorer.zksync.io/address/0xABF70d9a1fe52ca5e9339A6Ef76759614C1b5eE9#contract%23write) * Active ZK Capped Minters * [0x66fd4fc8fa52c9bec2aba368047a0b27e24ecfe4](https://explorer.zksync.io/address/0x66fd4fc8fa52c9bec2aba368047a0b27e24ecfe4) (Initial Merkle Distributor for ZK Airdrop) * [0xb294F411cB52c7C6B6c0B0b61DBDf398a8b0725d](https://explorer.zksync.io/address/0xb294F411cB52c7C6B6c0B0b61DBDf398a8b0725d) (Second Distributor for ZK Airdrop) * [0xf29d698e74ef1904bcfdb20ed38f9f3ef0a89e5b](https://explorer.zksync.io/address/0xf29d698e74ef1904bcfdb20ed38f9f3ef0a89e5b) (Third Distributor for ZK Airdrop) * [0xa97fbc75ccbc7d4353c4d2676ed18cd0c5aaf7e6](https://explorer.zksync.io/address/0xa97fbc75ccbc7d4353c4d2676ed18cd0c5aaf7e6) (Matter Labs ZK Token Allocation) * [0xd78dc27d4db8f428c67f542216a2b23663838405](https://explorer.zksync.io/address/0xd78dc27d4db8f428c67f542216a2b23663838405) (ZKsync Foundation ZK Token Allocation) * [0x21b27952f8621f54f3cb652630e122ec81dd2dc1](https://explorer.zksync.io/address/0x21b27952f8621f54f3cb652630e122ec81dd2dc1) (Guardians ZK Token Allocation) * [0x0ad50686c159040e57ddce137db0b63c67473450](https://explorer.zksync.io/address/0x0ad50686c159040e57ddce137db0b63c67473450) (Security Council ZK Token Allocation) * [0x0681e3808a0aa12004fb815ebb4515dc823cfbb4](https://explorer.zksync.io/address/0x0681e3808a0aa12004fb815ebb4515dc823cfbb4) (ZKsync Association ZK Token Allocation) ### L1 Contracts * Protocol Upgrade Handler address: [0xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3](https://etherscan.io/address/0xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3) * Emergency Upgrade Board address: [0xECE8e30bFc92c2A8e11e6cb2e17B70868572E3f6](https://etherscan.io/address/0xECE8e30bFc92c2A8e11e6cb2e17B70868572E3f6) * Guardians address: [0x600dA620Ab29F41ABC6596a15981e14cE58c86b8](https://etherscan.io/address/0x600dA620Ab29F41ABC6596a15981e14cE58c86b8) * Security Council address: [0x66E4431266DC7E04E7d8b7FE9d2181253df7F410](https://etherscan.io/address/0x66E4431266DC7E04E7d8b7FE9d2181253df7F410) * Foundation address: [0xbC1653bd3829dfEc575AfC3816D4899cd103B51c](https://etherscan.io/address/0xbC1653bd3829dfEc575AfC3816D4899cd103B51c) ### Depricated Production Contracts: {% hint style="info" %} As a result of how [ZIP-5](https://vote.zknation.io/dao/proposal/32477831455745537024214395992964479454779258818502397012096084176779102554510?govId=eip155:324:0x76705327e682F2d96943280D99464Ab61219e34f) was executed, certain contracts listed above were updated. The depricated contracts are listed below. {% endhint %} ZkProtocolGovernor * Timelock: [0x3701fB675bCd4A85eb11A2467628BBe193F6e6A8](https://explorer.zksync.io/address/0x3701fB675bCd4A85eb11A2467628BBe193F6e6A8) ZkTokenGovernor * Governor: [0x10560f8B7eE37571AD7E3702EEb12Bc422036E89](https://explorer.zksync.io/address/0x10560f8B7eE37571AD7E3702EEb12Bc422036E89) * Timelock: [0x3E21c654B545Bf6236DC08236169DcF13dA4dDd6](https://explorer.zksync.io/address/0x3E21c654B545Bf6236DC08236169DcF13dA4dDd6) ZkGovOpsGovernor * Governor: [0x496869a7575A1f907D1C5B1eca28e4e9E382afAb](https://explorer.zksync.io/address/0x496869a7575A1f907D1C5B1eca28e4e9E382afAb) * Timelock: [0xC3e970cB015B5FC36edDf293D2370ef5D00F7a19](https://explorer.zksync.io/address/0xC3e970cB015B5FC36edDf293D2370ef5D00F7a19) L1 Contracts * Protocol Upgrade Handler address: [0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897](https://etherscan.io/address/0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897) * Emergency Upgrade Board address: [0xdEFd1eDEE3E8c5965216bd59C866f7f5307C9b29](https://etherscan.io/address/0xdEFd1eDEE3E8c5965216bd59C866f7f5307C9b29) * Guardians address: [0xD677e09324F8Bb3cC64F009973693f751c33A888](https://etherscan.io/address/0xD677e09324F8Bb3cC64F009973693f751c33A888) * Security Council address: [0xBDFfCC71FE84020238F2990a6D2954e87355De0D](https://etherscan.io/address/0xBDFfCC71FE84020238F2990a6D2954e87355De0D) ## **ZKsync Governance System: Testnet Contracts** ### L2 Contracts * Token: * ZK Token: [0x69e5DC39E2bCb1C17053d2A4ee7CAEAAc5D36f96](https://sepolia.explorer.zksync.io/address/0x69e5DC39E2bCb1C17053d2A4ee7CAEAAc5D36f96) * ZkProtocolGovernor * Governor: [0x5a6862ee581b6cDb517D24f0a69237f9D900C23C](https://sepolia.explorer.zksync.io/address/0x5a6862ee581b6cDb517D24f0a69237f9D900C23C) * Timelock: [0xa0eD7885B408961430F89d797cD1cc87530D8fBe](https://sepolia.explorer.zksync.io/address/0xa0eD7885B408961430F89d797cD1cc87530D8fBe) * ZkTokenGovernor * Governor: [0x98fF5B31bBa84f5Ad05a7635a436151F74aDa466](https://sepolia.explorer.zksync.io/address/0x98fF5B31bBa84f5Ad05a7635a436151F74aDa466) * Timelock: [0x0d9DD6964692a0027e1645902536E7A3b34AA1d7](https://sepolia.explorer.zksync.io/address/0x0d9DD6964692a0027e1645902536E7A3b34AA1d7) * ZkGovOpsGovernor * Governor: [0x56f6379F945e95558069acb3E945ee3480025605](https://sepolia.explorer.zksync.io/address/0x56f6379F945e95558069acb3E945ee3480025605) * Timelock: [0x0569a17602Ef32B8aa2fdeC44DCD3F7109f96f91](https://sepolia.explorer.zksync.io/address/0x0569a17602Ef32B8aa2fdeC44DCD3F7109f96f91) * Capped Minter Deployment * ZkCappedMinterV3Factory: [0xABF70d9a1fe52ca5e9339A6Ef76759614C1b5eE9](https://sepolia.explorer.zksync.io/address/0xABF70d9a1fe52ca5e9339A6Ef76759614C1b5eE9#contract#write) ### L1 Contracts * Protocol Upgrade Handler proxy address: [0xe3a615778aeEC76df1B368948a1D1614497Db858](https://sepolia.etherscan.io/address/0xe3a615778aeEC76df1B368948a1D1614497Db858) * Emergency Upgrade Board address: [0x0B2b3D1d87933C5009C49EffBAe279cdF39c6C96](https://sepolia.etherscan.io/address/0x0B2b3D1d87933C5009C49EffBAe279cdF39c6C96) * Guardians address: [0x3A8Ac6A7a4A026F42f805B40bB992edF01654595](https://sepolia.etherscan.io/address/0x3A8Ac6A7a4A026F42f805B40bB992edF01654595) * Security Council address: [0x25Ab0397DA109A50C8921A1d4a034e0973602469](https://sepolia.etherscan.io/address/0x25Ab0397DA109A50C8921A1d4a034e0973602469) * Foundation address: [0x46d3c220de912100DE9Ee5052511ad5FCb2C190b](https://sepolia.etherscan.io/address/0x46d3c220de912100DE9Ee5052511ad5FCb2C190b) ### Depricated Testnet Contracts: {% hint style="info" %} As s result of how [ZIP-5](https://vote.zknation.io/dao/proposal/32477831455745537024214395992964479454779258818502397012096084176779102554510?govId=eip155:324:0x76705327e682F2d96943280D99464Ab61219e34f) was executed, certain contracts listed above were updated. The depricated contracts are listed below. {% endhint %} ZkProtocolGovernor * Timelock: [0x59EF1efe5e031b56a987603cD9CBAfBA48Dd1833](https://sepolia.explorer.zksync.io/address/0x59EF1efe5e031b56a987603cD9CBAfBA48Dd1833) L1 Contracts * Protocol Upgrade Handler address: [0x9B956d242e6806044877C7C1B530D475E371d544](https://sepolia.etherscan.io/address/0x9B956d242e6806044877C7C1B530D475E371d544) * Emergency Upgrade Board address: [0xfC4cf3248A8f5fbA7Fa6bD67a3BB43cfc7514e55](https://sepolia.etherscan.io/address/0xfC4cf3248A8f5fbA7Fa6bD67a3BB43cfc7514e55) * Guardians address: [0xe95141dd86828D23c2aA8Ed518644Af5e4216D79](https://sepolia.etherscan.io/address/0xe95141dd86828D23c2aA8Ed518644Af5e4216D79) * Security Council address: [0x541E05fbe96895095E0f4b70865AbaC70cb12e0e](https://sepolia.etherscan.io/address/0x541E05fbe96895095E0f4b70865AbaC70cb12e0e) ## Ownership Transfer Sequence 1. A transfer of ownership of [L1SharedBridge](https://etherscan.io/address/0xd7f9f54194c633f36ccd5f3da84ad4a1c38cb2cb), [BridgeHub](https://etherscan.io/address/0x303a465b659cbb0ab36ee643ea362c509eeb5213), [StateTransitionManager](https://etherscan.io/address/0xc2ee6b6af7d616f6e27ce7f4a451aedc2b0f5f5c), [ValidatorTimelock](https://etherscan.io/address/0x5d8ba173dc6c3c90c8f7c04c9288bef5fdbad06e) from a centralized 4/7 multisig to the decentralized [ProtocolUpgradeHandler](https://etherscan.io/address/0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897) was proposed. [Transaction link](https://etherscan.io/tx/0x83d26938171003102f077922c8b32ddf01a3994f654aa1c684453fb2b36456a5). 2. [EmergencyUpgradeBoard](https://etherscan.io/address/0xdefd1edee3e8c5965216bd59c866f7f5307c9b29) accepted ownership of the contracts in the previous step by executing an emergency upgrade approved by the Security Council, Guardians, and the Foundation. [Transaction link](https://etherscan.io/tx/0x04252ef77e208a233dfe0e7a3c70a04c8c8e95364c6ec67e5dd4ca7299bad8cb). 3. Ownership of [ProxyAdmin](https://etherscan.io/address/0xC2a36181fB524a6bEfE639aFEd37A67e77d62cf1) was transferred to the decentralized [ProtocolUpgradeHandler](https://etherscan.io/address/0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897). [Transaction link](https://etherscan.io/tx/0x16775779a40b1f754fb8a4724f27f0a2065ed4d6e5862ea10ad9083d1f190d08). 4. Onwership of [Era L2 ProxyAdmin](https://era.zksync.network/address/0xdB1E46B448e68a5E35CB693a99D59f784aD115CC) was transferred to the decentralized [ProtocolUpgradeHandler](https://etherscan.io/address/0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897), aliased L2 address `0xA08b9912416E8aDc4D9C21Fae1415d3318A129A8`. [Transaction link](https://explorer.zksync.io/tx/0xcb7c4f89ff61c472e6fdb89500518c4ebb7b6b52ee47a27fe673b680734a7935). 5. Ownership of [Era UpgradeableBeacon](https://explorer.zksync.io/address/0x1Eb710030273e529A6aD7E1e14D4e601765Ba3c6) was transferred to the decentralized [ProtocolUpgradeHandler](https://etherscan.io/address/0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897), aliased L2 address `0xA08b9912416E8aDc4D9C21Fae1415d3318A129A8`. [Transaction link](https://explorer.zksync.io/tx/0xeb93ddd8c79bdd0beb2b2ca1ba8e58e77c417578d039ecd8095402f459fe8559). 6. Ownership of [Era L2 bridge](https://explorer.zksync.io/address/0x11f943b2c77b743AB90f4A0Ae7d5A4e7FCA3E102) was transferred to [Era L2 ProxyAdmin](https://era.zksync.network/address/0xdB1E46B448e68a5E35CB693a99D59f784aD115CC). [Transanction link](https://explorer.zksync.io/tx/0x927e0591b9f2ef2341b074942f5e058fae14138a4788015b396eef23c01f9e60). 7. Ownership of [Era L2 wETH](https://explorer.zksync.io/address/0x5AEa5775959fBC2557Cc8789bC1bf90A239D9a91) was transferred to [Era L2 ProxyAdmin](https://era.zksync.network/address/0xdB1E46B448e68a5E35CB693a99D59f784aD115CC). [Transaction link](https://explorer.zksync.io/tx/0x993e872dcb300a3f51da9e404115d4b09c85a247a041b8d584558f14fc2ec5af). 8. Ownership of [Cronos L2 Bridge](https://explorer.zkevm.cronos.org/address/0x309429de3621992cb0ab8982a448c9cc5c38405b) was transferred to the decentralized [ProtocolUpgradeHandler](https://etherscan.io/address/0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897), aliased L2 address `0xA08b9912416E8aDc4D9C21Fae1415d3318A129A8`. [Transaction link](https://explorer.zkevm.cronos.org/tx/0x5233c9560c1c5062fb318a546f0649a7ec16fa31aa9d258d35cb3ac854e5ec54). 9. Ownership of [Cronos L2 UpgradeableBeacon](https://explorer.zkevm.cronos.org/address/0x100af9367f9e27bd1c58a82976059ab67998810f) was transferred to the decentralized [ProtocolUpgradeHandler](https://etherscan.io/address/0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897), aliased L2 address `0xA08b9912416E8aDc4D9C21Fae1415d3318A129A8`. [Transaction link](https://explorer.zkevm.cronos.org/tx/0xbea11de6a2834ea57922d5f2e80a5d645131c67b5a166695cd1e8ff70669cb8d). 10. [ZK Token](https://explorer.zksync.io/address/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E) Admin role was granted to the decentralized [ProtocolUpgradeHandler](https://etherscan.io/address/0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897), Minter and Minter Admin roles granted to the [TimelockController](https://explorer.zksync.io/address/0x3E21c654B545Bf6236DC08236169DcF13dA4dDd6) of the decentralized Token Governor, all other admin roles revoked. [Transaction link](https://explorer.zksync.io/tx/0xc1a06497815dd79f6a131bb6f47ded02374c22a06615c1e0e8ca9cf7fcc824e8). If you want to learn more about connecting to ZKsync Mainnet and Testnet contracts, please visit [docs.zksync.io](https://docs.zksync.io/build/connect-to-zksync). # ZK Token ## Token Properties
AttributeValue
Token TickerZK
Token Address0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E
Supply Cap21,000,000,000
Snapshot29710983
InflationToken supply can be increased through a protocol governance upgrade.
Deployed onZKsync Era
Transferrable to Ethereum MainnetYes
## Token Distribution
CategoryTokensPercentageDescription
Token Assembly6,146,000,70029.27%To be allocated by the Token Assembly
Ecosystem Initiatives4,179,000,00019.90%The ZKsync Foundation administers ecosystem initiatives supporting ZKsync ecosystem growth.
Airdrop3,675,000,00017.50%A one-time airdrop with no lock ups.
Investors4,154,642,00619.78%Investors and advisors
Team2,845,357,29413.55%Matter Labs employees
Sum21,000,000,000100%
> ℹ️ The numbers for Investor and Team token allocations were updated in June 2025 to reflect updated calculations. ## Lock Ups Investor and team tokens have a 4 year unlock period between June 2024 to June 2028, including a one year cliff. On June 2025, 3.6% of the total supply will unlock from the team and investor allocation. After June 2025, a maximum of 0.8% token supply will unlock monthly until June 2028. ## Capped Minters For most onchain organizations, tokens are minted at launch and passively held in wallets. This leads to multiple issues. It creates pressure to focus on financial engineering like investments or treasury diversification, and removes the agency from token recipients to determine when and how to receive tokens. Instead of minting the entire supply of tokens at once, ZKsync uses **capped minters.** Capped minters are unique smart contracts that enable “just-in-time minting.” Each capped minter contract receives a maximum number of tokens they are allowed to mint. Those with the minter role of a capped minter can mint tokens from that supply whenever they choose to, up to the maximum specified. This design removes the risks associated with a large treasury and instead shifts the agency of token management to the capped minters and their designated administrators. This explains the discrepancy between `Max Total Supply` visible on the [block explorer](https://era.zksync.network/token/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E) and the programmed Supply Cap of 21,000,000,000. Not all the tokens have been minted by their designated capped minters. After the ZK token launch, capped minters were created to distribute token allocations to the ZKsync Foundation, the airdrop, Investors, and Matter Labs' team member vesting contracts. The 29.3% that is governed by the Token Assembly is not in a capped minter, it is simply the remaining amount on the ZK token contract. The Token Assembly grants minting rights to administrators of Token Programs. Read more here about [Token Program Proposals](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps). > ℹ️ Read more about the [latest version of the ZK capped minter ](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps/capped-minters-101)(currently V3) contracts and factory. Once deployed, the contracts and admin multisig (if applicable) must undergo at least one security review by a Security Council member or reputable security firm. > Between October 24 and October 30, Team tokens were transferred from one custody provider to another. These tokens began to unlock as per the details in `Lock Ups` heading above. # ZK Airdrop {% hint style="info" %} Certain jurisdictions are blocked from the ZK airdrop, these include: Cuba; Iran; North Korea; Russia; Syria; specific regions of Ukraine: Crimea, Donetsk and Luhansk. These geographical regions must be blocked to comply with the sanctions regulations set forth by the U.S. Department of Treasury’s Office of Foreign Assets Control (“OFAC”), the United Nations Security Council (“UNSC”), the European External Action Service (“EEAS”), and His Majesty’s Treasury (“HMT), which mandate the prohibition of providing product or services accessible from domains to persons from specific countries and territories. Additionally, persons residing in the United States will also be prohibited from participating in the airdrop. {% endhint %}
| Category | Data | | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Snapshot Date |

March 24, 2024 00:00:00 UTC

Era Block Number: 29710983
Lite Block Number: 187273

| | ZKsync user claim start | Week of June 17th, 2024 | | ZKsync user claim end | January 3rd, 2025 | | Total token amount | 3,675,000,000 | | [Total eligible wallets](https://github.com/ZKsync-Association/zknation-data/blob/main/eligibility_list.csv) | 695,232 | There are two ways in which wallets qualified for the 17.5% airdrop: * **Users** (89%): ZKsync users who bridged funds onto ZKsync Era and met at least one of the [seven eligibility criteria](#step-1-eligibility). * **Contributors** (11%): Individuals, developers, researchers, communities, and companies who contributed to the ZKsync ecosystem and protocol through development, advocacy, education or participation regardless of their ZKsync network usage. ## Usage-Based Airdrop Eligibility and allocations for ZKsync users had four sequential steps: 1. **Eligibility**: Every address that has ever transacted on ZKsync Era and ZKsync Lite was checked against eligibility criteria. 2. **Allocation**: A value-scaling formula adjusts an address’s allocation based on amounts sent to ZKsync Era and how long those crypto-assets have stayed on the wallet. 3. **Multipliers**: Addresses that met certain criteria could receive multipliers on their allocation. 4. **Sybil Detection**: A standard sybil filtering methodology applied heuristics to detect bot behavior. ### Step 1: Eligibility Every address that has ever bridged funds into ZKsync Era was checked against eligibility criteria that identifies people who thoughtfully spent time exploring ZKsync. **Each address must have at least one point to be eligible for the airdrop.** | Name | Network | Description | Point Value | | ----------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------- | | Contract Interactions | ZKsync Era | Interacted with at least 10 non-token smart contracts on ZKsync Era. (Eligible contracts must have had at least 30 days of activity) | 1 | | Paymaster Activity | ZKsync Era | Used paymasters for at least 5 transactions on ZKsync Era | 1 | | Token Trader | ZKsync Era | Traded at least 10 distinct ERC-20 tokens on ZKsync Era DEXs | 1 | | DeFi Liquidity Provider | ZKsync Era | Provided any amount of liquidity to tracked DEXs and Borrow/Lend protocols on ZKsync Era | 1 | | Libertas Omnibus Holder | ZKsync Era | Held at least 1 Libertas Omnibus NFT at snapshot | 1 | | ZKsync Lite Activity | ZKsync Lite | Active for more than 3 distinct months on ZKsync Lite before ZKsync Era mainnet | 1 | | Gitcoin Donor | ZKsync Lite | Donated to Gitcoin via rounds hosted on ZKsync Lite | 1 | ### Step 2: Allocation Allocations for eligible addresses was based on a **value-scaling** formula. This formula adjusts an address’s allocation based on amounts sent to ZKsync Era and how long those crypto-assets have stayed on the wallet. That is to say, an address with 100 USD sent to ZKsync Era at mainnet launch will be weighted more than an address who only put 100 USD a month before snapshot. Crypto-assets held on ZKsync Lite do not count when determining an address’s allocation. Value scaling is a multi-step process: 1. First, the daily USD balance of crypto-assets held by an address was calculated, including the wallet’s balance or crypto-assets sent to DeFi protocols. 2. Next, to emphasize the increased utility of crypto-assets at work compared to those sitting idly in wallets, crypto-assets in DeFi were valued at 2x their nominal value. 3. Finally, the time weighted average balance was calculated for each wallet by summing the daily balance and dividing by total number of days in the snapshot period. The snapshot period from public mainnet launch of ZKsync Era on March 24, 2023 to March 24, 2024 is 366 days long. Below are two examples demonstrating how value scaling is calculated and the effect which time, amount of money, and DeFi usage have on the resulting time weighted average balance. #### **Alice** Alice sent $100 in crypto-assets to ZKsync Era 250 days before the snapshot was taken. After 50 days, they sent another $100 in crypto-assets and kept it in their wallet for the remainder of the time until snapshot $$ TWAB = \frac{$100 \* 50 days + $200 \* 200 days}{366 days} = $122.95 $$ #### **Bob** Bob sent $1,000 in crypto-assets to ZKsync Era just 25 days before the snapshot was taken. He immediately put $500 in crypto-assets of this into a DEX liquidity pool and left the rest in their wallet where it remained until snapshot. Recall that crypto-assets in DeFi protocols are weighted at 2 times their nominal value $$ TWAB = \frac{$500 \* 25 days + $500 \* 25 days \* 2}{366 days} = $102.46 $$ ### Step 3: Multipliers Each address could receive multipliers based on activity that signaled a high likelihood of human behavior or contribution to ZKsync. These multipliers apply on top of eligibility and allocations from ZKsync Era and Lite usage. These multipliers include: * Hold one of these ZKsync native NFT collections at snapshot: Dudiez, Hue, Moody Mights, Webears, ZKPENGZ, zkSkulls, or zkVeggies. * These seven collections were selected based on having a median trade price of at least $25 and a total trade volume of $20,000 in the 30 days prior to snapshot. * Hold at least $50 of one of these ZKsync native ERC-20 tokens at snapshot: AAI, HOLD, KOI, MEOW, MUTE, RF, ZF, ZORRO. * Similarly to the seven eligible NFT projects above, tokens of the top seven projects ranked by market capitalization at the time of snapshot. Eight tokens are included because KOI and MUTE are the same project * Smart Contract Wallets created via ZKsync Era native account abstraction. * Held at least 50% of the ARB/OP/ENS airdrop for more than 90 days after claiming. * In the first 1,000 addresses to interact with qualifying Ethereum smart contracts at least two times. A qualifying contract is one with at least 100 ETH in transaction fees spend on it. After Step 3, each address was assigned a token allocation. Addresses had to meet a minimum requirement of 450 ZK and were capped at a maximum of 100,000 ZK. Addresses with fewer than 450 ZK had their tokens recycled back into the pool. Addresses with more than 100,000 ZK had their excess tokens recycled back into the pool as well. These tokens were then redistributed and brought the minimum allocation up to 917 ZK. ### Step 4: Sybil Detection The combination of eligibility criteria, value scaling, and multipliers eliminated most bot swarms. However, our sybil detection methodology further filtered the remaining bots. It intentionally used a very conservative heuristics framework, to avoid accidentally punishing real people. The core idea is to find large groups of externally owned accounts (EOAs) that are ultimately owned by the same user or entity and filter them from the eligible addresses. To group EOAs into clusters of common ownership, two heuristics were used: * CEX deposit address reuse heuristic * Common funding heuristic Finally, the clusters from the two heuristics were combined into a single list of EOA clusters, and all the clusters with more than 20 EOAs were filtered. **CEX Deposit Address Reuse** The first heuristic leverages centralized exchange (CEX) deposit address reuse. CEXs create deposit addresses for customers to process deposits. Since they usually have a single deposit address per customer, if multiple addresses send crypto-assets to the same deposit address, they are likely all controlled by the same entity. Using this insight, this heuristic groups EOAs that sent transactions to the same CEX deposit address during a 1 year period. **Funding Source Patterns** The second heuristic examines funding patterns. Every time a new address is created, its owner needs to fund it with ETH to pay for transaction fees. If we find a group of EOAs with the same ultimate funder, they are likely owned by the same entity. Concretely, we look for funding transfers of similar amounts that occurred within a predefined time window

The image above shows an example of a bot swarm detected by this approach. It has 1,029 EOAs that were ultimately funded through a CEX (i.e. the red node).

## Contribution-Based Airdrop {% hint style="info" %} GitHub Developers and ZKsync GitHub Discussion Helpers must associate their address to their handle by June 25th, 00:00 CEST to claim.\ \ External Projects, Protocol Guild and ZKsync native project contributors will be able to claim starting June 24th, 2024 {% endhint %} ### **ZKsync Native Projects** *215,250,000 Tokens* Allocation directly to the contributors and treasuries of ZKsync native projects building on ZKsync Era, including DeFi protocols, ZKsync chains, NFT collections, marketplaces, infrastructure, gaming, and more. A full list of these projects can be found [here](https://github.com/ZKsync-Association/zknation-data/blob/main/zksync_native_project_list.csv). ### **Builders** *86,895,375 Tokens* Allocated to individuals, developers, researchers, communities, and companies who contributed to the ZKsync ecosystem and protocol through development, advocacy, or education | Category | Description | | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | External Projects | [Contributors and employees of these organizations](https://github.com/ZKsync-Association/zknation-data/blob/main/external_project_list.csv) | | GitHub Developers |

Developers contributing to these repositories

To qualify, a user must have had at least 25 commits across all eligible repos prior to March 24 0:00 UTC, 2024

| | [Protocol Guild](https://protocol-guild.readthedocs.io/en/latest/) | Ethereum researchers and developers | | ZKsync GitHub Discussion Helpers | Users who meaningfully contributed in discussions on the [ZKsync Community Developer Hub on GitHub](https://github.com/zkSync-Community-Hub/zksync-developers/discussions). | | ZK Quest Participants | People who participated in the ZK Quest developer activations at Istanbul Devconnect 2023 and/or ETH Denver 2024 | | Security Researchers | Participants in open security contests hosted by platforms such as Code4rena, Cantina, and Codehawks. To qualify, a user must have had at least $100 earned on Code4rena or Codehawks, or one critical report on Cantina. | | Community Moderators | Community moderators and members of the zkStars program | | ZKsync Event POAPs | POAPs rewarded to people for in-person events: [102366, ](https://collectors.poap.xyz/drop/102366)[107276, ](https://collectors.poap.xyz/drop/107276)[144302, ](https://collectors.poap.xyz/drop/144302)[144304, ](https://collectors.poap.xyz/drop/144304)[158767, ](https://collectors.poap.xyz/drop/158767)[159713, ](https://collectors.poap.xyz/drop/159713)[173207](https://collectors.poap.xyz/drop/173207) | | ZK Credo Translators | [ZK Credo](https://github.com/zksync/credo/) language translators | ### Onchain Communities *102,375,000 tokens* Allocated to a small group of experimental onchain communities for exploring novel ways to organize using tokens and NFTs. | **Group** | **Description** | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | $DEGEN Airdrop Recipients | Recipients of the Season 1 $DEGEN airdrop awarded for being an early user on Farcaster | | $BONSAI Airdrop Recipients | Recipients of the Season 1 $BONSAI airdrop awarded for being an early user on Lens | | Crypto The Game | Participants in Season 1, Season 2, and the CTG team | | Pudgy Penguin and Milady Maker Holders | Holders of Pudgy Penguin or Milady Maker NFTs. Allocations are rewarded on a per-address basis rather than per-NFT. | # FAQs ### General Token FAQs * [ZK Token FAQ](https://docs.zknation.io/zk-token/faqs/zk-token-faqs) * [ZK 代币常见问题解答 (Mandarin)](https://docs.zknation.io/zk-token/faqs/zk-dai-bi-chang-jian-wen-ti-jie-da) ### Claiming * [ZK Token Claim FAQ](https://docs.zknation.io/zk-token/faqs/zk-token-claim-faqs) # ZK Token FAQs ## 1. How could someone qualify for this airdrop? At the highest level, there were two ways in which a wallet address qualified for the **17.5% airdrop**: 1. **Users (89%):** ZKsync users who bridged crypto-assets onto ZKsync Era and met at least one of the [seven eligibility criteria](/zk-token/zk-airdrop#step-1-eligibility). 2. **Contributors (11%):** Individuals, developers, researchers, communities, and companies who contributed to the ZKsync protocol and ecosystem through development, advocacy, education, or participation *regardless of their ZKsync network usage*. **For wallets in the 11% Contributor category, ZKsync Era activity was optional.** The contributor allocation focused, for example, on people and communities who built early projects on ZKsync, contributed to relevant GitHub repositories, performed security research, served as Discord moderators, or participated in communities such as Degen, Bonsai, Crypto the Game, Pudgy, and Milady. ## 2. When you say this is a usage-based airdrop, what does that mean? The user-based allocation (89% of the total airdrop) was all about identifying and rewarding a diverse group of users on ZKsync Era who will help govern and grow ZKsync for the long haul. The goal was to find folks who were bridging crypto-assets to ZKsync Era, and give them a [multiplier bonus](/zk-token/zk-airdrop#step-3-multipliers) for doing things that are indicative of being an organic user. Such people are very likely to become a valuable member of the ZKsync community. A wallet's history across chains can reveal a lot about its owner. Real users tend to be more risk-on, especially when they feel part of a community. They spend time exploring, trying out new protocols, and holding onto speculative assets. On the flip side, bots and opportunists play it safe, putting in minimal effort while trying to blend in and extract value. ## 3. I met some of the eligibility criteria, but did not get an allocation, why not? ZKsync user airdrop allocations (89% of the total airdrop) were based on a combination of: 1. How many of the [seven eligibility criteria](https://docs.zknation.io/zk-token/zk-airdrop#step-1-eligibility) were met. 2. The amount bridged and held on ZKsync Era - either in your wallet or DeFi protocols -- based on a time-weighted average balance (TWAB) over 12 months ending on the snapshot date. **This is characterized as value scaling** (see details in [question 5](#id-5.-how-does-value-scaling-work)). 3. A bonus multiplier: If the wallet was part of a pre-defined group, such as early ETH adopters, holders of top ZKsync native NFTs/tokens, or holders of an airdrop from ARB, OP, ENS, amongst others, it received an allocation multiplier. ***Important: Transaction volume alone had no impact on the size of allocations.*** Allocations were calculated for users based on the above criteria. In order to receive an airdrop allocation, the result had to be larger than ZK 450. ***This means that even if you hit all seven criteria, but you held a small amount on average over time, or did not qualify for any of the other bonus multipliers, you might not qualify for an allocation.*** | Property | Catelyn | Jon | Eddard | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Address** | [0x211cc9b2de4c18523ce2481664596dd2183e966f](https://explorer.zksync.io/address/0x211cc9b2de4c18523ce2481664596dd2183e966f) | [0xbe13dae86c043cb5c2f898cdd3e6342b4880674f](https://explorer.zksync.io/address/0xbe13dae86c043cb5c2f898cdd3e6342b4880674f) | [0xa894aa1dd71960921193bfe3ee5f400dee96c03f](https://explorer.zksync.io/address/0xa894aa1dd71960921193bfe3ee5f400dee96c03f) | | **Eligibility points** | 3 | 3 | 3 | | **Time-weighted Average Balance (TWAB)** | 50 USD | 50 USD | 30 USD | | **Multiplier** | Held ZKsync native NFT: Dudiez, Hue, Moody Mights, Webears, ZKPENGZ, zkSkulls, or zkVeggies | 0 | 0 | | **Allocation** | 5,239 | 1,040 |

340 0
(did not meet
ZK 450 threshold)

| ## 4. I met four eligibility criteria and got less than someone I saw on X who only met two eligibility criteria. Why? The number of eligibility criteria met was only one of three factors that determined the size of an allocation. The ZKsync airdrop allocation is a combination of eligibility criteria, your time-weighted-average-balance (TWAB) on ZKsync Era, and your bonus multiplier. In this case, the other person might have bridged a larger amount of crypto-assets into ZKsync Era and/or held them there for a longer period of time. Alternatively, the other person might have qualified for one of the bonus multipliers or be part of the contributor-based airdrop, while you were not. ## 5. How does “value scaling” work? To identify and reward users putting crypto-assets into the ZKsync Era platform, allocations were based, in part, on a **value-scaling** formula. This formula adjusted an address’s allocation based on amounts sent to ZKsync Era and how long those crypto-assets were in the wallet. ***For example, an address with $100 sent to ZKsync Era at mainnet launch (March 2023) and held since then will be weighted more than an address that only put $100 on a month before the snapshot.*** *Value Scaling = Time-Weighted Average Balance (TWAB) = **Scaling** allocations based on how much **value** in crypto-assets someone bridged and for how long they held them.* ***Reminder: Transaction volume alone has no impact on value scaling.*** *For more, see* [*these examples*](/zk-token/zk-airdrop#alice)*.* ## 6. What if I only used ZKsync Lite? Why was I excluded? To be eligible for the airdrop, addresses had to meet [one eligibility criteria](https://docs.zknation.io/zk-token/zk-airdrop#step-1-eligibility) ***and*** bridge crypto-assets onto ZKsync Era. The focus of the airdrop was on ZKsync Era, the first ZK chain, as it is poised to become the decentralized hub for the entire ZKsync ecosystem. ZKsync Lite users, as the OGs of the ZKsync ecosystem, were able to receive up to two eligibility points for using ZKsync Lite. But they also needed to, at some point, have crypto-assets on ZKsync Era. For the usage-based airdrop: **If a user only used ZKsync Lite and not ZKsync Era, unfortunately, they were not eligible to receive any user airdrop allocation.** *\*Gitcoin provided us with a list of users that had donated through Gitcoin on ZKsync Lite. This list contained donations starting from September 2022.* ## 7. Why are there addresses with 0 transactions that still got an allocation? The airdrop was separated into a user-based allocation (89% of airdrop) and a contributor-based allocation (11% of airdrop). **Wallets in the contributor category did not need to show activity on ZKsync Era.** The contributor allocation focused, for example, on people and communities who built early projects on ZKsync, contributed to relevant Github repositories, performed security research, moderated the community on Discord, or participated in communities such as Degen, Bonsai, Crypto the Game, Pudgy, and Milady. There are 184 addresses which meet eligibility criteria on ZKsync Lite and bridged assets on ZKsync Era, but have no other transactions. These wallets are eligible for the airdrop. Additionally, 11 test addresses were added to the allocation for internal quality assurance and testing. These addresses were allocated the minimum allocation of 917 tokens. Once they are claimed, these tokens will be sent to the burn address. 0x6adb27812220f1ff5df618e3273d83c430705eec \ 0xb1ded8ff2f7a45f436951f082dda770e1dcee84d \ 0x07528fba97b02bba1aaa03a8ffe51d3fda86b585 0xc527a57ebcc7af699055bb8a3aca917a00a235ed 0x358291b1ea089437a9b16fb8c23d8a035ea7c358 0x023e3e6d98d7a5c7209910ab4ab9f91713dbdc1d 0x65f8dfc419b418ae82f289059d038428d038cd9a 0x6cc3a7f20f0f2f3d3fb5e07f89f7449e6a2537d6 \ 0xae757f4c8aad55712018e6fef0612a091279517a \ 0x5f66edefd2d3d228244d5801911cdccb87df92bc 0x0e602a94192f9da3db92f159a724ea8442916987\ 0x1bf7C517AFF73AD03C28C243ea800E3A7a443Fb9 ## 8. Why are external groups like Degen and Bonsai rewarded instead of ZKsync users? A small portion (2.8%) of the total airdrop was reserved for experimental onchain communities: Degen and Bonsai recipients, Crypto The Game, Pudgy, and Milady. These communities are known to be advocates and fervent defenders of their ecosystem and share the same cypherpunk values as ZK Nation, while also experimenting with innovative ways to self-organize. These positive-sum communities are valuable additions to any network and will hopefully be long-term members and stewards of ZKsync. ## 9. Why did some people get more than 100K tokens? 100K is the maximum reward for the user-based allocation of the airdrop (again, 89% of airdrop). 155 addresses (0.022%) received an allocation greater than 100K tokens by qualifying for the maximum [user reward](https://docs.zknation.io/zk-token/zk-airdrop#usage-based-airdrop) in addition to qualifying for rewards from the [contributors category](https://docs.zknation.io/zk-token/zk-airdrop#contribution-based-airdrop) (11% of total airdrop). Example groups that are part of the contributors category: ZKsync native projects, GitHub Developers, Security Researchers, Discord Community Moderators, ZK Credo Translators, and more. ## 10. How did you decide which ecosystem projects were eligible for the airdrop? The following project categories received retroactive rewards: 1. Top Defi protocols. Top DeFi protocols on ZKsync Era by TVL that have demonstrated their dedication to building on ZKsync. With over a hundred projects listed on [DeFi Llama](https://defillama.com/chain/zkSync%20Era), the ones that had more than 2M USD in TVL were included. These projects are all dedicated to use their allocation to further the growth of the DeFi ecosystem on ZKsync. 2. Top community-led growth. Projects that have consistently been building their own communities and collaborating with other communities in the ZKsync ecosystem. These include gaming, NFTs, and meme projects. The following project categories received proactive allocations for upcoming launches. These projects have committed to redistributing their allocations back to the ZKsync community (see [thread of initial announcements](https://x.com/TheZKNation/status/1801378351040307565)): 1. Upcoming ZK chains. These projects are critical early adopters of the ZKsync hyperscaling vision. 2. DeFi blue chips. Industry’s leading Defi projects that have recently launched or will launch soon. Determining the allocation size was based on several factors, including: * Loyalty to the ZKsync ecosystem as their main home. * Maturity metrics: TVL, size of community, levels of activity. * Growth potential. * Dedication to growing ZKsync communities. ## 11. Why did TVL spike in November 2023? In late November 2023, a single whale deposited roughly 40,000,000 USD into ZKBase. In early January 2024, this same whale removed this amount from the protocol. You can see this activity on [DeFiLlama](https://defillama.com/protocol/zkbase#information). The whale’s address is [0x7929a629ba65491d02756c742f9f7b611e891c16](https://era.zksync.network/address/0x7929a629ba65491d02756c742f9f7b611e891c16). This address was not eligible for the airdrop and did not receive any allocation. Even though it has a high TWAB, it did not meet any [eligibility requirements](https://docs.zknation.io/zk-token/zk-airdrop#step-1-eligibility). If it did meet them, it would have been eligible only for the maximum allocation of 100,000 ZK. This example showcases how the airdrop prioritized organic users over whales. ## 12. Why did you allocate tokens to CEXs? There were four identified CEX wallets that were eligible to receive a total of 93,677 ZK tokens. All wallets that qualified for the airdrop received the appropriate allocation, based on the[ eligibility criteria](https://docs.zknation.io/zk-token/zk-token-faq#id-1.-how-could-someone-qualify-for-this-airdrop). It is unlikely they will claim. 0x4a41d76b0524a3989998380c033f12bfeb5f7201 0x8ae57a027c63fca8070d1bf38622321de8004c67 0xa84fd90d8640fa63d194601e0b2d1c9094297083 0xf89d7b9c864f589bbf53a82105107622b35eaa40 ## 13. I participated in ZK Quest, why didn’t I get as many ZK tokens as other participants? Within ZK Quest, participants received allocations based on the difficulty of the quests and the maturity of the ZK Quest platform. There were three tiers of allocations: * Highest tier: Completed all the quests at ETHDenver 2024 * Middle tier: Completed at least one coding quest at ETHDenver 2024 * Lowest tier: Completed at least one quest in ETHDenver 2024 or DevConnect Istanbul ## 14. Why was I not eligible despite performing well in the various airdrop checkers? Many airdrop checkers are focused on the activity metrics that previous airdrops used—such as the transaction volume or the amount of gas spent. But this is also well known and exploited by the industrial sybils, which made an activity-based airdrop no longer feasible for ZKsync. No statements were ever made implying that activity metrics were relevant for a potential airdrop. The approach was designed to reward organic users: those who used the network because it was valuable to them, not those who tried to game the system and extract value. Activity metrics are easily gameable by industrial bot farms. Aggressive sybil filtering can be effective at eliminating naive sybils, at the expense of falsely flagging many organic users. However, professional industrial farms employ sophisticated algorithmic strategies that are indistinguishable from real people. They fund accounts from many distinct exchange addresses, never interact with each other, use randomized amounts, and use software to randomize daily patterns of human behavior, and even perform activities unique to the project (for example, using ZKsync paymasters). Such programmatic sybil accounts will always outnumber the accounts of real people with a huge ratio. Thus, an activity-based approach would have left organic users at a colossal disadvantage. By far the largest part of the airdrop allocation would have gone to professional sybils. ## 15. Did you use sybil detection? Yes. Explicit sybil detection was used in addition to the unique airdrop design that created a natural advantage for organic users. Here is the full overview of our anti-sybil philosophy. ### **The problem** Aggressive sybil filtering can be effective at eliminating naive sybils, at the expense of falsely flagging many organic users. However, professional industrial farms employ sophisticated algorithmic strategies that are indistinguishable from real people. They fund accounts from many distinct exchange addresses, never interact with each other, use randomized amounts, and use software to randomize daily patterns of human behavior, and even perform activities unique to the project (for example, using ZKsync paymasters). The majority of such bots are completely undetectable, even with the most advanced anti-sybil methodology. Thus, any traditional airdrop design anticipated by sybils would lead to the absolute majority of the allocation ending up in the hands of bot farms. ### **Our strategy** That’s why we chose an alternative path: prioritizing accounts that belong to the organic users with high likelihood. This strategy was implemented through value scaling and multipliers. ### **Value scaling** The idea behind [value scaling](https://docs.zknation.io/zk-token/zk-airdrop#step-2-allocation) is to exploit the asymmetry between sybils and humans, and to invert it to the advantage of humans. It is based on the following insight. Sybils expected allocations to be distributed more or less evenly between all accounts, so they took advantage of having programmable bots to create more accounts than a real person will do in their whole life. But since they want to operate in a capital efficient manner, they used very small amounts of crypto-assets to fund each of those accounts. Real people, on the other hand, tend to concentrate most of their wealth in just a few accounts, making their balances much larger compared to bots. By focusing on balances, value-scaling eliminated most bots and opportunists, leaving a large majority of organic people intact. ### **Multipliers** Value-scaling alone is far from perfect, since it would still falsely eliminate some real people with less capital onchain. To improve upon this, allocations were boosted with onchain behavior that strongly signals true human behavior and stack [eligibility points](https://docs.zknation.io/zk-token/zk-airdrop#step-1-eligibility) or directly through [multipliers](https://docs.zknation.io/zk-token/zk-airdrop#step-3-multipliers). ### **Explicit sybil detection** At the final step of the process, an explicit sybil detection was applied. You can review the methodology [here](https://docs.zknation.io/zk-token/zk-airdrop#step-4-sybil-detection) using industry standard heuristics. Conventional sybil detection was configured to lower the rate of false positives. This means that a larger number of sybils could pass through the filter, but less people were falsely flagged as bots. For the same reason we relied on our own methodology, and not on unvalidated third party data sets. This was a conscious trade-off. There will be sybils in every airdrop. However, for every example of sybil that can be identified, there are hundreds that were excluded. ## 16. Has the eligibility list changed since the checker was released? The following are the only changes that have been made to the [airdrop eligibility list](https://github.com/ZKsync-Association/zknation-data/blob/main/eligibility_list.csv) since the checker opened and the CSV file was posted on June 10, 2024: Additions: Security researchers and Crypto The Game participants were included as part of the Contribution-based allocations. However, 56 Cantina researchers and 25 Crypto The Game participants were mistakenly omitted from the final eligibility list. To rectify this oversight, Cantina security researchers were included for claiming starting Monday, June 17 and Crypto The Game participants were included for claiming starting Monday, June 24. It is important to note that the allocations for other security researchers and Crypto The Game participants were not reduced to accommodate the newly eligible wallet addresses. Removals: Matter Labs team members are not eligible for this airdrop. The majority of team member wallet addresses were excluded from the original eligibility list. However, between eligibility and claim, 29 more team member wallet addresses were collected. These addresses are now removed from the CSV. Replacements: An incorrect wallet address was submitted for the AAVE DAO as part of the [ZKsync Native Project allocation](https://docs.zknation.io/zk-token/zk-airdrop#zksync-native-projects). This wallet was updated to reflect the correct address. These are the only changes made to the airdrop eligibility list. No other alterations or exceptions were made. ## 17. How were ZKsync native project and external project allocations determined? As determined by each project, contributors were placed into different tiers based on their level of contribution. Additionally, allocations to contributors of ZKsync native projects were weighted higher than those of external projects. Contributors across the ZKsync native projects and external projects were only eligible for one allocation. When a contributor was submitted for multiple projects, they were assigned to the project type and tier, resulting in the highest allocation. *Disclaimer: Addresses are published in accordance with the* [*Privacy Policy*](https://zknation.io/privacy)*.* # ZK Token Claim FAQs ## How do I mint and claim my ZK token allocation as a part of the ZKsync airdrop? Follow these steps: 1. Head to claim.zknation.io 2. Connect your wallet 3. Click the ‘Claim’ button 4. Delegate your ZK tokens to either a third-party delegate or yourself Claiming will be open until January 3, 2025. ## What is the timeline for claiming my ZK tokens? * General claiming is open from June 17, 2024 at 9 AM CEST to January 3, 2025 at 11:59 PM CEST. * Claiming for certain external projects, Protocol Guild and ZKsync-native project contributors is open from June 24, 2024 at 9 AM CEST to January 3, 2025 at 11:59 PM CEST . * Claiming for GitHub contributors that associated their address after June 13, 2024 at 3 PM CEST is open from June 27, 2024 at 9 AM CEST to January 3, 2025 at 11:59 PM CEST. Note: If your GitHub account is eligible and is not yet associated with an address, follow the steps below by June 25, 2024 at 0:00 CEST. ## Can I still associate an address with a GitHub account to mint and claim ZK tokens? Eligible GitHub developers and ZKsync GitHub discussion helpers must associate their address to their account by June 25, 2024 at 00:00 CEST to claim. Please follow the instructions below. 1. Head to claim.zknation.io 2. Enter your GitHub account name 3. Follow the prompt to connect your GitHub account by logging in 4. Connect your wallet, sign the message to verify that you own the wallet 5. Follow the prompt to connect your wallet to complete the association ## How long does it take to mint and claim my ZK tokens? The entire process should take just a couple of minutes. For the first 4-8 hours, due to heavy traffic, the minting/claiming process may take several minutes. After this initial period, the processing should speed up. Please be patient, all claims will be processed as quickly as possible. ## I keep encountering claiming errors. What should I do? If you receive an error, try closing your browser and starting the process again. If the error persists, you may [manually mint and claim your ZK tokens](https://github.com/ZKsync-Association/zknation-data/blob/main/README.md). ## Can multi-sig wallets (e.g. SAFE) claim ZK tokens? ZK tokens allocated to multi-sig wallets on L1 and L2 cannot be used on claim.zknation.io. To mint/claim the ZK tokens from the ZKsync airdrop from a multi-sig, please follow the [instructions for manual claiming](https://github.com/ZKsync-Association/zknation-data/blob/main/README.md). ## Can I manually claim my ZK tokens? Follow the [instructions provided on GitHub ](https://github.com/ZKsync-Association/zknation-data/blob/main/README.md)to manually claim your tokens. ## I am eligible for allocations that are distributed at different dates. How do I claim each of them? Some addresses can be eligible to claim allocations are different times. For example, the user airdrop and the project contributor airdrop have two different claim dates. To claim at multiple dates, at the end of the claims process, users will see a link to start the claim process for the next allocation. Alternatively, if they reload the screen and recheck eligibility, they will see their eligibility for the next airdrop. ## Can I still claim airdrop tokens if I missed the 3rd January 2025 claim window deadline? After the claim window closes, it is no longer possible to claim the airdrop. ## What happens to tokens that are not claimed during the airdrop window? As the airdrop tokens were not minted, any unclaimed ZK from the airdrop will be added to the balance of total mintable supply under the control of the [Token Assembly](https://docs.zknation.io/zksync-governance/zksync-governance-procedures-overview#id-4.-governance-bodies). These tokens can be distributed via governance on the [Token Governor](https://docs.zknation.io/zksync-governance/schedule-1-standard-governance-procedures#id-4.-token-governor). # ZK 代币常见问题解答 ## 1. 如何获得此次空投的资格？ 地址有两种方式有资格获得17.5% 的空投： 1. 用户（89%）：将加密资产桥接到 ZKsync Era 并满足[七个资格标准](https://docs.zknation.io/zk-token/zk-airdrop#step-1-eligibility)中至少一项的 ZKsync 用户。 2. 贡献者（11%）：无论是否使用 ZKsync 网络，通过开发、宣传、教育或参与为 ZKsync 协议和生态做出贡献的个人、开发者、研究人员、社区和公司。 对于 11% 贡献者类别的钱包，ZKsync Era 活动是可选的。贡献者分配主要针对在 ZKsync 上构建早期项目、为相关 GitHub 存储库做出贡献、进行安全研究、担任 Discord 版主或参与 Degen、Bonsai、Crypto the Game、Pudgy 和 Milady 等社区的人员和社区。 ## 2. 当提到这次是基于使用情况的空投时，这是什么意思？ 基于用户的分配（占空投总额的 89%）主要是为了识别和奖励 ZKsync Era 上的多元化用户群体，他们将帮助长期管理和发展 ZKsync。目标是找到将加密资产连接到 ZKsync Era 的人，并为他们做的表明自己是有机用户的行为提供[乘数奖励](https://docs.zknation.io/zk-token/zk-airdrop#step-3-multipliers)。这样的人很可能成为 ZKsync 社区的宝贵成员。 钱包在各个链上的历史记录可以揭示很多关于其所有者的信息。真正的用户往往更不惧风险，尤其是当他们觉得自己是社区的一部分时。他们会花时间探索、尝试新的协议并持有投机性资产。另一方面，机器人和投机者则谨慎行事，在试图融入社区并获取价值的同时，付出最少的努力。 ## 3. 我满足部分资格要求，但没有获得分配，为什么？ ZKsync 用户空投分配（占空投总量的 89%）基于以下组合： 1. [七项资格标准](https://docs.zknation.io/zk-token/zk-airdrop#step-1-eligibility)中有多少项得到满足。 2. 基于截至快照日期的 12 个月内的时间加权平均余额 (TWAB)，在 ZKsync Era 上桥接和持有的金额（无论是在您的钱包中还是 DeFi 协议中）。这被称为价值缩放（请参阅[问题 5](https://docs.zknation.io/zk-token/zk-token-faq#id-5.-how-does-value-scaling-work)中的详细信息）。 3. 奖金乘数：如果钱包属于预定义组的一部分，例如早期的 ETH 采用者、顶级 ZKsync 原生 NFT/代币的持有者，或 ARB、OP、ENS 等空投的持有者，它将获得分配乘数。 ***重要提示：交易量本身对分配规模没有影响。*** 根据上述标准为用户计算分配金额。为了获得空投分配金额，结果必须大于 ZK 450。 ***这意味着，即使您满足所有七项标准，但您在一段时间内平均持有的金额很少，或者没有资格获得任何其他奖金乘数，您也可能没有资格获得分配。*** | | | | | | --------------- | --------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | 地址 | [0x211cc9b2de4c18523ce2481664596dd2183e966f](https://explorer.zksync.io/address/0x211cc9b2de4c18523ce2481664596dd2183e966f) | [0xbe13dae86c043cb5c2f898cdd3e6342b4880674f](https://explorer.zksync.io/address/0xbe13dae86c043cb5c2f898cdd3e6342b4880674f) | [0xa894aa1dd71960921193bfe3ee5f400dee96c03f](https://explorer.zksync.io/address/0xa894aa1dd71960921193bfe3ee5f400dee96c03f) | | 资格点数 | 3 | 3 | 3 | | 时间加权平均余额 (TWAB) | 50 美元 | 50 美元 | 30 美元 | | 乘数 | 持有 ZKsync 原生 NFT：Dudiez、Hue、Moody Mights、Webears、ZKPENGZ、zkSkulls 或 zkVeggies | 0 | 0 | | 分配 | 5,239 | 1,040 | ~~340~~ 0（未达到 ZK 450 门槛） | ## 4. 我满足四项资格标准，但得到的报酬却比我在 X 上看到的仅满足两项资格标准的某人少。为什么？ 满足的资格标准数量只是决定分配大小的三个因素之一。ZKsync 空投分配是资格标准、ZKsync Era 上的时间加权平均余额 (TWAB) 和奖金乘数的组合。 在这种情况下，另一个人可能将大量加密资产转入 ZKsync Era 并/或将其持有更长的时间。或者，另一个人可能有资格获得奖金乘数之一或成为基于贡献者的空投的一部分，而你却没有。 ## 5. “价值缩放”如何发挥作用？ 为了识别和奖励将加密资产放入 ZKsync Era 平台的用户，分配部分基于价值缩放公式。该公式根据发送到 ZKsync Era 的金额以及这些加密资产在钱包中的时间长短调整地址的分配。 例如，在主网启动时（2023 年 3 月）向 ZKsync Era 发送 100 美元并从那时起持有的地址将比在快照前一个月仅存入 100 美元的地址权重更大。 价值缩放 = 时间加权平均余额 (TWAB) =根据某人桥接的加密资产的价值以及持有时间长短来缩放分配。 提醒：交易量本身对价值缩放没有影响。 想要了解更多信息，请参阅 [这些示例](https://docs.zknation.io/zk-token/zk-airdrop#step-2-allocation) ## 6. 如果我只使用 ZKsync Lite 怎么办？为什么我被排除在外了？ 要获得空投资格，地址必须满足 一项资格标准 并将加密资产桥接到 ZKsync Era。空投的重点是第一条 ZK 链 ZKsync Era，因为它有望成为整个 ZKsync 生态的去中心化枢纽。 ZKsync Lite 用户作为 ZKsync 生态的 OG，最多可以获得 2 个使用 ZKsync Lite 的资格积分。但他们也需要在某个时候在 ZKsync Era 上拥有加密资产。 对于基于使用情况的空投：如果用户只使用了 ZKsync Lite 而没有使用 ZKsync Era，那么很遗憾，他们没有资格获得任何用户空投分配。 *\*Gitcoin 向我们提供了通过 Gitcoin 在 ZKsync Lite 上捐款的用户列表。此列表包含自 2022 年 9 月开始的捐款。* ## 7.为什么有些交易为 0 的地址仍然得到了分配？ 空投分为基于用户的分配（占空投的 89%）和基于贡献者的分配（占空投的 11%）。贡献者类别的钱包不需要在 ZKsync Era 上显示活动。例如，贡献者分配侧重于在 ZKsync 上构建早期项目、为相关 Github 存储库做出贡献、进行安全研究、在 Discord 上管理社区或参与 Degen、Bonsai、Crypto the Game、Pudgy 和 Milady 等社区的人员和社区。 符合 ZKsync Lite 资格条件且在 ZKsync Era 上有桥接资产，但没有其他交易的地址有 184 个，这些钱包符合空投资格。 此外，还为内部质量保证和测试添加了 11 个测试地址。这些地址分配了最低 917 个代币。一旦认领，这些代币将被发送到销毁地址。 0x6adb27812220f1ff5df618e3273d83c430705eec \ 0xb1ded8ff2f7a45f436951f082dda770e1dcee84d \ 0x07528fba97b02bba1aaa03a8ffe51d3fda86b585 0xc527a57ebcc7af699055bb8a3aca917a00a235ed 0x358291b1ea089437a9b16fb8c23d8a035ea7c358 0x023e3e6d98d7a5c7209910ab4ab9f91713dbdc1d 0x65f8dfc419b418ae82f289059d038428d038cd9a 0x6cc3a7f20f0f2f3d3fb5e07f89f7449e6a2537d6 \ 0xae757f4c8aad55712018e6fef0612a091279517a \ 0x5f66edefd2d3d228244d5801911cdccb87df92bc 0x0e602a94192f9da3db92f159a724ea8442916987\ 0x1bf7C517AFF73AD03C28C243ea800E3A7a443Fb9 ## 8. 为什么奖励的是像Degen、Bonsai这样的外部团体，而不是ZKsync用户？ 空投总额的一小部分（2.8%）预留给了实验性的链上社区：Degen 和 Bonsai 的接收者、Crypto The Game、Pudgy 和 Milady。这些社区以其生态的倡导者和热心捍卫者而闻名，与 ZK Nation 有着相同的密码朋克价值观，同时也在尝试创新的自组织方式。这些积极正向的社区对任何网络来说都是宝贵补充，有望成为 ZKsync 的长期成员和守护者。 ## 9. 为什么有些人获得了超过10万个代币？ 100K 是空投基于用户分配的最高奖励（再次占空投的 89%）。155 个地址（0.022%）获得了超过 100K 个代币的分配，因为他们符合最高 用户奖励的资格，并且还符合 贡献者类别 的奖励资格（占空投总额的 11%）。 属于贡献者类别的示例群组：ZKsync 原生项目、GitHub 开发者、安全研究人员、Discord 社区版主、ZK Credo 翻译者等等。 ## 10. 生态中哪些项目有资格获得空投是如何确定的？ 以下项目类别获得了追溯性奖励: 1. 头部 DeFi 协议。ZKsync Era 上按照 TVL 排名的头部 DeFi 协议已证明其致力于在 ZKsync 上进行构建。[DeFi Llama](https://defillama.com/chain/zkSync%20Era)上列出了超过一百个项目，其中包括 TVL 超过 200 万美元的项目。这些项目都致力于用空投分配来进一步促进 ZKsync 上的 DeFi 生态的发展。
2. 头部的社区主导的增长。一直在建立自己的社区并与 ZKsync 生态中的其他社区合作的项目。其中包括游戏、NFT 和 meme 项目。 以下项目类别已获得即将发布的主动分配。这些项目已承诺将其分配奖励重新分配给 ZKsync 社区（请参阅[初始公告推文流](https://x.com/TheZKNation/status/1801378351040307565)）： 3. 即将推出的 ZK 链。这些项目是 ZKsync hyperscaling 愿景的关键早期采用者。 4. DeFi 蓝筹项目。近期上线或即将上线的行业领先的 DeFi 项目。 分配奖励多少的确定取决于几个因素，包括： * 忠诚于 ZKsync 生态作为自己的主要家园。 * 成熟度指标：TVL、社区规模、活跃度。 * 增长潜力。 * 致力于发展 ZKsync 社区。 ## 11. 为什么 TVL 在 2023 年 11 月飙升？ 2023 年 11 月下旬，一头巨鲸向 ZKBase 存入了约 40,000,000 美元。2024 年 1 月初，该巨鲸从协议中取出了这笔钱。你可以在[DeFiLlama上看到这一活动](https://defillama.com/protocol/zkbase#information)。 巨鲸的地址是[0x7929a629ba65491d02756c742f9f7b611e891c16](https://era.zksync.network/address/0x7929a629ba65491d02756c742f9f7b611e891c16) 。 此地址不符合空投资格，因此未获得任何分配。尽管其 TWAB 较高，但不符合任何[资格要求](https://docs.zknation.io/zk-token/zk-airdrop#step-1-eligibility)。即使符合要求，也只能获得最高 100k 的分配。 这个例子体现了空投会优先考虑有机用户而不是巨鲸用户。 ## 12. 为什么要将代币分配给CEX？ 已确定有 4 个 CEX 钱包有资格收到总计 93,677 个代币。 所有符合空投资格的钱包都将根据[资格标准](https://docs.zknation.io/zk-token/zk-token-faq#id-1.-how-could-someone-qualify-for-this-airdrop)获得适当的分配。 他们不太可能申领。 0x4a41d76b0524a3989998380c033f12bfeb5f7201 0x8ae57a027c63fca8070d1bf38622321de8004c67 0xa84fd90d8640fa63d194601e0b2d1c9094297083 0xf89d7b9c864f589bbf53a82105107622b35eaa40 ## 13.我参加了ZK Quest，为什么我没有获得和其他参与者一样多的代币？ 在 ZK Quest 中，参与者根据任务难度和 ZK Quest 平台的成熟度获得分配。分配分为三个层级： * 最高级别：完成 ETHDenver 2024 的所有任务 * 中等级别：在 ETHDenver 2024 上完成至少一项编码任务 * 最低级别：在 ETHDenver 2024 或 DevConnect Istanbul 中完成至少一项任务 ## 14.为什么我在各种空投检查器中表现良好，却没有资格？ 许多空投检查器都专注于以前空投使用的活跃行为指标，例如交易量或消耗的 gas 量。但这些也是众所周知的，并被产业化 sybil 攻击所利用，这使得基于活跃行为的空投对 ZKsync 来说不再可行。官方未曾有声明暗示活跃指标与潜在空投有关。这种方法是为了奖励有机用户：因为网络对他们有价值而使用网络的人，而不是那些试图作弊并榨取价值的人。 产业化机器人农场很容易操纵活跃指标。激进的 sybil 过滤可以有效消除粗浅的的 sybil，但代价是会错误地标记许多有机用户。然而，专业的产业化机器人农场采用了复杂的算法策略，这些策略与真人难以区分。他们从许多不同的交易所地址为账户提供资金，彼此之间从不互动，使用随机金额，并使用软件随机化而模仿人类的日常行为模式，甚至专门执行某个项目独有的活跃行为（例如，使用 ZKsync paymasters）。 此类程序化 sybil 账户的数量总是会远远超过真人账户。因此，基于活跃行为的空投方法会让有机用户处于极大的劣势。到目前为止，空投分配的大部分都会流向专业的 sybil 账户。 ## 15.你们使用了 sybil 检测吗？ 是的。除了独特的空投设计外，还使用了显式的 sybil 检测，为有机用户创造了天然优势。以下是我们对反 sybil 理念的完整概述。 ### **问题** 激进的 sybil 过滤可以有效消除粗浅的 sybil，但代价是错误地标记许多有机用户。然而，专业的产业化农场采用了复杂的算法策略，这些策略与真人难以区分。他们从许多不同的交易所地址为账户提供资金，彼此之间从不互动，使用随机金额，并使用软件随机化而模仿人类的日常行为模式，甚至执行项目独有的活跃行为（例如，使用 ZKsync paymasters）。 即使使用最先进的反 sybil 攻击方法，大多数此类机器人也完全无法被检测到。因此，任何传统的 sybil 攻击所预期的空投设计都会导致绝大多数分配奖励落入机器人农场的手中。 ### **我们的策略** 这就是为什么我们选择了另一条路径：优先考虑那些更有可能属于有机用户的账户。这一策略是通过价值缩放和乘数实现的。 ### **价值缩放（Value scaling）** [价值缩放](https://docs.zknation.io/zk-token/zk-airdrop#step-2-allocation)背后的想法是利用 sybil 和人类之间的不对称，并将其转化为对人类的优势。它基于以下洞察。 sybil 希望分配奖励在所有账户之间或多或少均匀分布，因此他们利用可编程机器人创建比真人一生中创建的账户更多的账户。但由于他们希望以资本高效的方式运营，他们使用非常少量的加密资产为每个账户提供资金。另一方面，真人倾向于将大部分财富集中在少数几个账户中，从而真人用户的余额比机器人大得多。 通过关注余额，价值缩放消除了大多数机器人和机会主义者，从而使绝大多数有机的人类用户不被误伤。 ### **乘数** 仅进行价值缩放还远远不够完美，因为它仍然会错误地消除一些链上资本较少的真实的人。 为了改善这一点，会通过链上行为（如果强烈地表明了真实的人类行为）和堆叠[资格点数](https://docs.zknation.io/zk-token/zk-airdrop#step-1-eligibility)或直接通过[乘数](https://docs.zknation.io/zk-token/zk-airdrop#step-3-multipliers)增加奖励分配。 ### **显式 sybil 检测** 在该过程的最后一步，应用了显式 sybil 检测。可以[在此处](https://docs.zknation.io/zk-token/zk-airdrop#step-4-sybil-detection)查看我们受行业标准策略启发的方法论。 我们调低了传统的 sybil 检测配置，从而降低误伤率。这意味着更多的 sybil 可以通过过滤器，但真人被错误标记为机器人的情况更少。出于同样的原因，我们依赖于一套自己的方法论，而不是未经验证的第三方数据集。这是故意进行的让步。 每次空投都会有 sybil。然而，对于每一个可以识别的 sybil 示例，都有数百个被排除在外。 *免责声明：地址的公布遵循此*[*隐私政策*](https://zknation.io/privacy)*.* # ZKsync Governance 101 ### What does the ZKsync Governance System govern? > Please refer to [ZKsync Governance Procedures: Overview](https://docs.zknation.io/zksync-governance/zksync-governance-procedures-overview) and [Schedule 1: Standard Governance Procedures](https://docs.zknation.io/zksync-governance/schedule-1-standard-governance-procedures) for more information. * **ZKsync Protocol:** The ZKsync Governance System governs the ZKsync protocol. The ZKsync protocol is a series of connected smart contracts deployed on Ethereum and on ZKsync Chains themselves (L2 system contracts). The ZKsync Chains (e.g. Era, Abstract, Lens) are built using the ZKsync Stack toolkit and implemented with the ZKsync protocol. Protocol upgrades are approved by passing a ZIP through the Protocol Governor. * **Token Assembly ZK Token Allocation:** The Token Assembly was given control over 29.3% of the total token supply (21B ZK) at the time of the token launch in June 2024. This allocation is meant to fund initiatives in line with the [ZK Credo](https://docs.zknation.io/zk-nation/mission-zk-credo) and [ZKsync Governance North Star](https://docs.zknation.io/zk-nation/zksync-governance-system-north-star). Proposals that distribute ZK are approved by passing a TPP through the Token Governor. * **“GovOps” via Governance Advisory Proposals (GAPs):** GAPs provide legitimacy to off-chain decisions through onchain Token Assembly Delegate voting (e.g. ratification of standards & policies, elections) ### Elements of ZKsync Governance The ZKsync governance system has 3 Governors, 3 proposal types & 3 governance bodies. **3️⃣ Governors** The ZKsync governance system utilizes three OZ standard Governors: Protocol Governor, Token Governor, GovOps Governor. Read more about each Governor and find contract addresses [here](https://docs.zknation.io/zksync-governance/zksync-governance-procedures-overview#id-6.-standard-governance-procedures). Having three separate Governors allows for more flexibility and customization for each Governor. For example, parameters for the Protocol Governor can differ from parameters for the Token Governor. **3️⃣ Proposal Types** The ZKsync governance system has three types of proposals at inception: * **ZKsync Improvement Proposals ("ZIPs")**: These proposals outline changes to the ZKsync protocol contracts via the Protocol Upgrade Governor. * **Token Program Proposals (”TPPs”)**: These proposals activate new mechanics through which the ZK token is minted and burned by participants who are actively developing the ZKsync ecosystem. * **Governance Advisory Proposals (”GAPs”)**: These proposals specify offchain decisions and actions that require approval by the Token Assembly, but are not directly related to the ZKsync protocol or the ZK token. For example: ratifications, elections, or other decisions requiring onchain voting. All proposals are managed by ZKsync governance smart contracts that operate directly onchain. The parameters of these governors, such as voting periods and timelocks, are specified in the [ZKsync Governance Procedures](https://docs.zknation.io/zksync-governance/zksync-governance-procedures-overview). **3️⃣ Governance Bodies** The ZKsync Governance system is governed by three governance bodies: The Token Assembly, ZKsync Security Council, and ZKsync Guardians. Read more about the three governance bodies [here](https://docs.zknation.io/zksync-governance/zksync-governance-procedures-overview#id-4.-governance-bodies).
### How do the governance bodies interact with each proposal type?
### Where is ZKsync governance deployed? > ℹ️ Find all relevant governance contract addresses [here](https://docs.zknation.io/zk-nation/zksync-governance-contract-addresses). The source code is available in the [zk-governance repo](https://github.com/zksync-association/zk-governance). The ZK token is deployed on Era. Read more [here](https://docs.zknation.io/zk-token/zk-token). All Governor contracts are deployed on Era and Ethereum. * Era: The Governor contracts that allow Token Assembly to voting on proposals. * ZkToken Governor * ZkProtocol Governor * ZkGovOps Governor * Ethereum: Contracts that enable L1 execution of ZKsync Improvement Proposals (ZIPs) * Protocol Upgrade Handler * Emergency Upgrade Board - contracts responsible for accepting approvals from all Governance bodies (ZkProtocolGovernor voting result, Seurity Council, Guardians, Foundation) and making the upgrades. The ZKsync Association was responsible for deploying all governance contracts. This is one reason why the ZKsync Association is considered the “utility provider” for the governance system. ### How are token allocation through governance different at ZKsync than other onchain organizations? #### **Capped Minters** As outlined in [ZK Token page](https://docs.zknation.io/zk-token/zk-token#capped-minters), not all ZK tokens were minted at launch. The total supply of the ZK token is managed in the [ZK token contract](https://explorer.zksync.io/token/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E#contract#read-proxy). ZKsync uses **capped minter** contracts to request to mint new ZK tokens, enabling “just-in-time minting.” Each capped minter receives a maximum number of tokens they are allowed to mint. Anyone with the minter role on a capped minter contract can then mint tokens from that supply whenever they choose to, up to the maximum “cap” specified. This design removes the risks associated with a large treasury and instead shifts the agency of token management to the capped minters. #### **Token Program Proposals (TPPs)** In the ZKsync governance framework, **Token Program Proposals (TPPs)** are used to assign minting and burning rights of ZK tokens to specified capped minters, and activate new token mechanics. A program can have one or multiple capped minters. It is also possible to nest “child” capped minters under “parent” capped minters. Learn more about capped minter V3 contracts [here](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps/capped-minters-101#zk-capped-minter-v3). Capped minters for a program have to be deployed before a TPP is submitted onchain. Capped minters can be assigned an admin, cap, start and stop time upon deployment. Learn more about how to deploy a capped minter in the V3 factory [here](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps/capped-minters-101). Capped minters are granted the MINTER role from the ZK token contract when the Token Assembly successfully passes a TPP.
#### **Token Programs Standards** Token Program design standards are different than funding proposals in other ecosystems. Key elements of Token Program standards: * Support Governance North Star metrics / Token Assembly Priorities (see GAP-1) * Reward onchain, verifiable metrics * Automation in distribution > reduction of reliance on manual execution * Rewarding multiple participants working towards similar goal/metric > rewarding one specific party Read more about Token Programs, token mechanics in this [TPP FAQ](https://forum.zknation.io/t/tpp-frequently-asked-questions/141) and the [TPP Guidelines](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps) in the docs. # Delegating ZK Voting Power The ZK token is used in the ZKsync governance system to provide voting power to participants through the process of delegation. Each ZK token holds 1 vote. To activate the voting power of your ZK tokens, a token holder must delegate the voting power of their tokens to a ZKsync address. This address can be your own or a third-party. Once an address is delegated voting power, the controller of that address becomes a Delegate who is able to vote on governance proposals. ### How Delegation Works * Delegating token voting power does not change the ownership of ZK tokens, but simply activates the voting power of ZK tokens and provides that voting power to an address chosen by the token holder. * Delegation can be changed at any time by the token holder on [delegate.zknation.io](http://delegate.zknation.io/). Once token voting power is delegated, the delegation will persist until it is changed or the tokens are sold or transferred to a different address. * Delegation cannot be split across multiple addresses. Once delegated, all voting power held in one wallet is delegated to a single address. * ZK token voting power can only be delegated by the wallet owner. Tokens held within wallets on centralized exchanges cannot be delegated. * Delegates who create a profile before Saturday June 15th at 11:59pm UTC will be eligible for consideration to be included in the ZK token claim flow. ### Why Delegating is Important Delegation activates ZK token voting power. If an ecosystem requires an active Delegate base to meet quorum and approve governance proposals. Through delegation, it is possible for someone who does not own any ZK tokens to hold voting power without acquiring ZK tokens directly. This increases participation in ZKsync governance. If you are are interested in participating as a Delegate, visit [Getting Started as a ZKsync Delegate](https://forum.zknation.io/t/getting-started-as-a-zksync-delegate/104) for more information. ### Delegating through Governance Portals * Visit [vote.zknation.io](https://delegate.zknation.io/dao) * Connect your wallet & sign in if prompted * Check you are on the ZKsync Era Mainnet network * Select the "Delegate" button on the right-hand side of the screen * Select who you want to delegate to: "Myself" or "Someone else" * If delegating to yourself, sign the transaction to execute self-delegation * If delegation to another address, enter the address and sign the transaction to execut delegation ### Delegating through Safe UI * Login to your [Safe wallet](https://app.safe.global/welcome/accounts) and select "New transaction" in the top left corner. * Select "Transaction Builder" * Enter the ZK token contract. All governance contracts can be found on the [ZKsync Governance Conract Addresses](/zk-nation/zksync-governance-contract-addresses) page. Once the address is entered, the ABI should load automatically. * Scroll down the page and change the *Contract Method Selector* input. Change it to `delegate` * Enter the address of the Delegate you would like to delegate to (yourself or another Delegate) * Select “Add new transaction” * Select “Create branch” in top right and follow the instructions in the Safe UI to review and execute the transaction > For more details on how to delegate your voting power on Cactus, [see this guide](https://docs.tally.xyz/how-to-use-tally/delegate-on-tally/). # Voting on Proposals Delegates who have been delegated ZK token voting power can vote on ZKsync governance proposals. See the different ways Delegates can vote on proposals below. [Click here](https://docs.zknation.io/voting-and-delegation/zk-token-delegation) to learn more about delegation. ### Voting through Governance Portals Delegates can interact with ZKsync contracts through specialized website applications called governance portals. Currently, there are two primary governance portals connected to ZKsync governance contracts: 1. **Cactus:** The ZKsync Tally Governance Portal is owned and managed by the ZKsync Association. You can access the portal at [vote.zknation.io](http://vote.zknation.io). Follow [these steps](https://docs.tally.xyz/how-to-use-tally/use-tally-as-a-safe-multisig/) to vote with a multisig on Cactus. 2. **alt.vote.zknation.io:** This interface offers an alternative to the Tally interface. You can access the portal at [alt.vote.zknation.io](http://alt.vote.zknation.io/). ### Voting through the ZKsync Era Block Explorer Besides governance portals, anyone can interact with ZKsync governance contracts on the [ZKsync Era Block Explorer](http://explorer.zksync.io). Follow these steps to vote: #### Step 1: Select the Right Governor Navigate to the right governor contract by pasting the relevant governor contract address into the ZKsync Era Block Explorer search bar. * For Protocol Upgrade Proposals (or “ZKsync Improvement Proposals”), use the Protocol Governor address. * For Token Program Proposals, use the Token Governor address. * For Governance Advisory Proposals, use the GovOps Governor address.
#### Step 2: View Governor Contract * Navigate to the “Contract” tab * Select “Write”
#### Step 3: Find the Right Proposal * Identify the proposal ID, for example on Cactus
#### Step 4: Prepare Vote * Go back to the Governor Contract / Write as Proxy * Go to “castVote” function OR “castVoteWithReason” * Paste the Proposal ID * Vote FOR the proposal by assigning a value of `1` OR * Vote AGAINST the proposal by assigning a value of `0` OR * Vote ABSTAIN the proposal by assigning a value of ‘2’ * If you called the function `castVoteWithReason` add a string of text with your comment
#### Step 5: Complete Vote * Make sure to “Connect Wallet” * Then, click on “Write” * Complete the transaction ### Voting through Safe UI If you are voting with a Safe multisig, in addition to voting through [vote.zknation.io](http://vote.zknation.io), you are able to cast your vote through the Safe UI. Follow these steps: #### Step 1: Login to your Safe Wallet Login to your [Safe wallet](https://app.safe.global/welcome/accounts) and select "New transaction" in the top left corner.
#### Step 2: Select the right Governor Enter the right governor contract by pasting the relevant governor contract address into the ZKsync Era Block Explorer search bar. All governor contracts can be found on the [ZKsync Governance Cotnract Addresses](/zk-nation/zksync-governance-contract-addresses) page. * For Protocol Upgrade Proposals (or “ZKsync Improvement Proposals”), use the Protocol Governor address. * For Token Program Proposals, use the Token Governor address. * For Governance Advisory Proposals, use the GovOps Governor address. Once the address is entered, the ABI should load automatically.
#### Step 3: Select Action * Scroll down the page and change the *Contract Method Selector* input. Change it to `castVote` or `castVoteWithReason` if you prefer to leave a note on why you voted a certain way.
#### Step 4: Find the right proposal * Identify the correct proposal ID, for example on Cactus
#### Step 5: Prepare Vote * Fill out the remaining parameters: * Paste the Proposal ID * In the *Support* input, enter one of the following: * Vote FOR the proposal by assigning a value of `1` OR * Vote AGAINST the proposal by assigning a value of `0` OR * Vote ABSTAIN the proposal by assigning a value of `2` * If you called the function `castVoteWithReason` add a string of text with your comment #### Step 6: Complete Vote * Select "New Transaction" at the bottom of the page * Select "Create Batch" in the top right corner * Follow the instructions in the Safe UI to review and execute the transaction
# Proposal Type Overview What is the standard proposal process for each proposal type? Each proposal type has their own specific process given the parameters set on the governor and differences in the execution process. The proposal standard processes for each proposal type are outlined in [Schedule 1: Standard Governance Procedures](https://docs.zknation.io/zksync-governance/schedule-1-standard-governance-procedures). **Proposal Parameters Overview**
> ℹ️ Learn more about the [voting extension period](https://forum.zknation.io/t/understanding-the-voting-extension/698) and how it works for each proposal type. **ZIP Process & Timeline**
**TPP Process & Timeline**
**GAP Process & Timeline**
#### What is the proposal process for emergency upgrades? The proposal standard processes for each proposal type are outlined in [Schedule 2: Emergency Response Procedures](https://docs.zknation.io/zksync-governance/schedule-2-emergency-response-procedures)**.**
# ZKsync Proposal Guidelines ### How do I submit a ZKsync governance proposal? Proposals are submitted onchain on the [ZKsync Governance Portal](https://vote.zknation.io/dao) (via Cactus - formerly Tally) or on other applications connected to ZKsync governance contracts. To submit a proposal, Delegates must meet the proposal submission threshold of 0.1% or 21 million ZK of the total ZK token supply (21 billion). If a Delegate does not meet the threshold, or the author is not a Delegate, they can find a Delegate to sponsor and submit the proposal on their behalf. Delegate profiles can be viewed at [delegate.zknation.io](http://delegate.zknation.io). ZKsync Governance Proposals pass a vote if delegates reach quorum, defined as 3% or 630 million ZK voting power in support of the proposal, AND have a simple majority of “For” votes (>50%). Each proposal must also be consistent with the values of the[ ZK Credo](https://docs.zknation.io/zk-nation/mission-zk-credo) and support the sustainable development of the ZKsync protocol and must not violate applicable law. Otherwise, it may be vetoed by the ZKsync Guardians or may be removed from the ZKsync governance portal. ### What should I do before submitting a proposal onchain? Delegates should submit a proposal onchain after the idea has been shared widely with the ZKsync community. Delegates are encouraged to: 1. Refine the idea with a working group of 2-5 people. 2. Develop a draft proposal, informed through conversations and research, and post it on the [ZKsync Governance Forum](https://forum.zknation.io/) under the relevant category (will depend on proposal type). 3. Use the ZKsync Governance Forum, social media, and Delegates to gather feedback and create awareness of the proposal idea, draft, or full proposal. 4. Gather informal voting commitments from other Delegates in the ZKsync community. Delegate profiles can be viewed at [delegate.zknation.io](http://delegate.zknation.io). 5. Submit the proposal onchain via the [ZKsync Governance Portal](https://vote.zknation.io/dao), or an alternative application connected to ZKsync governance contracts. ### How do I add an onchain action to a proposal on Cactus? You can add the necessary onchain actions on Cactus as part of the onchain proposal. To do so, visit the “Actions” section of the proposal creation flow on Cactus. Then select “Custom action” and upload the necessary Application Binary Interface (ABI) file. The ABI file describes the methods and variables within a smart contract that are accessible and callable by external users or other smart contracts. You can read more about Cactus’s onchain actions [here](https://docs.tally.xyz/).
### Removal of Proposals from Portal ZKsync governance proposals can be viewed on the ZKsync Governance Portal powered by Cactus. However, some proposals may be removed and become unavailable on the portal if the proposal: 1. is deemed illegal under Austrian law 2. enables access to ZK tokens by prohibited addresses, including those associated with sanctioned entities, individuals, or jurisdictions, as well as addresses linked to illicit activities like fraud, money laundering, terrorist financing, or other criminal enterprises. Any proposal removed from the ZKsync Governance Portal powered by Cactus may continue to be accessible via services not owned or managed by the ZKsync Association. # ZKsync Improvement Proposals (ZIPs) ### What is a ZKsync Improvement Proposal (ZIP)? ZKsync Improvement Proposals (ZIPs) include all proposals submitted through the ZKsync [Protocol Governor](https://github.com/zksync-association/zk-governance/blob/master/l2-contracts/src/ZkProtocolGovernor.sol). The Protocol Governor is a smart contract deployed on ZKsync Chain Era, and ZIPs are used to propose upgrades to the ZKsync protocol. Protocol Governor proposals are executed through the transmission of a message from ZKsync to Ethereum. ### Types of Protocol Upgrades The Protocol Governor is responsible for executing proposals related to: * Upgrades to the ZKsync protocol * Upgrades to the Protocol Governor, Token Governor, and GovOps Governor * Upgrades to the ZK token contract * Upgrades to the Security Council Multisig (i.e. to the Security Council and Security Council members) * Upgrades to the Guardian Multisig (i.e. to the Guardians and Guardian members) * ZKsync Layer 2 Era upgrades ### What information should I include in a ZIP? A ZKsync Improvement Proposal should include all the necessary information for ZKsync Delegates to make an informed decision and vote on the proposal. The proposal length and detail should align with the impact of the ZIP. **All ZIPs should include:** * MOTIVATION: Detail why this ZIP is necessary and what issues or opportunities it seeks to address within the ZKsync ecosystem. Discuss the benefits of the proposed changes to users and developers. Read more [here](https://docs.zknation.io/zk-nation/zksync-governance-system-north-star). * SPECIFICATION: The technical specification should describe the syntax, semantics, and any new components. This section should be precise enough to enable developers to implement the change. * RATIONALE: Discuss the rationale behind the design decisions and the approach taken. Explain why key choices were made and describe alternative solutions that were considered, if appropriate. * BACKWARDS COMPATIBILITY: Discuss any backward compatibility issues. Describe the impact of the proposed change on existing applications, contracts, or the broader ZKsync protocol, highlighting how backward compatibility is handled or why breaking changes are necessary. * SECURITY CONSIDERATIONS: Examine the security aspects related to the proposal. Discuss potential threats, risks, and vulnerabilities, and explain how they are addressed or mitigated. > ✍️ TEMPLATE: Proposers are encouraged to follow the standard proposal template for ZKsync Improvement Proposals, available [here](https://github.com/zksync-association/governance-resources/blob/main/proposal-templates/01_zip_template_protocol_governor.md). *NOTE: We recommend all documentation is included in the onchain proposal, or linked with an onchain source such as Arweave, IPFS, etc. This allows the proposal content to be public and accessible across web3 applications.* # ZIP FAQ > Find full technical documentation for the ZKsync protocol at [zksync.io](http://zksync.io). ### How can a ZIP upgrade the ZKsync Protocol? The Protocol Governor contracts (L2) have a direct link to “protocol upgrade handler” for the ZKsync protocol that is deployed on L1. The ZIP improvement proposals (ZIPs) give instructions to the protocol upgrade handler on L1, and the upgrade handler executes changes on L1 & L2 contracts. ### What is included in the “core” ZKsync protocol? * [L1 contracts](https://docs.zksync.io/zksync-protocol/contracts/l1-contracts): a set of contracts that powers interaction with the rollup on Ethereum. (e.g. Verifier Contract) * [System contracts](https://docs.zksync.io/zksync-protocol/contracts/system-contracts): a set of contracts deployed on L2 that are responsible for various protocol functions. (e.g. L1 Messenger, Default Account Contract, Storage Management Contract) * [Bootloader](https://docs.zksync.io/zksync-protocol/contracts/bootloader): Part of the execution environment in which all the transactions are executed on L2. * Proof System * ZK circuits: ZK circuits generate cryptographic proofs (e.g., zk-SNARKs or zk-STARKs) that attest to the validity of batched state transitions on L2. These ensure that all operations on L2 are valid without needing to replicate the computational workload on L1. Read more [here](https://docs.zksync.io/zksync-protocol/circuits). ### What is the upgrade handler? The [upgrade handler](https://etherscan.io/address/0xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3) is the owner of State Transition Managers & owner of L1 shared bridge, bridge hub & other contracts (e.g USDC bridge or L2 bridge counterparts). ### What is the Change Type Manager? A [Change Type Manager (CTM)](https://docs.zksync.io/zksync-protocol/contracts/l1-contracts/l1-ecosystem-contracts#state-transition-manager-stm) is a critical component designed to handle and coordinate the execution of operations that span between Layer 1 (L1) and Layer 2 (L2). It serves as a factory to deploy ZKsync Chains, and it is responsible for ensuring that all the ZKsync Chains deployed by it are up-to-date. It ensures that all state transitions comply with the ZKsync protocol's rules and guarantees data consistency, and ensures consistency, validity, and synchronization across these layers. All current ZKsync Chains are deployed to the main ZKsync CTM. ### What are the different types of state changes that a ZIP can include? * Type 1: Protocol upgrade that *does not* affect ZKsync Chains * Example: Changes to Governor parameters (e.g. change voting delay from 7 days to 3 days) * Type 2: Protocol upgrade that *does* affect ZKsync Chains, but *does not* require action * Example: Upgrading bridge functionality, Upgrading bridge functionality, adding new State Transition Managers, Adding a new ZKsync Chain with a custom state (e.g. [ZIP-7 Lens Chain inclusion on Elastic Network](https://vote.zknation.io/dao/proposal/53064417471903525695516096129021600825622830249245179379231067906906888383956?govId=eip155:324:0x76705327e682F2d96943280D99464Ab61219e34f)) * Type 3: Protocol upgrade that *does* affect ZKsync Chains *AND* requires an action from ZKsync Chains * Example: Any protocol version change (e.g. [ZIP-3 Protocol Defense](https://vote.zknation.io/dao/proposal/39897055470405054808751466940888279812739313934036970931300785151980460250983?govId=eip155:324:0x76705327e682F2d96943280D99464Ab61219e34f)) ### For ZIPs that do require action from ZK Chains, what does that look like? **Standard Case:** If a state-change protocol upgrade to the ZKsync protocol is successfully approved via a ZIP, each individual ZKsync Chain admin will have to upgrade to the new version by set deadline, otherwise a chain that doesn’t upgrade will not be able to commit new batches. A few examples: * Circuit upgrade: If there is an upgrade of ZK circuits from 1.0 to 2.0, you are changing what is enshrined in L1 but also updating all parameters of ZKsync chains to adopt new proof generation process. * Interop: When interop arrives and if it the upgrade passed through governance, all chains will have Interop: Interop will be introduced in the v29 protocol upgrade. If approved by the Token Assembly, ZKsync Chains who want to access interop will have to be on v29 to use it. However with later upgrades, ZKsync Chains who remain on v29 will still be able to send interop to v30+ Chains. **Defensive Case (governance force upgrade)**: In the case of an emergency, a protocol upgrade approved by governance may force an upgrade to a specific chain or all Chains. * Example: Emergency upgrade needed to fix circuit bug that allows bad batch to be proven even if it is not proven. ### Can ZKsync Chains opt out of an upgrade that is approved by the passing of a ZIP? It is possible to run an outdated version as long as it has not been disabled, but it is not recommended to be more than 1 version behind the latest version. The dev team who proposes the ZIP should always provide clear deadlines as to when ZKsync Chains should upgrade to the latest version. ### What are the exact list of params that the ZKsync Chain admin have control over? Can these be impacted by ZIPs? Every ZKsync Chain has an admin contract known as the ChainAdmin. The roles each ChainAdmin of a ZKsync Chain has can be [found here](https://docs.zksync.io/zk-stack/running/ownership-model#roles-overview) > ℹ️ ZIPs currently cannot impact these parameters. # Token Program Proposals (TPPs) ### What is a ZK Token Program Proposal (TPP)? Token Program Proposals (TPPs) include all proposals submitted through the ZKsync [Token Governor.](https://github.com/zksync-association/zk-governance/blob/master/l2-contracts/src/ZkTokenGovernor.sol) Token Programs assign minting and burning rights of ZK tokens to specified capped minters, activating new mechanics to distribute the ZK token. All TPPs should be aligned with these guidelines to help achieve the goals supporting the vision of the ZK Credo. > ℹ️ Learn more about ZKsync strategic priorities by visiting the [ZKsync Governance North Star](https://docs.zknation.io/zk-nation/zksync-governance-system-north-star) and [GAP-1: ZKsync Token Program Priorities 2025 v1.0](https://vote.zknation.io/dao/proposal/13823050748058617424077595486689751986818771098977300222700522842013613046754?govId=eip155:324:0x496869a7575A1f907D1C5B1eca28e4e9E382afAb). ### What is a capped minter? [Capped minters](/zksync-governance-proposals/token-program-proposals-tpps/capped-minters-101) are unique smart contracts of the ZKsync ecosystem that allow for “just-in-time minting.” Each capped minter is assigned a maximum number of tokens, known as the “cap,” which is allowed to be minted. Those with the minter role of a capped minter can mint tokens from that supply whenever they choose to, up to the maximum specified. How is this relevant for governance? Unlike other token launches, not all ZK tokens were minted upon the launch of the ZK token. In other words, there is no token treasury. Instead, the Token Assembly grants minting rights to administrators of Token Programs. The Token Assembly has access to 29.3% of the total token supply, as defined during the token launch. This design removes the risks associated with a large treasury and instead helps shift the agency of token management to the final token recipient. > ℹ️ Learn more about the [benefits of capped minters](https://forum.zknation.io/t/understanding-key-benefits-of-capped-minters/686). > ℹ️ Token Programs must use the latest version of the [ZK capped minter (currently V3)](https://forum.zknation.io/t/introducing-zk-capped-minter-v3/934) contracts and factory. Once deployed, the contracts and admin multisig (if applicable) must have at least one security review by a Security Council member or reputable security firm. ### What is a token mechanic? Token mechanics are a series of smart contracts executing ZK token allocations based on pre-determined, (onchain) verifiable criteria. A capped minter is the core building block to any token mechanic. Token mechanics programmatically enforce process rather than having to manually manage it. They also help reduce management multisig signer responsibilities & coordination. > ℹ️ Learn more about token mechanics and TPP standards in the [TPP FAQ](https://forum.zknation.io/t/tpp-frequently-asked-questions/141). ### What information should I include in a TPP? A ZK Token Program Proposal should include all the necessary information for ZKsync Delegates to make an informed decision and vote on the proposal. The proposal length and detail should align with the scale of the ZK Token mechanic and accountability measures. **All TPPs should include:** * IMPACT: Describe how the token program will impact one of the [ZKsync Governance North Star metrics](https://docs.zknation.io/zk-nation/zksync-governance-system-north-star) and what metrics it will use to measure success. Please also reference other guiding documents such as a technical roadmap or annual priorities for the Token Assembly. * MECHANIC: Token Programs should deploy self-executing smart-contracts that are designed to distribute tokens autonomously based on predefined conditions or metrics ("mechanics"). Every mechanic should support ZKsync adoption and innovation, and include the following: * A token model that describes how the mechanic uses and distributes ZK to achieve the Token Program objectives. Use this as a template to start with: “This TPP deploys a(n) \[Mechanic Type] smart-contract supporting \[North Star Metric] that allocates ZK tokens based on \[Onchain Action Eligibility/Metric]” * All allocations, including: * Program Rewards: ZK being distributed to qualifying participants * Proposal Success Rewards: Token allocations as a reward for code development, code audits, and coordination efforts leading to a successful vote on the proposal. * Mechanic Usage Fees: Token allocations necessary to cover the program’s smart contracts fees over the course of the program. * Administration: Token allocations related to SteerCo member participation, program monitoring, and other management. * Security Review: Token mechanics and capped minter structures should link to relevant security reviews and audits from Security Council members or another vetted organization. * PLAN: Outline a long-term project plan (for example 6-months to 2+ years) with outcomes, milestones, and deliverables aligned to the ZKsync Governance North Star, endorsed ZKsync Strategic Priorities, and the ZK Credo. * Specify KPIs supporting those outcomes and the overarching vision of the Token Program. Include how those KPIs will be measured (e.g. onchain, elsewhere). * Explain the permissionless pathways available for public participation. For example, address questions like: how is the program composable?, what standards does it follow?, will there be a public communication channel?, and what projects are available for contributors? * ACCOUNTABILITY FRAMEWORK: Specify what methods will hold the program, mechanic, operations, and participants accountable for their commitments. For example, this can include items such as: * **Public Reporting:** Publishing of consistant reports for transparency of progress and updates * **Onchain Token Allocation Tracking:** Token allocations are publicly available by default, but some programs may include additional analytics tracking. * **Token Assembly oversight:** The Token Assembly may cancel the program at any point via a Token Program Proposal. See [Token Program Cancellation](/zksync-governance-proposals/token-program-proposals-tpps) below. * **Legal Contracts:** All Program Administrators (multisig signers), program service providers and directly listed recipients of ZK tokens in any given proposal will be required to contract with ZKGPS and complete KYC/KYB. [Learn more about ZKGPS here](/legal/zksync-governance-program-systems-zkgps). > ✍️ TEMPLATE: Proposal authors are encouraged to follow the [standard proposal template for Token Program Proposals](https://github.com/zksync-association/governance-resources/blob/main/proposal-templates/02_tpp_template_token_governor.md).\ > \ > ✍️ MULTISIG CONFIGURATION: All multisigs related to Token Programs must conform to industry best practice. [Multisig guidelines are available on the ZKsync Association Github repository for review.](https://github.com/zksync-association/governance-resources/blob/main/MultisigGuide_TokenProgram.md) > ℹ️ *NOTE: All documentation should be included in the onchain proposal, or include links to an onchain source such as Arweave, IPFS, etc. This allows the proposal content to be public and accessible across web3 applications.* ### Calldata Preparation The design of the mechanic and what address is set as the admin will determine what calldata is needed for the onchain proposal. Below are a few general rules: 1. All parent capped minters in the mechanic need to be granted the minter role from the ZK token contract. 2. Depending on who the admin is on each capped minters will also impact what calldata is needed: 1. Calldata for proposal with multisig as admin on parent: 1. Grant minter role from ZK token contract to parent 2. Calldata for proposal with Token Governor Timelock as admin on parent: 1. Grant minter role from ZK token contract to parent 2. Grant minter role from ZK token contract to child 1 3. Grant minter role from ZK token contract to child 2 4. Grant minter role from ZK token contract to… ### Token Program Cancellation A Token Program can be cancelled by the Token Assembly or the Token Program managers. * **Onchain cancellation by Token Program managers:** * **Cancellation Process:** Program Managers deactivate capped minter contract according to its version: * **CappedMinterV1:** Transfer control of all capped minter admin multisigs to the burn address. To transfer control of a multisig to a burn address, propose a transaction that adds the burn address as the sole owner (0x0000000000000000000000000000000000000000). Then, in either the same or a following transaction, remove all signers except the burn address. Since no one controls the private key, no future actions are possible. * **CappedMinterV2:** Call the `cancel` method on the contract to permanently revoke all roles. * **Prior to onchain cancellation:** All final token disbursements, legal contracts review, and forum communications should be completed prior to on-chain cancellation. * **Forum Communication:** The Token Program manager should provide a clear rationale for the cancellation of the program via the official governance forum. The communication should include relevant timelines. Program cancellation plans should be shared a month in advance. * **Legal Contracts Review:** Token Program managers are responsible for liaising with the ZKsync Association and ZKGPS to review the program’s legal agreements. For example, to terminate applicable service-provider contracts. * **Final Disbursements:** Token Program managers must execute final disbursements for any work completed to date, ensuring distributions are made within a reasonable timeframe. All tokens minted under a Token Program's capped minter must be allocated according to the terms of that program. Unallocated minted tokens cannot be returned to the Token Assembly. Program managers should publish a detailed accounting report detailing all final allocations to all program service provider and token program participants. * **Onchain cancellation by Token Assembly:** * **Cancellation Process:** Submit and execute a TPP onchain to revoke the ZK Token minter role from active capped minters for specific program. The proposal should provide a clear rationale for the cancellation of the program. * **Prior to onchain cancellation:** * **Forum Communication:** The ZKsync Delegate submitting the proposal should follow the standard guidelines in proposal submission, including publishing a forum post with the program cancellation proposal details. * **Legal Contracts Review:** If quorum is met and approval is expected, Token Program managers are responsible for liaising with the ZKsync Association and ZKGPS to review the program’s legal agreements. For example, to terminate applicable service-provider contracts. * **Final Disbursements**: If quorum is met and approval is expected, the Token Program managers are responsible for executing final disbursements for work-to-date prior to the execution of the cancellation proposal onchain. Upon execution of the cancellation proposal, no further tokens may be minted under the canceled Token Program. All tokens minted under a Token Program's capped minter must be allocated according to the terms of that program. Unallocated minted tokens cannot be returned to the Token Assembly. Program managers should publish a detailed accounting report detailing all final allocations to all program service provider and token program participants. # TPP FAQ ### What onchain actions can I deploy with a TPP? Delegates need to include the appropriate onchain action in their proposal to successfully connect ZK tokens to a Token Program mechanic. An onchain action is represented by a hexadecimal value known as *calldata*. The calldata, or executable payload, instructs the ZKsync Token Governor Timelock (further details linked below) to give access to ZK Tokens. The approval of a Token Program Proposal allows a specified address to mint ZK tokens (up to the capped amount) or mint and directly transfer them to a designated recipient. This is done by granting the MINTER role to the address of a designated capped minter via the Token Governor Timelock. * **Minter Address Approval (most common):** Token Governor acts as MINTER\_ADMIN. The Delegate proposer specifies an address, such as a ZkCappedMinter contract, to act as MINTER. A specific agent (individual, entity, or autonomous code) represented by an Ethereum address can then mint tokens via the approved address. * **Direct Mint:** Token Governor Timelock contract acts as MINTER. The Delegate proposer specifies the recipient of the ZK Token (\_mintReceiver) and the ZK Token amount (\_mintAmount). The Token Governor then mints tokens directly to that address. For more information about the ZKsyncTokenGovernor, Timelock Contract, and ZK Token, you can visit . > ℹ️ Proposals will be removed from the ZKsync Governance Portal if they enable access to ZK tokens by prohibited addresses, including those associated with sanctioned entities, individuals, or jurisdictions, as well as addresses linked to illicit activities like fraud, money laundering, terrorist financing, or other criminal enterprises. ### **Onchain Action Example 1: Minter Address Approval for up to 100 ZK tokens** Minter Address Approvals are expected to be the most common method to access ZK tokens. Minter Address Approvals allow specific mechanics to mint tokens on demand. By minting on demand, mechanics reduce dependencies on custodial services. Minting on demand can also have other benefits, such as reducing security risks, ensuring that the tokens have a clean history, and allowing recipients to choose the time and place of minting, which may help them clarify the tax treatment of their tokens. **Example Proposal:** 1. Alice submits a Token Program Proposal for Minter Address Approval. If the proposal is approved, then “MechanicManager *can* Mint *a maximum of* 100 ZK” 1. ZKTokenGovernor-Timelock acts as `MINTER_ADMIN` for ZK token contract ([ZKtokenV2.sol](https://github.com/zksync-association/zk-governance/blob/master/l2-contracts/src/ZkTokenV2.sol)) 2. Mechanic\_ZKCappedMinter is set as `MINTER` role of ZKtokenV2.sol 3. MechanicManager is set as `ADMIN` of Mechanic\_ZKCappedMinter 1. Note: Capped Minter has immutable Cap, which cannot be changed by `ADMIN` or any other party 2. Alice's Token Program Proposal has calldata that: 1. Calls `_grantRole` on ZKtokenV2.sol 2. Assigns `MINTER_ROLE` to Mechanic\_ZKCappedMinter 1. The Mechanic\_ZKCappedMinter is a separate smart contract deployed prior to proposal submission. To ensure quality of the smart contract, Mechanic\_ZKCappedMinter bytecode hash should match . An example can be viewed on the [ZKsync Block Explorer](https://era.zksync.network/address/0x00D3dc9676572d04665A64Ee72A78cF0358F6382#code), using the [deployment logs](https://www.notion.so/FINAL-Token-Governor-Proposal-Submission-Guidelines-NEW-SUBPAGE-1d697013caf546dabbebb9f8aeaefecd?pvs=21) which specify the `ContractDeployed` event with `bytecodeHash` of `0x0100007911f29707ff4a93ecdc84a682cbc3969469865c43bb233b35c3068b24` 2. The Mechanic\_ZKCappedMinter parameters would be set as follows for this proposal: 1. TOKEN = \[ZK Token Contract]; 2. ADMIN = MechanicManager; 3. CAP = 100; 3. If Alice's proposal passes, then MechanicManager can mint 100 ZK tokens through the Mechanic\_ZKCappedMinter after the proposal transaction is executed onchain. ### **Onchain Action Example 2: Direct mint of 100 ZK tokens** Direct minting should be used if the mechanic requires ZK tokens to be immediately minted. For example, a novel Token Program Proposal may require staked ZK tokens at inception, or swapping ZK tokens for another digital asset immediately upon proposal approval. **Example Proposal:** 1. Alice submits a Token Program Proposal for Direct mint. If the proposal is approved, then “MechanicManager receives 100 ZK” 1. ZKTokenGovernor-Timelock acts as `MINTER` for ZKtokenV2.sol 2. Alice's Token Program Proposal has calldata that: 1. Sets `_mintReceiver` as MechanicManager 2. Sets `_mintAmount` to `100` 3. Calls `_mint(_mintReceiver, _mintAmount)` 3. If Alice's proposal passes, then MechanicManager receives 100 ZK tokens when the proposal is executed. 4. Should Alice be assigned the `ADMIN` role of the MechanicManager, then Alice can manage funds as specified in the MechanicManager. > ℹ️ If you need support drafting the executable proposal code for your proposal, please reach out to the ZKsync Association for support at [forum.zknation.io](http://forum.zknation.io/). ### Are token programs the right channel to ask for grants? Token programs are intended to be for mobilizing large and long-term mechanics, not grants. In other words, token programs should launch self-executing smart contract designed to distribute tokens autonomously based on predefined conditions or metrics. If you have an idea for a grant, transform it into a ZK token mechanic supporting a specific [ZKsync goal and KPI](https://docs.zknation.io/zk-nation/zksync-governance-system-north-star). ### What tools are available for token mechanics? The ZK token is an ERC20 token and is compatible with common web3 tools. To better understand the possibilities in autonomous token flows, you can connect with organizations such as: * Drips () * Hedgey () * Hats () * MetaLex () * Merkl () * Sablier () * Superfluid () > ℹ️ You can also check out the [TPP Builders](https://forum.zknation.io/c/token-mechanics/tpp-builders/43) section of [forum.zknation.io](http://forum.zknation.io) for more potential technical tools and partners for token mechanic development. ### Can the Token Assembly change the total supply cap via a governance proposal? * The ZKsync Token Assembly could submit a proposal through the Protocol Governor to propose to change the 21B ZK total supply cap. # Capped Minters 101 ### What are Capped Minters? Capped minters are unique smart contracts of the ZKsync ecosystem that allow for “just-in-time minting.” Each capped minter is assigned a maximum number of tokens, known as the “cap,” which is allowed to be minted. Those with the minter role of a capped minter can mint tokens from that supply whenever they choose to, up to the maximum specified. [Learn more about how Capped Minters](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps#what-is-a-capped-minter) are used in ZKsync token governance. ### ZK Capped Minter V3 The current version of the capped minter contract is the [ZKCappedMinterV3](https://github.com/zksync-association/zkminters/blob/main/src/ZkCappedMinterV3.sol). The ZK Capped Minter V3 expands the limited functionality of V2. **ZK Capped Minter V3 Features Overview:** * **Minting Cap:** Like V2, the ZK Capped Minter V3 enforces a strict upper limit on the total number of tokens that can be minted, ensuring controlled token allocations. * **Multiple Minters:** Uses role-based permissions to manage minting rights, enabling the immutable admin to assign multiple minters for the capped minter. * **Nested Minters:** As a result of the minter role, token programs can have hierarchies of nested capped minters. This is particularly useful for the creation of sub-programs, or agent-specific minting rights. * **Transferable admin:** Unlike the V2, it is possible to transfer the admin role to a different address by the admin, enabling flexible deployment configuration & admin management * **Updatable MINTABLE address:** Unlike the V2, the minting source of a program mechanic or capped minter can be updated if original source reaches the minting cap * **Start and Expiration Dates:** Adds the ability to arbitrarily set a start and expiration time for a capped minter. * **Pause and Close Operations:** Allows the admin to pause or fully cancel minting activities, providing a safeguard against unforeseen issues. The admin can also assign other addresses to have the power to pause. * **Metadata:** Allows admin to set a custom metadata URI, allowing each minter to contained additional information related to connected token flows. * **Events:** Emits onchain events for granting the minter role, minting, cancelling, setting metadata. New analytics and monitoring are possible. ### Deploying a Capped Minter You can deploy a capped minter through a the [ZKCappedMinterV3 Factory](https://explorer.zksync.io/address/0xABF70d9a1fe52ca5e9339A6Ef76759614C1b5eE9#contract#write). You can find the source code for the V3 Factory [here](https://github.com/zksync-association/zkminters/blob/main/src/ZkCappedMinterV3.sol). The V3 Factory was created to make capped minter deployment more accessible. > ℹ️ Testnet capped minter deployment can be done through the [Testnet\_ZkCappedMinterV3Factory](https://sepolia.explorer.zksync.io/address/0xABF70d9a1fe52ca5e9339A6Ef76759614C1b5eE9#contract%23write) 1. Go to the [CappedMinter V3 Factory](https://explorer.zksync.io/address/0xABF70d9a1fe52ca5e9339A6Ef76759614C1b5eE9#contract%23write) 2. Select “Contract” and “Write” 3. Toggle down "1. createMinter"
3. Connect your wallet 4. Specify the parameters for the capped minter V3 being deployed: * **Mintable Token Address (`_mintable`):** The address of the token contract that will be minted from. * **Administrator Address (`_admin`):** The address granted administrative privileges, including the ability to assign the MINTER role. * **Minting Cap (`_cap`):** The maximum number of tokens that can be minted by this contract. This input is in uint256, meaning it requires 18 decimals. For example, if the cap is meant to be 1,000,000 ZK, it would be entered as 1000000000000000000000000. * **Start Time (`_startTime`):** The seconds timestamp from which minting is permitted. This input is in uint48 (i.e. epoch time). Use an epoch time converter to get the correct input for the start time desired. Please note that the start time has to be some time in the future from the moment of deployment. * **Expiration Time (`_expirationTime`):** The seconds timestamp after which minting is no longer allowed. This input is in uint48 (i.e. epoch time). Use an epoch time converter to get the correct input for the end time desired. Please note that any child capped minters will expire on the specified end date of a parent capped minter. * **saltNonce:** arbitrary value that helps define the deployed contract’s address. > Please note that these parameters cannot be updated after the contract has been deployed.
**Where to find capped minter address after deployed:** After the transaction has been signed to create the capped minter, a hash should appear under the deploy button. Take note of the hash and go to the "Events" tab ### Verifying a Capped Minter #### **Verifying in Command Line** 1. Set your working directory: Please note the input below is an EXAMPLE - customize as needed. This is where you will copy the contracts and build the folder system for the code. ```bash cd Documents/Dev/ ``` 2. Clone the repo where governance contracts are managed ```bash git clone ``` 3. (Optional) Install Hardhat ([see npm docs](https://docs.npmjs.com/cli/v8/configuring-npm/install)) ```css npm install --save-dev hardhat npm install --save-dev typescript ``` 4. Change directory to L2 governance contract working directory ```bash cd l2-contracts/ ``` 5. Set default network 1. // Change default network to zkSyncEra 2. // (IF TESTNET) Change default network to zkSyncTestnet ```lua nano hardhat.config.ts ``` 6. Compile contracts ```python npx hardhat compile ``` 7. Verify Contract 1. npx hardhat verify \[contract address] \[token] \[admin] \[cap] \[starttime] \[expirationtime] 2. Change your parameters as needed EXAMPLE: ``` npx hardhat verify 0x721b6d77a58FaaF540bE49F28D668a46214Ba44c 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E 0x77CC0A0582475bfD74CD838610e817d05c181E11 8301475000000000000000000 1736899200 1752537600 ``` ### Reading a Capped Minter Contract In order to read the parameters of an already deployed capped minter contract, simply paste the address in the [ZKsync Era Block Explorer](https://explorer.zksync.io/), go to “Contract”, and the “Read”. There, you will find the following parameters.
1. CAP: Query this parameter to see the immutable cap on a given capped minter 2. DEFAULT\_ADMIN\_ROLE: Query this parameter to get the default admin role address 3. EXPIRATION\_TIME: Query this parameter to see the end (expiration) date of a capped minter 4. MINTABLE: Query this parameter to get the address of the token being minter (ZK) 5. MINTER\_ROLE: Query this parameter to get the minter role address for this capped minter 6. PAUSER\_ROLE: Query this parameter to get the pauser role address for this capped minter 7. START\_TIME: Query this parameter to see the start (activation) date of a capped minter 8. closed: Query this parameter to check if the minter is closed 9. getRoleAdmin: Query this parameter to see if a role is an admin of another role on the capped minter 10. hasRole: Query this parameter to verify if a specific address has a certain role 11. metadataURI: Query this parameter to get a URI for capped minter metadata 12. minted: Query this parameter to see how much ZK has been minted from the CAP 13. paused: Query this parameter to see if the capped minter contract has been pause (true = paused, false = not paused) 14. supportsinterface: Query this parameter by adding an interface ID to check if an interface is supported with the contract *Example from the* [*TPP-6*](https://vote.zknation.io/dao/proposal/38542076628472360665761284306860773162167153028104855759973536253827423667325?govId=eip155:324:0xb83FF6501214ddF40C91C9565d095400f3F45746) *capped minter.* ### Nested Capped Minters (Parent / Child) It is possible to nest “child” capped minters under a “parent” capped minter. While a parent capped minter’s target to mint from will always be the ZK token contract, a child’s target to mint from will be the parent (or a mod linked to the parent).
#### **Grant minter role on deployed capped minters** **Parent Capped Minters:** As only the admin of a contract can grant the minter role to another address, and the Token Governor Timelock (controlled by Token Assembly) is the admin of the ZK token contract, the minter role from the ZK token contract to any parent capped minter needs to be granted via governance proposal. Please see [Token Program Proposals (TPPs)](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps) to learn more about submitting a TPP. **Child Capped Minters & Mods:** The admin of each capped minter (that is not the Token Timelock) is able to grant the minter role on a capped minter without needing Token Assembly approval (e.g. on child capped minters/minter mods you are the admin of). There is no limit to how many addresses can have the minter role on a given minter contract. It is recommended that all minter roles are assigned in a mechanic before a proposal is submitted onchain for testing purposes and to ensure the smooth launch of a program. Follow these steps in order to grant the minter role on child minters or mods: **Through Era Block Explorer:** * Open the contract you want to grant the role from in the [Era block explorer](https://explorer.zksync.io/) * Go to “Contract” > “Read” * Select “MINTER ROLE” > query, copy the role address * Go to “Write” tab > select “grantRole”, paste minter role address into “role” field * Copy address you want to grant the role to in the “account” field * Select “Write” **Through Safe:** * Make sure you are in the Safe account that is the admin of the capped minter you are granting the minter role from. * Select “New Transaction” > Custom * Enter the address of the Capped minter you are granting the minter role from * **ABI:** If the ABI does not automatically show up, go to the capped minter address on the [Era block explorer](https://explorer.zksync.io/), go to “Contract”, scroll down to the bottom to find the “Contract ABI” field, copy & paste into ABI section on Safe * **Action:** Section the action you want to execute (e.g. grantRole) * **Enter Role Address:** To find the role adddress, open the contract you want to grant the role from in the Era block explorer, go to “Contract” > “Read”, select “MINTER ROLE” > query, copy the role address and paste into Safe * **Enter Account Address:** Enter the address you want to grant the role to * Follow instructions to propose/sign transaction to execute on the Safe interface. ### Common Role Addresses There are two common roles that are assigned in standard token mechanics. These addresses can also be found directly in the contract functions of each minter contract. See [Reading a Capped Minter Contract](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps/capped-minters-101#reading-a-capped-minter-contract) section below.
RoleRole AddressRole Action
Minter Role0x9f2df0fed2c77648de5860a4cc508cd0818c85b8b8a1ab4ceeef8d981c8956a6Addresses granted this role will be able to mint from a given minter contract.
Pauser Role0x65d7a28e3265b37a6474929f336521b332c1681b933f6cb9f3376673440d862aAddresses with this role will be able to pause minting from a given minter contract.

This role is commonly assigned to the ZKsync Security Council for extra oversight on Token Programs.
### Confirming the Minter Role on a Capped Minter Minting rights are represented by the minter role. The minter role is granted and revoked by passing a Token Program Proposal (TPP). To verify if a capped minter has the minter role or not, following the steps below. **Verify Parent Capped Minter has minter role on ZK token contract** 1. Open the [ZK token contract](https://sepolia.explorer.zksync.io/address/0x06eb75609e3c8daebe26e479e7232edeb25bc1c2#contract) on the Era Block Explorer 2. Go to Contract > Read 3. Toggle down the hasRole parameter 4. Enter the MINTER\_ROLE address (query from above) 5. Enter address of the capped minter 6. Select “Query” If the query returns true, the capped minter has the minter role on the ZK token contract and is able to mint up to it’s specified cap. If it returns false, it means the capped minter does not have the minter role, and no tokens can be minted from that capped minter. **Verify child capped minter or minter mod has minter role on parent capped minter** 1. Open the Parent Capped Minter contract on the [Era Block Explorer](https://explorer.zksync.io/) 2. Go to Contract > Read as Proxy 3. Toggle down the hasRole parameter 4. Enter the MINTER\_ROLE address (query from above) 5. Enter address of the child capped minter 6. Select “Query” If the query returns true, the child capped minter has the minter role on the parent capped minter and is able to mint up to it’s specified cap. If it returns false, it means the child capped minter does not have the minter role, and no tokens can be minted from that capped minter.
### Minting from a Capped Minter > ℹ️ Please note that only users assigned the minter role are able to mint from a capped minter. The Admin of a capped minter can assign the minter role on a give capped minter. #### Minting ZK from Era Block Explorer 1. Enter the capped minter address you want to mint from in the [Era Block Explorer](https://explorer.zksync.io/) 2. Go to “Contract”, then “Write” 3. Connect the wallet that has the minter role 4. Toggle down the “mint” parameter 5. Enter address of where you want the ZK minted to in “\_to (address)”: 6. Enter the amount ZK in “amount (unit256) > ℹ️ We recommend doing a test mint for a small portion of the full cap to the target address before minting the full cap. 7. Select “write” 8. Verify that the minted ZK was received by target address #### Mint Tokens through Safe UI 1. Login to the SC Ops multisig [Safe wallet](https://app.safe.global/welcome/accounts) and select "New transaction" in the top left corner 2. Select “Transaction Builder” 3. Enter the capped minter contract address: (the ABI should automatically load) 4. Scroll down to “Contract Method Selector” and select “mint” 5. Enter address of where you want the ZK minted to in “\_to (address)”: 6. Enter the amount ZK in “amount (unit256) > ℹ️ We recommend doing a test mint for a small portion of the full cap to the target address before minting the full cap. 7. Select “Add new transaction” 8. Select “Create branch” in top right and follow the instructions in the Safe UI to review and execute the transaction 9. Verify that the minted ZK was received by target address # Minter Mods Overview ### What are Minter Mods? Minter Modifiers, or “Minter Mods,” are additional contracts that can be deployed and connected to a capped minter. Each Minter Mod is a separate contract that implements specific minting rules or restrictions, and they all follow a consistent interface (ZkMinterV1) that allows them to be composed together. These mods can be chained together in any order, with each one acting as a gatekeeper that must approved before the mint request reaches the [CappedMinterV3](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps/capped-minters-101#zk-capped-minter-v3). The four current Minter Mods are the Rate Limiter Mod, Delay Mod, Eligibility Mod and Trigger Mod. Read more about each below. ### Why use Minter Mods? Capped minters combined with Minter Mods provide the infrastructure to enforce custom minting and distribution rules, removing intermediary minted token custody management and the burden of manual token distribution for a given program. As a result, treasury-less and autonomous token programs can be composed, custom to the needs of a given program. The idea behind Minter Mods comes from the challenges of managing token programs through manual multisig coordination. Relying on program admins to sign and execute large volumes of transactions creates operational bottlenecks and places significant trust in those admins to distribute tokens as promised in onchain proposals. By introducing programmatic enforcement of minting and distribution rules, this trust requirement is removed. Instead, the community can transparently verify the rules and roles that govern token minting at any time. ### Minter Mod Toolkit There are currently four audited Minter Mods in the ZKsync Minter Mod toolkit. Visit the [zkminters repo](https://github.com/zksync-association/zkminters/tree/main) for all Minter Mod code & audits. #### Rate Limiter Mod
Sourcecodehttps://github.com/zksync-association/zkminters/blob/main/src/ZkMinterRateLimiterV1.sol
Audithttps://github.com/zksync-association/zkminters/blob/main/audits/ZKRateLimiterReview_final_with_fixes.pdf
Deployment FactoryZkMinterRateLimiterV1Factory
**Description:** Limits the rate at which tokens can be minted over a specified period of time (e.g. day, week, month). This enables Token Programs to be “self-serve” and adds a level of security by putting a cap on how much any party with minting rights can mint within a given time period. **Examples of use:** * **Self-serve service provider payments**: Grant a program service provider minting rights on a capped minter with a cap of the full program payment with a rate limiter that limits their monthly minting amount to the agreed upon monthly rate. * **Vesting Tool:** In a particular prize program, each prize capped minter has a rate limit on it to limit the amount a winner can mint in 1 day/week/month. * **Price fluctuation protection**: Put a “global” rate limiter on a program parent capped minter (rather than on each child capped minter) to prevent the total amount minted from any children to not succeed a certain amount from the parent if price fluctuates dramatically during the program. **How to deploy:** Use the [ZkMinterRateLimiterV1Factory](https://explorer.zksync.io/address/0x6Cb59905FCEDA9f578a5fAC5867D0560f762Cb00#contract%23write) to deploy a Rate Limiter mod. Please reach out to the ZKsync Governance Team for guidance on mechanic deployment. > The admin of a Rate Limiter contract is able to update the \_mintRateLimit and \_mintRateLimitWindow variables after it has been deployed if needed. #### Delay Mod
Sourcecodehttps://github.com/zksync-association/zkminters/blob/main/src/ZkMinterDelayV1.sol
Audithttps://github.com/zksync-association/zkminters/blob/main/audits/ZKMinterDelayModV1Review_final_with_fixes.pdf
Deployment FactoryZkMinterDelayV1Factory
**Description:** Creates a time delay (veto window) between a mint request and mint execution on the linked capped minter. In practice, this enables Token Programs to be “self-serve” & allow for flexible minting allowance. **Examples of use:** * **Self-serve Payments:** A Token Program service provider has a service agreement to provide up to 100K ZK worth of services/month. Each month, the services provider can request to mint payment for work completed that month (e.g. up to 100K ZK) from the program capped minter (rather than SteerCo having to mint tokens & send to service provider.) If the service provider’s request is not aligned to monthly service agreement (e.g. request of 200K ZK), the SteerCo can simply deny the request (veto) within the specified delay window. * **Optimistic Prize Claim:** Parties with minter role are able to claim a prize optimistically by requesting a mint. Only after veto / verification window will the mint request be available. **How to deploy:** Use the [ZkMinterDelayV1Factory](https://explorer.zksync.io/address/0x022cd302a2A0C7f78EC17341cAB911eCE3E7CCC5#contract%23write) to deploy a Delay Mod. Please reach out to the ZKsync Governance Team for guidance on mechanic deployment. #### Eligibility Mod
Sourcecodehttps://github.com/zksync-association/zkminters/blob/main/src/ZkMinterERC1155EligibilityV1.sol
Audithttps://github.com/zksync-association/zkminters/blob/main/audits/ERC1155EligibilityMinterV1Review.pdf
Deployment FactoryZkMinterERC1155EligibilityV1Factory (pending)
**Description:** Limits who can mint from a specific capped minter based on holding a specific ERC1155-based token. Anyone holding a specific ERC1155 will be able to mint from a linked capped minter. This mod could be copied and adapted to work with other ERCs. **Examples of use:** * **Self-claiming rewards:** In a self-claiming reward mechanic, only participants holding a specific ERC-1155 is able to mint from a specific capped minter. * **Multiple Unknown Minters:** More than one party is expected to need the minter role on a capped minter that may be unknown at the time of launch. Assign the minter role to an ERC1155 (e.g. a Hat) so that anyone with that Hat (which can be distributed later), has minting rights on a give capped minter. **How to deploy:** Use the **ZkMinterERC1155EligibilityV1Factory** (pending) to deploy an Eligibility Mod. Please reach out to the ZKsync Governance Team for guidance on mechanic deployment. #### Trigger Mod
SourcecodePending
AuditPending
Deployment FactoryPending
**Description:** Enables creation of separate “mint” & “trigger” functions on a capped minter, and the assignment of an immutable target address to a capped minter. The trigger mod allows one to immediately execute multiple function calls - all in one atomic transaction. **Examples of use:** * **Mint to contract:** A vendor needs to be paid through a streaming contract (e.g. Drips, Hedgy). The trigger contract can be used to autonomously mint and send the minted tokens to the given streaming contract, removing the risk of custody management of minted tokens from the program admin. * **USD Denomination:** A vendor’s service fee is denominated in USD. The trigger mod contract can automate the ZK <> USDC conversion calculation, mint and send action on a specified regular basis (e.g. monthly). * **Operational Security:** The trigger mod allows the admin to set an immutable target address, meaning regardless of who or what triggers the mint, it will always be minted to the same target address. **How to deploy:** Use the **Trigger Mod Factory** (pending) to deploy a Trigger Mod. Please reach out to the ZKsync Governance Team for guidance on mechanic deployment. ### Build A New Minter Mod Every project has unique minting requirements that may not be supported by the current set of Minter Mods. We invite others to play around with Minter Mods Learn more about how to [deploy your own Minter Mod here](https://github.com/zksync-association/zkminters/tree/main#building-a-new-minter-mod)! Have an idea for a new minter mod or example of how they could be used? Post it in the [Token Mechanics category](https://forum.zknation.io/c/token-mechanics/26) on the forum. # Governance Advisory Proposals (GAPs) ### What is a Governance Advisory Proposal (GAP)? Governance Advisory Proposals (GAPs) include all proposals submitted through the ZKsync [GovOps Governor](https://github.com/zksync-association/zk-governance/blob/master/l2-contracts/src/ZkGovOpsGovernor.sol). These proposals are not connected to the ZK token or to the ZKsync protocol. Instead, GovOps Governors provide legitimacy to offchain decisions through onchain Token Assembly Delegate voting. ### Types of Governance Advisory Proposals Governance Advisory Proposals can be used for a variety of use-cases: 1. **Ratification:** Create a GAP to ratify changes to canonical governance-related documents, such as the ZKsync Governance Procedures or the ZK Credo. 2. **Elections or Nomination:** Create a GAP to elect or nominate supervisors, directors, and/or officers for specific governance bodies, in accordance with their bylaws. For example, this can include an Emergency Supervisor to the Security Council or Guardians. 3. **Governance Oracle:** Connect an external application or interoperable chain to ZKsync governance. For example, an application or a ZKsync Chain built on ZKsync Era may submit a proposal to change a specific parameter. ### What information should I include in a GAP? A Governance Advisory Proposal should include all the necessary information for ZKsync Delegates to make an informed decision and vote on the proposal. The proposal length and detail should align with the impact of the GAP. **All GAPs should include:** * IMPACT: Describe how the token program will ***impact*** assets, builders, and the community of ZKsync, and what future vision these changes will contribute to. For example, it could be focused on increasing the diversity of assets and number of builders on ZKsync, contributing to ZKsync's vibrant economy. Read more [here](https://docs.zknation.io/zk-nation/zksync-governance-system-north-star). * RECOMMENDED ACTIONS: Describe the set of actions that the proposal is recommending. If the proposal includes changes to specific documents, specify the original document source and track changes. If the proposal advises on an election, specify the terms, responsibilities, and any relevant legal contracts. * PLAN: Outline the relevant ***plans*** for implementation if the proposal passes. This could include specific ***outcomes, milestones,*** and ***deliverables.*** * ACCOUNTABILITY FRAMEWORK: Specify what methods will hold the program, operations, and participants accountable for their commitments. For example, this can include items such as an Accountability Council, Token Streaming Terms, KYC or reputation staking. > ✍️ TEMPLATE: Proposers are encouraged to follow the standard proposal template for Governance Advisory Proposals, available [here](https://github.com/zksync-association/governance-resources/blob/main/proposal-templates/03_gap_template_govops_governor.md). > ℹ️ *NOTE: All documentation should be included in the onchain proposal, or include links to an onchain source such as Arweave, IPFS, etc. This allows the proposal content to be public and accessible across web3 applications.* ### What onchain actions can I execute through a GAP? The GovOps Governor and its timelock contract, through which Governance Advisory Proposals are submitted, are not connected to the ZKsync Protocol, the ZK Token contract or other ZKsync contracts at inception. However, proposers can still include onchain actions for Governance Advisory Proposals such as: #### Example: Adopt SEAL Safe Harbor Agreement and enshrine agreement onchain [GAP-2](https://vote.zknation.io/dao/proposal/35395412545014978447594654620386134175315194219985614464693911512436668500487?govId=eip155:324:0x496869a7575A1f907D1C5B1eca28e4e9E382afAb) adopted the SEAL Whitehat Safe Harbor Agreement and established a rapid response mechanism that enables whitehats to effectively intervene during active exploits, safeguarding user funds and reinforcing ZKsync's proactive security measures. The agreement was registered on ZKsync Era in the Safe Harbor Registry at address 0x5f5eEc1a37F42883Df9DacdAb11985467F813877, including all adoptionDetails, ensuring transparency and immutability. # GAP FAQ ### What onchain actions can I execute through a GAP? The GovOps Governor and its timelock contract, through which Governance Advisory Proposals are submitted, are not connected to the ZKsync Protocol, the ZK Token contract or other ZKsync contracts at inception. However, proposers can still include onchain actions for Governance Advisory Proposals such as: #### Example: Adopt SEAL Safe Harbor Agreement and enshrine agreement onchain [GAP-2](https://vote.zknation.io/dao/proposal/35395412545014978447594654620386134175315194219985614464693911512436668500487?govId=eip155:324:0x496869a7575A1f907D1C5B1eca28e4e9E382afAb) adopted the SEAL Whitehat Safe Harbor Agreement and established a rapid response mechanism that enables whitehats to effectively intervene during active exploits, safeguarding user funds and reinforcing ZKsync's proactive security measures. The agreement was registered on ZKsync Era in the Safe Harbor Registry at address 0x5f5eEc1a37F42883Df9DacdAb11985467F813877, including all adoptionDetails, ensuring transparency and immutability. ### Do GovOps proposals always have an onchain action? No, not always. The GovOps Governor and its timelock contract, through which Governance Advisory Proposals are submitted, are not connected to the ZKsync Protocol, the ZK Token contract or other ZKsync contracts at inception. # ZKsync Governance Procedures: Overview *Version published on 12 September 2024. Last updated on 2 December 2025.* ### 1. Introduction 1. The ZKsync Governance Procedures describe the ZKsync governance system, which is responsible for the governance of the ZKsync protocol. 2. The ZKsync governance system includes standard and emergency response procedures along with specifications for governance bodies, namely the ZKsync Security Council and ZKsync Guardians. 3. The ZK token is a protocol token used within the ZKsync governance system to allocate and delegate voting power over governance proposals, and may have additional functionality in the future if approved pursuant to the process described in these Governance Procedures. 1. The ZK token contract is deployed at [0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E](https://era.zksync.network/token/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E) on ZKsync Era. 4. If there are changes made to the smart contracts, code and onchain mechanisms that comprise the ZKsync governance system, the ZKsync Governance Procedures will be updated to reflect such changes. 1. The ZKsync Association is expected to maintain and update these ZKsync Governance Procedures as necessary. 2. However, the ZKsync Association does not assume responsibility for the completeness of these Governance Procedures, which are intended to function as a high-level and readily-understandable description of the governance and the governance processes involved in the ZKsync Protocol. The Governance Procedures are incomplete because they relate and refer to smart contracts, code and onchain mechanisms that operate deterministically in accordance with their specifications. As such, the ZKsync Governance Procedures must only be read in conjunction with a thorough understanding of those smart contracts, code and onchain mechanisms, and the ZKsync Governance Procedures are not in themselves intended to be a comprehensive account of all relevant risks, uncertainties, adverse/negative facts and disclaimers relating to the governance and the governance processes involved in the ZKsync Protocol. ### 2. ZKsync Protocol 1. The ZKsync governance system is expected to govern smart contracts related to the ZKsync protocol, including but not limited to: 1. DiamondProxy contract deployed at [0x32400084C286CF3E17e7B677ea9583e60a000324](https://etherscan.io/address/0x32400084C286CF3E17e7B677ea9583e60a000324) on Ethereum. 2. Legacy ZKsync ERC20 Bridge deployed at [0x57891966931Eb4Bb6FB81430E6cE0A03AAbDe063](https://etherscan.io/address/0x57891966931Eb4Bb6FB81430E6cE0A03AAbDe063) on Ethereum. 3. ZKsync ERC20 Bridge deployed at [0x11f943b2c77b743AB90f4A0Ae7d5A4e7FCA3E102](https://explorer.zksync.io/address/0x11f943b2c77b743AB90f4A0Ae7d5A4e7FCA3E102) on ZKsync. 4. ZKsync Shared Bridge deployed at [0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB](https://etherscan.io/address/0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB) on Ethereum. 5. ZKsync beacon proxy deployed at [0x1Eb710030273e529A6aD7E1e14D4e601765Ba3c6](https://explorer.zksync.io/address/0x1Eb710030273e529A6aD7E1e14D4e601765Ba3c6) on ZKsync. 6. ZKsync Validator Timelock deployed at [0xa8CB082A5a689E0d594d7da1E2d72A3D63aDc1bD](https://etherscan.io/address/0xa8CB082A5a689E0d594d7da1E2d72A3D63aDc1bD) on Ethereum. 7. ZKsync Wrapped Ether contract deployed at [0x57891966931Eb4Bb6FB81430E6cE0A03AAbDe063](https://explorer.zksync.io/address/0x57891966931Eb4Bb6FB81430E6cE0A03AAbDe063) on ZKsync. ### 3. ZK Credo 1. The [ZK Credo](https://docs.zknation.io/zk-nation/mission-zk-credo) sets out the vision and values of ZKsync. 1. The role of ZKsync Guardians is to serve as protectors of the Mission (as defined in Schedule 4) of ZKsync, as set out in the ZK Credo. ### 4. Governance Bodies 1. The governance bodies that participate in the ZKsync governance system include: 1. **Token Assembly**: The Token Assembly is a governance body made up of ZK tokenholders, who delegate the voting power of ZK tokens they hold, to ZKsync addresses in order to (indirectly) participate in the ZKsync governance system. 1. The voting power of the Token Assembly is held and exercised by the controllers of the ZKsync addresses to which voting power has been delegated ("**Delegates**"). 2. ZK tokenholders can also delegate the voting power of their ZK tokens to themselves, by delegating to a ZKsync address they control. 3. Delegates may propose and vote on governance proposals. 2. **ZKsync Security Council** ("**Security** **Council**"): The Security Council is a governance body currently made up of a minimum of nine (9) members out of twelve (12) allocated seats, whose powers, procedures, and membership is set out in Schedule 3: ZKsync Security Council. 1. The Security Council controls the following Ethereum L1 multsig: [0x66E4431266DC7E04E7d8b7FE9d2181253df7F410](https://etherscan.io/address/0x66E4431266DC7E04E7d8b7FE9d2181253df7F410) 2. The primary responsibility of the Security Council is to evaluate and approve Protocol Governor proposals (as defined below) that have been approved by Delegates, before the proposals are executed onchain. 3. The Security Council can freeze the ZKsync protocol in case of an emergency. 4. The Security Council can initiate and/or approve emergency upgrades, which will be executed subject to the additional approval of both the ZKsync Guardians and the ZKsync Foundation. 3. **ZKsync Guardians** ("**Guardians**"): Guardians are a governance body who serve as protectors of the ZK Credo, made up of a minimum of five (5) individuals out of eight (8) allocated seats, whose powers, procedures, and membership are set out in Schedule 4: ZKsync Guardians. 1. The Guardians control the following Ethereum L1 multsig: [0x600dA620Ab29F41ABC6596a15981e14cE58c86b8](https://etherscan.io/address/0x600dA620Ab29F41ABC6596a15981e14cE58c86b8) 2. Guardians have the independent power to veto governance proposals that are inconsistent with the ZK Credo. This includes the power to veto governance proposals that are abusive, malicious or could otherwise adversely affect ZKsync or its governance system. The Guardians' decisions are made at their sole discretion. 3. The Guardians are not required to assess the legality of governance proposals. 4. Guardians may evaluate and approve Protocol Governor proposals, approved by Delegates, if the Security Council, for any reason, abstain from exercising their approval during the Risk Review Period. 5. Guardians can approve Emergency Upgrades, which will be executed subject to the additional approval of the Security Council and the ZKsync Foundation. ### 5. Supporting Entities 1. **ZKsync Foundation**: The ZKsync Foundation is a Cayman foundation that, among other things, provides grants and enters into agreements with a diverse range of (potentially competing) market participants each of whom are working on or in relation to ZKsync, ZKsync related technology, the Ethereum 'layer-1' blockchain system or other zero-knowledge based cryptographic technology more widely, including for the purposes of studying, evaluating, testing, monitoring, maintaining, facilitating, fostering and improving the use or functionality of ZKsync and ZKsync related technology. 1. The ZKsync Foundation controls the following Ethereum L1 multisig ("**ZKsync Foundation Multisig**"): [0xbC1653bd3829dfEc575AfC3816D4899cd103B51c](https://etherscan.io/address/0xbC1653bd3829dfEc575AfC3816D4899cd103B51c) 2. The ZKsync Foundation can approve Emergency Upgrades, which will be executed subject to the approval of both the ZKsync Guardians and the ZKsync Security Council. 2. **ZKsync Association**: The ZKsync Association is an Austrian association (Verein) ("**ZKsync Association**") that is primarily responsible for: (i) designing the ZKsync governance system; (ii) deploying the initial governance and token smart contracts; (iii) appointing the initial members of the governance bodies described below; (iv) conducting the ZK token airdrop; (v) supporting the ongoing governance of the ZKsync protocol as contemplated by its governing documents (e.g., by periodically updating these Governance Procedures); and (vi) removing content on the following interfaces that, at its sole discretion, violates or conflicts with Austrian law or could result in negative tax consequences: 1. The ZKsync Governance Portal available at and . 2. The ZK Nation Governance Documentation available at . 3. The ZKsync Governance Forum available at . ### 6. Standard Governance Procedures 1. The standard procedure for governance proposals voted on by Delegates using the voting power conveyed by the ZK token and executed by smart contracts deployed for the purpose of decentralized onchain governance (such smart contracts, "**Governors**") are set out in Schedule 1: Standard Governance Procedures. 2. There are three (3) Governors in the ZKsync governance system, each of which is responsible for a specific type of governance proposal: 1. **Protocol Governor**: responsible for executing ZKsync Improvement Proposals ("**ZIPs**") that upgrade the ZKsync protocol and/or components of the ZKsync governance system. 1. The Protocol Governor is an OpenZeppelin smart contract deployed on ZKsync Era: [0x76705327e682F2d96943280D99464Ab61219e34f](https://explorer.zksync.io/address/0x76705327e682F2d96943280D99464Ab61219e34f) 2. The Protocol Governor Timelocks is an OpenZeppelin smart contract deployed on ZKsync Era: [0x085b8B6407f150D62adB1EF926F7f304600ec714](https://explorer.zksync.io/address/0x085b8B6407f150D62adB1EF926F7f304600ec714) 2. **Token Governor**: responsible for executing Token Program Proposals ("**TPPs**") that assign minting and burning rights of ZK tokens for token programs that are aligned with the Token Program Guidelines, and help achieve the goals supporting the vision of the ZK Credo. 1. The Token Governor is an OpenZeppelin smart contract deployed on ZKsync Era: [0xb83FF6501214ddF40C91C9565d095400f3F45746](https://explorer.zksync.io/address/0xb83FF6501214ddF40C91C9565d095400f3F45746) 2. The Token Governor Timelock is an OpenZeppelin smart contract deployed on ZKsync Era: [0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d](https://explorer.zksync.io/address/0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d) 3. **GovOps Governor**: responsible for facilitating Governance Advisory Proposals ("**GAPs**") related to governance and operations that do not have direct onchain consequences. 1. The GovOps Governor is an OpenZeppelin smart contract deployed on ZKsync Era: [0xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160](https://explorer.zksync.io/address/0xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160) 2. The GovOps Governor Timelock is an OpenZeppelin smart contract deployed on ZKsync Era: [0xC9E442574958f96C026DeF9a50C3236cab17428a](https://explorer.zksync.io/address/0xC9E442574958f96C026DeF9a50C3236cab17428a) ### 7. Emergency Response Procedures 1. Procedures for executing a protocol upgrade to the ZKsync protocol to address threats that pose immediate security risks to the ZKsync ecosystem and/or the ZKsync governance system are set out in Schedule 2: Emergency Response Procedures. 2. There are two (2) types of Emergency Responses that can be executed in the ZKsync governance system: 1. Freeze of Layer 1 contracts; and/or 2. Execution of an Emergency Upgrade. 3. The three (3) governance bodies involved in initiating and/or approving Emergency Upgrades with their respective multisigs ("**Emergency Upgrade Signers**") are the: 1. Security Council; 2. Guardians; and 3. ZKsync Foundation. 4. Each Emergency Upgrade Signer is represented in the ZKsync governance system by a multisig which is made up of Signers. As used in these Governance Procedures, "**Signer**" means (1) a multisig wallet or (2) an externally owned account (EOA). ### 8. Legal 1. These Governance Procedures are provided for informational purposes only, are not a binding legal agreement, and may be changed prior to launch of the ZKsync governance system to address security vulnerabilities or similar matters. 2. Upon its launch, the ZKsync governance system is not controlled by the ZKsync Association or any third-party entity, but requires the approval of the Token Assembly to decide and make any changes or updates to the ZKsync protocol. The ZKsync Association will make good faith efforts to reflect any changes or updates to the ZKsync governance system in these ZKsync Governance Procedures. However, there is no guarantee of up-to-dateness or completeness. 3. In the event of a conflict between these ZKsync Governance Procedures and any agreement or obligation entered into by any person or entity in connection with the matters described herein, including the code referred to in these ZKsync Governance Procedures, such agreement or obligation, or the relevant code shall control in all respects. 4. These ZKsync Governance Procedures are subject to the Risk Factors and Disclaimers described [here](https://docs.zknation.io/legal/risk-factors-and-disclaimers), which are incorporated by reference in their entirety as if set forth herein. 5. Nothing herein shall create, or be construed as creating, between or among any person or entity described herein and any other person or entity (except as may be expressly agreed by the applicable parties in writing): (1) an agency or fiduciary relationship, or any assumption of duty or responsibility, (2) a service or employment relationship, or (3) a joint enterprise, business opportunity relationship, partnership, unincorporated association or similar relationship. # Schedule 1: Standard Governance Procedures ### 1. Overview 1. "**Standard Governance Procedures**" refer to the governance processes related to the three (3) Governor smart contracts that govern elements of ZKsync protocol and the ZKsync governance system, as voted on by Delegates using the voting power conveyed by the ZK token. ### 2. Protocol Governor 1. The Protocol Governor is a smart contract deployed on ZKsync Era. 2. The Protocol Governor allows for the delegated voting power conveyed by the ZK token to be used to vote on ZKsync Improvement Proposals ("[**ZIPs**](https://docs.zknation.io/zksync-governance-proposals/zksync-improvement-proposals-zips)"), which are queued for permissionless execution on Ethereum if passed. 3. Protocol Governor proposals are executed through the transmission of a message from ZKsync Era to Ethereum. Proposals are required to contain a hash of the proposal specification, which may then be executed on Ethereum. 4. The Protocol Governor is responsible for executing proposals related to: 1. ZKsync Era protocol upgrades; 2. ZKsync network upgrades; 3. Upgrades to the Protocol Governor, Token Governor, and GovOps Governor; 4. Upgrades to the ZK token contract; 5. Upgrades to the Security Multisig (i.e. to the Security Council and Security Council Members); and 6. Upgrades to the Guardian Multisig (i.e. to the Guardians and Guardian members). ### 3. Protocol Governor Proposal Process 1. The [proposal and voting process](https://docs.zknation.io/zksync-governance-proposals/zksync-improvement-proposals-zips#proposal-process-timeline) for the Protocol Governor is set out below. 2. **Proposal Submission**: Any Delegate who meets the proposal threshold is able to submit a proposal to the Protocol Governor via the [ZKsync Governance Portal](https://vote.zknation.io/dao) or any other interface connected to the Protocol Governor. 1. The proposal threshold required for a Delegate to submit a proposal to the Protocol Governor is 0.1% (or 21 million) of the total number of ZK tokens that may be minted (currently 21 billion). 3. **Vote Delay Period:** Upon submission, a proposal enters a three (3) day vote delay period, prior to the commencement of the Voting Period. "Voting Period", as referred to herein, means the period during which Delegates can submit their onchain votes to a submitted proposal. 1. A proposal may be cancelled during the Vote Delay Period by the proposer, at their discretion. 4. **Voting Period**: The Voting Period for a Protocol Governor proposal is seven (7) days. 1. Protocol Governor proposals have a quorum requirement of 3.0% (or 630 million) of the total number of ZK tokens that may be minted (currently 21 billion) and require a simple majority of the total number of "for" and "against" votes (i.e., casted votes without considering abstentions) to pass. 2. If a vote causes quorum to be reached within the last 3 days of the voting period, the proposal's voting period is extended by 3 days from the point quorum is met. 5. **ZKsync Era Proposal Execution**: Upon approval by Delegates, a Protocol Governor proposal is executed on ZKsync Era through the transmission of a message from ZKsync Era to the *ProtocolUpgradeHandler* contract on Ethereum. 6. **Offchain Veto Period**: Once an approved Protocol Governor proposal has been executed on ZKsync Era, the proposal will proceed to a three (3) day Timelock Period on Ethereum, during which time Guardians have the ability to exercise an Offchain Veto as described in Schedule 4: ZKsync Guardians. A "Timelock Period", as referred to herein, means a predetermined time delay imposed on approved governance proposals, during which a proposal cannot progress to the next stage of the proposal process. 1. The Offchain Veto Period on the Protocol Governor is a three (3) day period that commences at the end of the Voting Period, if a proposal is approved. 2. If an Offchain Veto is exercised, the written veto must be signed (including by electronic means) by at least five (5) of the Guardians (or a majority of the Guardians, if fewer than five) and for each Guardian, countersigned by an independent legal counsel or other person subject to recognized professional codes of conduct, and transmitted to a director or officer of the ZKsync Security Council Foundation. 3. The Guardian Multisig can extend the Offchain Veto Period from three (3) days to seven (7) days, with the approval of any two (2) Signers (as defined in the Overview) on the Guardian Multisig. 7. If an Offchain Veto is exercised by the Guardians during the Offchain Veto Period, the proposal will not be approved by the Security Council or Guardians during the Risk Review Period, and after thirty (30) days the proposal will be canceled. 8. **Risk Review Period**: If an Offchain Veto is not exercised by the Guardians during the Offchain Veto Period, the proposal progresses to the Risk Review Period, where the Security Council is required to (1) complete technical reviews of all necessary code relevant to the proposal, and (2) approve the proposal unless technical deficiencies are identified. 1. During the 30 -day Risk Review Period, the proposal can only progress towards final execution if approved by the Security Council, or Guardians. 1. If the Security Council approves a proposal during the Risk Review Period, the proposal immediately progresses to the Timelock Period described below. 2. Guardians can approve a proposal during the Risk Review Period if the Security Council is unable or unwilling to approve the proposal, however the proposal will not proceed to the Timelock Period until the end of the 30-day Risk Review Period. 3. If neither the Security Council nor Guardians approve a proposal during the Risk Review Period, the proposal will be canceled at the end of the 30-day period (i.e. the proposal will not progress to final execution). 9. **Timelock Period**: Upon successful approval during the Risk Review Period, the proposal proceeds to a 24-hour Timelock Period. 10. **Final Execution**: Following the expiration of the Timelock Period, the proposal is queued for permissionless execution on Ethereum. ### 4. Token Governor 1. The Token Governor is a smart contract deployed on ZKsync Era. 2. The Token Governor allows for the delegated voting power conveyed by the ZK token to be used to vote on proposals related to assigning minting and burning rights for ZK tokens allocated to Token Programs. 3. Token Program Proposals ("[**TPPs**](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps)") must be made in accordance with the Token Program Guidelines, and help achieve the goals supporting the vision of the ZK Credo. 4. Token Governor proposals can be executed on ZKsync Era if passed in accordance with the proposal process below. ### 5. Token Governor Proposal Process 1. The [proposal process](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps#proposal-process-timeline) for a Token Governor is set out below. 1. **Proposal Submission**: Any Delegate who meets the proposal threshold is able to submit a proposal to the Token Governor, which is deployed on ZKsync Era, as well as the ZKsync Foundation Multisig, which has a signing threshold of three (3) Signers. 1. The proposal threshold required for a Delegate to submit a proposal to the Token Governor is 0.1% of the total number of ZK tokens that may be minted (currently 21 billion). 2. A proposal may be submitted via the [ZKsync Governance Portal](https://vote.zknation.io/dao) or any other interface connected to the Token Governor. 2. **Vote Delay Period**: Upon submission, a proposal enters a three (3) day vote delay period, prior to the commencement of the Voting Period. 1. A proposal may be cancelled during the Vote Delay Period by Guardians, if they choose to exercise their Onchain Veto as set out in *Schedule 4: ZKsync Guardians*. 3. **Voting Period**: The Voting Period for Token Governor proposals is seven (7) days. 1. Token Governor proposals have a quorum requirement of 3.0% (or 630 million) of the total number of ZK tokens that may be minted (currently 21 billion) and require a simple majority of the total number of "for" and "against" votes (i.e., casted votes without considering abstentions) to pass. 2. If a vote causes quorum to be reached in the last 2 days of the voting period, the proposal's voting period is extended 2 days from the point quorum is met. 3. A proposal may be cancelled during the Voting Period by Guardians, if they choose to exercise their Onchain Veto as set out in *Schedule 4: ZKsync Guardians*. 4. **Timelock Period**: If an Onchain Veto is not exercised by the Guardians during the Onchain Veto Period, and the proposal is approved by Delegates, the proposal progresses to a 3-day Timelock Period. 5. **Execution**: Following the expiration of the Timelock Period, the proposal is queued for permissionless execution on ZKsync Era. ### 6. GovOps Governor 1. The GovOps Governor is a smart contract deployed on ZKsync Era. 2. The GovOps Governor allows for the delegated voting power conveyed by the ZK token to be used to vote on Governance Advisory Proposals ("[**GAPs**](https://docs.zknation.io/zksync-governance-proposals/governance-advisory-proposals-gaps)"), that do not have direct onchain consequences. 3. The GovOps Governor is responsible for proposals related to offchain governance and/or operations of the ZKsync governance system. ### 7. GovOps Governor Proposal Process 1. The [proposal process](https://docs.zknation.io/zksync-governance-proposals/governance-advisory-proposals-gaps#proposal-process-timeline) for the GovOps Governor is set out below. 1. **Proposal Submission**: Any Delegate who meets the proposal threshold is able to submit a proposal to the GovOps Governor. 1. The proposal threshold required for a Delegate to submit a proposal to the GovOps Governor is 0.1% of the total number of ZK tokens that may be minted (currently 21 billion). 2. A proposal may be submitted via the [ZKsync Governance Portal](https://vote.zknation.io/dao) or any other interface connected to the GovOps Governor. 2. **Vote Delay Period**: Upon submission, a proposal enters a three (3) day vote delay period, prior to the commencement of the Voting Period. 1. A proposal may be cancelled during the Vote Delay Period by Guardians, if they choose to exercise their Onchain Veto as set out in *Schedule 4: ZKsync Guardians*. 3. **Voting Period**: The Voting Period for GovOps Governor proposals is seven (7) days. 1. GovOps Governor proposals have a quorum requirement of 3.0% (or 630 million) of the total number of ZK tokens that may be minted (currently 21 billion) and require a simple majority of the total number of "for" and "against" votes (i.e., casted votes without considering abstentions) to pass. 1. If a vote causes quorum to be reached in the last 2 days of the voting period, the proposal's voting period is extended 2 days from the point quorum is met. 2. A proposal may be cancelled during the Voting Period by Guardians, if they choose to exercise their Onchain Veto as set out in *Schedule 4: ZKsync Guardians*. 4. **Timelock Period**: If an Onchain Veto is not exercised by the Guardians during the Onchain Veto Period, and the proposal is approved by Delegates, the proposal progresses to a 3-day Timelock Period. 5. **Execution**: Following the expiration of the Timelock Period, the proposal may be executed, offchain or onchain, at the discretion of the proposer or parties named in the specification of the proposal. # Schedule 2: Emergency Response Procedures ### 1. Overview 1. Emergency Response Procedures detail the Emergency Responses that may be initiated and/or executed by specific governance bodies, to respond to security threats presented to the ZKsync protocol and/or the ZKsync governance system. 2. There are two emergency responses that may be executed within the ZKsync governance system: 1. Freeze of Layer 1 contracts; and/or 2. Emergency Upgrade (as defined below, each or together referred to as "**Emergency Response**" or "**Emergency Responses**"). 3. The Security Council is responsible for the identification and/or confirmation of certain circumstances that may require an Emergency Response to be taken. 4. Once the Security Council has classified a threat sufficient to invoke the Emergency Response Procedures, it may initiate a freeze and/or Emergency Upgrade to neutralize the threat. ### 2. Freeze 1. The Security Council may freeze any smart contracts which make up the ZKsync protocol, for differing periods of time. 1. A twelve (12) hour freeze may be initiated with the execution of an onchain transaction that is approved by three (3) Signers (as defined in the Overview) on the Security Multisig ("**Soft Freeze**"). 1. With the approval of nine (9) Signers on the Security Multisig, the signing threshold for a Soft Freeze may be changed by the Security Multisig to require a minimum of one (1) Signer and a maximum of nine (9) Signers. 2. A seven (7) day freeze may be initiated with an onchain transaction approved by nine (9) Signers on the Security Multisig ("**Hard Freeze**"). 2. After a Soft Freeze and/or a Hard Freeze has been initiated, the Security Council may unfreeze (“Unfreeze”) the contracts at their discretion, with the approval of nine (9) Signers on the Security Multisig. 3. After a Soft Freeze and a Hard Freeze have been initiated, an Emergency Upgrade must be passed before any subsequent freezes may be initiated. 4. Once frozen, if an Emergency Upgrade is executed the freeze is removed 5. Once frozen, an Emergency Upgrade is required to initiate a subsequent freeze 6. If freeze period expires, anyone may unfreeze the protocol ### 3. Emergency Upgrade 1. An upgrade can be executed by a multisig that calls an upgrade on the ProtocolUpgradeHandler contract ("**Emergency Upgrade Multisig**"), which does not require the approval of the Token Assembly ("**Emergency Upgrade**"). 2. The Emergency Upgrade Multisig requires the approval of the multisig of all three governance bodies who are signers on the Emergency Upgrade Multisig ("**Emergency Upgrade Signers**"). 3. The Emergency Upgrade Signers are: 1. Security Council; 2. Guardians; and 3. ZKsync Foundation. 4. An Emergency Upgrade may be initiated by any address. 5. In order to execute an Emergency Upgrade with the Emergency Upgrade Multisig, all three (3) Emergency Upgrade Signers must each reach the signing threshold on their respective multisig. 1. The signing threshold for the Security Multisig to approve an Emergency Upgrade on the Emergency Upgrade Multisig is nine (9) Signers. 2. The signing threshold for Guardian Multisig to approve an Emergency Upgrade on the Emergency Upgrade Multisig is five (5) Signers. 3. The signing threshold for the ZKsync Foundation Multisig to approve an Emergency Upgrade on the Emergency Upgrade Multisig is three (3) Signers. 6. An Emergency Upgrade may be executed, whether a freeze is active or not, with sufficient approval from the Emergency Upgrade Multisig. 7. An Emergency Upgrade during a freeze may include a message executed solely for the purpose of allowing the Security Council to initiate a subsequent freeze. # Schedule 3: ZKsync Security Council ### 1. Overview 1. The Security Council is a governance body designed to safeguard the security of the ZKsync protocol (ZKsync ERA, ZKsync Chains, and other components of ZKsync) and components of the ZKsync ecosystem governed by Protocol Governor proposals. 2. The Security Council consists of 8 technical experts ("**Security Council Members**") who are Signers (as defined in the Overview) of a multisig wallet ("**Security Multisig**") that has the power to perform certain standard and emergency actions (Emergency Responses) related to the ZKsync protocol as part of the ZKsync governance system. 3. The address of the Security Multisig, which is deployed on Ethereum, is: [0x66E4431266DC7E04E7d8b7FE9d2181253df7F410](https://etherscan.io/address/0x66E4431266DC7E04E7d8b7FE9d2181253df7F410). ### 2. Security Council Membership 1. Legal 1. Legal obligations of Security Council Members are governed by (1) contractual agreements entered into between the Security Council Members and the ZKsync Security Council entity; and (2) the bylaws of the ZKsync Security Council entity (to which the Security Council Members agree to be bound). 2. The ZKsync Security Council entity bylaws can be found [here](https://drive.google.com/file/d/1W5Z5rodkG9lEGIGVT3HSBQ7Foeed4mYL/view?usp=sharing). 2. Security Council Members 1. The following 8 entities and individuals are members of the Security Council: 1. Chainlight, represented by Tim Becker\ 0x84BF0Ac41Eeb74373Ddddae8b7055Bf2bD3CE6E0 2. Cyfrin, represented by Mark Scrine\ 0x35eA56fd9eAd2567F339Eb9564B6940b9DD5653F 3. Dedaub, represented by Neville Grech\ 0xB7aC3A79A23B148c85fba259712c5A1e7ad0ca44 4. Matter Labs, represented by Vlad Bochok\ 0xc3Abc9f9AA75Be8341E831482cdA0125a7B1A23e 5. Nethermind, represented by Mauricio Cortes\ 0x69462a81ba94D64c404575f1899a464F123497A2 6. Open Zeppelin, represented by Juan Bautista Carpanelli\ 0x34Ea62D4b9bBB8AD927eFB6ab31E3Ab3474aC93a 7. Peckshield, represented by Xuxian Jiang\ 0xFB90Da9DC45378A1B50775Beb03aD10C7E8DC231 8. Spearbit, represented by Mike Leffer\ 0x9B8Be3278B7F0168D82059eb6BAc5991DcdfA803 3. Term 1. Security Council Members will serve on the Security Council until they are removed or replaced. 4. Removal of Security Council Members 1. A Protocol Governor proposal, approved by Delegates, is required to remove a Security Council Member from the Security Council as a Signer of the Security Multisig. 2. In exceptional circumstances, a Security Council Member may be removed from the Security Council and Security Multisig by an Emergency Upgrade, which requires the approval of the Emergency Upgrade Multisig. 5. Replacement and Addition of Security Council Members 1. The Board of the ZKsync Security Council Foundation will recommend candidates to replace any Security Council Members that have been removed from the Security Council and Security Multisig, and may use the GovOps Governor as part of this process. 2. A Protocol Governor proposal, approved by Delegates, is required to be passed in order to add new Security Council Members to the Security Multisig. 3. In exceptional circumstances, where there is a security threat and the period of time required to submit a Protocol Governor proposal is considered by Guardians to put the Mission of the ZK Credo at risk, Security Council Members may be added to the Security Council and Security Multisig by an Emergency Upgrade, which requires the approval of the Emergency Upgrade Multisig. ### 3. Emergency Responses 1. Power to freeze 1. The Security Council has the power to freeze the ZKsync protocol, or parts thereof, for various periods of time, in response to imminent or active security threats, such as critical bugs or exploits, that could jeopardize the integrity of the ZKsync protocol. 2. A Soft Freeze, which initiates a freeze for twelve (12) hours, requires approval from three (3) Security Council Members. 1. The signature threshold for a Soft Freeze (between one (1) and six (6) Signers) may be adjusted at the sole discretion of Security Council Members, with the approval of six (6) Signers on the Security Multisig. 3. A Hard Freeze, which initiates a freeze for seven (7) days, requires approval from six (6) Security Council Members. 4. While the ZKsync protocol is frozen, only an Emergency Upgrade may be executed to address the threat. 5. After a Soft Freeze and a Hard Freeze have been initiated, an Emergency Upgrade must be passed before any subsequent freezes may be initiated. 6. Once frozen, an Emergency Upgrade may be executed in order to remove the freeze and/or initiate a subsequent freeze. 2. Power to unfreeze 1. After a Soft Freeze and/or a Hard Freeze has been initiated, the Security Council may unfreeze (“Unfreeze”) the contracts at their discretion, with the approval of six (6) Signers on the Security Multisig. 3. Emergency Upgrade 1. Any Security Council Member may initiate an Emergency Upgrade without the express approval of the Token Assembly in response to a security threat. 2. In order to pass an Emergency Upgrade, approval is required from Emergency Upgrade Multisig (i.e., six (6) Signers on the Security Multisig, along with five (5) Signers on the Guardian Multisig, and three (3) Signers on the ZKsync Foundation Multisig. ### 4. Non-Emergency Actions 1. If a Protocol Governor proposal is approved by Delegates, the proposal progresses to a three (3) day Timelock Period during which time Guardians can exercise an Offchain Veto of the proposal ("**Offchain Veto Period**"). 2. If Guardians exercise their veto during the Offchain Veto Period, with a minimum of five (5) Guardians transmitting an offchain signed statement to the ZKsync Security Council Foundation stating they are exercising their veto power, the Security Council shall abstain from approving the Protocol Governor proposal in the Risk Review Period. 1. With approval from any two (2) individual Guardians, the Offchain Veto Period may be extended from three (3) days to seven (7) days, if the extension is executed in the first three (3) days of the Offchain Veto Period. 3. If Guardians do not exercise their veto during the Offchain Veto Period, the proposal will progress to a 30-day period that commences at the end of the Offchain Veto Period, during which time the proposal must be approved by either the Security Council or Guardians in order to progress ("**Risk Review Period**"). 4. It is the responsibility of the Security Council to evaluate all Protocol Governor proposals that progress to the Risk Review Period, provided the Guardians have not exercised their Offchain Veto Power on a given proposal. 5. The signing threshold for the Security Multisig to approve a Protocol Governor proposal during the Risk Review Period is three (3) Signers on the Security Multisig. 6. Upon reaching the signing threshold of the Security Multisig, approval of the Protocol Governor proposal by the Security Council may be executed immediately, progressing the proposal to the 24-hour Timelock Period before execution. 7. If the Security Council, for any reason, is unwilling or unable to approve a Protocol Governor proposal during the Risk Review Period, Guardians can approve the Protocol Governor proposal during this period, and execution (with Timelock Period) of this approved proposal will be initiated at the end of the 30-day Risk Review Period. # Schedule 4: ZKsync Guardians ### 1. Overview 1. The [ZK Credo](https://github.com/zksync/credo) sets out the vision and values of ZKsync ("**the Mission**"). The Mission is protected by Guardians, who have the independent power to veto governance proposals that are inconsistent with the ZK Credo. This includes the power to veto governance proposals that are abusive, malicious or could otherwise adversely affect ZKsync or its governance system. The Guardians' decisions are made at their sole discretion. 1. The Guardians are not required to assess the legality of governance proposals. 2. For the powers of the ZKsync Association with respect to content (e.g. proposals) related to the ZKsync governance system shown on its controlled online interfaces, please refer to Section 5.2. 2. Guardians are a governance body consisting of eight (8) individuals who are Signers (as defined in the ZKsync Governance Procedures: Overview) of a multisig wallet ("**Guardian Multisig**") that has the ability to exercise veto powers and approve Protocol Governor proposals during the Risk Review Period, and approve Emergency Responses related to the ZKsync protocol. 3. The address of the Guardian Multisig, which is deployed on Ethereum, is: [0x600dA620Ab29F41ABC6596a15981e14cE58c86b8](https://etherscan.io/address/0x600dA620Ab29F41ABC6596a15981e14cE58c86b8). ### 2. Membership 1. Legal 1. Legal obligations of Guardians are governed by the bylaws of the ZKsync Guardians entity. 2. The bylaws of the ZKsync Guardians entity can be found [here](https://drive.google.com/file/d/1D_xkc1YeB46x1r8MnN2Sy-_1CurqP7y3/view?usp=sharing). 2. Members 1. The following eight (8) individuals are Guardians: 1. Juan Benet \ 0x55c671BcE13120387Ded710A1d1b80C0e3d8E857 2. Alex Gluchowski \ 0x6D26874130A174839b9cd8CB87Ed4E09D0c1a5f0 3. Bartek Kiepuszewski \ 0x015318c16AE443a20DE0A776dB06a59F0D279057 4. pcaversaccio \ 0xCe7a3dFcc35602155809920Ff65e093aa726f6cf 5. Gabriel Shapiro \ 0x178D8Eb1A1fb81B5102808A83318Bb04C6a9fC6D 6. Awa Sun Yin \ 0x2A90830083C5Ca1f18d7AA7fCDC2998f93475384 7. Aleksandr Vlasov \ 0x590926dBCDfD19627c3BbD2A6Eb96DeC7a3AbF69 8. Eric Wall \ 0x538612F6eba6ff80FBD95D60dCDee16b8FfF2c0f 3. Term 1. Guardians will act as Signers on the Guardian Multisig until they are removed or replaced in accordance with the specifications in this schedule. 4. Removal of Guardians 1. Guardians may be removed from the Guardian Multisig by passing a Protocol Governor proposal (it being understood that Guardians have veto power over such proposals). 5. Replacement of Guardians 1. Guardians will recommend candidates to replace any Guardian that is removed from the Guardian Multisig. 2. A Protocol Governor proposal, approved by Delegates, is required to be executed (i.e. no Offchain Veto is passed) in order to replace a Guardian on the Guardian Multisig. ### 3. Veto Powers 1. When Guardians exercise either an Onchain Veto or an Offchain Veto (as defined below), they are required, as a governance body, to communicate a justification for their actions in the ZKsync Forum () within 48-hours of exercising a veto. ### 4. Onchain Veto 1. The Guardians may exercise an onchain veto on any proposal submitted to the Token Governor or the GovOps Governor ("**Onchain Veto**"). 2. With the signatures of five (5) Signers on the Guardian Multisig, the Guardians have the power to execute an Onchain Veto by calling the cancel function from the Guardian Multisig, which means the proposal cannot progress towards execution. 3. The Onchain Veto may be exercised during the Vote Delay Period or during the Voting Period on the relevant Governor. ### 5. Offchain Veto 1. An offchain veto, communicated as a digitally signed written statement transmitted to the Security Council by electronic messaging ("**Offchain** **Veto**"), may be exercised with respect to any proposal or group of proposals submitted to the Protocol Governor. 2. Guardians may also exercise their veto in relation to proposals submitted to the Protocol Governor that affects the Guardians themselves. 3. With a written statement signed by five (5) Guardians, the Guardians may exercise an Offchain Veto by communicating the signed statement to the ZKsync Security Council Foundation. 4. The Offchain Veto may be exercised at any time during the three (3) day Timelock Period that commences at the end of the Voting Period for a proposal that has been approved by Delegates on the Protocol Governor ("**Offchain Veto Period**"). 5. With the signatures of two (2) Signers on the Guardian Multisig, the Guardians may execute an onchain transaction to extend the Offchain Veto Period from three (3) days to seven (7) days, if the extension is executed within the first three (3) days of the Offchain Veto Period. ### 6. Risk Review 1. With the approval of five (5) Signers on the Guardian Multisig, the Guardians may approve a Protocol Governor proposal during the Risk Review Period, as defined in Schedule 3: ZKsync Security Council, if the Security Council, for any reason, is unwilling or unable to approve the proposal. 2. Where Guardians approve a Protocol Governor proposal during the Risk Review Period, that approval will be executed onchain 30 days after the Risk Review Period commences. ### 7. Emergency Upgrades 1. The Guardian Multisig is one (1) of three (3) Signers required to approve an Emergency Upgrade. 2. Any individual Guardian is able to submit an Emergency Upgrade for onchain approval, provided the intention of the Emergency Upgrade is to protect the Mission. 3. An Emergency Upgrade requires onchain approval from five (5) Signers on the Guardian Multisig, along with approvals from the Security Multisig and the ZKsync Foundation Multisig, in order to be executed. # ZK Nation Code of Conduct ### **Welcome to the ZK Nation Community!** Our goal is to cultivate a safe, friendly, and inclusive space that benefits all participants of ZK Nation in alignment with the values and vision of the [ZK Credo](https://github.com/zksync/credo). This Code of Conduct outlines our shared values and expectations to help ensure that the community remains a positive and enriching environment for everyone. #### **When and how to use the ZK Nation Code of Conduct** This is your guide for engaging as part of the ZK Nation community. This Code of Conduct applies to all physical and digital spaces related to ZK Nation funded by the ZKsync Association, which includes, but is not limited to: * ZK Nation Docs at [docs.zknation.io](http://docs.zknation.io) * ZK Nation Governance Portal at [vote.zknation.io](http://vote.zknation.io) * ZK Nation Forum at [forum.zknation.io](https://forum.zknation.io/) Your continued access and/or engagement is contingent upon following these guidelines. #### **Expected Behaviors** * **Be Ethical:** We endeavor to enrich the ZKsync governance system, while not infringing on the rights and wellbeing of others. Tax evasion, promoting information leaks, speculating on tokens or token prices, or otherwise breaking the law are strictly prohibited. * **Be Kind and Respectful:** Treat everyone with kindness, empathy, and respect. We all come from different backgrounds, perspectives and experiences, so let’s celebrate our differences and foster a culture of openness and understanding. We may have strong feelings about other layer 1 and layer 2 blockchains, but that is no reason to disparage, defame, or slander any competitor to ZKsync or what other chains are doing. Feel free to compare metrics and features, but keep to the facts and be respectful of all the builders in web3 trying to advance freedom through blockchain technology. * **Share and Learn:** Our community is a space for sharing knowledge, experiences, and ideas. Positively contribute to discussions, offer helpful feedback, be willing to educate others on your work and remain open to learning from others. * **Give Credit:** When sharing content or ideas that aren’t your own, ensure you give proper credit to the original creator. Plagiarism and intellectual property infringement are strictly prohibited. * **Respect Privacy:** Always seek consent before sharing personal information about yourself or others. Respecting each other’s privacy is vital to building trust within our community. * **Be Inquisitive And Embrace Continuous Improvement:** We strive to improve from each experience, and are open to constructive criticism. We encourage questions, and redirect them to the appropriate channel if we do not have the answer. * **Mind Your Language:** Communication is key. Use clear and considerate language in your interactions. We aim to create a welcoming environment for users of all ages, so please avoid excessive profanity or explicit content. Remember that ZKsync community members are a diverse bunch. English is our primary working language, but to help others where English is not their first language, be succinct and avoid acronyms where possible. * **Stay On Topic:** While we encourage friendly conversations, please ensure your discussions remain relevant to the community’s purpose. To keep our space focused and valuable, off-topic or irrelevant content may be redirected or removed, and users who persist with such behavior may be restricted or removed from accessing the forum. Specific topics that are not appropriate include offering to buy or sell any cryptocurrency or engage in price speculation. * **No Hate Speech or Harassment:** Let's maintain a constructive and uplifting atmosphere in all interactions. We have a zero-tolerance policy for any form of hate speech, bullying, harassment, or discrimination. This includes, but is not limited to: * Violent threats or language directed against another person. * Sexist, racist, or otherwise discriminatory jokes and language. * Posting sexually suggestive, explicit, or violent material. * Posting (or threatening to post) other people's personally identifying information ("doxing"). * Sharing private content without explicit consent, such as messages sent privately or non-publicly. * Personal insults. * Unwelcome sexual attention. * Excessive or unnecessary profanity. * Repeated harassment of others. In general, if someone asks you to stop, then stop. * Advocating for, or encouraging, any of the above behavior. * **Have Fun and Connect:** Finally, remember that the ZKsync community is a place to connect, learn, and enjoy. Participate in a manner that encourages positive interactions and enhances the experiences of all. #### Managing Violations If you are the subject of, or witness to, any violations of this Code of Conduct, please contact us at . #### **Attribution** License: Version: 1.1 Apache 2.0 license, derived from the Apache Foundation Code of Conduct. Also, CC BY-SA 3.0 derived from the Mozilla Community Participation Guidelines. The ZK Nation CODE OF CONDUCT applies to all digital and physical environments related to the ZK Nation and ZKsync governance funded by the ZKsync Association. # ZKsync Delegation Standards > ℹ️ The ZKsync Delegate Standards are opt-in, but all Delegates within the ZKsync Token Assembly are expected to adhere to the following set of standards in addition to the [ZK Nation Code of Conduct](https://docs.zknation.io/~/changes/H66bL261LQuvpaaVG6z9/zk-nation-community/zk-nation-code-of-conduct). In addition to the general community standards outlined in the [ZK Nation Code of Conduct](https://docs.zknation.io/~/changes/H66bL261LQuvpaaVG6z9/zk-nation-community/zk-nation-code-of-conduct), delegates are held to a set of more specific standards that support healthy governance. ### Good Faith & Best Interest * Delegates should act with honesty, integrity, and transparency, at all times. * Delegates should operate and vote in what they believe is in the best interest of the ZKsync network & ecosystem. * Delegates should be committed to fostering a safe, welcoming, and harassment-free environment for all. * There will be no tolerance for discrimination against any person based on geographic, ethnic, sexual, religious, or other identifying features. ### Care & Attention * Delegates should provide due care and attention in their role, making professional and unbiased reviews of each proposal prior to the submission of their vote. * Delegates should ensure that they communicate the rationale behind each of their votes in a clear and accessible way (e.g. on the forum). > 👉 Aim to provide comments with thoughts and attitudes towards new proposal drafts posted on the forum *before* they are submitted onchain. * Delegates should maintain a working knowledge of developments & happenings within the network and community of ZKsync. ### Conflicts of Interest * Delegates should avoid conflicts of interest where possible and mitigate their impact when not possible. Please disclose any conflicts of interest in your Cactus Delegate profile and be sure to keep it up to date as things change. ### **Communication, Availability and Responsiveness** * Delegates should - within reason - be accessible to the community to answer questions, respond to comments, and discuss issues. They should try to maintain an active presence on community channels. * Delegates should communicate their intention to stop being a delegate at least *one month* in advance to allow ZK holders to re-delegate. > 👉 Post an announcement on the forum under [*Delegates*](https://forum.zknation.io/c/delegates/17) to let the community know they should re-delegate any ZK that is currently delegated to your address. ### Disclaimers * The Delegate Standards will not cover all possible scenarios and edge cases. We ask that delegates please act in accordance with the spirit of the Code and refrain from exploiting loopholes that may exist. * Any changes to the Delegate Standards should be discussed on the forum under the [*Delegates*](https://forum.zknation.io/c/delegates/17) category. #### Attributions: * Radworks: [Delegate Standards](https://govradicle.super.site/delegate-standards) * Uniswap: [\[RFC\] Delegate Code of Conduct](https://gov.uniswap.org/t/rfc-delegate-code-of-conduct/20913) * Optimism: [Delegate Expectations](https://community.optimism.io/token-house/delegate-expectations), [Delegate Code of Conduct \[OLD\]](https://gov.optimism.io/t/delegate-code-of-conduct-old/3943) * MakerDAO: [Recognized Delegate Code of Conduct](https://forum.makerdao.com/t/recognised-delegate-code-of-conduct/9384) # ZK Token MiCA White Paper The ZKsync Association has drawn-up a white paper on the ZK Token that takes into account the relevant requirements of the EU Markets in Crypto-Assets Regulation (Regulation (EU) 2023/1114 –"MiCAR"). {% embed url="" %} # Risk Factors & Disclaimers *17 June 2024* ### Scope and Purpose of ZKsync Governance Procedures The ZKsync Governance Procedures aim to make certain disclaimers, disclosures, and other risk-oriented information which relate to governance and the governance processes involved in the ZKsync protocol (the ZKsync blockchain network and ZKsync governance system are collectively referred to herein as the “**ZKsync Protocol**”). The ZKsync Governance Procedures are intended to disclaim any legal obligations of ZKsync Protocol participants to one another and to any third parties and to serve as a guide to a range of potential risks, uncertainties, and adverse/negative facts that may be associated with the ZKsync Protocol or its use or results of operation. It is highly recommended that you carefully study the ZKsync Governance Procedures including, but not limited to the related smart contracts, code and onchain mechanisms before directly or indirectly using the ZKsync Protocol, the ZK token, engaging in any ZKsync governance system or otherwise engaging in any other activities directly or indirectly related to the ZKsync ecosystem. The ZKsync Governance Procedures are intended to function as a high-level and readily-understandable description of the governance and the governance processes involved in the ZKsync Protocol. However, they are incomplete because they relate and refer to smart contracts, code and onchain mechanisms that operate deterministically in accordance with their specifications. As such, the ZKsync Governance Procedures must only be read in conjunction with a thorough understanding of those smart contracts, code and onchain mechanisms. If you are unable to understand or read smart contracts, code and onchain mechanisms you should take advice from a person (legal and natural persons are collectively referred to as “**Persons**”) that can. As such, the ZKsync Governance Procedures are not in themselves and are not intended to be a comprehensive account of all relevant risks, uncertainties, adverse/negative facts and disclaimers relating to the governance and the governance processes involved in the ZKsync Protocol. ### The Governance Parties Decisions made by any Person referred to in the ZKsync Governance Procedures (collectively, “**Governance Parties**”) are made at the sole discretion of the applicable Governance Party. Unless explicitly agreed to in writing by a Governance Party, no Governance Party shall have express or implied duties to any Person, or be liable under any circumstance, for decisions made in good faith in connection with their roles contemplated by or made pursuant to the ZKsync Governance Procedures. ### The ZKsync Governance Procedures The ZKsync Governance Procedures are intended to be for descriptive, disclosure and informational purposes only and nothing contained herein shall be construed as creating any agency, partnership, joint venture or other form of joint enterprise, employment, or fiduciary relationship between or among any Governance Party and any other Person. No Person, by virtue of the ZKsync Governance Procedures, will have any right, power, or authority to act or create an obligation, express or implied, on behalf of another party. Nothing herein shall be deemed or constructed as creating a business opportunity relationship. No Governance Party is a party to the ZKsync Governance Procedures and no Governance Party makes any guarantee of potential earnings that will, or may, be received in connection with activities relating to the ZKsync Protocol, and has not provided anyone with any statements relating thereto. ### Limitations on Liability The ZKsync Protocol and all other relevant technologies related to the ZKsync Protocol are being provided on an as-is basis, without representation, warranty, insurance or indemnity, and any and all participation is solely at your own risk. No Governance Party or any other Person has made or makes any other express or implied representation or warranty, either written or oral, including any representation or warranty as to the accuracy or completeness of any information provided in the ZKsync Governance Procedures or as to the future success of the ZKsync Protocol or any representation or warranty arising from statute or otherwise in law. IN NO EVENT SHALL ANY GOVERNANCE PARTY OR ANY OF ITS AFFILIATES, OWNERS, DIRECTORS, OFFICERS, EMPLOYEES, AGENTS OR REPRESENTATIVES BE LIABLE TO ANY PERSON FOR CLAIMS OR DAMAGES OF ANY KIND WHATSOEVER, INCLUDING CONSEQUENTIAL, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, PUNITIVE OR ENHANCED DAMAGES, LOST PROFITS OR REVENUES, OR DIMINUTION IN VALUE ARISING OUT OF, RELATING TO, OR IN CONNECTION WITH ANY ACTION TAKEN OR NOT TAKEN IN RELATION TO THESE ZKSYNC GOVERNANCE PROCEDURES AND THE ACTIVITIES CONTEMPLATED THEREBY, REGARDLESS OF (A) WHETHER SUCH DAMAGES WERE FORESEEABLE, (B) WHETHER OR NOT A PERSON WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES AND (C) THE LEGAL OR EQUITABLE THEORY (CONTRACT, TORT, OR OTHERWISE) UPON WHICH THE CLAIM IS BASED. No action or inaction on the part of any Governance Party described in these ZKsync Governance Procedures will entitle any other Person to equitable relief, including specific performance, injunctive relief, rescission, or any other form of equitable remedy. ### Irreversibility of Transactions and Lack of Remedies and Insurance for Damages Blockchain transactions are, under normal conditions, irreversible. Any tokens, including any ZK tokens, that you deposit into ZKsync-related smart contracts are subject to potential risk of permanent disablement, impairment, loss or forfeiture in the event of any exploits, bugs or malfunctions of the relevant smart contracts or the underlying blockchain itself (including both ZKsync and Ethereum), and no remedy will be available from any Person due to any normal or direct damages, indirect, special, incidental, consequential or punitive damages or losses of any character, including damages for loss of goodwill, lost profits, lost sales or business you may suffer in connection with your participation in the ZKsync Protocol and all other relevant technologies related to the ZKsync Protocol or use of any related technologies. ### Experimental Technology; Technical Risks; Independent Due Diligence Required The technologies and assets involved in the ZKsync Protocol are highly experimental and risky, have uncertain and potentially volatile value (if any), and should be directly evaluated by experts in blockchain technologies before use. Use them solely at your own risk. You must not rely on the ZKsync Governance Procedures, any articles, blogs, social media posts, summaries or published code audits as an accurate description or evaluation of the ZKsync Protocol or any other blockchain, or for purposes of making any financial, governance, voting or other decision. Instead, you must only participate in the ZKsync Protocol after thoroughly reviewing and understanding the related smart contracts, code and onchain mechanisms that operate deterministically in accordance with their specifications, in accordance with your own independent due diligence process (which should be supplemented by professional advice, where you are unable to or do not have the required skills to form your own independent opinion). ### Multisignature Controls Over the ZKsync Protocol Certain elements of the ZKsync Protocol can be modified or controlled by certain cryptographic multisignature smart contracts stored on their respective blockchains (each, a “**Multisig**”). Each Multisig, in turn, is administered by Persons who each hold one or more private keys, a subset of which may (by signing their respective private keys to the same transaction and broadcasting that transaction to blockchain validators or sequencers) instruct validators or sequencers to perform Multisig operations. It is possible for the Multisig key holders, through the Multisig, to change certain parameters of the ZKsync smart contracts or other ZKsync-related technologies. This discretion of the Multisig key holders constitutes a material risk, and could enable your tokens, including but not limited to any ZK tokens, to be adversely affected, impacted, lost, damaged, destroyed, diluted, modified, used in unexpected ways, subjected to unexpected risks, or misappropriated. ### ZKsync Multisig Key Holders The Multisig keyholders of the ZKsync Security Council Foundation are expected to be independent service providers of the ZKsync Security Council Foundation. These keyholders are expected to execute a Multisignature Participation Agreement and a service level agreement with the ZKsync Security Council Foundation providing, among other things, that they will use their signature authority in their independent judgment to foster ZKsync as a public good which is available for ZKsync users and others in the ZKsync community. The Multisignature Participation Agreement and a service level agreement are expected to contain legal constraints on the authority of the Multisig keyholders to use their signature authority to change the ZKsync Protocol to enhance the overall security of those systems. The Multisig keyholders of the ZKsync Guardians Foundation are expected to be directors of the ZKsync Guardians Foundation. These keyholders are expected to execute a Multisignature Participation Agreement with the ZKsync Guardians Foundation providing, among other things, that they will use their signature authority in their independent judgment to foster ZKsync as a public good which is available for ZKsync users and others in the ZKsync community. The Multisignature Participation Agreement is expected to contain legal constraints on the authority of the Multisig keyholders to use their signature authority to change the ZKsync Protocol. However, the existence of a Multisignature Participation Agreement and / or the relevant bylaws of the relevant entity do not guarantee that the Multisig key holders will comply with their terms, and, due to the nature of private/public- key cryptography, ZKsync and other relevant technologies, the ability and willingness of the ZKsync Security Council Foundation or the ZKsync Guardians Foundation to timely and effectively enforce the terms of the Multisignature Participation Agreement and or the relevant bylaws against the Multisig key holders, and other factors, the Multisig key holders’ performance of their obligations under the Multisig Participation Agreement and or the bylaws cannot be guaranteed and is subject to numerous risks and uncertainties. By using the ZKsync Protocol you agree to assume all risks arising from the existence and operation of each Multisig ### Other ZKsync-Related Multisigs Systems not constituting a part of the ZKsync Protocol, but used in the functioning of the ZKsync Protocol within the ZKsync ecosystem, may also be subject to control by Multisigs, or even by single administrative accounts. Such systems may include bridges, vaults, bots, oracles and other blockchain systems on which the foregoing are deployed, and other relevant technologies. Any mutability of such systems through their respective Multisigs or other control accounts may adversely affect the functioning of the ZKsync protocol including but not limited to the ZKsync ecosystem and/or the ZKsync governance system. Please be aware of all such dependencies and review their applicable code and documentation to understand these risks. ### Risks of No Promised Efforts or Resources The ZKsync Protocol is intended to be community-governed. After the public launch of the ZKsync Protocol, none of the Persons who created all or any part of the ZKsync Protocol smart contract system should be expected to have a material ongoing role in ZKsync research, development or promotion. Certain relevant parties may elect to undertake limited ministerial activities directly or indirectly related to ZKsync, such as maintaining availability of a ZKsync related web interface, but no promise, guarantee or assurance of such ministerial efforts or any other efforts is being made, and any such efforts which do occur may be abandoned at any time, with or without advanced notice. There is no ‘ZKsync enterprise’, ‘ZKsync company’ or ‘ZKsync business’. The ZKsync Protocol is comprised of multiple different inter-related technologies, systems and smart contracts and from time to time will be used, interacted with or otherwise referred to by a diverse range of participants each of whom will have different interests, whether economic, technical, social or otherwise. Many such interests will be in direct conflict and as such, you acknowledge that there cannot be a direct collective benefit or adverse effect of participants interacting with the ZKsync Protocol. No Person has promised you, or assumed any obligation to you to exert or provide financial, technical, social or other support for, any efforts, capital or resources in connection with the ZKsync Protocol. No Person has promised you, or assumed any obligation to you to exert or provide financial, technical, social or other support for, any research, development, promotion, marketing, maintenance, monitoring, or improvements relating to the ZKsync Protocol. Any past, present or future efforts on the part of any Person are being conducted on a voluntary and not committed basis, and are not intended as, and must not be construed or relied upon as, a promise of continuing efforts. Any past, present or future efforts on the part of any Person may not have the intended outcome, and the willingness or ability of any particular Person to influence or otherwise change the ZKsync Protocol. ### Risks of Decentralized Governance Updates, changes or amendments to the ZKsync Protocol may require approval of the Token Assembly, which consists of a dispersed group of ZK token holders that may be unable or unwilling to sufficiently coordinate to produce action or inaction. ### Risks of Builder ZK Token Allocations Certain Persons who contributed to the research and development of the ZKsync Protocol have received 16.1% of the ZK token supply, subject to lockup. Further details can be found at: ; No such Person has made any representation, promise, guarantee or assurance to you that any ZK token granted to any such Person, or any funding or resources of any such Person, will be held, used or spent for the benefit of the ZKsync Protocol and any such Person may interact with their ZK token at their sole discretion, subject to any contractual restrictions on such. Any sale or other transfer or distribution of such ZK tokens could occur without warning. Any such transaction would increase the circulating supply of ZK tokens. Depending on the number of ZK tokens sold, transferred, or distributed, the terms of sale, transfer or distribution and the prevailing market conditions, such a sale, transfer or other distribution could have a material adverse effect on the price or value of, or demand for, ZK tokens. While locked, the ZK tokens of builders will be votable. Any use of such ZK to vote in relation to the ZKsync Protocol could affect governance outcomes. No assurance can be made that any such ZK token recipients will participate in ZK governance. Any voting of such ZK tokens could fail to be conducted on a reasonable, good faith, diligent, or disinterested basis and may not be done in the best interests of other ZK token holders or the ZKsync protocol including but not limited to the ZKsync ecosystem and/or the ZKsync governance system or the ZKsync community. Any ZK token holder could have financial, social or other interests or incentives which could outweigh their respective interests and incentives (if any) relating to the ZKsync Protocol. No ZK token holder owes you fiduciary duties, duties of care or other legal duties which would preclude them from following such extrinsic interests to the detriment of your interests or the interests of the ZKsync Protocol. ZK token holders who choose to participate in governance will be required to use their own personal independent discretion and decision-making in doing so, including the choice as to any delegation of their voting power to a delegate. As a result of the foregoing factors and the lack of any Person or group of Persons able to control and manage the ZKsync Protocol, any discretionary decision-making related to such systems depends on the effectiveness of spontaneous group decision-making among participating ZK token holders. There may be disputes, differences of opinion, disagreements, conflicting incentives and a lack of coordination among or between any or all governance participants, and such circumstances may adversely affect governance results. ### ZKsync Content; Informational Purposes Only All publications, articles, blogs, Xeets, tweets, messages, posts, other online communications, videos, documents, statements, analyses and information relating to the ZKsync Protocol (collectively, “**ZKsync Content**”) are intended solely for general educational purposes regarding the code, smart contracts, software systems and other social or governance systems relating to the ZKsync Protocol and not as financial, legal, accounting, investment, tax or other advice or services, including any recommendation as to any action or inaction. Accessing or using the ZKsync Content does not create any fiduciary, service or other contractual or common law relationship between you and the Persons who produce or publish the ZKsync Content. The ZKsync Content is not intended as and does not provide or create or constitute a part of any advice, representation, warranty, certification, guarantee, promise, offer, issuance, solicitation, undertaking, service, indemnity, insurance, partnership, joint venture, or enterprise, express or implied. The ZKsync Content is not and does not constitute a part of an offer or agreement to make any products or services available now or in the future, to maintain or update or improve any technologies or content, or to sell or buy or otherwise transact in any asset or enter into any transaction, including anything in relation to the ZKsync Protocol. The ZKsync Content may be inaccurate, incomplete, out-of-date, or biased. The ZKsync Content may utilize incorrect data and assumptions, make incorrect predictions, or fail to account for material risks. The ZKsync Content was not prepared by fiduciaries, has not been assessed by independent third parties and may have been prepared by Persons with undisclosed material conflicts of interest. All use of the ZKsync Content and the technologies described therein, including but not limited to the ZKsync Protocol. You must not rely on the ZKsync Content as a basis for making any financial, economic, social, voting or other decision but must instead conduct your own independent due diligence into all relevant matters or engage your own professional advisors to conduct such due diligence on your behalf. ### No Governmental/Regulatory Review or Approval The ZKsync Content and the matters described in the ZKsync Content have not been reviewed, approved, endorsed, opined on, licensed or registered by or with any regulator or other entity (including governmental agencies, commissions, and self-regulatory organizations), and the authors of the ZKsync Content are not licensed to provide any legal, financial, accounting, investment, broker, dealer, or other advice or services. ### Uncertain Nature of Forward-Looking Statements; No Duty to Update. Any forward-looking statements in the ZKsync Content are subject to numerous assumptions, risks and uncertainties, and thus the events described or predicted therein are subject to change or to fail to occur in accordance therewith. The authors of the ZKsync Content undertake no obligation to update, supplement or amend any statement that becomes inaccurate or incomplete after the date on which the ZKsync Content is first published, or to alert the public as to any such inaccuracy or incompleteness, whether such inaccuracy or incompleteness arises as a result of new information, changes in plans, unanticipated events or otherwise. ### No Investment or Lending; No Contract Rights; Absence of Counterparties Your transactions utilizing the ZKsync Protocol are not intended to be an investment, a capital-raising transaction for an enterprise, a sale of your tokens to any Person or group of Persons or a purchase of tokens from any Person or group of Persons. They are also not intended to be a loan, consignment or deposit of your tokens to or with, or a service provided to you by, any Person or group of Persons. Your deposited and/or locked tokens will not be owned by or under the control of any Person or group of Persons involved in creating the ZKsync Protocol. There is no private or governmental insurance (on the part of the creators of the ZKsync Protocol, any nation-state or any other Person) available to compensate you for any such losses or other adverse circumstances relating to ZKsync transactions or smart contract interactions. \* \* \* \* \*
# ZKsync Association The ZKsync Association is a non-profit association established under Austrian law to enhance digital literacy and empower all members of society with the skills and knowledge to understand the blockchain and digital economy with focus on (i) cryptography, especially in the field of zero knowledge, and (ii) blockchain-based networks, systems, architectures, applications and products, particularly those involving zero-knowledge and/or artificial intelligence, and promote the development and dissemination of such knowledge. Through this mandate, the ZKsync Association supports, promotes, and helps develop ZKsync’s protocol token and its governance system. The ZKsync Association is also the home to the ZKsync Governance Team. This team maintains infrastructure and resources for blockchain governance operations, oversees the system design and updates, educates the ZK-Community as well as the public on decentralized governance, blockchain technology (in particular in the realm of zero knowledge proofs), and ensures that processes aligns with ZKsync’s core principles. A copy of the Articles of Association for the ZKsync Association can be found here: [ZKsync Association AoA Bylaws (Jan 31 2025).](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGbudQH8k8UtO68sj1Zni%2Fuploads%2FJ24PBRLgLu0uuNHUGuDX%2FZKsync%20Association%20AoA%20Bylaws%20Jan%2031%202025.pdf?alt=media\&token=0c769007-dcde-4e4d-8b3b-827bd2d248d8) ### Means & Activites The ZKsync Association achieves it's purpose through means outlined in the Articles of Association. The main areas of focus for the ZKsync Association include: **Compliance:** * **Regulatory compliance:** As the Issuer, the Association ensures that all activities involving the ZK token and other applicable tokens comply with the requirements of the Markets in Crypto-Assets Regulation (MiCAR). **Community Coordination** * **Open governance portal:** Operate a free of charge, publicly available governance portal for ZKsync (a ZK-based Layer 2 blockchain), proposal forums, communication channels, on-chain voting resources, and governance updates. * **Transparent governance coordination:** Promote transparent, open, and accessible communication and coordination among decentralized governance bodies, particularly within the ZKsync ecosystem, to ensure transparent decision-making for all members of society. * **Community engagement & education:** Organize and sponsor a range of events (e.g. meetups, hackathons, roundtables, etc.) and maintain online communication channels to facilitate the exchange of ideas between interested participants and the general public and to enhance digital literacy and broader adoption of blockchain and ZK technologies in general across all skill levels. **Resources & Adoption** * **Public resources:** Develop and disseminate knowledge, tools, and resources for blockchain technology, ZK protocols and decentralized governance - particularly on the ZKsync protocol - by establishing and maintaining a freely accessible library of research, educational materials, and open-source software for public access. * **Adoption of ZK ecosystems:** Promote the widespread adoption and use of zero-knowledge proof and blockchain technology, as well as ZKsync and other ZK-enabled blockchains by the global ZK Community, including developers, researchers, educators, creators, and users. #### Past Work The ZKsync Association supported the ecosystem through a range of initiatives, including several key focus areas outlined below. Additional details on the Association’s work can be found in the [annual operations reports](https://github.com/zksync-association/governance-resources/blob/main/Annual-Reports/ZKsync_Association_Operational_Report_2024-2025.pdf). * Launched the ZK Token and ZKsync Governance System (including interfaces, documentation and other resources) * Supported live governance operations, including standard protocol upgrades, emergency actions, and complex token programs * Published ZK Token MiCAR White Paper * Assisted due diligence and information requests related to ZK Token listings * Hosted, attended and spoke at various public events and conferences throughout the year, including [Delegate meetups](https://forum.zknation.io/t/summary-key-takeaways-zksync-delegate-meetup-ethdenver-2025/584), curating governance-focused Community Hubs at [Devcon](https://forum.devcon.org/t/sea-community-hub-proposal-collective-intelligence-governance-hub/4025/25#p-10371-gov-geeks-recap-1) & [Devconnect](https://forum.zknation.io/t/zksync-governance-devconnect/866), and hosting [governance operator workshops](https://forum.zknation.io/t/berlin-blockchain-week-2025-governance-takeaways/716). ### Donations The ZKsync Association operates as a non-profit and it relies on donations in order to pursue its purpose. If you would like to support the ZKsync Association, please reach out to for more information. ### Association Membership Please refer to the [ZKsync Association Membership](https://docs.zknation.io/legal/zksync-association-membership/zksync-association-membership) page to learn more about membership. # ZKsync Association Membership ## Membership Information for the ZKsync Association ### 1. General information The ZKsync Association is an association under the laws of Austria, with its corporate seat in Vienna ("Association"). The Association is a voluntary, permanent establishment for the pursuit of the direct and indirect promotion, development, and support of the ZKsync blockchain protocol, the surrounding community, and its ecosystem. ### 2. Association Membership 2.1 Active delegates can become members of the Association. 2.2 Membership in the Association is open to all delegates of ZKsync Governance who have received delegated voting power from ZK tokenholders ("Delegates"). Delegates who opt-in to membership become members of the Association Token Assembly ("ATA"), which is a body of the Association. 2.3 By submitting a proposal or voting on a proposal through the Association’s ZKsync governance interface at [www.zknation.io](http://www.zknation.io) (the “Portal”) a Delegate agrees to join the Association as a member prior to submitting a proposal or vote. Delegates may actively decide to not become members of the Association during the voting process (by selecting the appropriate check-box). For a limited period, the Portal of the Association will also be available for non-members to participate in the voting process to ensure the initial adoption of ZKsync. ### 3. Rights, obligations & benefits of extraordinary members 3.1 As members of the ATA, extraordinary members can form the will and opinion of the Association with regard to the further development of the ZKsync protocol. A copy of the Articles of Association is located here: [ZKsync Association AoA Bylaws (Jan 31 2025)](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGbudQH8k8UtO68sj1Zni%2Fuploads%2FJ24PBRLgLu0uuNHUGuDX%2FZKsync%20Association%20AoA%20Bylaws%20Jan%2031%202025.pdf?alt=media\&token=0c769007-dcde-4e4d-8b3b-827bd2d248d8) 3.2 In their role as a member of the ATA, members have the following rights and obligations: (a) the right to submit ZKsync governance proposals via the Portal (subject to certain voting power thresholds), (b) the right to vote on such ZKsync governance proposals via the Portal (subject to certain voting power thresholds), (c) right to veto proposed Board members (up to three cycles of vetoes), (d) obligation to promote the interests of the Association and to comply with the Articles of Association and the resolutions of the Association's bodies. 3.3 If Delegates decide to join the Association, they will henceforth, as the ATA, participate in ZKsync governance, being considered a body of the Association: (a) ATA members submit and vote on a proposal via the Portal, as a body of the Association, the vote of the ATA members determines the instruction to the Association's Board. Only if the ATA passes a proposal, the Association's Board will (continue to) promote and endorse the matter. (e) As the ATA and its members act as a body of the Association, respectively within the Association's decision-making process, the Association assumes that the Association alone would be liable for the vote and actions that result from it, and not the individual members. ### 4. Termination of the membership as an extraordinary member 4.1 Membership expires upon death or, in the case of legal entities, upon loss of legal personality, voluntary resignation or exclusion. Resignation can take place at any time. The Board must be notified in writing of any resignation. This can be achieved by a Delegate affirmatively changing their membership status on its profile in the Portal. 4.2 The exclusion of a member from the Association can be ordered by the Board due to severe violations of other membership obligations, dishonorable behavior or for other similar reasons (e.g. violation of the code of conduct). # ZKsync Governance Program Systems (ZKGPS) ### What is ZKGPS? ZKsync Governance Program Systems (ZKGPS) is an ownerless Cayman Foundation responsible for the administration and execution of Token Program Proposals approved by ZKsync Governance. The purpose of ZKGPS is to: 1. **Enter legal contracts in service of the Token Assembly:** ZKGPS contracts with service providers and/or program participants, creating a legal obligation between service providers and proposal participants to act as prescribed in the specification of the relevant governance proposal. * Program Administrators (minter admins / multisig signers / veto executors) * Service Providers/Vendors for proposal operations (service agreements) 2. **Ensure KYC/KYB Compliance:** Perform KYC/KYB on individuals and entities who receive ZK tokens through governance proposals (excluding users). The ZKsync Governance Team will work closely with the Director of ZKGPS to connect proposal authors, multisig signers and service providers with ZKGPS in order to complete KYC and coordinate contracts. ZKGPS was established on October 24th 2024.The bylaws for ZKGPS can be found [here](https://drive.google.com/file/d/1moP5hrppIzO0RyAsqgNY2J20M_YJA0Be/view?usp=sharing). ### Engaging with ZKGPS Any participant likely to receive ZK tokens in exchange for services provided as part of a Token Program recipient of ZK through a Token Assembly approved Token Program will be required to contract with ZKGPS and complete KYC/KYB. The ZKsync Governance Team can help support getting in touch with ZKGPS. Contracts related to a given Token Program Proposal will not take effect until the relevant proposal has been executed onchain. To prevent delays following proposal execution, participants likely to contract with GPS will be contacted and asked to complete KYC/KYB prior to onchain proposal execution.