Token Program Proposals (TPPs)
Last updated
Last updated
Token Program Proposals (TPPs) include all proposals submitted through the ZKsync . Token Programs assign minting and burning rights of ZK tokens to specified capped minters, activating new mechanics to distribute the ZK token. All TPPs should be aligned with these guidelines to help achieve the goals supporting the vision of the ZK Credo.
ℹ️ Learn more about ZKsync strategic priorities by visiting the and .
Token Programs approved by the Token Assembly deploy token mechanics. Token mechanics are smart contracts executing ZK token allocations based on pre-determined, (onchain) verifiable criteria.
ℹ️ Learn more about token mechanics and TPP standards in the .
are unique smart contracts of the ZKsync ecosystem that allow for “just-in-time minting.” Each capped minter is assigned a maximum number of tokens, known as the “cap,” which is allowed to be minted. Those with the minter role of a capped minter can mint tokens from that supply whenever they choose to, up to the maximum specified.
How is this relevant for governance? Unlike other token launches, not all ZK tokens were minted upon the launch of the ZK token. In other words, there is no token treasury. Instead, the Token Assembly grants minting rights to administrators of Token Programs. The Token Assembly has access to 29.3% of the total token supply, as defined during the token launch. This design removes the risks associated with a large treasury and instead helps shift the agency of token management to the final token recipient.
ℹ️ Token Programs must use the (currently V2) contracts and factory. Once deployed, the contracts and admin multisig (if applicable) must have at least one security review by a Security Council member or reputable security firm.
A ZK Token Program Proposal should include all the necessary information for ZKsync Delegates to make an informed decision and vote on the proposal. The proposal length and detail should align with the scale of the ZK Token mechanic and accountability measures.
All TPPs should include:
IMPACT: Describe how the token program will impact one of the and what metrics it will use to measure success. Please also reference other guiding documents such as a technical roadmap or annual priorities for the Token Assembly.
MECHANIC: Token Programs should deploy self-executing smart-contracts that are designed to distribute tokens autonomously based on predefined conditions or metrics ("mechanics"). Every mechanic should support ZKsync adoption and innovation, and include the following:
A token model that describes how the mechanic uses and distributes ZK to achieve the Token Program objectives. Use this as a template to start with: “This TPP deploys a(n) [Mechanic Type] smart-contract supporting [North Star Metric] that allocates ZK tokens based on [Onchain Action Eligibility/Metric]”
All allocations, including:
Program Rewards: ZK being distributed to qualifying participants
Proposal Success Rewards: Token allocations as a reward for code development, code audits, and coordination efforts leading to a successful vote on the proposal.
Mechanic Usage Fees: Token allocations necessary to cover the program’s smart contracts fees over the course of the program.
Administration: Token allocations related to SteerCo member participation, program monitoring, and other management.
PLAN: Outline a long-term project plan (for example 6-months to 2+ years) with outcomes, milestones, and deliverables aligned to the ZKsync Governance North Star, endorsed ZKsync Strategic Priorities, and the ZK Credo.
Specify KPIs supporting those outcomes and the overarching vision of the Token Program. Include how those KPIs will be measured (e.g. onchain, elsewhere).
Explain the permissionless pathways available for public participation. For example, address questions like: how is the program composable?, what standards does it follow?, will there be a public communication channel?, and what projects are available for contributors?
ACCOUNTABILITY FRAMEWORK: Specify what methods will hold the program, mechanic, operations, and participants accountable for their commitments. For example, this can include items such as a Steering Committee, Token Streaming Terms, staking, or contracting with ZKGPS (l).
ℹ️ NOTE: All documentation should be included in the onchain proposal, or include links to an onchain source such as Arweave, IPFS, etc. This allows the proposal content to be public and accessible across web3 applications.
Delegates need to include the appropriate onchain action in their proposal to successfully connect ZK tokens to a Token Program mechanic. An onchain action is represented by a hexadecimal value known as calldata. The calldata, or executable payload, instructs the ZKsync Token Governor Timelock (further details linked below) to give access to ZK Tokens.
The approval of a Token Program Proposal allows a specified address to mint ZK tokens (up to the capped amount) or mint and directly transfer them to a designated recipient. This is done by granting the MINTER role to the address of a designated capped minter via the Token Governor Timelock.
Minter Address Approval (most common): Token Governor acts as MINTER_ADMIN. The Delegate proposer specifies an address, such as a ZkCappedMinter contract, to act as MINTER. A specific agent (individual, entity, or autonomous code) represented by an Ethereum address can then mint tokens via the approved address.
Direct Mint: Token Governor Timelock contract acts as MINTER. The Delegate proposer specifies the recipient of the ZK Token (_mintReceiver) and the ZK Token amount (_mintAmount). The Token Governor then mints tokens directly to that address.
ℹ️ Proposals will be removed from the ZKsync Governance Portal if they enable access to ZK tokens by prohibited addresses, including those associated with sanctioned entities, individuals, or jurisdictions, as well as addresses linked to illicit activities like fraud, money laundering, terrorist financing, or other criminal enterprises.
Minter Address Approvals are expected to be the most common method to access ZK tokens. Minter Address Approvals allow specific mechanics to mint tokens on demand. By minting on demand, mechanics reduce dependencies on custodial services. Minting on demand can also have other benefits, such as reducing security risks, ensuring that the tokens have a clean history, and allowing recipients to choose the time and place of minting, which may help them clarify the tax treatment of their tokens.
Example Proposal:
Alice submits a Token Program Proposal for Minter Address Approval. If the proposal is approved, then “MechanicManager can Mint a maximum of 100 ZK”
Mechanic_ZKCappedMinter is set as MINTER role of ZKtokenV2.sol
MechanicManager is set as ADMIN of Mechanic_ZKCappedMinter
Note: Capped Minter has immutable Cap, which cannot be changed by ADMIN or any other party
Alice's Token Program Proposal has calldata that:
Calls _grantRole on ZKtokenV2.sol
Assigns MINTER_ROLE to Mechanic_ZKCappedMinter
The Mechanic_ZKCappedMinter parameters would be set as follows for this proposal:
TOKEN = [ZK Token Contract];
ADMIN = MechanicManager;
CAP = 100;
If Alice's proposal passes, then MechanicManager can mint 100 ZK tokens through the Mechanic_ZKCappedMinter after the proposal transaction is executed onchain.
Direct minting should be used if the mechanic requires ZK tokens to be immediately minted. For example, a novel Token Program Proposal may require staked ZK tokens at inception, or swapping ZK tokens for another digital asset immediately upon proposal approval.
Example Proposal:
Alice submits a Token Program Proposal for Direct mint. If the proposal is approved, then “MechanicManager receives 100 ZK”
ZKTokenGovernor-Timelock acts as MINTER for ZKtokenV2.sol
Alice's Token Program Proposal has calldata that:
Sets _mintReceiver as MechanicManager
Sets _mintAmount to 100
Calls _mint(_mintReceiver, _mintAmount)
If Alice's proposal passes, then MechanicManager receives 100 ZK tokens when the proposal is executed.
Should Alice be assigned the ADMIN role of the MechanicManager, then Alice can manage funds as specified in the MechanicManager.
A Token Program can be cancelled by the Token Assembly or the Token Program managers.
Onchain cancellation by Token Program managers:
Cancellation Process: Program Managers deactivate capped minter contract according to its version:
CappedMinterV1: Transfer control of all capped minter admin multisigs to the burn address. To transfer control of a multisig to a burn address, propose a transaction that adds the burn address as the sole owner (0x0000000000000000000000000000000000000000). Then, in either the same or a following transaction, remove all signers except the burn address. Since no one controls the private key, no future actions are possible.
CappedMinterV2: Call the cancel method on the contract to permanently revoke all roles.
Prior to onchain cancellation: All final token disbursements, legal contracts review, and forum communications should be completed prior to on-chain cancellation.
Forum Communication: The Token Program manager should provide a clear rationale for the cancellation of the program via the official governance forum. The communication should include relevant timelines. Program cancellation plans should be shared a month in advance.
Legal Contracts Review: Token Program managers are responsible for liaising with the ZKsync Association and ZKGPS to review the program’s legal agreements. For example, to terminate applicable service-provider contracts.
Final Disbursements: Token Program managers must execute final disbursements for any work completed to date, ensuring distributions are made within a reasonable timeframe. All tokens minted under a Token Program's capped minter must be allocated according to the terms of that program. Unallocated minted tokens cannot be returned to the Token Assembly. Program managers should publish a detailed accounting report detailing all final allocations to all program service provider and token program participants.
Onchain cancellation by Token Assembly:
Cancellation Process: Submit and execute a TPP onchain to revoke the ZK Token minter role from active capped minters for specific program. The proposal should provide a clear rationale for the cancellation of the program.
Prior to onchain cancellation:
Forum Communication: The ZKsync Delegate submitting the proposal should follow the standard guidelines in proposal submission, including publishing a forum post with the program cancellation proposal details.
Legal Contracts Review: If quorum is met and approval is expected, Token Program managers are responsible for liaising with the ZKsync Association and ZKGPS to review the program’s legal agreements. For example, to terminate applicable service-provider contracts.
Final Disbursements: If quorum is met and approval is expected, the Token Program managers are responsible for executing final disbursements for work-to-date prior to the execution of the cancellation proposal onchain. Upon execution of the cancellation proposal, no further tokens may be minted under the canceled Token Program. All tokens minted under a Token Program's capped minter must be allocated according to the terms of that program. Unallocated minted tokens cannot be returned to the Token Assembly. Program managers should publish a detailed accounting report detailing all final allocations to all program service provider and token program participants.
The ZK token is an ERC20 token and is compatible with common web3 tools. To better understand the possibilities in autonomous token flows, you can connect with organizations such as:
✍️ TEMPLATE: Proposal authors are encouraged to follow the . ✍️ MULTISIG CONFIGURATION: All multisigs related to Token Programs must conform to industry best practice.
For more information about the ZKsyncTokenGovernor, Timelock Contract, and ZK Token, you can visit .
ZKTokenGovernor-Timelock acts as MINTER_ADMIN for ZK token contract ()
The Mechanic_ZKCappedMinter is a separate smart contract deployed prior to proposal submission. To ensure quality of the smart contract, Mechanic_ZKCappedMinter bytecode hash should match . An example can be viewed on the , using the which specify the ContractDeployed event with bytecodeHash of 0x0100007911f29707ff4a93ecdc84a682cbc3969469865c43bb233b35c3068b24
ℹ️ If you need support drafting the executable proposal code for your proposal, please reach out to the ZKsync Association for support at .
Please refer to the for a detailed outline of the TPP process and timeline.
Token programs are intended to be for mobilizing large and long-term mechanics, not grants. In other words, token programs should launch self-executing smart contract designed to distribute tokens autonomously based on predefined conditions or metrics. If you have an idea for a grant, transform it into a ZK token mechanic supporting a specific .
Drips ()
Hedgey ()
Hats ()
MetaLex ()
Merkl ()
Sablier ()
Superfluid ()
ℹ️ You can also check out the section of for more potential technical tools and partners for token mechanic development.
