ZKsync Governance Feed
Monitor onchain ZKsync governance events
Last updated: 5/16/2025, 7:00:49 PM
View SourceBy ZKSync Governance • 5/16/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 60512795
- Timestamp: 5/16/2025, 6:58:41 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "97689115420129047109255183628089175185608660755000395855946331923921270505453"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0x0000000000000000000000000000000000008008"
}
]
},
"values": {
"value": [
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0x62f84b24...00000000"
}
]
},
"voteStart": {
"value": "1747681121"
},
"voteEnd": {
"value": "1748285921"
},
"description": {
"value": "# [ZIP-10] Activate ZK Gateway as a Settlement Layer\n| **Title** | Activate ZK Gateway as a Settlement Layer |\n| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Proposal Type** | ZIP |\n| **One Sentence Summary:** | This proposal aims to whitelist ZK Gateway chain as a settlement layer for the Elastic Network, paving the way to facilitate fast interop by providing a layer for cheap batch settlement and as well as quick communication between ZK Chains. |\n| **Proposal Author** | Matter Labs |\n| **Proposal Sponsor:** | Cyfrin |\n| **Date Created:** | May 2025 |\n| **Version** | v1 |\n| **Summary of Action** | This proposal will whitelist ZK Gateway chain as a settlement layer for Elastic Network. |\n| **Link to contracts** | https://github.com/matter-labs/era-contracts/tree/release-v27 |\n\n# **\\[ZIP-10] Activate ZK Gateway as a Settlement Layer**\n\n# **Abstract**\n\nZIP-10 builds on the groundwork laid by [ZIP-6 Prepare ZKsync for ZK Gateway](https://www.tally.xyz/gov/zksync/proposal/67712324710515983914473127418805437707715095849437613773846173900686148862581?govId=eip155:324:0x76705327e682F2d96943280D99464Ab61219e34f), which shipped V26 of ZKsync.\n\nZIP-10 approves ZK Gateway as an optional shared settlement layer for the Elastic Network. ZK Gateway aims to enhance the efficiency of batch settlements across ZK Chains, reducing settlement costs and stabilizing pricing for users, especially for ZK Chains that do not depend on Ethereum for DA. In addition, ZK Gateway will facilitate future interopability across the Elastic Network and provide even cheaper pricing in the future, once optimized precompiles are available in the next release.\n\n# **Motivation**\n\nThe motivations for this proposal are:\n\n1. **Cheaper settlement costs**. When settling on top of Gateway, ZK Chains are able to utilize cheaper settlement costs for settling their batches (i.e. committing, proving and executing those), which will translate into cheaper and more stable pricing for users, particularly in future releases when precompiles are available.\n2. **Future interop facilitations.** As a result of the above, ZK Chains will be able to settle batches faster, allowing for faster trustless interop. Also, ZK Gateway is able to serve as a communication layer between ZK Chains, paving the way to seamless interop with additional security requirements.\n\n# **Specification**\n\nZIP-10 is a continuation of efforts started with [ZIP-6](https://www.tally.xyz/gov/zksync/proposal/67712324710515983914473127418805437707715095849437613773846173900686148862581?govId=eip155:324:0x76705327e682F2d96943280D99464Ab61219e34f). With the approval of ZIP-6, V26 was implemented on the Elastic Network. The main feature of V26 was the support of shared settlement layers for the Elastic Network. ZIP-10 does not introduce new code changes in addition to ZIP-6. Instead, ZIP-10 focuses on whitelisting the ZK Gateway chain as an optional shared settlement layer.\n\n[Here](https://github.com/matter-labs/era-contracts/blob/release-v27/docs/gateway/overview.md) you can read more about how settlement layers as well as how the ZK Chains would be able to migrate on top of the ZK Gateway in the future.\n\nNote, the decision to migrate on top of ZK Gateway is an optional choice which can be made by each individual ZK ChainAdmin. Also, there is always an option to opt out of using Gateway.\n\nThe ZK Gateway has been deployed as a ZK Chain, with chainID 9075. ZK Gateway uses the ZK token as the base token and maintains the same security properties as ZKsync Era. ZK Gateway is also a permanent rollup, i.e. regardless of the actions of the ChainAdmin it will always use Ethereum as its DA layer.\n\nFor simplicity, in this release, the ZK Gateway is just a chain with the same capabilities as a standard ZK Chain. In the future, the chain can be upgraded to a more specialized version. To prevent unintended usage and to make this future migration easier, deploying of contracts inside the ZK Gateway will only be available under a whitelist.\n\nAs part of the ZIP execution, governance will complete the following actions:\n\n1. Call `Bridgehub.registerSettlementLayer` to register this chain as a valid settlement layer.\n2. Do an L1->GW transaction to whitelist a `ChainTypeManager` on top of Gateway to manage the ZK Chains that settle on top of it.\n3. Do the calls to [Bridgehub](https://etherscan.io/address/0x303a465B659cBB0ab36eE643eA362c509EEb5213) and [CTMDeploymentTracker](https://etherscan.io/address/0x6078F6B379f103de1Aa912dc46bb8Df0c8809860) to ensure that everything is set up to facilitate future [ZK chain migrations](https://github.com/matter-labs/era-contracts/blob/release-v27/docs/gateway/chain_migration.md) on top of ZK Gateway.\n\n# **Rationale**\n\nThis upgrade introduces a new shared settlement network in an incremental way, while already providing value for ZK Chains of the Elastic Network. It will give an opportunity for ZK Chains to receive more stable batch settling pricing, while allowing prices that are much cheaper than L1 starting with a future upgrade, that will introduce more efficient cryptographic precompiles.\n\nReusing an existing ZK Chain architecture for a shared settlement layer allows ZK Chains to enjoy the benefits faster while relying on already battle-tested codebase that is used by all ZK Chains.\n\n# **Backwards Compatibility**\n\nNo backwards compatibility issues.\n\n# **Security Considerations**\n\nAll the existing code has been audited as a part of the previous ZIPs.\n\nDuring the initial release Matter Labs will be the sole sequencer of the ZK Gateway with planned transition to a decentralized setting over time."
}
}By ZKSync Governance • 5/16/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 60508832
- Timestamp: 5/16/2025, 4:50:21 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExtended
- Contract Address:0xb83F...57460xb83FF6501214ddF40C91C9565d095400f3F45746
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "47039743821393144264923138033474021479144633689510868538815755013680786377936"
},
"extendedDeadline": {
"value": "1748019021"
}
}By ZKSync Governance • 5/15/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 60460657
- Timestamp: 5/15/2025, 3:35:31 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExtended
- Contract Address:0xb83F...57460xb83FF6501214ddF40C91C9565d095400f3F45746
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "42065487101304397091733612230088767526898725546086370988745501935513610356311"
},
"extendedDeadline": {
"value": "1747928131"
}
}By ZKSync Governance • 5/15/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 60445689
- Timestamp: 5/15/2025, 8:12:48 AM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExtended
- Contract Address:0xEEEa...b1600xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "103259976736823883300634095721999212673593591495252565610431467445162492146868"
},
"extendedDeadline": {
"value": "1747901568"
}
}By ZKSync Governance • 5/6/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 60026326
- Timestamp: 5/6/2025, 4:08:05 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0xb83F...57460xb83FF6501214ddF40C91C9565d095400f3F45746
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "42065487101304397091733612230088767526898725546086370988745501935513610356311"
},
"proposer": {
"value": "0x4e3D9399C28c724293dd545225Ec843Ac4c9e953"
},
"targets": {
"value": [
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
}
]
},
"values": {
"value": [
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
},
{
"value": ""
},
{
"value": ""
},
{
"value": ""
},
{
"value": ""
},
{
"value": ""
},
{
"value": ""
},
{
"value": ""
},
{
"value": ""
},
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0xd547741f...d30a82b0"
},
{
"value": "0xd547741f...3954c2ec"
},
{
"value": "0xd547741f...90ffc4ab"
},
{
"value": "0xd547741f...0107d33a"
},
{
"value": "0xd547741f...f8c2c392"
},
{
"value": "0xd547741f...8a58cbcc"
},
{
"value": "0xd547741f...c6e09ba9"
},
{
"value": "0xd547741f...174b8dcf"
},
{
"value": "0xd547741f...8d2f5964"
},
{
"value": "0xd547741f...edca40a9"
}
]
},
"voteStart": {
"value": "1747152485"
},
"voteEnd": {
"value": "1747757285"
},
"description": {
"value": "# [TPP-4] Deactivate Capped Minters for TPP-1 Ignite Program\n| Title | Deactivate Capped Minters for TPP-1 Ignite Program |\n| ------------------------ | ------------------------------------------------------------------------------------- |\n| **Proposal Type** | TPP |\n| **One Sentence Summary** | This proposal removes the minter role from all Ignite Program capped minters. |\n| **Proposal Author** | Baptiste (Merkl) |\n| **Proposal Sponsor** | Baki |\n| **Submitted onchain** | 2025-05-06 |\n| **Version** | v1 |\n| **Summary of Action** | Revoke Minter Role from all Ignite Program capped minters to prevent further minting. |\n| **Link to forum post** | https://forum.zknation.io/t/tpp-x-deactivate-capped-minters-for-tpp1-ignite/665 |\n| **Link to contracts** | n/a |\n\n### Simple Summary\n\nThis proposal removes the minter role from Ignite Program capped minters.\n\n### Abstract\n\nNow that the Ignite Program has concluded, the Token Assembly will ensure that no remaining unminted supply in the affiliated program or admin capped minters can be minted. This proposal includes the call data required to revoke the minter role from all capped minters linked to the Ignite Program.\n\n### Motivation\n\n[Cancellation of Token Programs](https://docs.zknation.io/zksync-governance-proposals/token-program-proposals-tpps#token-program-cancellation) using the ZkCappedMinterV1 can be done in one of two ways:\n\n1. Sending the admin multisig control to a burn address; or\n2. Revoking the Minter Role via a Token Assembly proposal.\n\nThe DSC multisig is required to remain active to complete unclaimed token reallocations. As such, a Token Assembly-approved proposal is necessary to revoke the Minter Role from Ignite capped minters.\n\nPlease note that the limitations considered here are specific to the Ignite Program deployed with ZkCappedMinterV1 contracts.\n\nFor future token programs, the ZkCappedMinterV2 contracts allow the deactivation of a ZkCappedMinterV2 through the admin controlled `cancel()` function. Please refer to the following [documentation](https://forum.zknation.io/t/zk-capped-minter-v2-nested-minters-start-time-expiration-pause-and-cancel/417) for more information.\n\n### Impact\n\nThis proposal ensures the safety and security of the remaining unminted supply in each capped minter. Neither the DeFi Steering Committee multisig or any other actor who would be able to gain access the multisig would be able to mint any further tokens from the Ignite Program Capped Minters.\n\n### Mechanic\n\nThis proposal would include the `revokeRole()` call on each of the following Ignite Program capped minters.\n\n| Capped Minter | Address | Total Cap (ZK) | Remaining Cap (ZK) |\n| ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | -------------- | ------------------ |\n| IP-ZK-Distro-Minter-1 | [0xe546AEaaC57584da7554e7F88154DeDAD30A82b0](https://explorer.zksync.io/address/0xe546AEaaC57584da7554e7F88154DeDAD30A82b0) | 50,000,000 | ~11,492,378 |\n| IP-ZK-Distro-Minter-2 | [0x11791c6249631555cEb75CB39128789E3954c2EC](https://explorer.zksync.io/address/0x11791c6249631555cEb75CB39128789E3954c2EC) | 50,000,000 | ~37,582,899 |\n| IP-ZK-Distro-Minter-3 | [0x3BC3f64d084bE6d3336f10340DC8424290FFc4ab](https://explorer.zksync.io/address/0x3BC3f64d084bE6d3336f10340DC8424290FFc4ab) | 50,000,000 | 50,000,000 |\n| IP-ZK-Distro-Minter-4 | [0xDa2fBE31Fd47Af741bdB3dBC4eb662dA0107D33a](https://explorer.zksync.io/address/0xDa2fBE31Fd47Af741bdB3dBC4eb662dA0107D33a) | 50,000,000 | 50,000,000 |\n| IP-ZK-Distro-Minter-5 | [0x6b689B93B368c7C25E6e5ecaeAb23C11F8C2c392](https://explorer.zksync.io/address/0x6b689B93B368c7C25E6e5ecaeAb23C11F8C2c392) | 50,000,000 | 50,000,000 |\n| IP-ZK-Distro-Minter-6 | [0x2CC6c7b1a59A23fB3faCAFe4A3791C5c8A58Cbcc](https://explorer.zksync.io/address/0x2CC6c7b1a59A23fB3faCAFe4A3791C5c8A58Cbcc) | 50,000,000 | 50,000,000 |\n| IP-ZK-Admin-Minter-OBL | [0xD375A20d93C2F7C6a83B19C5ae153cF2C6e09ba9](https://explorer.zksync.io/address/0xD375A20d93C2F7C6a83B19C5ae153cF2C6e09ba9) | 4,995,500 | 2,811,028 |\n| IP-ZK-Admin-Minter-Merkl | [0x2ADa5C15BC4FEE97EC2463ce4F8E4557174B8Dcf](https://explorer.zksync.io/address/0x2ADa5C15BC4FEE97EC2463ce4F8E4557174B8Dcf) | 4,634,500 | 3,707,600 |\n| IP-ZK-Admin-Minter-DSC | [0x4E86e74237Eb1f9432810eB5ab5861368d2f5964](https://explorer.zksync.io/address/0x4E86e74237Eb1f9432810eB5ab5861368d2f5964) | 3,250,000 | 2,890,000 |\n| IP-ZK-Admin-Minter-Supporting-Services | [0x178bFf5A197FB4499526D04Db602C45cEDCA40a9](https://explorer.zksync.io/address/0x178bFf5A197FB4499526D04Db602C45cEDCA40a9) | 12,120,000 | 18,230,349 |\n| **Total Amount of Unminted ZK Remaining in Capped Minters** | | 325,000,000 | ~276,714,254 |\n\n### Plan & Accountability\n\nIf the proposal is passed, there will be no further action or oversight required to prevent further minting from the Ignite Program capped minters.\n\n### Other Information\n\nOriginal Proposal: [\\[TPP-001\\] ZKsync Ignite Program: Creating a Liquidity Hub for ZKsync](https://vote.zknation.io/dao/proposal/61143334896738427838139044418897411872404555684850233057602201527014096413671?govId=eip155:324:0x10560f8B7eE37571AD7E3702EEb12Bc422036E89)\n\nProgram Cancellation: [ZKsync Ignite Cancellation](https://forum.zknation.io/t/zksync-ignite-cancellation/612)"
}
}By ZKSync Governance • 5/6/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 60021880
- Timestamp: 5/6/2025, 1:51:42 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0xb83F...57460xb83FF6501214ddF40C91C9565d095400f3F45746
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "47039743821393144264923138033474021479144633689510868538815755013680786377936"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
}
]
},
"values": {
"value": [
{
"value": "0"
},
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
},
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0x2f2ff15d...b601cfd8"
},
{
"value": "0x2f2ff15d...29be9db6"
}
]
},
"voteStart": {
"value": "1747144302"
},
"voteEnd": {
"value": "1747749102"
},
"description": {
"value": "# [TPP-3] ZIP Audit Reimbursement Program (ZARP)\n# \\[TPP-3] ZIP Audit Reimbursement Program (ZARP)\n\n| **Proposal Type** | TPP |\n| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **One Sentence Summary** | An annual program valued at $5m USD (89,285,714 ZK) to reimburse security audit costs for successfully executed ZKsync Improvement Proposals (ZIPs) in 2025, ensuring high security standards for ZKsync protocol development. |\n| **Proposal Author** | ZKsync Foundation |\n| **Proposal Sponsor** | Cyfrin |\n| **Submitted Onchain** | 2025-05-06 |\n| **Version** | v1 |\n| **Summary of Action** | This proposal establishes a ZIP Audit Reimbursement Program valued at $5m USD in ZK (89,285,714 ZK) to reimburse developers for audit costs associated with successfully implemented ZIPs. The program will be funded through the ZK token minter and payments will be distributed autonomously upon the successful execution of a given ZIP. |\n| **Total ZK Requested** | 89,285,714 ZK |\n| **Link to Forum Post** | https://forum.zknation.io/t/tpp-3-zip-audit-reimbursement-program-zarp/636 |\n| **Link to Contracts** | ZarpMain: [0x51E818785dEa065D392ac21F04E9cac5B601Cfd8](https://explorer.zksync.io/address/0x51E818785dEa065D392ac21F04E9cac5B601Cfd8#contract#read), ZarpRetro: [0x70F6998FC0c492d9DD08b1105259252329be9Db6](https://explorer.zksync.io/address/0x70F6998FC0c492d9DD08b1105259252329be9Db6#contract#read) |\n\n## Abstract\n\nThe ZIP Audit Reimbursement Program (ZARP) allocates $5m USD in ZK over the 2025 calendar year to increase security standards across the ZKsync protocol by reimbursing the costs associated with third-party audits of successful ZIPs. This program will ensure that ZIP developers strive for exceptional security audit standards, resulting in secure and robust contributions to the ZKsync protocol.\n\n## Motivation\n\nThis proposal aligns with [GAP 001: ZKsync Token Program Priorities 2025](https://www.tally.xyz/gov/zksync/proposal/13823050748058617424077595486689751986818771098977300222700522842013613046754?govId=eip155:324:0x496869a7575A1f907D1C5B1eca28e4e9E382afAb), which emphasizes the importance of accelerating ZKsync protocol development. As security is a foundational pillar of protocol integrity, this program directly supports the \"**Secure the Protocol**\" priority within GAP 001.\n\n## Impact\n\nThis program directly contributes to securing the ZKsync protocol, aligning with the [ZKsync Governance North Star](https://docs.zknation.io/zk-nation/zksync-governance-system-north-star) metric of protecting assets, builders, and the community from adversarial actors. By ensuring that all ZIPs undergo thorough security audits, the program mitigates vulnerabilities and strengthens the resilience of the protocol, removing the financial burden of security audits.\n\n### Primary Goals & Metrics\n\n| **Goal** | **Metric** | **Target** |\n| --------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------ |\n| Secure the Protocol | % of successfully implemented ZIPs that receive audits | 100% of eligible ZIPs audited |\n| Secure the Protocol | Number of security incidents related to newly implemented ZIPs that require an emergency upgrade to resolve | 0 incidents |\n| Public Accountability | Number of reimbursements publicly documented | 100% of reimbursements tracked |\n\n## Token Mechanic\n\nThis Token Program Proposal (TPP) approves the creation of two capped minters to fund audit reimbursements for ZIPs executed in 2025. The total value of the two capped minters is 89,285,714 ZK, which is the ZK token value of $5m USD based on the 30-day average from 27 April 2025. An overview of the two capped minters is set out below:\n\n1. `ZarpMain` – A general-purpose capped minter for ZIPs executed between May 1 and December 31, 2025. A total of 49,810,714 ZK may be minted from `ZarpMain`. Each ZIP will request its own allocation from this minter.\n2. `ZarpRetro` – A capped minter to reimburse audit costs for ZIPs approved by the Token Assembly between January 1 and April 30, 2025. A total of 39,475,000 ZK may be minted from `ZarpRetro`.\n\n\n\n## 1. `ZarpMain`: Future Audit Reimbursements (Q2 - Q4, 2025)\n\n`ZarpMain` is a capped minter that will fund audit reimbursements for any developer who submits a successfully executed ZIP on ZKsync between May 1, 2025 and December 31, 2025. Any ZIP author is eligible to claim audit reimbursements by following the outlined process, supporting the decentralization of protocol development. Developers will deploy a nested “child” capped minter to be able to draw from this main capped minter with successful protocol upgrade execution.\n\n### `ZarpMain` Capped Minter Parameters\n\n| Parameter | Value |\n| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |\n| **Name** | ZarpMain |\n| **Contract Address** | [0x51E818785dEa065D392ac21F04E9cac5B601Cfd8](https://explorer.zksync.io/address/0x51E818785dEa065D392ac21F04E9cac5B601Cfd8#contract#read) |\n| **Admin** | [Protocol Governor Timelock](https://explorer.zksync.io/address/0x085b8B6407f150D62adB1EF926F7f304600ec7149) |\n| **Target** | [ZK Token](https://explorer.zksync.io/address/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E) |\n| **Cap** | 49,810,714 ZK |\n| **Start Time** | 19 May 2025 |\n| **End Time** | 31 January 2026 |\n| **Minter Role** | N/A (child minters who assume the MINTER role are deployed per ZIP) |\n\n### Eligibility Criteria\n\nTo be eligible for reimbursement:\n\n* The ZIP must be successfully executed on ZKsync between May 1 and December 31, 2025.\n* The ZIP must include a third-party audit from a recognized security firm.\n* Audit invoice(s) must be submitted for verification to the ZKsync Security Council via direct message on the governance forum, before the ZIP is submitted onchain.\n\nReimbursements cover audit fees, formal verification costs, and code competitions. They do not cover ZIP development labor, travel, or other indirect expenses. A given audit may only be reimbursed once.\n\n### Claim Process\n\nTo claim reimbursement through `ZarpMain`, ZIP authors must complete the following steps before onchain submission of the relevant ZIP:\n\n1. Deploy a child capped minter with the following parameters (see [Capped Minter V2](https://forum.zknation.io/t/zk-capped-minter-v2-nested-minters-start-time-expiration-pause-and-cancel/417) for deployment instructions):\n\n| Parameter | Value |\n| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Admin** | [Protocol Governor Timelock](https://explorer.zksync.io/address/0x085b8B6407f150D62adB1EF926F7f304600ec7149) |\n| **Target** | `ZarpMain` |\n| **Cap** | Amount of ZK matching the reimbursement request calculated using the 30-day average of the price from the date the child capped minter is deployed. |\n| **Start Time** | 30 days after the expected protocol upgrade approval date |\n| **End Time** | 31 January 2026 |\n\nPlease reach out to Gov Team for support creating child capped minters.\n\n2. In the ZIP draft posted on the governance forum, include:\n\n* Link to the audit report\n* Link to the deployed child capped minter contract\n\n3. In the onchain ZIP submission, include calldata to:\n\n* Grant MINTER role:\n 1. on the parent capped minter (`ZarpMain`) to the child capped minter; and\n 2. on the child capped minter to the ZIP developer\n* Grant PAUSER role on the child capped minter to the ZKsync Security Council on ZKsync Era ([0xfFB6126FF8401665081b771bB11cCD0e09f95D5A](https://explorer.zksync.io/address/0xfFB6126FF8401665081b771bB11cCD0e09f95D5A))\n\n\n\nIf the ZIP passes the Token Assembly vote, the child minter’s MINTER role will become active after a 30-day buffer. During this time, the Security Council will verify the audit details if it has not already done so. If necessary, the Security Council may pause the minter using their PAUSER role, preventing misuse of funds.\n\n## 2. `ZarpRetro`: Past Audit Reimbursement (Q1, 2025)\n\n`ZarpRetro` is a capped minter used to reimburse audit costs for ZIPs approved by the Token Assembly prior to April 30, 2025. Any ZIP author is eligible for retroactive reimbursement. Matter Labs has been the only developer to submit protocol upgrades to date. As a result, Matter Labs is the sole claimant under the `ZarpRetro` capped minter.\n\n### `ZarpRetro` Capped Minter Parameters\n\n| Parameter | Value |\n| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Name** | ZarpRetro |\n| **Contract Address** | [`0x70F6998FC0c492d9DD08b1105259252329be9Db6`](https://explorer.zksync.io/address/0x70F6998FC0c492d9DD08b1105259252329be9Db6#contract#read) |\n| **Admin** | Matter Labs Multisig ([`0xb84cFd9EBA97d991afa2E7B76b900804eE911Ab7`](https://app.safe.global/settings/setup?safe=zksync:0xb84cFd9EBA97d991afa2E7B76b900804eE911Ab7)) |\n| **Target** | [ZK Token](https://explorer.zksync.io/address/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E) |\n| **Cap** | 39,475,000 ZK |\n| **Start Time** | 19 May 2025 |\n| **End Time** | 31 January 2026 |\n| **Minter Role** | \\[Admin to confirm post-execution] |\n\nThe ZKsync Security Council has reviewed (or will review) the audit invoices and reports for ZIPs approved prior to 30 April 2025 to confirm eligibility.\n\nThe total value of the ZarpRetro Capped Minter is $2,210,600 USD. Using the 30-day average price of ZK from 27 April 2025, this amounts to 39,475,000 ZK tokens, which is the cap of the ZarpRetro Capped Minter.\n\n### Summary of Retro Audit Reimbursements\n\n| ZIP | Amount Claimed (USD) |\n| ----------------------------------------------------- | -------------------- |\n| ZIP-3 Protocol Defense | $91,440 |\n| ZIP-6 Gateway Prep | $1,490,540 |\n| ZIP-9 EVM Emulator | $628,620 |\n| **Total USD** | **$2,210,600** |\n| **Total ZK** <small>at 0.056 (30-day average)</small> | **39,475,000** |\n\n### Eligibility\n\nAll ZIPs approved by the Token Assembly prior to 30 April 2025 were developed by Matter Labs. As such, Matter Labs will define the MINTER address for the `ZARPRetro` capped minter.\n\nDetails of audit reimbursements being claimed by Matter Labs are set out in the tables below.\n\n| ZIP | Auditor | $USD Claimed | Audit Report(s) |\n| ----- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| ZIP-3 | OpenZeppelin | $91,440 | [Protocol Defense Report](https://github.com/matter-labs/era-contracts/blob/main/audits/ZKsync%20Protocol%20Defense%20Audit%20-%20Final%20Report%20\\(Sept%202024\\).pdf) |\n| ZIP-6 | OpenZeppelin | $510,540 | [ZKsync Custom Asset Bridge Audit](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKsync%20Custom%20Asset%20Bridge%20Audit%20\\(OpenZeppelin\\).pdf) + [ZKChain Upgrades and Libraries Diff Audit](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKChain%20Upgrades%20and%20Libraries%20Diff%20Audit%20\\(OpenZeppelin\\).pdf) + [ZKChain & Gateway Upgrade Audit](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKsync%20ZKChain%20and%20Gateway%20Upgrade%20Audit%20\\(OpenZeppelin\\).pdf) + [ZKChain Release Candidate Audit](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKChain%20Release%20Candidate%20Audit%20\\(OpenZeppelin\\).pdf) |\n| ZIP-6 | Audittens | $380,000 | [Gateway Security Competition](https://github.com/Audittens/Audittens/blob/main/audit-reports/ZKsync%20Gateway%20Audit.pdf) |\n| ZIP-6 | Audittens | $100,000 | [Hyperchains Security Competition](https://github.com/Audittens/Audittens/blob/main/audit-reports/ZKsync%20Shared%20Bridge%20\\(USDC\\)%20Audit.pdf) |\n| ZIP-6 | Cyfrin | $500,000 | [CodeHawks Security Competition](https://codehawks.cyfrin.io/c/2024-10-zksync/submissions) |\n| ZIP-9 | OpenZeppelin | $628,620 | [EVM Equivalence Audit](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20EVM%20Equivalence%20Audit.pdf) + [FFLONK Verifier Audit](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20FFLONK%20Verifier%20Audit.pdf) + [FFLONK & EVM Emulator Diff Audit](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20FFLONK%20and%20EVM%20Equivalence%20Diff%20Audit.pdf) |\n\nAll reimbursements claimed from the ZarpRetro capped have been reviewed and approved by the Security Council.\n\n### Claim Process\n\nAs the admin of the `ZarpRetro` capped minter, Matter Labs will be able to assign the minter role at their discretion that will be able to mint tokens in the `ZarpRetro` capped minter. The tokens are available to mint at any time until 31 January 2026.\n\n## Plan\n\n### **Measurement & Reporting**\n\n* **On-chain tracking**: The `ZarpMain` Capped Minter will record all disbursements, ensuring transparency.\n* **Quarterly governance updates**: The Security Council will publish status reports tracking disbursements and participation.\n* **End-of-year report**: A detailed impact analysis will be presented to the community.\n\n## Accountability Framework\n\n* The Security Council will review all reimbursement requests.\n* Conflicts of interest will be managed via a recusal policy.\n* All reimbursements are publicly documented for transparency.\n* Program impact is evaluated annually with Token Assembly input.\n\n## Participants\n\n* Security Council (responsible for oversight and pausing ineligible distributions).\n* ZIP developers and/or contributors (subject to KYC/KYB as per ZKsync Association policy)."
}
}By ZKSync Governance • 5/5/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 59987813
- Timestamp: 5/5/2025, 4:38:23 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0xb83F...57460xb83FF6501214ddF40C91C9565d095400f3F45746
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "37336317904360891872634439686262641429380301134230744013571346123315862024472"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
},
{
"value": "0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E"
}
]
},
"values": {
"value": [
{
"value": "0"
},
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
},
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0x2f2ff15d...921277e5"
},
{
"value": "0x2f2ff15d...8a86af52"
}
]
},
"voteStart": {
"value": "1747067903"
},
"voteEnd": {
"value": "1747672703"
},
"description": {
"value": "# [TPP-3] ZIP Audit Reimbursement Program (ZARP)\n## \\[TPP-3] ZIP Audit Reimbursement Program (ZARP)\n\n| **Proposal Type** | TPP |\n| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **One Sentence Summary** | An annual program valued at $5m USD (~89m ZK) to reimburse security audit costs for successfully executed ZKsync Improvement Proposals (ZIPs) in 2025, ensuring high security standards for ZKsync protocol development. |\n| **Proposal Author** | ZKsync Foundation |\n| **Proposal Sponsor** | Cyfrin |\n| **Submitted Onchain** | 2025-05-05 |\n| **Version** | v1 |\n| **Summary of Action** | This proposal establishes a ZIP Audit Reimbursement Program valued at $5m USD in ZK (~89m ZK) to reimburse developers for audit costs associated with successfully implemented ZIPs. The program will be funded through the ZK token minter and payments will be distributed autonomously upon the successful execution of a given ZIP. |\n| **Link to Forum Post** | https://forum.zknation.io/t/tpp-3-zip-audit-reimbursement-program-zarp/636 |\n| **Link to Contracts** | ZarpMain: [0xc117c6A6ad15799ce8e6912132E76baA921277e5](https://explorer.zksync.io/address/0xc117c6A6ad15799ce8e6912132E76baA921277e5#contract#contract-info), ZarpRetro: [0xEdE7012A5Fd6CB04318b6F8ca9A6dd508a86AF52](https://explorer.zksync.io/address/0xEdE7012A5Fd6CB04318b6F8ca9A6dd508a86AF52#contract) |\n\n## Abstract\n\nThe ZIP Audit Reimbursement Program (ZARP) allocates $5m USD in ZK over the 2025 calendar year to increase security standards across the ZKsync protocol by reimbursing the costs associated with third-party audits of successful ZIPs. This program will ensure that ZIP developers strive for exceptional security audit standards, resulting in secure and robust contributions to the ZKsync protocol.\n\n## Motivation\n\nThis proposal aligns with [GAP 001: ZKsync Token Program Priorities 2025](https://www.tally.xyz/gov/zksync/proposal/13823050748058617424077595486689751986818771098977300222700522842013613046754?govId=eip155:324:0x496869a7575A1f907D1C5B1eca28e4e9E382afAb), which emphasizes the importance of accelerating ZKsync protocol development. As security is a foundational pillar of protocol integrity, this program directly supports the \"**Secure the Protocol**\" priority within GAP 001.\n\n## Impact\n\nThis program directly contributes to securing the ZKsync protocol, aligning with the [ZKsync Governance North Star](https://docs.zknation.io/zk-nation/zksync-governance-system-north-star) metric of protecting assets, builders, and the community from adversarial actors. By ensuring that all ZIPs undergo thorough security audits, the program mitigates vulnerabilities and strengthens the resilience of the protocol, removing the financial burden of security audits.\n\n### Primary Goals & Metrics\n\n| **Goal** | **Metric** | **Target** |\n| --------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------ |\n| Secure the Protocol | % of successfully implemented ZIPs that receive audits | 100% of eligible ZIPs audited |\n| Secure the Protocol | Number of security incidents related to newly implemented ZIPs that require an emergency upgrade to resolve | 0 incidents |\n| Public Accountability | Number of reimbursements publicly documented | 100% of reimbursements tracked |\n\n## Token Mechanic\n\nThis Token Program Proposal (TPP) approves the creation of two capped minters to fund audit reimbursements for ZIPs executed in 2025. The total value of the two capped minters is 88,759,019 ZK, which is the ZK token value of $5m USD based on the 30-day average from 27 April 2025. An overview of the two capped minters is set out below:\n\n1. `ZarpMain` – A general-purpose capped minter for ZIPs executed between May 1 and December 31, 2025. A total of 49,516,882 ZK may be minted from `ZarpMain`. Each ZIP will request its own allocation from this minter.\n2. `ZarpRetro` – A capped minter to reimburse audit costs for ZIPs approved by the Token Assembly between January 1 and April 30, 2025. A total of 39,242,138 ZK may be minted from `ZarpRetro`.\n\n\n\n## 1. `ZarpMain`: Future Audit Reimbursements (Q2 - Q4, 2025)\n\n`ZarpMain` is a capped minter that will fund audit reimbursements for any developer who submits a successfully executed ZIP on ZKsync between May 1, 2025 and December 31, 2025. Any ZIP author is eligible to claim audit reimbursements by following the outlined process, supporting the decentralization of protocol development. Developers will deploy a nested “child” capped minter to be able to draw from this main capped minter with successful protocol upgrade execution.\n\n### `ZarpMain` Capped Minter Parameters\n\n**Name**: ZarpMain\n\n**Contract Address**: [0xc117c6A6ad15799ce8e6912132E76baA921277e5](https://explorer.zksync.io/address/0xc117c6A6ad15799ce8e6912132E76baA921277e5#contract#contract-info)\n\n**Admin**: [Protocol Governor Timelock](https://explorer.zksync.io/address/0x085b8B6407f150D62adB1EF926F7f304600ec7149)\n\n**Target**: [ZK Token](https://explorer.zksync.io/address/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E)\n\n**Cap**: 49,516,882 ZK\n\n**Start Time**: 19 May 2025\n\n**End Time**: 31 January 2026\n\n**Minter Role**: N/A (child minters who assume the MINTER role are deployed per ZIP)\n\n### Eligibility Criteria\n\nTo be eligible for reimbursement:\n\n* The ZIP must be successfully executed on ZKsync between April 1 and December 31, 2025.\n* The ZIP must include a third-party audit from a recognized security firm.\n* Audit invoice(s) must be submitted for verification to the ZKsync Security Council via direct message on the governance forum, before the ZIP is submitted onchain.\n\nReimbursements cover audit fees, formal verification costs, and code competitions. They do not cover ZIP development labor, travel, or other indirect expenses. A given audit may only be reimbursed once.\n\n### Claim Process\n\nTo claim reimbursement through `ZarpMain`, ZIP authors must complete the following steps before onchain submission of the relevant ZIP:\n\n1. Deploy a child capped minter with the following parameters (see [Capped Minter V2](https://forum.zknation.io/t/zk-capped-minter-v2-nested-minters-start-time-expiration-pause-and-cancel/417) for deployment instructions):\n\n**Admin**: [Protocol Governor Timelock](https://explorer.zksync.io/address/0x085b8B6407f150D62adB1EF926F7f304600ec7149)\n\n**Target**: `ZarpMain`\n\n**Cap**: Amount of ZK matching the reimbursement request calculated using either the 7-day, 30-day, or 60-day average of the price from the date the child capped minter is deployed.\n\n**Start Time**: 30 days after the expected protocol upgrade approval date\n\n**End Time**: 31 January 2026\n\n2. In the ZIP draft posted on the governance forum, include:\n\n* Link to the audit report\n* Link to the deployed child capped minter contract\n\n3. In the onchain ZIP submission, include calldata to:\n\n* Grant MINTER role:\n 1. on the parent capped minter (`ZarpMain`) to the child capped minter; and\n 2. on the child capped minter to the ZIP developer\n* Grant PAUSER role on the child capped minter to the ZKsync Security Council on ZKsync Era ([0xfFB6126FF8401665081b771bB11cCD0e09f95D5A](https://explorer.zksync.io/address/0xfFB6126FF8401665081b771bB11cCD0e09f95D5A))\n\n\n\nIf the ZIP passes the Token Assembly vote, the child minter’s MINTER role will become active after a 30-day buffer. During this time, the Security Council will verify the audit details if it has not already done so. If necessary, the Security Council may pause the minter using their PAUSER role, preventing misuse of funds.\n\n## 2. `ZarpRetro`: Past Audit Reimbursement (Q1, 2025)\n\n`ZarpRetro` is a capped minter used to reimburse audit costs for ZIPs approved by the Token Assembly prior to April 30, 2025. Any ZIP author is eligible for retroactive reimbursement. Matter Labs has been the only developer to submit protocol upgrades to date. As a result, Matter Labs is the sole claimant under the `ZarpRetro` capped minter.\n\n### `ZarpRetro` Capped Minter Parameters\n\n**Name**: `ZarpRetro`\n\n**Contract Address**: [0xEdE7012A5Fd6CB04318b6F8ca9A6dd508a86AF52](https://explorer.zksync.io/address/0xEdE7012A5Fd6CB04318b6F8ca9A6dd508a86AF52)\n\n**Admin**: Matter Labs Multisig ([0xb84cFd9EBA97d991afa2E7B76b900804eE911Ab7](https://app.safe.global/home?safe=zksync:0xb84cFd9EBA97d991afa2E7B76b900804eE911Ab7))\n\n**Target**: [ZK Token](https://explorer.zksync.io/address/0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E)\n\n**Cap**: 39,242,138 ZK\n\n**Start Time**: 19 May 2025\n\n**End Time**: 31 January 2026\n\n**Minter Role**: \\[Admin to confirm post-execution]\n\nThe ZKsync Security Council has reviewed (or will review) the audit invoices and reports for ZIPs approved prior to 30 April 2025 to confirm eligibility.\n\nThe total value of the ZarpRetro Capped Minter is $1,230,600 USD. Using the 30-day average price of ZK, this amounts to 71,374 ZK tokens, which is the cap of the ZarpRetro Capped Minter.\n\n### Summary of Retro Audit Reimbursements\n\n| ZIP | Amount Claimed (USD) |\n| ----------------------------------------------------- | -------------------- |\n| ZIP-3 Protocol Defense | $91,440 |\n| ZIP-6 Gateway Prep | $1,490,540 |\n| ZIP-9 EVM Emulator | $628,620 |\n| **Total USD** | **$2,210,600** |\n| **Total ZK** <small>at 0.058 (30-day average)</small> | **39,242,138** |\n\n### Eligibility\n\nAll ZIPs approved by the Token Assembly prior to 30 April 2025 were developed by Matter Labs. As such, Matter Labs will define the MINTER address for the `ZARPRetro` capped minter.\n\nDetails of audit reimbursements being claimed by Matter Labs are set out in the tables below.\n\n| ZIP | Auditor | $USD Claimed | Audit Report(s) |\n| ----- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| ZIP-3 | OpenZeppelin | $91,440 | [Protocol Defense Report](https://github.com/matter-labs/era-contracts/blob/main/audits/ZKsync%20Protocol%20Defense%20Audit%20-%20Final%20Report%20\\(Sept%202024\\).pdf) |\n| ZIP-6 | OpenZeppelin | $510,540 | [ZKsync Custom Asset Bridge Audit](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKsync%20Custom%20Asset%20Bridge%20Audit%20\\(OpenZeppelin\\).pdf) + [ZKChain Upgrades and Libraries Diff Audit](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKChain%20Upgrades%20and%20Libraries%20Diff%20Audit%20\\(OpenZeppelin\\).pdf) + [ZKChain & Gateway Upgrade Audit](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKsync%20ZKChain%20and%20Gateway%20Upgrade%20Audit%20\\(OpenZeppelin\\).pdf) + [ZKChain Release Candidate Audit](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKChain%20Release%20Candidate%20Audit%20\\(OpenZeppelin\\).pdf) |\n| ZIP-6 | Audittens | $380,000 | [Gateway Security Competition](https://github.com/Audittens/Audittens/blob/main/audit-reports/ZKsync%20Gateway%20Audit.pdf) |\n| ZIP-6 | Audittens | $100,000 | [Hyperchains Security Competition](https://github.com/Audittens/Audittens/blob/main/audit-reports/ZKsync%20Shared%20Bridge%20\\(USDC\\)%20Audit.pdf) |\n| ZIP-6 | Cyfrin | $500,000 | [CodeHawks Security Competition](https://codehawks.cyfrin.io/c/2024-10-zksync/submissions) |\n| ZIP-9 | OpenZeppelin | $628,620 | [EVM Equivalence Audit](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20EVM%20Equivalence%20Audit.pdf) + [FFLONK Verifier Audit](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20FFLONK%20Verifier%20Audit.pdf) + [FFLONK & EVM Emulator Diff Audit](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20FFLONK%20and%20EVM%20Equivalence%20Diff%20Audit.pdf) |\n\nAll reimbursements claimed from the ZarpRetro capped have been reviewed and approved by the Security Council.\n\n### Claim Process\n\nAs the admin of the `ZarpRetro` capped minter, Matter Labs will be able to assign the minter role at their discretion that will be able to mint tokens in the `ZarpRetro` capped minter. The tokens are available to mint at any time until 31 January 2026.\n\n## Plan\n\n### **Measurement & Reporting**\n\n* **On-chain tracking**: The `ZarpMain` Capped Minter will record all disbursements, ensuring transparency.\n* **Quarterly governance updates**: The Security Council will publish status reports tracking disbursements and participation.\n* **End-of-year report**: A detailed impact analysis will be presented to the community.\n\n## Accountability Framework\n\n* The Security Council will review all reimbursement requests.\n* Conflicts of interest will be managed via a recusal policy.\n* All reimbursements are publicly documented for transparency.\n* Program impact is evaluated annually with Token Assembly input.\n\n## Participants\n\n* Security Council (responsible for oversight and pausing ineligible distributions).\n* ZIP developers and/or contributors (subject to KYC/KYB as per ZKsync Association policy)."
}
}By ZKSync Governance • 5/1/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 59837118
- Timestamp: 5/1/2025, 1:13:59 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0xEEEa...b1600xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "103259976736823883300634095721999212673593591495252565610431467445162492146868"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0xEa88046C61506480e8B69fFB4A5Dd8F80eC721b6"
}
]
},
"values": {
"value": [
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0x"
}
]
},
"voteStart": {
"value": "1746710039"
},
"voteEnd": {
"value": "1747314839"
},
"description": {
"value": "# [GAP-3] Authorization for Security Council to Convert Recovered ETH into ZK\n| Title | Authorization for Security Council to Convert Recovered ETH into ZK |\n| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Proposal Type | GAP |\n| One Sentence Summary | This proposal authorizes the ZKsync Security Council to convert ETH, recovered from the April 2025 exploit of unclaimed airdrop tokens, back into ZK tokens. |\n| Proposal Author | ZKsync Security Council |\n| Proposal Sponsor | Cyfrin |\n| Date Created | 1 May 2025 |\n| Version | 1.0 |\n| Summary of Action | Authorise Security Council to swap ETH to ZK, then transfer ZK to Token Governor Timelock. |\n| Link to contracts | Not Applicable |\n\n## Abstract\n\nThis proposal authorizes the ZKsync Security Council to convert ETH, recovered from the April 2025 exploit of unclaimed airdrop tokens, back into ZK tokens. The assets are currently in the custody of the Security Council following a [successful safe harbor resolution](https://x.com/TheZKNation/status/1915110305790660939) with the hacker.\n\nDue to the potential for arbitrage and market manipulation, the methods and timing of the ETH-to-ZK conversion will not be disclosed publicly in advance. By passing this proposal, the Token Assembly affirms its intent to restore the unminted airdrop token supply in ZK form and delegates execution authority to the Security Council, under conditions of post-trade transparency and governance oversight.\n\n## Motivation\n\nOn April 13th, 2025, a compromised admin key was used to mint ~111.8 million ZK tokens from expired airdrop distributor contracts ([see announcement](https://x.com/zksync/status/1912165357642473488)). Following incident response and investigation, the Security Council negotiated a 90% return of the exploited funds. The recovered funds are currently held in Security Council multisigs on ZKsync Era and Ethereum.\n\nThe following table summarises the returned funds:\n\n| Asset Type | Amount Returned | Chain | Receiving Address | Transaction Link |\n| ---------- | ------------------ | ----------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |\n| ZK Tokens | 44,687,278.5988 ZK | ZKsync Era | `0xfFB6126FF8401665081b771bB11cCD0e09f95D5A` | [View Transaction](https://explorer.zksync.io/tx/0x4d79d0ffcca0098e69f642930de90d58adcda42ee649870a68f9279fcfcd418e) |\n| ETH | 1,021.3 ETH | ZKsync Era | `0xfFB6126FF8401665081b771bB11cCD0e09f95D5A` | [View Transaction](https://explorer.zksync.io/tx/0xfb4ae0efd38aedee7712046317397fe695ab8b90e7169870875c611887dce166) |\n| ETH | 776 ETH | Ethereum L1 | `0xb13dF19C56a75f9087CC03b10D482B4a775daB47` | [View Transaction](https://etherscan.io/tx/0xa344a0e759652246e51b1def91c8081b3527bdbbcab92128100f8fbc11c204df) |\n\nThis proposal ensures that the recovered ETH is responsibly converted back into ZK to align with the original intent of ZKsync governance. The recommended action minimizes risk to the protocol and the token by allowing operational discretion to the Security Council, who is trusted with emergency mitigation.\n\n## Specification\n\nIf this proposal is approved, the ZKsync Security Council is authorized to convert the recovered ETH into ZK tokens, including bridging and/or transferring ETH to a destination that allows for this conversion. \n\nThe timing, venue, and method of conversion shall be at the discretion of the Security Council, guided by the best interests of the Token Assembly. Public disclosure of trade details in advance is not required in order to minimize the risk of arbitrage or market manipulation.\n\nOnce all recovered ETH has been converted to ZK, the Security Council will transfer the total amount of ZK tokens to governance custody by transferring the tokens to the Token Governor Timelock, which is controlled by the Token Assembly.\n\nA public report will be issued upon completion of the conversion, summarizing the trade method, execution outcomes, and custody details. The Security Council must confirm that no personal gain was derived by the Security Council entity or members of the Security Council from the execution of the trades.\n\nThis is a one-time authorization limited to the ETH recovered from the April 2025 exploit.\n\n## Other Information\n\n* [Incident Report: Compromised Admin Key to Unclaimed Airdrop Tokens](https://zksync.mirror.xyz/W5vPDZqEqf2NuwQ5x7SyFnIxqqpE1szAFD69iaaBFnI)\n* [Returned Funds Onchain Confirmation](https://x.com/TheZKNation/status/1915110305790660939)\n* [Security Council Safe Harbor Message](https://x.com/TheZKNation/status/1914338338804244511)"
}
}By Ethereum Governance • 4/28/2025
Event Details
- Network: Ethereum Mainnet
- Chain ID: 1
- Block: 22367584
- Timestamp: 4/28/2025, 12:33:11 PM
Governance Info
- Governance Body: Ethereum Governance
- Event Type: UpgradeExecuted
- Contract Address:0xE30D...5Ab30xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3
Event Data
{
"_id": {
"value": "0x2d3883b5d936c6a3c8b4170c4735bbf437de601b3f5afaceeee27b6b52907574"
}
}By Ethereum Governance • 4/26/2025
Event Details
- Network: Ethereum Mainnet
- Chain ID: 1
- Block: 22356518
- Timestamp: 4/26/2025, 7:31:59 PM
Governance Info
- Governance Body: Ethereum Governance
- Event Type: UpgradeApprovedBySecurityCouncil
- Contract Address:0xE30D...5Ab30xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3
Event Data
{
"_id": {
"value": "0x2d3883b5d936c6a3c8b4170c4735bbf437de601b3f5afaceeee27b6b52907574"
}
}By ZKSync Governance • 4/19/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 59347481
- Timestamp: 4/18/2025, 8:34:12 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallExecuted
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0x576ba7df7bf49594c02e1e376b2ddd26f038e9b4f6dbfa0bd2631b0ad5a0ada4"
},
"index": {
"value": "0"
},
"target": {
"value": "0x0000000000000000000000000000000000008008"
},
"value": {
"value": "0"
},
"data": {
"value": "0x62f84b24...00000000"
}
}By ZKSync Governance • 4/19/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 59347481
- Timestamp: 4/18/2025, 8:34:12 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExecuted
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "112142012854508751423955156601121618924383324119199970784935099214632480260394"
}
}By ZKSync Governance • 4/18/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 59342222
- Timestamp: 4/18/2025, 7:46:54 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallScheduled
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0x576ba7df7bf49594c02e1e376b2ddd26f038e9b4f6dbfa0bd2631b0ad5a0ada4"
},
"index": {
"value": "0"
},
"target": {
"value": "0x0000000000000000000000000000000000008008"
},
"value": {
"value": "0"
},
"data": {
"value": "0x62f84b24...00000000"
},
"predecessor": {
"value": "0x0000000000000000000000000000000000000000000000000000000000000000"
},
"delay": {
"value": "0"
}
}By ZKSync Governance • 4/15/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 59197015
- Timestamp: 4/15/2025, 3:36:59 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExtended
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "112142012854508751423955156601121618924383324119199970784935099214632480260394"
},
"extendedDeadline": {
"value": "1745005019"
}
}By ZKSync Governance • 4/7/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 58794464
- Timestamp: 4/7/2025, 10:57:01 AM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "112142012854508751423955156601121618924383324119199970784935099214632480260394"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0x0000000000000000000000000000000000008008"
}
]
},
"values": {
"value": [
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0x62f84b24...00000000"
}
]
},
"voteStart": {
"value": "1744297021"
},
"voteEnd": {
"value": "1744901821"
},
"description": {
"value": "# [ZIP-9] V27 EVM Emulation Upgrade\n| **Proposal Type** | ZIP |\n| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------ |\n| **One Sentence Summary** | ZIP-9 proposes the V27 upgrade for ZKsync with two key features: (1) EVM emulation, and (2) Fflonk verifier. |\n| **Proposal Author** | Matter Labs |\n| **Proposal Sponsor** | Cyfrin |\n| **Date Created** | 7-April-2025 |\n| **Version** | v1 |\n| **Summary of Action** | Upgrade ZKsync to V27 |\n| **Link to Contracts** | [https://github.com/matter-labs/era-contracts/tree/release-v27](https://github.com/matter-labs/era-contracts/tree/release-v27) |\n\n# \\[ZIP-9] V27 EVM Emulation Upgrade\n\n## Abstract\n\nZIP-9 proposes the V27 upgrade for ZKsync. The key features of V27 are:\n\n* The EVM emulation, enabling the direct deployment and execution of EVM contracts on ZKsync without recompilation;\n* Fflonk verifier, optimizations and security improvements.\n\n## Motivation\n\nThe pursuit of full EVM equivalence at the bytecode level is a cornerstone of ZKsync’s technical vision, [as outlined in the 2025 roadmap](https://zksync.mirror.xyz/QG2Xr4lQdJTbyjeKftPVc6-pj2t9-H9WEGnvCcnusck). This initiative is fundamental to ensuring that ZKsync can seamlessly support all tools and frameworks designed for Ethereum Layer 1, thus significantly enhancing the developer experience.\n\nThe primary motivation for the V27 upgrade is to integrate Ethereum-compatible smart contract development into ZKsync EraVM. By implementing an EVM emulator, ZKsync can offer developers the ability to use standard Solidity and Vyper compilers, as well as popular tooling such as Foundry, Hardhat, and Remix without modifications. This initiative supports the broader goal of making ZKsync a fully interoperable and user-friendly platform that maintains high performance and security standards of the underlying EraVM.\n\nAnother key aspect of the upgrade is support for verifying Fflonk proofs, which will significantly reduce the cost of on-chain proof verification on Ethereum. This is an important part of the overall initiative to minimize transaction costs on ZKsync.\n\n## Specification\n\nThe V27 upgrade contracts can be found in the [Era Contracts Github repo](https://github.com/matter-labs/era-contracts/tree/release-v27). Details of the V27 upgrade are listed below:\n\n### EVM emulation\n\nThis release adds an optional EVM emulation mode, allowing chains to deploy and execute EVM contracts without recompiling for EraVM. This is an important step towards full EVM equivalence, which will open up new possibilities for developers and various Web3 protocols. EVM emulation provides following features:\n\n* **Standard Compiler Support:** Allows the use of unmodified EVM compilers for Solidity, Vyper and other languages.\n* **Tooling Compatibility:** Supports existing Ethereum development environments and build tools without the need for plugins or adaptations.\n* **Consistent Address Derivation:** Opens the way to deploy contracts using `create` and `create2` consistently with Ethereum address derivation scheme.\n* **Emulated EVM equivalence**: For EVM contracts, the environment is compatible with EVM. This includes support for most opcodes and precompiles, as well as emulated EVM-equivalent gas cost of operations. More details on equivalence are provided in documentation page.\n* **Pre-Deployed EVM Contracts:** Includes essential contracts such as `create2` factories, `multicall3`, and `singletonFactory` (ERC2470) to facilitate common contract interactions.\n\nFor developer resources on the EVM emulator, please visit documentation: [EVM emulator overview](https://docs.zksync.io/zksync-era/unique-features/evm-emulator/evm-emulator) and [EVM emulator documentation](https://docs.zksync.io/zksync-protocol/evm-emulator/overview).\n\nNew system contracts:\n\n* [**EvmEmulator**](https://github.com/matter-labs/era-contracts/blob/release-v27/system-contracts/contracts/EvmEmulator.yul): EraVM invokes this contract every time a call to the computer contract happens. EvmEmulator loads the EVM contract’s bytecode and executes it in the runtime.\n* [**EvmGasManager**](https://github.com/matter-labs/era-contracts/blob/release-v27/system-contracts/contracts/EvmGasManager.yul): Technical system contract used to emulate EVM storage gas behavior including warm/cold accesses mechanics.\n* [**EvmHashesStorage**](https://github.com/matter-labs/era-contracts/blob/release-v27/system-contracts/contracts/EvmHashesStorage.sol): Separate system contract that stores EVM code hashes (keccak256 hash of EVM bytecode).\n* [**EvmPredeploysManager**](https://github.com/matter-labs/era-contracts/blob/release-v27/system-contracts/contracts/EvmPredeploysManager.sol): Contract used to deploy important ecosystem EVM contracts like Create2 factories.\n\nNew precompiles to enhance EVM compatibility:\n\n* [**Identity**](https://github.com/matter-labs/era-contracts/blob/release-v27/system-contracts/contracts/precompiles/Identity.yul) (0x04): Just returns the input data.\n\nThe EVM emulation feature also requires the following changes:\n\n* **VM and circuits**:\n * Remove additional EVM emulation gas stipend. This stipend was implemented in the past as part of preparations for the EVM emulation, but in the final implementation it is not needed: the caller pays for the emulation in full.\n * Increase memory stipend for EVM emulation frames. EVM emulator uses memory to store stack and bytecode. The initial free heap size has been adjusted to account for this.\n* **L1 ecosystem contracts**\n * EVM emulator hash is added to batch meta params (similar to DefaultAccount bytecode hash).\n * Admin facet: added function `allowEvmEmulation()` to enable EVM emulator on the chain.\n * Mailbox facet: added special service L1→L2 transaction functionality, which is necessary for the mechanism of enabling EVM emulator on the chain.\n* **System contracts**\n * Bootloader and DefaultAccount: support deployment of EVM contracts by EOAs (with tx without field `to`).\n * ContractDeployer: Add functionality to deploy EVM contracts using `create`, `create2` and forced deployments. This functionality is available if the chain has the EVM emulation feature enabled.\n * KnownCodesStorage: Add functionality to publish EVM bytecodes.\n * AccountCodeStorage: Add EVM-specific functionality.\n\nAlong with the EVM emulator, we provide a set of contracts that can be deployed to pre-defined addresses. This list includes important frequently used contracts that are typically deployed using keyless transactions:\n\n* Create2 proxy: `0x4e59b44847b379578588920cA78FbF26c0B4956C`\n [GitHub - Arachnid/deterministic-deployment-proxy: An Ethereum proxy contract that can be used for deploying contracts to a deterministic address on any chain.](https://github.com/Arachnid/deterministic-deployment-proxy)\n* Create2 deployer: `0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2`\n [GitHub - pcaversaccio/create2deployer: Helper smart contract to make easier and safer usage of the \\`CREATE2\\` EVM opcode.](https://github.com/pcaversaccio/create2deployer)\n* ERC2470 singleton factory: `0xce0042B868300000d44A59004Da54A005ffdcf9f`\n [ERC-2470: Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470)\n* Safe Singleton Factory: `0x914d7Fec6aaC8cd542e72Bca78B30650d45643d7`\n [safe-singleton-factory/source/deterministic-deployment-proxy.yul at main · safe-global/safe-singleton-factory · GitHub](https://github.com/safe-global/safe-singleton-factory/blob/main/source/deterministic-deployment-proxy.yul)\n* Create2 proxy: `0x7A0D94F55792C434d74a40883C6ed8545E406D12`\n [GitHub - Zoltu/deterministic-deployment-proxy: An Ethereum proxy contract that can be used for deploying contracts to a deterministic address on any chain.](https://github.com/Zoltu/deterministic-deployment-proxy)\n\nDetailed overview of EVM emulation can be read in the contracts repo: [era-contracts/docs/evm\\_emulation at release-v27 · matter-labs/era-contracts · GitHub](https://github.com/matter-labs/era-contracts/tree/release-v27/docs/evm_emulation)\n\nEVM gas model emulation explainer: [EVM gas emulation overview](https://github.com/matter-labs/era-contracts/blob/release-v27/docs/evm_emulation/evm_gas_emulation.md)\n\n### Fflonk verifier\n\nThe other feature of the V27 release is optional proof verification with Fflonk (previously, only the Plonk protocol was used). The new verifier contract implementation can accept both Plonk and Fflonk proofs, providing flexibility during the transition period. An important reason for this change is that on-chain verification of Fflonk proofs is approximately 30% cheaper than verification of Plonk proofs, while consuming roughly the same (or even fewer) resources to generate the proof.\n\nNew flexible dual verifier implementation: [DualVerifier.sol](https://github.com/matter-labs/era-contracts/blob/release-v27/l1-contracts/contracts/state-transition/verifiers/DualVerifier.sol)\nNew Fflonk verifier implementation: [L1VerifierFflonk.sol](https://github.com/matter-labs/era-contracts/blob/release-v27/l1-contracts/contracts/state-transition/verifiers/L1VerifierFflonk.sol)\n\n### Additional changes\n\nThe V27 update includes several optimizations, improvements, and fixes for EraVM and circuits that enhance the security and performance of the protocol. Improvements also affect Boojum’s gadgets and internal functions. For detailed info please read corresponding audit reports:\n\n* **EraVM changes and fixes audit:** [V27 security audit](https://github.com/matter-labs/zksync-protocol/blob/main/audits/ZKsync%20V27%20security%20audit%20report.pdf)\n* **EraVM changes and fixes audit #2:** [V27 security audit #2](https://github.com/matter-labs/zksync-protocol/blob/main/audits/ZKsync%20V27%20security%20audit%20report%202.pdf)\n\nSeveral minor changes and fixes in the contracts are listed in the changelog: [V27 changelog](https://github.com/matter-labs/era-contracts/blob/release-v27/docs/upgrade_history/v27_evm_emulation/v27-evm-emulation.md#changes)\n\n## Rationale\n\n### EVM emulation\n\nThe EVM emulator is designed as a translation layer that does not replace but enhances the EraVM execution environment. This approach allows ZKsync to leverage the robust security and performance of EraVM while extending compatibility with the broader Ethereum ecosystem. More specifically, the emulation of the EVM environment on top of EraVM minimizes the number of changes required in critical and battle-tested parts of the system, such as circuits, thereby significantly enhancing the security of new functionality for the ecosystem. As a result, the implementation of the emulator in the Yul language simplifies its development, testing and auditing, which in turn will make further updates and improvements a lot easier.\n\nAn important drawback of this approach is the increased cost of EVM contract execution compared to native EraVM contracts, due to the need to emulate the EVM environment. It is also important to note that the emulation cannot provide 100% equivalence with EVM; detailed information can be found in the list of differences: [differences from EVM (Cancun)](https://github.com/matter-labs/era-contracts/blob/release-v27/docs/evm_emulation/differences_from_cancun_evm.md). Despite the described shortcomings, emulation will open the way for a large number of use cases. A fully EVM-equivalent native execution environment is a key part of the [2025 roadmap](https://zksync.mirror.xyz/QG2Xr4lQdJTbyjeKftPVc6-pj2t9-H9WEGnvCcnusck).\n\n## Implementation & Backwards Compatibility\n\n### EVM emulation\n\nThe EVM emulator will be integrated into the ZKsync Era protocol as a system contract that intercepts and translates EVM bytecode to EraVM instructions dynamically. This system ensures that all Ethereum-compatible contracts can be executed without altering their original code.\n\nThis feature does not affect already deployed EraVM contracts. EVM emulation is an **optional** feature which can be enabled separately for each ZK Chain by the corresponding chain admin.\n\nTo test compatibility with EVM, a widely used canonical set of state tests was used: [ethereum/tests](https://github.com/ethereum/tests/tree/a0e848269dd2af2b061fe9a4749d40963c2bdb5c). Corresponding test runner infrastructure for the emulator: [era-evm-tester](https://github.com/matter-labs/era-evm-tester).\n\n### Fflonk verifier\n\nTo simplify upgrades and improve fault tolerance, the new Fflonk verifier will be added as an optional, second option for proving. This approach improves backward compatibility, but still requires changing the input data layout for zk-SNARK verification to distinguish between the two types of proofs. This should be taken into account when submitting proofs to the verifier. More detailed info: [DualVerifier contract](https://github.com/matter-labs/era-contracts/blob/81b5b7d5c4b83e7193962f9e12e0c7186e0b7202/l1-contracts/contracts/state-transition/verifiers/DualVerifier.sol#L36-L42).\n\n## Security Considerations\n\nThe introduction of an EVM emulator involves complex interactions between different virtual machine instructions sets and system contracts. The verifier is an absolutely critical part of the protocol, on which the correctness and verifiability of the ecosystem depends.\n\nRigorous security audits and testing have been completed to ensure that proposed changes do not introduce vulnerabilities. Audit reports:\n\n* **EVM emulator contracts audit**: [https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync EVM Equivalence Audit.pdf](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20EVM%20Equivalence%20Audit.pdf)\n* **FFLONK verifier contracts audit**: [https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync FFLONK Verifier Audit.pdf](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20FFLONK%20Verifier%20Audit.pdf)\n* **FFLONK and EVM emulator contracts diff audit**: [https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync FFLONK and EVM Equivalence Diff Audit.pdf](https://github.com/matter-labs/era-contracts/blob/release-v27/audits/ZKsync%20FFLONK%20and%20EVM%20Equivalence%20Diff%20Audit.pdf)\n* **EraVM changes and fixes audit:** [V27 security audit](https://github.com/matter-labs/zksync-protocol/blob/main/audits/ZKsync%20V27%20security%20audit%20report.pdf)\n* **EraVM changes and fixes audit #2:** [V27 security audit #2](https://github.com/matter-labs/zksync-protocol/blob/main/audits/ZKsync%20V27%20security%20audit%20report%202.pdf)"
}
}By Ethereum Governance • 3/27/2025
Event Details
- Network: Ethereum Mainnet
- Chain ID: 1
- Block: 22137920
- Timestamp: 3/27/2025, 7:21:59 AM
Governance Info
- Governance Body: Ethereum Governance
- Event Type: UpgradeApprovedBySecurityCouncil
- Contract Address:0xE30D...5Ab30xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3
Event Data
{
"_id": {
"value": "0xeb2c2f18ce9b8fb6c3b5e127b31fe96e9c68f5ad9ab9881232fdda5c02d218a4"
}
}By Ethereum Governance • 3/26/2025
Event Details
- Network: Ethereum Mainnet
- Chain ID: 324
- Block: 22131475
- Timestamp: 3/26/2025, 9:47:35 AM
Governance Info
- Governance Body: Ethereum Governance
- Event Type: UpgradeApprovedBySecurityCouncil
- Contract Address:0xE30D...5Ab30xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3
Event Data
{
"_id": {
"value": "0xa21bc099ce1f3147a25f0ad48d5fffdb4a158a908c8cc535f4f429becd9a4c84"
}
}By Ethereum Governance • 3/26/2025
Event Details
- Network: ethereum
- Chain ID: 324
- Block: 22131475
- Timestamp: 3/26/2025, 9:47:35 AM
Governance Info
- Governance Body: Ethereum Governance
- Event Type: UpgradeApprovedBySecurityCouncil
- Contract Address:0xE30D...5Ab30xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3
Event Data
{
"_id": {
"value": "0xa21bc099ce1f3147a25f0ad48d5fffdb4a158a908c8cc535f4f429becd9a4c84"
}
}By ZKSync Governance • 3/17/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 57819893
- Timestamp: 3/17/2025, 7:36:29 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExecuted
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "98806622840077485421207653857298019081476009136539565020582912190689619102417"
}
}By ZKSync Governance • 3/17/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 57819893
- Timestamp: 3/17/2025, 3:36:29 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallExecuted
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0x853a09aaa86c7a014f88eefd34f8902051367e548f62ca77cc40a4a89f27d84d"
},
"index": {
"value": "0"
},
"target": {
"value": "0x0000000000000000000000000000000000008008"
},
"value": {
"value": "0"
},
"data": {
"value": "0x62f84b24...00000000"
}
}By ZKSync Governance • 3/17/2025
Event Details
- Network: ZKSync Era
- Chain ID: 324
- Block: 57819893
- Timestamp: 3/17/2025, 3:36:29 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallExecuted
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0x853a09aaa86c7a014f88eefd34f8902051367e548f62ca77cc40a4a89f27d84d"
},
"index": {
"value": "0"
},
"target": {
"value": "0x0000000000000000000000000000000000008008"
},
"value": {
"value": "0"
},
"data": {
"value": "0x62f84b24...00000000"
}
}By ZKSync Governance • 3/17/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 57819639
- Timestamp: 3/17/2025, 3:29:43 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallScheduled
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0x853a09aaa86c7a014f88eefd34f8902051367e548f62ca77cc40a4a89f27d84d"
},
"index": {
"value": "0"
},
"target": {
"value": "0x0000000000000000000000000000000000008008"
},
"value": {
"value": "0"
},
"data": {
"value": "0x62f84b24...00000000"
},
"predecessor": {
"value": "0x0000000000000000000000000000000000000000000000000000000000000000"
},
"delay": {
"value": "0"
}
}By ZKSync Governance • 3/17/2025
Event Details
- Network: ZKSync Era
- Chain ID: 324
- Block: 57819639
- Timestamp: 3/17/2025, 3:29:43 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallScheduled
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0x853a09aaa86c7a014f88eefd34f8902051367e548f62ca77cc40a4a89f27d84d"
},
"index": {
"value": "0"
},
"target": {
"value": "0x0000000000000000000000000000000000008008"
},
"value": {
"value": "0"
},
"data": {
"value": "0x62f84b24...00000000"
},
"predecessor": {
"value": "0x0000000000000000000000000000000000000000000000000000000000000000"
},
"delay": {
"value": "0"
}
}By ZKSync Governance • 3/14/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 57667473
- Timestamp: 3/14/2025, 7:20:34 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExtended
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "98806622840077485421207653857298019081476009136539565020582912190689619102417"
},
"extendedDeadline": {
"value": "1742239234"
}
}By ZKSync Governance • 3/10/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 57436909
- Timestamp: 3/10/2025, 7:08:38 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExecuted
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "53064417471903525695516096129021600825622830249245179379231067906906888383956"
}
}By ZKSync Governance • 3/10/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 57436909
- Timestamp: 3/10/2025, 3:08:38 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallExecuted
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0x5cf1538bb87104d603d35c155d8e76bdbb53bb33a7959fdd719f2efcf8b7f847"
},
"index": {
"value": "0"
},
"target": {
"value": "0x0000000000000000000000000000000000008008"
},
"value": {
"value": "0"
},
"data": {
"value": "0x62f84b24...00000000"
}
}By ZKSync Governance • 3/10/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 57436649
- Timestamp: 3/10/2025, 3:03:50 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallScheduled
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0x5cf1538bb87104d603d35c155d8e76bdbb53bb33a7959fdd719f2efcf8b7f847"
},
"index": {
"value": "0"
},
"target": {
"value": "0x0000000000000000000000000000000000008008"
},
"value": {
"value": "0"
},
"data": {
"value": "0x62f84b24...00000000"
},
"predecessor": {
"value": "0x0000000000000000000000000000000000000000000000000000000000000000"
},
"delay": {
"value": "0"
}
}By Ethereum Governance • 3/7/2025
Event Details
- Network: Ethereum Mainnet
- Chain ID: 1
- Block: 21997330
- Timestamp: 3/7/2025, 8:16:59 PM
Governance Info
- Governance Body: Ethereum Governance
- Event Type: UpgradeExecuted
- Contract Address:0x8f7a...18970x8f7a9912416e8AdC4D9c21FAe1415D3318A11897
Event Data
{
"_id": {
"value": "0x3774f8d203c4b4a7cf46c7867bc726a1350d77345c4fd8d2f92f64c53b4765b8"
}
}By Ethereum Governance • 3/6/2025
Event Details
- Network: Ethereum Mainnet
- Chain ID: 1
- Block: 21990135
- Timestamp: 3/6/2025, 8:08:47 PM
Governance Info
- Governance Body: Ethereum Governance
- Event Type: UpgradeApprovedBySecurityCouncil
- Contract Address:0x8f7a...18970x8f7a9912416e8AdC4D9c21FAe1415D3318A11897
Event Data
{
"_id": {
"value": "0x3774f8d203c4b4a7cf46c7867bc726a1350d77345c4fd8d2f92f64c53b4765b8"
}
}By ZKSync Governance • 3/6/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 57178611
- Timestamp: 3/6/2025, 3:42:09 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "98806622840077485421207653857298019081476009136539565020582912190689619102417"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0x0000000000000000000000000000000000008008"
}
]
},
"values": {
"value": [
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0x62f84b24...00000000"
}
]
},
"voteStart": {
"value": "1741534929"
},
"voteEnd": {
"value": "1742139729"
},
"description": {
"value": "# [ZIP-8] Upgrade Chain Creation Params\n| **Title** | Upgrade Chain Creation Params |\n| ------------------------- | ------------------------------------------------------------------------------------- |\n| **Proposal Type** | ZIP |\n| **One Sentence Summary:** | This proposal fixes the `ChainCreationParams` for the chain after the ZIP-6 upgrade. |\n| **Proposal Author** | Matter Labs, point of contact is @StanislavBreadless |\n| **Proposal Sponsor:** | Cyfrin |\n| **Date Created:** | 6-March-2025 |\n| **Version** | v1 |\n| **Summary of Action** | Updating the `genesisBatchHash`, `genesisBatchCommitment` as well as `genesisUpgrade` |\n| **Link to contracts** | https://github.com/matter-labs/era-contracts/pull/1270 |\n\n# \\[ZIP-8] Upgrade Chain Creation Params\n\n# **Summary**\n\nThis ZIP proposes updating the chain creation parameters for new chains to enable chain creation after [ZIP6](https://www.tally.xyz/gov/zksync/proposal/67712324710515983914473127418805437707715095849437613773846173900686148862581?govId=eip155:324:0x76705327e682F2d96943280D99464Ab61219e34f) as well as the setting the new `genesisUpgrade` contract.\n\n# **Abstract**\n\nWhen setting `ChainCreationParams` for a protocol version, we derive `genesisBatchHash` and `genesisBatchCommitment` from the [zksync-era](https://github.com/matter-labs/zksync-era/blob/d635851f69cf156a0a6fcc4142b9d3bb48c566a3/etc/env/file_based/genesis.yaml#L1-L3) repository, where these values are continuously tested.\n\nIt is expected that system contracts and predeployed contracts (e.g., `L2NativeTokenVault`) retain the same hashes at genesis as those in the [era-contracts](https://github.com/matter-labs/era-contracts/blob/release-v26/AllContractsHashes.json) repository. However, due to a configuration issue in [foundry.toml](https://github.com/matter-labs/era-contracts/blob/f7ecdb91f7941a3be01ce08bf6a2e4a5fb02a8d5/l1-contracts/foundry.toml#L5), the generated hashes varied depending on the presence of the node\\_modules folder -- despite no dependencies being used from it.\n\nThis discrepancy resulted in `genesisBatchHash` and `genesisBatchCommitment` using contracts that were compiled without `node_modules`, while other data was compiled with it, making chain initialization impossible.\n\nThis upgrade ensures consistency by aligning `genesisBatchHash` and `genesisBatchCommitment` with the rest of the contracts, resolving the issue.\n\nSeparately, a small issue was found in the genesis upgrade that led to the default wrapped base token having always having the generic \"Wrapped Base Token\"/\"WBT\" name and symbol, respectively. This was caused by the genesis upgrade [calling itself](https://github.com/matter-labs/era-contracts/blob/f7ecdb91f7941a3be01ce08bf6a2e4a5fb02a8d5/l1-contracts/contracts/upgrades/L1GatewayBase.sol#L46), which is not possible since it is executed in the context of a diamond proxy. This is also [fixed](https://github.com/matter-labs/era-contracts/blob/eb95ce9ab40820be8cc4d792bb92a7274fd62e32/l1-contracts/contracts/upgrades/L1GatewayBase.sol#L50) in this release.\n\n# **Motivation**\n\nThe main objective is to unblock the creation of new chains after the ZIP6 upgrade. The secondary objective is to fix with the low severity `L1GenesisUpgrade` issue.\n\n# **Specification**\n\nThe new `genesisBatchHash` and `genesisBatchCommitment` were taken from the zksync-era after [adjusting the compilation](https://github.com/matter-labs/zksync-era/pull/3640) to be the same as in the `era-contracts` repo:\n\n* `genesisBatchHash` should be equal to `0x7bdb3d822ad837a3611c436d3be457363a08d06d83b74469831482353a7d8277`.\n* `genesisBatchCommitment` should be equal to `0x81f5e324a4019e4161fb9dc5058a588aa364a551fdd5c0e8788521e64e7ad596`.\n\nAlso, the new `L1GenesisUpgrade` contract was deployed at address [0x107e92E7360e595d8129B522ABD458361f32f66C](https://etherscan.io/address/0x107e92E7360e595d8129B522ABD458361f32f66C). Its bytecode corresponds to the code from this PR: [https://github.com/matter-labs/era-contracts/pull/1270](https://github.com/matter-labs/era-contracts/pull/1270) at commit `37238f745cf7b0bafbbb041601b5549552465893`.\n\n# **Rationale**\n\nThe upgrade approach chosen ensures that no new protocol version (even patch version) is introduced, which ensures that no actions are needed from the existing chains.\n\n# Backwards Compatibility\n\nNo issues with backwards compatibility.\n\n# Security Considerations\n\nThe new `genesisBatchHash` and `genesisBatchCommitment` have been already tested on testnet.\n\nThe new `L1GenesisUpgrade` corresponds to the code at commit `37238f745cf7b0bafbbb041601b5549552465893`. Its code has been [reviewed](https://github.com/matter-labs/era-contracts/blob/release-v26-1/audits/ZKChain%20Release%20Candidate%20Audit%20\\(e3dd33c\\).pdf) by OpenZeppelin at commit `e3dd33ceee8f803510cbd0debb8ed55fef4007e8`.\n\nThe diff between the commits can be seen [here](https://github.com/matter-labs/era-contracts/compare/e3dd33ceee8f803510cbd0debb8ed55fef4007e8...37238f745cf7b0bafbbb041601b5549552465893). Neither `L1GenesisUpgrade` nor any of its dependencies have been amended."
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56706339
- Timestamp: 2/27/2025, 6:48:56 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExecuted
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "67712324710515983914473127418805437707715095849437613773846173900686148862581"
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56706339
- Timestamp: 2/27/2025, 1:48:56 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallExecuted
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0xb2acd58b621cff22ede403c9125952215a60e4a8d548ab227e6f20235f6ec286"
},
"index": {
"value": "0"
},
"target": {
"value": "0xdA4358Ef83Bfc9e7aC421897cA56C77F9Be21308"
},
"value": {
"value": "0"
},
"data": {
"value": "0xfc936cf8...fabe898e"
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56706282
- Timestamp: 2/27/2025, 1:47:45 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallScheduled
- Contract Address:0x085b...c7140x085b8B6407f150D62adB1EF926F7f304600ec714
Event Data
{
"id": {
"value": "0xb2acd58b621cff22ede403c9125952215a60e4a8d548ab227e6f20235f6ec286"
},
"index": {
"value": "0"
},
"target": {
"value": "0xdA4358Ef83Bfc9e7aC421897cA56C77F9Be21308"
},
"value": {
"value": "0"
},
"data": {
"value": "0xfc936cf8...fabe898e"
},
"predecessor": {
"value": "0x0000000000000000000000000000000000000000000000000000000000000000"
},
"delay": {
"value": "0"
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56699585
- Timestamp: 2/27/2025, 4:25:26 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallExecuted
- Contract Address:0x3701...e6A80x3701fB675bCd4A85eb11A2467628BBe193F6e6A8
Event Data
{
"id": {
"value": "0xdb0cf36b3f053dd6848483f8995beb7500fcae813d9ca062753f1cf14e642ccb"
},
"index": {
"value": "1"
},
"target": {
"value": "0x76705327e682F2d96943280D99464Ab61219e34f"
},
"value": {
"value": "0"
},
"data": {
"value": "0xd07f91e9000000000000000000000000000000000000000000000000000000000003f480"
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56699585
- Timestamp: 2/27/2025, 4:25:26 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: TimelockChange
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
Event Data
{
"oldTimelock": {
"value": "0x3701fB675bCd4A85eb11A2467628BBe193F6e6A8"
},
"newTimelock": {
"value": "0x085b8B6407f150D62adB1EF926F7f304600ec714"
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56699585
- Timestamp: 2/27/2025, 4:25:26 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: LateQuorumVoteExtensionSet
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
Event Data
{
"oldVoteExtension": {
"value": "604800"
},
"newVoteExtension": {
"value": "259200"
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56699585
- Timestamp: 2/27/2025, 4:25:26 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: VotingDelaySet
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
Event Data
{
"oldVotingDelay": {
"value": "604800"
},
"newVotingDelay": {
"value": "259200"
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56699585
- Timestamp: 2/27/2025, 4:25:26 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExecuted
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "32477831455745537024214395992964479454779258818502397012096084176779102554510"
}
}By ZKSync Governance • 2/27/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56697862
- Timestamp: 2/27/2025, 3:53:45 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: CallScheduled
- Contract Address:0x3701...e6A80x3701fB675bCd4A85eb11A2467628BBe193F6e6A8
Event Data
{
"id": {
"value": "0xdb0cf36b3f053dd6848483f8995beb7500fcae813d9ca062753f1cf14e642ccb"
},
"index": {
"value": "0"
},
"target": {
"value": "0x76705327e682F2d96943280D99464Ab61219e34f"
},
"value": {
"value": "0"
},
"data": {
"value": "0x70b0f660000000000000000000000000000000000000000000000000000000000003f480"
},
"predecessor": {
"value": "0x0000000000000000000000000000000000000000000000000000000000000000"
},
"delay": {
"value": "0"
}
}By ZKSync Governance • 2/24/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56539079
- Timestamp: 2/24/2025, 6:57:02 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "53064417471903525695516096129021600825622830249245179379231067906906888383956"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0x0000000000000000000000000000000000008008"
}
]
},
"values": {
"value": [
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0x62f84b24...00000000"
}
]
},
"voteStart": {
"value": "1741028222"
},
"voteEnd": {
"value": "1741633022"
},
"description": {
"value": "# [ZIP-7] Lens Chain inclusion on Elastic Network\n| **Title** | \\[ZIP-7] Lens Chain inclusion on Elastic Network |\n| ------------------------- | ------------------------------------------------------ |\n| **Proposal Type** | ZIP |\n| **One Sentence Summary:** | Proposal for Lens Chain inclusion on Elastic Network. |\n| **Proposal Author** | Lens Chain |\n| **Proposal Sponsor:** | Cyfrin |\n| **Date Created:** | 24 February 2025 |\n| **Version** | v1 |\n| **Summary of Action** | Include Lens Chain in the Elastic Network |\n| **Link to contracts** | https://github.com/matter-labs/era-contracts/pull/1287 |\n\n# \\[ZIP-7] Lens Chain inclusion on Elastic Network\n\n## Summary\n\nLens Chain is a high performance chain built leveraging ZKsync and Avail. The Lens Labs team and Matter Labs have collaborated in the creation of the chain, and the migration of user profiles, followers and publications from Lens V2 on Polygon to Lens Chain.\n\nSince the state including the migration data will be applied on genesis, we need to request the inclusion of the chain on the Elastic Network.\n\n## Abstract\n\nThe deployment of Lens Chain, with its significant state changes at genesis, requires approval through ZKsync's governance system. This critical step ensures transparency and community validation of the migration process.\n\nThe implementation of this governance process, combined with our active data synchronization, represents a methodical approach to launching Lens Chain while maintaining the trust and engagement of our user community.\n\nAs far as we are aware, this is a first-time occurrence in the Elastic Network ecosystem of applying such large genesis state.\n\n## Motivation\n\nLens v2 has built a thriving community with over 600,000 profiles and unique handles. The protocol maintains strong engagement with 45,000 weekly active users who have collectively created 31 million publications.\n\nWhen Lens Chain launches, all existing user data will be automatically deployed at genesis. This means users can immediately start using Lens Chain at launch without taking any migration steps — their profiles, connections, and content will be ready and waiting for them.\n\nThis seamless migration process, developed in partnership with Matter Labs, represents a groundbreaking technical achievement in both blockchain and ZK technology. It is the first time a blockchain ecosystem has executed such a comprehensive automated migration at genesis.\n\n## Specification\n\nWe will be applying a genesis state on block 0 which includes:\n\n* Profiles - 645\\_408\n* Profile Managers - 588\\_371\n* Handles - 639\\_296\n* Apps - 359\n* Unlinked Handles - 2\\_421\n* Follows - 27\\_944\\_873\n* Root Posts - 11\\_756\\_025\n* Comments Depth 1 - 3\\_613\\_497\n* Comments Depth 2 - 563\\_735\n* Comments Depth 3 - 101\\_472\n* Comments Depth 4 - 36\\_221\n* Quotes - 308\\_217\n* Quotes Comments - 153\\_784\n\nMirrors will not be migrated and any comments greater depth then 4 will not be migrated either.\n\nAll Momoka publications will be migrated if they fall in the criteria above.\n\nWhile the vote is happening we will be syncing Lens v2 Polygon data onto Lens v3 on Lens Chain.\n\n### Contracts migration specification\n\nIn order to ensure the security of the migration process, it will consist of the following stages:\n\n* **Preparation before the vote**. During this stage, the governance over the network will be given to the ProtocolUpgradeHandler [from the ZIP5 upgrade](https://forum.zknation.io/t/zip-5-upgrade-governance-contracts/487). To be more concrete, the ownership will be transferred to [the following contract](https://etherscan.io/address/0x52bBEa5e3CD4B3F731151acd051F83d2c14a66dc#code). An intermediate owner for contracts is required since most of our contracts are Ownable2Step, so the Token Assembly will accept the ownership later during the vote. The deployed chain will have no bridging initialized and it will be expected to have 0 balances over all tokens. This is needed to ensure that no assets will have to be migrated.\n* **During the vote**. The chain will exist on a separate ecosystem, while the fact that the ownership has been transferred in the previous step will ensure that this temporary ecosystem is fully compliant with the main one (all state transitions are valid and verified by the same zero-knowledge circuits as the main ecosystem, etc).\n* **The network inclusion process**. The ProtocolUpgradeHandler will execute the following operations:\n * Accept ownership over the old ecosystem.\n * Register it in the current ecosystem via calling the `registerAlreadyDeployedHyperchain` [function](https://github.com/matter-labs/era-contracts/blob/3288adb0aee6c1c3022f6c817f95234764e0d611/l1-contracts/contracts/state-transition/StateTransitionManager.sol#L385) in the state transition manager.\n * Register the chain in the Bridgehub via the `createNewChain` [method](https://github.com/matter-labs/era-contracts/blob/3288adb0aee6c1c3022f6c817f95234764e0d611/l1-contracts/contracts/bridgehub/Bridgehub.sol#L140).\n * To ensure that the storage of the chain is fully compliant with the storage of the ZK chains that were registered via the standard process, the `executeUpgrade` function will be called upon the chain. It will use the [Migrator](https://etherscan.io/address/0x4d89b79A893aC95eB46E96e452AD21F71144c918#code) contract, the main job of which would be to set the correct ecosystem contracts' addresses.\n\n#### Relation to ZIP-6\n\nThe upgrade is expected to land on the mainnet after ZIP-6 has been executed on L1 (and so the v26 upgrade is available for chains), but before the second stage of the upgrade is executed (and so operating on the v26 version will not be mandatory yet).\n\nThis means that the chain will upgrade to v26 in the same manner as any other ZK chain. But it also means that the parameters for the Migrator contract need to be careful and contain the address of the `ValidatorTimelock` that is equal to the one from v25 and not v26.\n\n## Rationale\n\nWe aim to provide a seamless transition to Lens Chain while preserving users' existing Lens profiles, including their social connections and content history.\n\nThis ensures users can use Lens Chain and Lens V3 without any manual effort while maintaining their established social presence.\n\n## Backwards Compatibility\n\nNA - this is a request to include Lens Chain in the Elastic Network and there are no potential breaking changes.\n\n## Security Considerations\n\nThe technical implementation has been done in collaboration with the Matter Labs team, and security reviews have been performed on their end and on our end.\n\nAlongside all state validation has been confirmed as correct, with verification tasks run and other forms of validation.\n\n## **Other Information**\n\n* A migration blog will go into more in-depth detail of how we migrated the state - stay tuned\n* Lens Website - lens.xyz\n* Developer Docs - [https://dev-preview.lens.xyz/docs/chain/overview](https://dev-preview.lens.xyz/docs/chain/overview)"
}
}By ZKSync Governance • 2/20/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56328109
- Timestamp: 2/20/2025, 6:14:03 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExtended
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "67712324710515983914473127418805437707715095849437613773846173900686148862581"
},
"extendedDeadline": {
"value": "1740680043"
}
}By ZKSync Governance • 2/20/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 56320240
- Timestamp: 2/20/2025, 3:28:49 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalExtended
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "32477831455745537024214395992964479454779258818502397012096084176779102554510"
},
"extendedDeadline": {
"value": "1740670129"
}
}By ZKSync Governance • 2/11/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 55750208
- Timestamp: 2/11/2025, 7:29:07 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "67712324710515983914473127418805437707715095849437613773846173900686148862581"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0xdA4358Ef83Bfc9e7aC421897cA56C77F9Be21308"
},
{
"value": "0x0000000000000000000000000000000000008008"
},
{
"value": "0x0000000000000000000000000000000000008008"
}
]
},
"values": {
"value": [
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
},
{
"value": ""
},
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0xfc936cf8...fabe898e"
},
{
"value": "0x62f84b24...00000000"
},
{
"value": "0x62f84b24...00000000"
}
]
},
"voteStart": {
"value": "1739906947"
},
"voteEnd": {
"value": "1740511747"
},
"description": {
"value": "# Prepare ZKsync for ZK Gateway\n| **Title** | Prepare ZKsync for ZK Gateway |\n| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Proposal Type** | ZIP |\n| **One Sentence Summary:** | This proposal aims to upgrade ZKsync protocol features essential for compatibility with the forthcoming ZK Gateway, alongside other enhancements to empower ZK Chains and developers. |\n| **Proposal Author** | Matter Labs |\n| **Proposal Sponsor:** | Cyfrin |\n| **Date Created:** | 11-February-2025 |\n| **Version** | v1 |\n| **Summary of Action** | Deploy custom settlement layer support and flexible data availability configurations (including a secure permanent rollup mode) to prepare ZKsync for the forthcoming ZK Gateway integration; pre-deploy new asset routing and native token vault contracts to streamline bridging and asset migration; and migrate the legacy L1SharedBridge to an L1Nullifier for improved bookkeeping—collectively laying the groundwork for seamless cross-chain interoperability and efficient future upgrades. |\n| **Link to contracts** | https://github.com/matter-labs/era-contracts/tree/release-v26 |\n\n# **\\[ZIP-6] Prepare ZKsync for ZK Gateway**\n\n# **Summary**\n\nThis proposal seeks to prepare the ZKsync protocol for the upcoming ZK Gateway upgrade. ZK Gateway is slated for future deployment through a separate governance vote. This upgrade aims to align ZKsync's existing contracts with ZK Gateway's requirements, ensuring a seamless integration process and reducing the complexity of the upgrade to deploy ZK Gateway. Additionally, this proposal introduces enhancements to support custom Data Availability (DA) and bridge development, fostering greater flexibility for ZK Chains and developers.\n\n# **Abstract**\n\nThe primary objective of this proposal is to upgrade the ZKsync protocol by improving aspects of the ZKsync protocol required for compatibility with the ZK Gateway upgrade. ZK Gateway is a middleware component that provides proof aggregation across ZK Chains and will enable fast interoperability in future upgrades. The upgrade to deploy ZK Gateway is expected to be submitted to the Token Assembly for a vote in the coming months. This proposal serves as a foundational step to align ZKsync's existing contracts with the new ZK Gateway requirements, facilitating a smooth upgrade process for the deployment of ZK Gateway. The changes focus on streamlining the upgrade processes, adjusting lifecycle management for contract migrations, and introducing robust protocols for handling contract transitions effectively.\n\nAs well as the improvements mentioned, this upgrade also contains features that are not related to ZK Gateway, including: easier-to-use interfaces for developing custom bridges on top of ZK chains, support of custom DA as well as easier upgrading and deployment of new ZK chains.\n\n# **Motivation**\n\nThe motivations for this proposal are:\n\n1. **Risk Mitigation and Simplified Upgrade Path for ZK Gateway:** Proactively updating the ZKsync infrastructure to align with the ZK Gateway's requirements reduces the risk of complications during the ZK Gateway's future rollout. Separating the protocol changes from the actual deployment of the Gateway itself minimizes the complexity of the upgrade process. This proposal focuses only on the necessary protocol changes to enable the future integration of the ZK Gateway, with the deployment of the ZK Gateway to be addressed in a subsequent ZIP.\n2. **Custom Data Availability (DA) Solutions**: An integral component of this proposal involves introducing features that empower ZK chain administrators and developers with more control and flexibility. Enabling custom DA solutions is pivotal for catering to the specific needs of different chains and ensuring the long-term success of the Elastic Network. This update ensures that developers and administrators of ZK Chains are equipped with the tools necessary to optimize their operations within the Elastic Network effectively.\n\n# **Specification**\n\n### Prepare ZKsync for ZK Gateway\n\n* **Custom Settlement Layers:** Prepare the infrastructure necessary to support custom settlement layers for future deployments. This will allow ZK Chains within the Elastic Network to use ZK Gateway (once deployed) as their custom settlement layer, enabling future rapid proof aggregation and seamless cross-chain interoperability.\n\n### Additional Feature\n\n* **Custom Data Availability Layer Support:** Introduce support for custom data availability layers, enabling each ZK Chain within the Elastic Network to manage its data availability requirements efficiently and autonomously.\n* **Bridging Architecture Enhancements:** Implement changes that simplify the creation of bridges for assets with unique behaviors, facilitating smoother asset transfers between L1 and L2.\n* **Easier upgrade and more trustless deployment of chains:** As a result of the new bridging architecture, the standard bridging contracts, which include `L2AssetRouter` and `L2NativeTokenVault`, are now deployed upon genesis. After this upgrade, ZK Chains can rely less on the correctness of the manual initialization process. The upgrade flow for ZKsync governance will also be improved. Currently the Protocol Governor needs to upgrade a shared bridge on each separate ZK Chain. After this upgrade, this action will be automatically included as part of a protocol upgrade.\n\nFull documentation related to the contracts for this version can be read in this repo: [https://github.com/matter-labs/era-contracts/tree/release-v26/docs.](https://github.com/matter-labs/era-contracts/tree/release-v26/docs.)\n\n### Support for custom settlement layers\n\nThis release adds all the necessary functionality to deploy settlement layers and allow ZK Chains to migrate on top of them. In the future, the ZK Gateway settlement layer will be introduced and ZK Chains will be able to utilize it for cheaper batch processing and faster native interoperability.\n\nPlease note, this upgrade does not include actual deployment of a settlement layer. This will require a separate governance vote in the future.\n\nYou can read more about how settlement layers work in this Github repo: [https://github.com/matter-labs/era-contracts/blob/release-v26/docs/gateway/overview.md](https://github.com/matter-labs/era-contracts/blob/release-v26/docs/gateway/overview.md)\n\n### Custom DA layer support\n\nPreviously for all ZK Chains either Rollup or Validium DA layers were supported. Now the admin of each ZK Chain can select which DA layer to use.\n\nAs an additional security feature, we also introduced a *permanentRollup* mode, which allows a chain to become a rollup forever, excluding a possibility for a malicious admin to change the way the data availability is published for a ZK Chain. This will be the mode that ZKsync Era will use.\n\nSoon after this upgrade is completed, the corresponding tooling will be provided. For those who are curious about how the functionality is implemented at a deeper level, you can check out this documentation: [https://github.com/matter-labs/era-contracts/blob/release-v26/docs/gateway/gateway\\_da.md](https://github.com/matter-labs/era-contracts/blob/release-v26/docs/gateway/gateway_da.md)\n\n### Changes to bridging architecture\n\nPreviously, all deposits of tokens went through the [L1SharedBridge](https://github.com/matter-labs/era-contracts/blob/main/l1-contracts/contracts/bridge/L1SharedBridge.sol) which sends messages to its L2 counterpart, that is responsible for the creation of the corresponding “bridged” versions of tokens. This contract also has the role of the vault for the assets.\n\nThis design makes it harder to develop a custom bridging mechanism. If someone wanted to create their own bridge, they would have to reimplement a lot of boilerplate and constantly keep themselves up-to-date with future features.\n\nTo make this process simpler, the bridging architecture has been updated:\n\n* The main contract will be called [L1AssetRouter](https://github.com/matter-labs/era-contracts/blob/release-v26/l1-contracts/contracts/bridge/asset-router/L1AssetRouter.sol) which interacts with its [L2 counterpart](https://github.com/matter-labs/era-contracts/blob/release-v26/l1-contracts/contracts/bridge/asset-router/L2AssetRouter.sol). The `L1AssetRouter` will not hold the L1 tokens, but will serve as a central point of bridging communication between chains.\n* Instead of operating on token addresses, bridges will start operating on future-proof “asset ids”, which encode the asset origin id, as well as the contract that can define the canonical bridging contract for each chain. This contract that defines the correct way to bridge an asset is called “Asset deployment tracker”. On each chain, a separate “Asset handler” contract can be deployed to ensure that the bridging process is done as expected.\n* The default asset deployment tracker will be “native token vault”. It is represented by the [L1NativeTokenVault](https://github.com/matter-labs/era-contracts/blob/release-v26/l1-contracts/contracts/bridge/ntv/L1NativeTokenVault.sol) on L1 and the [L2NativeTokenVault](https://github.com/matter-labs/era-contracts/blob/release-v26/l1-contracts/contracts/bridge/ntv/L2NativeTokenVault.sol) on L2. The L1 contract will be where the funds are stored.\n* Note, that before, the `L2SharedBridge` had to be separately deployed after the creation of the chain. The new contracts (`L2AssetRouter`, `L2NativeTokenVault`, etc) will be pre-deployed. This will ensure easier upgrades for those contracts in the future. As a result, new ZK Chains will experience an easier flow of creation.\n* The old `L1SharedBridge` will *NOT* be upgraded to the `L1AssetRouter` or `L1NativeTokenVault`, but will be upgraded to the `L1Nullifier` contract that will be responsible for bookkeeping executed bridging operations. ⚠️ **Thus, this upgrade will require migration of funds to the** `L1NativeTokenVault` ⚠️ ***.***\n\n**Detailed documentation on asset router and bridging**\n\n[https://github.com/matter-labs/era-contracts/blob/release-v26/docs/bridging/asset\\_router/overview.md](https://github.com/matter-labs/era-contracts/blob/release-v26/docs/bridging/asset_router/overview.md)\n\n### Additional differences\n\nAdditional differences to the previous protocol version can be viewed here:\n\n[https://github.com/matter-labs/era-contracts/blob/release-v26/docs/upgrade\\_history/gateway\\_upgrade/gateway\\_diff\\_review.md](https://github.com/matter-labs/era-contracts/blob/release-v26/docs/upgrade_history/gateway_upgrade/gateway_diff_review.md)\n\n### ZIP-6 Upgrade Process\n\nThe upgrade process is described in detail here:\n\n[https://github.com/matter-labs/era-contracts/blob/release-v26/docs/upgrade\\_history/gateway\\_upgrade/upgrade\\_process (no gateway chain).md](https://github.com/matter-labs/era-contracts/blob/release-v26/docs/upgrade_history/gateway_upgrade/upgrade_process%20\\(no%20gateway%20chain\\).md)\n\nFrom the ZK Chains perspective:\n\n1. **Step 1: publishing of the upgrade data to the ChainTypeManager**. After this step, the new protocol version will get published to the `ChainTypeManager`. This will not affect ZK Chains functionality in any way, but each ZK chain will have 2 weeks to upgrade itself to the new protocol version. The necessary instructions are expected to be relatively straightforward and will be provided in a timely manner.\n\nOnce a ZK Chain is upgraded, it will already have the new L2 contracts. These contracts will already support bridging of L2 tokens to L1. After this step, the L1 bridging contracts will not be upgraded. As a result, it is not possible to finalize withdrawals of L2-native tokens until the L1 bridging contracts are upgraded, which is covered in Step 2.\n\nAll else (including withdrawals of the L1-native tokens) will work as usual.\n2\\. **Step 2: finalization of the upgrade on L1.** After the upgrade deadline has passed, the ZK Chains that have not yet upgraded, would stop from being able to publish new batches. For those ZK Chains that did migrate on time, no further action is needed.\n\n⚠️ Note however, immidiately after step 2 finalization is complete, ZK Chains — as well as their base tokens and bridging balances in general, need to be migrated to the new contracts. This can be done trustlessly by any wallet. The team that prepared the upgrade will do this for the entire network, which may take several minutes. As a result, this effectively means there will be **several minutes of deposits not working for ZK chains** while this upgrade takes place. ⚠️\n\n# **Rationale**\n\nThis ZIP focuses only on the preparation of the Elastic Network for the future deployment of Gateway. The limited scope was chosen to keep the upgrade simpler. The Gateway chain would facilitate future proof aggregation and seamless interoperability between ZK chains.\n\nAdditional features such as custom data availability support, more generic bridging give ZK chains and developers more flexibility when working with the Elastic Network.\n\n# **Backwards Compatibility**\n\nDue to renames for better readability (e.g. “hyperchain → ZK chain”, “StateTransitionManager → ChainTypeManager”), several getters on the contracts that were considered to be used rarely were deleted.\n\nThe existing SDKs will continue working for the old use-cases: depositing and withdrawing assets native to L1 on top of chains that were deployed before this upgrade.\n\nHowever new use-cases:\n\n* Depositing and withdrawing assets native to L2\n* Any bridging for chains that were deployed after this upgrade\n\nWould require a new SDK. The version of the new `zksync-ethers` SDK will be provided soon. Note, that this new SDK will not be compatible with chains that have not yet upgraded. Thus, with regard to the SDK, the upgrade should be done in the following order:\n\n* Firstly upgrade the chain\n* Then recommend the front-ends to migrate to the new SDK to support the new capabilities.\n\n# **Security Considerations**\n\n## Audit reports\n\nMultiple audits of the intermediate versions of the codebase have been performed by OpenZeppelin, which culminated into the final \"Release Candidate Audit\":\n\n* [ZKsync Custom Asset Bridge Audit (OpenZeppelin).pdf](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKsync%20Custom%20Asset%20Bridge%20Audit%20\\(OpenZeppelin\\).pdf)\n* [ZKChain Upgrades and Libraries Diff Audit (OpenZeppelin).pdf](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKChain%20Upgrades%20and%20Libraries%20Diff%20Audit%20\\(OpenZeppelin\\).pdf)\n* [ZKsync ZKChain and Gateway Upgrade Audit (OpenZeppelin).pdf](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKsync%20ZKChain%20and%20Gateway%20Upgrade%20Audit%20\\(OpenZeppelin\\).pdf)\n* [ZKChain Release Candidate Audit (OpenZeppelin).pdf](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKChain%20Release%20Candidate%20Audit%20\\(OpenZeppelin\\).pdf)\n\nThe last audit has found only Low/Note issues the fixes for which we decided to include in the next release, to keep the codebase identical to the one that was released on our internal staging env and the private testnet.\n\nAlso, an audit was conducted by Audittens: [ZKsync Gateway Audit (Audittens).pdf](https://github.com/matter-labs/era-contracts/blob/release-v26/audits/ZKsync%20Gateway%20Audit%20\\(Audittens\\).pdf). It covered the contracts at commit 7198b54fbcba37aa7a1dd75fc3067391af33e03e. All the issues found by Audittens were resolved.\n\nLater on, we conducted a CodeHawks competition with $500000 prize pool [https://codehawks.cyfrin.io/c/2024-10-zksync](https://codehawks.cyfrin.io/c/2024-10-zksync) for the full codebase that features the code the for upgrade. All the issues found during the contest were resolved. The final report is still private at the moment, but the diff between commits 7198b54fbcba37aa7a1dd75fc3067391af33e03e and a5754174938bd16a57b3cb59af5c604f9789bbc5 (that came after fixes from the Audittens' report and the CodeHawks contest) has been briefly reviewed by Audittens. This is also mentioned in the Audittens' report provided above.\n\nThe final commit that is identical to the code that is being deployed has been covered in the OpenZeppelin's Release Candidate report mentioned above. The diff can be seen [here](https://github.com/matter-labs/era-contracts/compare/91631aa5acfcd044bd71d0b6cf362ee6064f8319...4f109c42315c1d51bcad2b1a92b7044b6d6550f7). The diff contains only non-contract changes (scripts, tests, etc).\n\nAlso, for reference the diff between a5754174938bd16a57b3cb59af5c604f9789bbc5 (the last one reviewed by Audittens) and 4f109c42315c1d51bcad2b1a92b7044b6d6550f7 used for the release is the following [one](https://github.com/matter-labs/era-contracts/compare/a5754174938bd16a57b3cb59af5c604f9789bbc5...4f109c42315c1d51bcad2b1a92b7044b6d6550f7). It contains only:\n\n* Non-contract changes (scripts, tests, etc). This includes a new contract called ChainAdminOwnable but it is a full copy of the ChainAdmin contract from the current repo. This helps to test the backwards compatibility of tooling with the old ChainAdmin implementation. Due to the complexity of the new ChainAdmin contract, the Ownable it is also the recommended chain admin implementation to be used by chains. Ultimately, chains are never restricted in the version that they use (and may build their custom one if they wish to).\n* Contracts in da-contracts/contracts/da-layers/avail/\\* These contracts are not within the scope of the upgrade and will not be deployed as part of this upgrade.\n* `system-contracts/contracts/L2GatewayUpgrade.sol` has been amended to remove the requirement for the upgrade of the wrapped base token implementation to the new version. This is needed to allow the support of the custom wrapped base token implementations for chains. This change was thoroughly reviewed by an internal audit and [included](https://github.com/matter-labs/era-contracts/commit/91631aa5acfcd044bd71d0b6cf362ee6064f8319) in the OpenZeppelin's Release Candidate Audit.\n\n## Additional known issues\n\nThe following issues have been identified internally:\n\n* The default wrapped base token will always have the default `Wrapped Base Token`/`WBT` name and symbol respectively. This issue has a minor impact and could be fixed in the future. It was kept this way to keep the code the same between testing environments and the mainnet deployment.\n* Additional issues around correctly setting up the facets for chains on top of Gateway have been found. These were fixed in [this PR](https://github.com/matter-labs/era-contracts/pull/1238/files), but these issues do not affect the current upgrade, since the Gateway chain is not being deployed as part of it.\n\nGateway chain will be deployed within a separate ZIP and it will include the fixes for the issues above.\n\n## Upgrade review process\n\nIt is recommended to get familiar with the upgrade process [here](https://github.com/matter-labs/era-contracts/blob/release-v26/docs/upgrade_history/gateway_upgrade/upgrade_process%20\\(no%20gateway%20chain\\).md).\n\nThe community now has access to a Rust tool to verify the correctness of the upgrade. You can explore and use the tool directly by visiting the [Protocol Upgrade Verification Tool repo](https://github.com/matter-labs/protocol-upgrade-verification-tool/tree/main).\n\n⚠️ Warnings:\nCurrently, the `protocol-upgrade-verification-tool` tools returns two warnings:\n\n* That chain 325 does not have a wrapped base token. This has been agreed on with that chain. If you don't like the warning you can amend the tool to ignore the chain.\n* That the admin of the l2 wrapped base token store (https://etherscan.io/address/0x00937bfa497EBf4a26c14209B544dFb14d960555#writeContract) is not the ecosystem admin. This is true, we have given the ecosystem admin (https://etherscan.io/address/0x2cf3bD6a9056b39999F3883955E183F655345063#code) the status of pending admin, but it needs to accept it.\n\nThe latter should not be a blocker to start the voting delay. We will have plenty of time before the vote period actually begins to accept the vote.\n"
}
}By ZKSync Governance • 2/11/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 55749508
- Timestamp: 2/11/2025, 7:14:50 PM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: ProposalCreated
- Contract Address:0x7670...e34f0x76705327e682F2d96943280D99464Ab61219e34f
- Proposal Link: View Proposal
Event Data
{
"proposalId": {
"value": "32477831455745537024214395992964479454779258818502397012096084176779102554510"
},
"proposer": {
"value": "0xc11846203b0121C28285FA89EAd2249AafffaD2C"
},
"targets": {
"value": [
{
"value": "0x76705327e682F2d96943280D99464Ab61219e34f"
},
{
"value": "0x76705327e682F2d96943280D99464Ab61219e34f"
},
{
"value": "0x0000000000000000000000000000000000008008"
},
{
"value": "0x76705327e682F2d96943280D99464Ab61219e34f"
}
]
},
"values": {
"value": [
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
},
{
"value": "0"
}
]
},
"signatures": {
"value": [
{
"value": ""
},
{
"value": ""
},
{
"value": ""
},
{
"value": ""
}
]
},
"calldatas": {
"value": [
{
"value": "0x70b0f660000000000000000000000000000000000000000000000000000000000003f480"
},
{
"value": "0xd07f91e9000000000000000000000000000000000000000000000000000000000003f480"
},
{
"value": "0x62f84b24...00000000"
},
{
"value": "0xa890c910000000000000000000000000085b8b6407f150d62adb1ef926f7f304600ec714"
}
]
},
"voteStart": {
"value": "1739906090"
},
"voteEnd": {
"value": "1740510890"
},
"description": {
"value": "# Upgrade Governance Contracts\n# [ZIP-5] Upgrade Governance Contracts\n\n\n| **Title** | **[ZIP-5] Upgrade Governance Contracts** |\n|------------------------|----------|\n| **Proposal Type** | ZIP |\n| **One Sentence Summary** | This proposal suggests parameter changes to the Protocol Governor, redeploys all governance contracts, including contracts related to the protocol upgrade mechanism for ZKsync, namely the ProtocolUpgradeHandler. |\n| **Proposal Author** | Matter Labs, point of contact is @Stanislav Bezkorovainyi |\n| **Proposal Sponsor** | Cyfrin |\n| **Date Created** | 11-February-2025 |\n| **Version** | v1 |\n| **Summary of Action** | Parameter changes to the Protocol Governor, specifically reducing `_initialVotingDelay` from 7 days to 3 days and reducing `_lateQuorumVoteExtension` from 7 days to 2 days, along with deploying an upgradable version of the `ProtocolUpgradeHandler` and a new version of the `ZkProtocolGovernorTimelock`. Additionally, `GovOps` and `Token Governors` have been redeployed to update the veto guardian address to point to the new Guardians contracts. |\n| **Link to Contracts** | [GitHub PR #21](https://github.com/zksync-association/zk-governance/pull/21) |\n\n# [ZIP-5] Upgrade Governance Contracts\n\n## Summary\n\nThis proposal suggests parameter changes to the Protocol Governor, redeploys all governance contracts, including contracts related to the protocol upgrade mechanism for ZKsync, namely the `ProtocolUpgradeHandler`.\n\nThe Protocol Governor parameter changes in this proposal are designed to enhance the governance process by reducing the ZIP voting delay from 7 days to 3 days and reducing the quorum extension from 7 days to 2 days.\n\nThe `ProtocolUpgradeHandler` contract is responsible for executing protocol upgrades on Ethereum that have been approved by the Token Assembly. The current `ProtocolUpgradeHandler` contract is not upgradeable. This proposal includes the redeployment of the `ProtocolUpgradeHandler` contract to an upgradable version. This change ensures the Protocol Governor can execute upcoming ZKsync developments.\n\nAs part of the streamlined upgrade process, the existing `ProtocolUpgradeHandler` will continue to own the L2 chain-specific addresses (such as `L2SharedBridge`, etc.). The rationale behind this decision is detailed in the **Specification** section.\n\nIn addition to these changes, the redeployment of the `Token Governor` and `GovOps Governor` ensures that all facets of the governance framework remain consistent and secure. Specifically, these governors have been redeployed with their original parameters intact, with the only change being an update of the Veto Guardian to the new Guardians contract address.\n\n## Abstract\n\nThe ZKsync Protocol Governor is responsible for executing ZKsync Improvement Proposals (\"ZIPs\") that upgrade the ZKsync protocol and/or components of the ZKsync governance system. This proposal introduces three major amendments aimed at refining the efficiency and security of these processes:\n\n1. **Reduction of `_votingDelay`**: Decreasing the vote delay from 7 days to 3 days to enable faster onset of the voting period.\n2. **Reduction of `_lateQuorumVoteExtension`**: Shortening from 7 days to 2 days to expedite the closure of voting procedures.\n3. **Redeploy of the `ProtocolUpgradeHandler` to an upgradable version**: This version will allow for the modification of the implementation. This is needed in case of breaking changes to the interfaces of the functions of ecosystem contracts (e.g., `Bridgehub`, `StateTransitionManager`, etc.), as well as to include new contracts that fall under the scope of ZKsync contracts which can be frozen by an Emergency Upgrade. The above will happen during the **v26 upgrade**.\n\n## Motivation\n\nThe dual objective of this proposal is to streamline governance activities and improve the contracts governing protocol upgrades. Specifically:\n\n- **Governance Streamlining**: By reducing the `_votingDelay` and `_lateQuorumVoteExtension`, the ZIP governance process can react more swiftly to evolving needs of the ZKsync protocol, improving operational efficiency of protocol upgrades.\n- **Improve Protocol Upgrades**: Updating the `ProtocolUpgradeHandler` ensures that the Protocol Governor can effectively manage and secure new contracts introduced in future ZKsync upgrades by adding scope to the list of contracts the `ProtocolUpgradeHandler` controls. This change is vital for maintaining system integrity and alignment with the evolving architectural framework of ZKsync.\n\n## Specification\n\n### Governance Parameter Adjustments\n\n- **Reduce `_votingDelay`**: Modifies `_votingDelay` from 7 days to 3 days to accelerate the initiation of the voting period following proposal submission.\n- **Reduce `_lateQuorumVoteExtension`**: Modifies `_lateQuorumVoteExtension` from 7 days to 2 days, streamlining the voting process by shortening the extension period for achieving quorum.\n\n### Protocol Upgrade Enhancement\n\n- **Update to `ProtocolUpgradeHandler`**: \n - **Deployment of a New Contract**: A new upgradeable version of the `ProtocolUpgradeHandler` will be deployed to replace the existing non-upgradeable version.\n - **Upgradeability Feature**: Ensures future modifications to this contract can be made efficiently and securely.\n - **Proxy Ownership**: The proxy admin of the new `ProtocolUpgradeHandler` will be an OpenZeppelin `ProxyAdmin` contract, with the owner set to the `ProtocolUpgradeHandler` itself.\n - **Transfer of Ownership**: All L1 contracts’ ownerships will be transferred to the new upgradeable `ProtocolUpgradeHandler`. The `DEFAULT_ADMIN_ROLE` of the `ZK` token will also be granted to the new `ProtocolUpgradeHandler`.\n\n- **Update the `ZkProtocolGovernorTimelock` on L2**: \n - A new `ZkProtocolGovernorTimelock` contract will be used by the `ZkProtocolGovernor`, ensuring old upgrades cannot be re-executed with the new `ProtocolUpgradeHandler`.\n\n## Additional Context\n\n⚠️ This proposal does **not** include the transfer of ownerships of `L2SharedBridge`, `UpgradeableBeacon`, `L2WrappedBaseToken`, and similar L2 contracts that the `ProtocolUpgradeHandler` is the admin of. These contracts are deployed **once per chain** rather than ecosystem-wide. Future governance upgrades will aim to remove any mandatory upgrades requiring O(number_of_chains) L1→L2 transactions.\n\nThe old `ProtocolUpgradeHandler` will remain the owner of these contracts and continue accepting transactions from the old timelock, ensuring governance continuity.\n\n## Rationale\n\nThe governance parameter adjustments allow for quicker adaptation to community decisions and needs, while the upgrade to the `ProtocolUpgradeHandler` ensures the system's resilience and readiness to manage new contracts securely. These amendments optimize the governance process while aligning the Protocol Governor's capabilities with the latest technological advancements within the ZKsync ecosystem.\n\n## Backwards Compatibility\n\nThe proposed adjustments will not adversely affect existing operations but will streamline governance processes and enhance security protocols. They are designed to be backwards compatible, integrating seamlessly with the current operational protocols of ZKsync Era.\n\n## Security Considerations\n\nAny perceived security risks resulting from changing governance parameters to accelerate the ZIP governance process are mitigated by **Guardians** being able to veto a ZIP during the **Veto Period**. Further, all ZIPs continue to require **Security Council approval** to progress to execution.\n\nSince the `ProtocolUpgradeHandler` is now a proxy, some changes were required to its implementation: \n🔗 [GitHub PR #21](https://github.com/zksync-association/zk-governance/pull/21)\n\nThese changes do not alter the contract's behavior but facilitate the transition to a proxy implementation."
}
}By ZKSync Governance • 2/8/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 55519685
- Timestamp: 2/8/2025, 2:36:04 AM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: RoleRevoked
- Contract Address:0xe5d2...9c3d0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d
Event Data
{
"role": {
"value": "0x5f58e3a2316349923ce3780f8d587db2d72378aed66a8261c916544fa6846ca5"
},
"account": {
"value": "0x043DA37F21c4C83b97b546724c75600c2D0C9E16"
},
"sender": {
"value": "0x043DA37F21c4C83b97b546724c75600c2D0C9E16"
}
}By ZKSync Governance • 2/8/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 55519683
- Timestamp: 2/8/2025, 2:36:02 AM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: RoleGranted
- Contract Address:0xe5d2...9c3d0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d
Event Data
{
"role": {
"value": "0xd8aa0f3194971a2a116679f7c2090f6939c8d4e01a2a8d7e41d55e5351469e63"
},
"account": {
"value": "0xb83FF6501214ddF40C91C9565d095400f3F45746"
},
"sender": {
"value": "0x043DA37F21c4C83b97b546724c75600c2D0C9E16"
}
}By ZKSync Governance • 2/8/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 55519682
- Timestamp: 2/8/2025, 2:36:01 AM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: RoleGranted
- Contract Address:0xe5d2...9c3d0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d
Event Data
{
"role": {
"value": "0xfd643c72710c63c0180259aba6b2d05451e3591a24e58b62239378085726f783"
},
"account": {
"value": "0xb83FF6501214ddF40C91C9565d095400f3F45746"
},
"sender": {
"value": "0x043DA37F21c4C83b97b546724c75600c2D0C9E16"
}
}By ZKSync Governance • 2/8/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 55519680
- Timestamp: 2/8/2025, 2:35:59 AM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: RoleGranted
- Contract Address:0xe5d2...9c3d0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d
Event Data
{
"role": {
"value": "0xb09aa5aeb3702cfd50b6b62bc4532604938f21248a27a1d5ca736082b6819cc1"
},
"account": {
"value": "0xb83FF6501214ddF40C91C9565d095400f3F45746"
},
"sender": {
"value": "0x043DA37F21c4C83b97b546724c75600c2D0C9E16"
}
}By ZKSync Governance • 2/8/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 55519658
- Timestamp: 2/8/2025, 2:35:32 AM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: QuorumUpdated
- Contract Address:0xb83F...57460xb83FF6501214ddF40C91C9565d095400f3F45746
Event Data
{
"oldQuorum": {
"value": "0"
},
"newQuorum": {
"value": "630000000000000000000000000"
}
}By ZKSync Governance • 2/8/2025
Event Details
- Network: ZKSync
- Chain ID: 324
- Block: 55519658
- Timestamp: 2/8/2025, 2:35:32 AM
Governance Info
- Governance Body: ZKSync Governance
- Event Type: IsProposeGuardedToggled
- Contract Address:0xb83F...57460xb83FF6501214ddF40C91C9565d095400f3F45746
Event Data
{
"oldState": {
"value": false
},
"newState": {
"value": false
}
}