What new token mechanics can we envision with the new capped minter?
Over the course of December, the Governance Team has engaged with ScopeLift, FactoryDAO, Hats, Hedgey, and the ZKsync Ignite team to review the functionality of the ZK capped minter. A number of limitations were uncovered, creating friction in token mechanic design and composability.
Based on the outcomes of this analysis, the governance team is happy to announce the deployment of the ZK Capped Minter V2 and its associated Factory contract on ZKsync Era.
The new minter enhances our token governance framework, particularly in the execution of Token Program Proposals (TPPs). We strongly recommend all future TPPs use this version of the minter (V2), 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.
-rafa
Important Links
- ZK Capped Minter V2 Contract
- Source Code: ZkCappedMinterV2.sol
- Example Testnet Era Sepolia Contract Address:
0xd362d551dDC4e2076DEd4eabA6DA9E3bB3752B5D
- V2 Factory Contract:
- Source Code: ZkCappedMinterV2Factory.sol
- Era Contract Address:
0x0400E6bc22B68686Fb197E91f66E199C6b0DDD6a(Link here) - Testnet Era Sepolia Contract Address:
0x329CE320a0Ef03F8c0E01195604b5ef7D3Fb150E(Link here)
- Security Audit:
- Conducted by Offbeat Security: Audit Report
Context and Usage
In our 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]
The ZK Capped Minter V2 expands the limited functionality of V1, where the creator could assign a token, admin, and cap.
Features Overview:
- Minting Cap: Similar to V1, the ZK Capped Minter V2 enforces a strict upper limit on the total number of tokens that can be minted, ensuring controlled token allocations.
- [NEW] Multiple Minters: Uses role-based permissions to manage minting rights, enabling the immutable admin to assign multiple minters for the capped minter.
- [NEW] Nested Minters: As a result of the minter role, token programs can have hierarchies of nested capped minters. This is particularly useful for the creation of sub-programs, or agent-specific minting rights.
- [NEW] Start and Expiration Dates: Adds the ability to arbitrarily set a start and expiration time for a capped minter.
- [NEW] Pause and Cancel Operations: Allows the admin to pause or fully cancel minting activities, providing a safeguard against unforeseen issues. The admin can also assign other addresses to have the power to pause.
- [NEW] Metadata: Allows admin to set a custom metadata URI, allowing each minter to contained additional information related to connected token flows.
- [NEW] Events: Emits onchain events for granting the minter role, minting, cancelling, setting metadata. New analytics and monitoring are possible.
Separation of Roles: Unlike the first version of the capped minter, the admin and minter roles are now separate. Admins still have the ability to assign minting rights, including to the admin themself, but are not granted a minter role by default. This allows a capped minter to be deployed and granted the minter role from the ZK token, while ensuring the admin does not have direct access to the token allocation.
Configuration Parameters
When deploying a new instance of the ZK Capped Minter V2 via the Factory contract, the following parameters must be specified:
- Mintable Token Address (
_mintable): The address of the token contract that will be minted from. - Administrator Address (
_admin): The address granted administrative privileges, including the ability to assign the MINTER role. - Minting Cap (
_cap): The maximum number of tokens that can be minted by this contract. - Start Time (
_startTime): The seconds timestamp from which minting is permitted. - Expiration Time (
_expirationTime): The seconds timestamp after which minting is no longer allowed.
10000000000000000000. Start time and expiration time require uint48 inputs. This means time must be converted to a seconds epoch timestamp. There are online converters available, such as https://www.epochconverter.com/. For example, a start time of Jan 1st 2025 00:00AM UTC would be input as1735689600.
