Capped Minter Framework Update: R&D on Minter Mods and ZK Token Return

Token Mechanics TPP Builders
1

The ZKsync Governance Team (Gov Team) has been working on ways to further strengthen the Capped Minter framework, inspired by:

The following ideas are being researched and developed to expand the framework of capped minters. They use a modular framework for enhanced functionality and automation. As a result, minting contracts can better serve specific needs of Token Programs. The framework includes various “minter mods” as well as a “ZK Token Return.” The ZK Token Return contract allows for the secure return of unused minted ZK tokens from Token Programs.

Master Capped Minter (ZkCappedMinterV2)

The Capped Minter V2 contract was deployed in January (see forum post). This is an upgraded version of the V1, adding the following key additional functionality:

  • Admin and minter role are separate parameters (can be assigned to same address or separate addresses)
  • Manages time-based restrictions by adding start and end time parameters

The foundation of the Capped Minter V2 contract is the original token contract (like ZkTokenV1) which holds the ultimate minting authority through the MINTER_ROLE. This role is typically granted through governance to a Capped Minter V2 contract, which acts as the base minting mechanism with fundamental controls like total supply caps and time-based restrictions.

Introducing Minter Modifiers (”Minter Mods”)

Minter Modifiers, or “Minter Mods,” are additional contracts that can be deployed and connected to a Capped Minter V2. Each Minter Mod is a separate contract that implements specific minting rules or restrictions, and they all follow a consistent interface (ZkCappedMinterV2) that allows them to be composed together. These mods can be stacked in any order, with each one acting as a gatekeeper that must approve before the mint request reaches the CappedMinterV2.

:information_source: Please note that all of the mods and token return contract mentioned below are still being developed. The Gov Team will share contract addresses once they are ready.

  • Rate Limit Mod:
    • This minter mod controls the possible minting frequency. It limits the amount that can be minted from a capped minter per period (hourly, daily, weekly, monthly, etc.).
    • Sample Use Case: For a program that provides participants larger ZK rewards, this allows for a controlled minting rate from a capped minter. No matter how many times “mint” is requested, the contract will only allow a portion of the cap to be minted per period.
  • Delay Mod:
    • This minter mod adds time delay and veto opportunity between a mint request and execution.
    • Sample Use Case: In a self-claiming reward mechanic, this allows for a built-in veto period to deny a minting request from a specific capped minter.
  • Eligibility Mod:
    • This minter mod controls who can mint from a specific capped minter based on holding a specific ERC1155-based token. ERC-1155 was just an initial experiment, but additional eligibility mods could be created to be enable other ERC standard eligibility modules to capped minters.
    • Sample Use Case: In a self-claiming reward mechanic, only participants holding a specific ERC-1155 is able to mint from a specific capped minter.
  • Trigger Mod:
    • This minter mod allows to create a “mint trigger” function on a capped minter. This contract also allows you to assign an immutable target address to a capped minter, so regardless of who mints, the recipient is always the same. The contract accepts a JSON-style configuration that gets converted into the correct function call for .
    • Sample Use Case: The Trigger Mod allows you to automatically create funded vesting plans or streams.

Why have separate mods / factories?

An individual minter mod design is particularly powerful because:

  • Each mod is independent and can be added/removed without affecting others
  • The order of mods can be changed to create different permission hierarchies
  • New mods can be created and added to the system without modifying existing contracts
  • The system maintains a clear separation of concerns while allowing for complex rule combinations

ZK Token Return Contract

As of the moment, minted ZK tokens cannot be sent to the Token Assembly governance contracts as Token Assembly manages token supply, not a treasury of minted tokens. As a result, this inspired the need for a way to be able to “return” minted ZK from a Token Program to the total token supply.

This contract allows the an admin address holding any remaining minted tokens from a Token Program to execute a “return” function. This will transfer the tokens to a ZkTokenReturn contract, which will return the minted but unused tokens to the overall token supply.

As a result, the balance of “minted tokens” on the ZK token contract will decrease by the returned amount, making the supply tokens available for future programs.

Case Study: ZK Token Incentive Program

Minter Mods and the Token Return contracts will be designed in a way that they can be chained together, effectively connecting a minting source (the ZK Token Contract) to layers of flow control such as caps, rate limits, eligibility requirements, delays, and triggers.

Below is an example design for an incentive program that uses the rate limiter mod, Trigger Mod and the Token Return contract. This example incentive program is allowed to mint up to the cap (e.g. 100 ZK). Each season has a rate limit (1 ZK / day) for a specific season allowance (e.g. 10 ZK), that can be minted into a distributor contract to distribute rewards for that season.

  • The rate limit prevents minting of total parent cap available in a single transaction within the defined period. As a result, a executive program steerco can delegate day-to-day operational control to a tactical and season-specific team.
  • The trigger mod allows the season-specific tactical team to automatically deploy necessary distributor contracts. As a result, the season-specific tactical multisig does not hold custody of any minted tokens at any point in the process; tokens are minted and transferred immediately and trustlessly upon contract deployment of distributor contracts.
  • The token return allows the distributor admins to return unclaimed incentives across distributors to the total token supply.
  • As a final action, the executive program steerco calls cancel() on the parent capped minter V2. As a result, minting rights of child capped minters are revoked, and no further unminted ZK can be distributed.
//++++ EXAMPLE MINTER SETUP FOR INCENTIVE PROGRAM ++++//
ZK Token Contract
    │(grantRole(MINTER) via Token Governor)
    â–Ľ
Capped Minter: 100 ZK Program Parent (Program Supply Control)
    │(grantRole(MINTER) via Program SteerCo to Mod)
    â–Ľ
>> *Minter Mod: 1 ZK / Day Rate Limit (Frequency Control)*
    │(grantRole(MINTER) via Program SteerCo to Child)
    â–Ľ
Capped Minter: 10 ZK Season Child (Season Supply Control)
    │(grantRole(MINTER) via Season Operational Team to Mod)
    â–Ľ  
>> *Minter Mod: Trigger Contract (Automation)*
    │(setTarget(_address) via Season Operational Team to Distributor)
    â–Ľ
Distribution Contract
    │(sweepUnclaimed() via Distributor Admin)
    â–Ľ
Unclaimed Token Return
    │ returnAll() Return all unused minted tokens to ZK Token Total Supply
    â–Ľ
ZK Token Contract
    │[FUTURE PROGRAMS] (grantRole(MINTER) via Token Governor)
    â–Ľ

Work in Progress: Minter Mod and Token Return Designs

:warning: WARNING: The governance team has developed a rough sketch of the possible contracts. The initial draft MVP of the contracts have been written internally by the governance team to experiment. They are not fully designed, developed, or tested.

However, the MVP testnet contracts are shared below in the interest of ZKsync governance community knowledge, contribution, and reference. These contracts will change significantly once designs, development, security review, and security audits are complete.

ScopeLift will be serving as the development partner, as a continuation of previous work on the Capped Minter and ZKsync governance contracts.

Work in Progress: Trigger Automation

Factory Labs identified the opportunity for contract triggers as an outcome of their work on the Ignite Program. They are currently in the process of creating a first version of the Trigger Mod. Additional information will be shared once development is complete.

Next Steps

The governance team will continue to design, develop, and test different minter mods and the Token Return contract with the support of technical partners. Over time, the features that provide the most value will be developed further, and the framework will be simplified where possible.

New contract addresses (both mainnet and testnet) will be published as soon as they are viable so anyone can experiment with new mechanic designs. At that point, the code will also be published on the ZKsync Association github repository as a public good for the blockchain protocol governance community.

Feedback is welcome! Feel free to share your thoughts and questions below.

1 Like