The Governance Team is excited to announce the announce the deployment of the ZK Capped Minter V3 on ZKsync Era. The Governance Team worked with ScopeLift to deploy this new minter that enhances the token governance framework, enabling even more flexibility in the deployment and execution of Token Program Proposals (TPPs). We strongly recommend all future TPPs use this version of the minter (V3), which allows for greater flexibility.
Let us know if you have any questions! We look forward to seeing how the new functionality expands the possibilities of ZKsync governance Token Programs.
Important Links
- ZkCappedMinters (v3) contracts: zkminters/src/ZkCappedMinterV3.sol at main · zksync-association/zkminters · GitHub
- ZkCappedMinters (v3) factory source code: zkminters/src/ZkCappedMinterV3Factory.sol at main · zksync-association/zkminters · GitHub
- Security Audit: zkminters/audits/ZKCappedMinterV3.pdf at main · zksync-association/zkminters · GitHub
To understand how to deploy a capped minter, please visit Capped Minters 101.
Background
In the ZKsync governance framework, Token Program Proposals (TPPs) are instrumental in assigning minting and burning rights of ZK tokens to specified capped minters, and activating new token mechanics. [ZK Nation Docs]
ZkCappedMinters (v3) expands the functionality based on limitations experienced using ZkCappedMinters (v2) that was introduced in January 2025. These limitations included:
- Frictions with deployment and configuration
- Lack of transferability of program mechanics structures to new parent capped minter if first parent’s cap is reached or expired
ZkCappedMinters (v3)
ZkCappedMinters (v3) introduces solutions for the limitations of the ZkCappedMinters (v2). The ZkCappedMinter (v3) will replace v2 as the new standard for capped minter deployment for Token Program mechanics. The v2 will still be available, but is not encouraged to use.
ZkCappedMinters (v3) has the same capabilities as v2, with the addition of:
- Transferable admin rights: Transfer admin role to enable more flexible deployment configuration & admin management
- Case Study 1: Alice deploys a capped minter, and corresponding mods on behalf of a token program administrator. Upon completion of initial quality control, Alice transfers admin controls to program administrator.
- Case Study 2: In the case a program admin needs to step down during a program, the admin address can be transferred to a new admin address
- Updatable MINTABLE address: Transfer minting source of a program mechanic or capped minter if original source reaches the minting cap
- Case Study 1: A program is a success and should continue, despite the current parent capped minter cap being reached and no new funds available. Instead of redeploying a new mechanic, pass a TPP with a new parent capped minter to fund the current program mechanic, and update all children and minter mods to point to new parent capped minter.
- Case Study 2: A token mechanic is deployed with a parent, a minter mod (e.g. rate limiter) and a few children. It is discovered during the program that it would make more sense to have a delay mod instead of a rate limiter as the minter mod between the parent and children. The new minter mod can be deployed and the mintable address from each child can be updated to the new minter mod address.
Security Considerations
The ZKsync Security Council should be granted the pauser role on all v3 capped minters and transaction monitoring should be setup to monitor transactions that changes admin or mintable addresses.
Please consult the ZKsync Governance Team to help determine the best option for a mechanic design.