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.
Capped Minter V2 Deployment & Verification Instructions
Added Mar 21, 2025
Step 1: Deploy Capped Minter
- Go to the CappedMinter V2 Factory
- Select “Contract” and “Write”
- Connect your wallet
- Specificy the parameters for the capped minter V2 being deployed:
- Mintable Token Address (
_mintable): The address of the token contract that will be minted from. - Administrator Address (
_admin): The address granted administrative privileges, including the ability to assign the MINTER role. - Minting Cap (
_cap): The maximum number of tokens that can be minted by this contract. - Start Time (
_startTime): The seconds timestamp from which minting is permitted. - Expiration Time (
_expirationTime): The seconds timestamp after which minting is no longer allowed. Please note that any child capped minters will expire on the specified end date of a parent capped minter.
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.
- Select “Write” in the bottom left. This will generate a transaction hash.
- After the transaction is confirmed, go to the event log (”Events”) of the factory to find address of capped minter. Double check the transaction hash next to address to make sure you have the correct one.
Step 2: Verify Contract
In Command Line
- Set your working directory: Customize as needed, this is where you will copy the contracts and build the folder system for the code
cd Documents/Dev/
- Clone the repo where governance contracts are managed
git clone https://github.com/zksync-association/zk-governance.git
- (Optional) Install Hardhat
npm install --save-dev hardhat
npm install --save-dev typescript
- Change directory to L2 governance contract working directory
cd l2-contracts/
- Set default network
- // Change default network to zkSyncEra
- // (IF TESTNET) Change default network to zkSyncTestnet
nano hardhat.config.ts
- Compile contracts
npx hardhat compile
- Verify Contract
- npx hardhat verify [contract address] [token] [admin] [cap] [starttime] [expirationtime]
- Change your parameters as needed
EXAMPLE:
npx hardhat verify 0x721b6d77a58FaaF540bE49F28D668a46214Ba44c 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E 0x77CC0A0582475bfD74CD838610e817d05c181E11 8301475000000000000000000 1736899200 1752537600
