Background

ZkCappedMinters (v1) were created to allow ZKsync governance to allocate ZK in an immutable and safe way. The first version of ZkCappedMinter (v1) went live prior to the initial airdrop and served it’s purpose. Immutable and capped token allocations were provided in a safe and secure manner to the governance bodies and ZKsync ecosystem entities.

However, recent governance proposals—such as the Era Ignite Proposal—have highlighted previously unknown limitations of the ZkCappedMinter v1. These limitations have also been validated with recent industry challenges, such as the recall vote from Arbitrums gaming fund.

Limitations and Solutions (Table)

ID Limitation Case Study Story Proposed Solution Open Questions
1 There is no internal contract method to “shut down” or “pause” a capped minter.

Currently, v1 can be cancelled with a Token Assembly vote (~14+ days lead time) or multisig handover to burn address. | A Failed TPP

  1. Alice successfully passes a TPP allowing an Steering Committee (3/5 multisig which she is part of) to mint 100 ZK via a ZkCappedMinterV1
  2. Alice, and the supporting team, does not achieve the necessary metrics to justify the continuation of the token program.
  3. The Steering Committee decides to shut down the failed program, or is requested via a governance vote to cancel the program. | Add closeMinter() method that an admin cal call. This revokes all roles and makes the contract unusable.

Add pauseMinter() method, based on OZ standard that the admin can call. | Should cancel be named something else like terminate? Is there a different naming standard to shut down a contract

What would pause mean in practice? Deny all mint requests? | | 2 | Only ZkCappedMinter Admin (immutable) has power to mint from ZkCappedMinter. | Creating a Sub-Program (Nested Capped Minters)

  1. Alice successfully passes a TPP allowing an Steering Committee (3/5 multisig which she is part of) to mint 100 ZK via a ZkCappedMinterV1
  2. The program requires the allocation of tokens to two parties: Bob’s Service Provider (10 ZK), and Charlie’s Distributor Team (90 ZK). | Add MINTER_ROLE as a separate possible role, set by admin through a grantMinterRole() function.

Add revokeRole() function. | What other design patterns should the capped minter inherit from the design choices of ZK TokenV1?

Should a separate role for “Cancel” and “Pause” be integrated? This would enable a separation of powers (e.g. a delegate council separate from minters could have power to cancel) | | 3 | Those granted the Minter Role of the ZkCappedMinter cannot be assigned a cap separate from the top-level cap. | See Sub-Program (Above) | NO CHANGE: Assign minter rights to a new capped minter, instead of the specific address itself. | | | 4 | Admin role is ALSO (by default) a minter role. | Pure Admin SteerCo (Non-minter)

  1. Alice successfully passes a TPP to mint 100 ZK via a ZkCappedMinterV1
  2. The program has a Steering Committee that oversees Alice as a the primary token mechanic manager.
  3. The Steering Committee is set as admin and shouldn’t be able to mint, only assign minters. | Add ADMIN_ROLE as a the contract manager role, without minting rights. It is set by default to the admin address which is immutable and set at deployment. This role is non-transferrable. | Can we use something like Access Control to manage all roles? | | 5 | Roles cannot be assigned based on token ownership, only specific addresses or contracts themselves. | Extended Eligibility Requirements via Token
  4. Alice successfully passes a TPP allowing them to control access to 100 ZK via a ZkCappedMinterV1, IF they complete KYC requirements.
  5. Alice completes KYC, receives an onchain NFT, attestation, or other role-asset such as a Hat from Hats Protocol. | NO CHANGE: Create helper contract. The Minter Role is assigned to this helper contract which then specifies minting rights based on token ownership and ID. | How does the helper contract inherit ZkCappedMinter admin? How does it verify eligibility based on token ownership? How does it manage ERC1155s vs. ERC721s?

Can this helper contract also split up roles based on cappedminter methods (Minters, Cancel, Pause, etc.) | | 6 | There is no way to reference external data / configurations. | Connecting Legal Metadata to Smart-Contract

  1. Alice successfully passes a TPP to mint 100 ZK via a ZkCappedMinterV1
  2. Alice’s Program Multisig is assigned as admin and minter.
  3. Alice’s Program Multisig becomes part of ZKsync Governance Program Services Legal Entity. | Extend into new hyperlinks by adding metadata mutable parameter set by admin via new method setMetadata and availble to read via readMetadata | What metadata do we think will be used if this is added? | | 7 | Minter rights have no restrictions on how much can be minted per period / phase (e.g. timelock-based caps). | Multi-Phase Program
  4. Alice successfully passes a TPP to mint 100 ZK via a ZkCappedMinterV1
  5. Alice’s Program has 3 phases, each one requiring 10,20,70 ZK respectively. | NO CHANGE: Assign minter role to streaming or vesting contract (e.g. Hedgey, Sablier, Superfluid, Splits, etc.) | How does the helper contract inherit ZkCappedMinter admin? | | 8 | Other security | Research Pending | Example: Add ReentrancyGuard to prevent reentrancy attacks on the minting function? | What improvements are needed, if any, regarding security? |

<aside> ❓

What other limitations should be addressed in the v2 design? If you have ideas, please connect with the ZKsync Association Governance Team.

</aside>

ZK Capped Minter v1 Code:

https://github.com/zksync-association/zk-governance/blob/master/l2-contracts/src/ZkCappedMinter.sol

ZK Capped Minter Factory v1 Code (in Development as of October 11, 2024 )

https://github.com/zksync-association/zk-governance/pull/13/files