Token Program Proposals (TPPs)

What is a ZK Token Program Proposal (TPP)?

Token Program Proposals (TPPs) include all proposals submitted through the ZKsync Token Governor. Token Programs assign minting and burning rights of ZK tokens to specified capped minters, activating new mechanics for the ZK token. All TPPs should be aligned with these guidelines and help achieve the goals supporting the vision of the ZK Credo.

Token Programs help ZKsync Delegates launch new ZK token experiments and mechanisms. ZK token mechanics should focus on specific onchain behaviors, such as automatically distributing ZK tokens if certain onchain eligibility criteria are met.

What information should I include in a TPP?

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 ZKsync assets, builders, and community, and what future vision these changes will contribute to. For example, it could be focused on increasing the diversity of assets and number of builders on ZKsync, contributing to a vision of ZKsync as a vibrant economy. Read more here.
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.
- All allocations, including any retroactive rewards for the development of the program’s smart-contracts. These allocations are referred to as "mechanic usage fees".
PLAN: Outline a long-term project plan (for example 6-months to 2+ years) with outcomes, milestones, and deliverables aligned to the ZKsync vision.
- 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 an Accountability Council, Token Streaming Terms, KYC, or staking.

✍️ TEMPLATE: Proposers are encouraged to follow the standard proposal template for Token Program Proposals, available here.

ℹ️ 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.

What onchain actions can I deploy with a TPP?

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.

A proposal can give access to ZK tokens in a variety of ways, depending on the role of the ZKsync Token Governor Timelock contract (0x123...ABCD ). The Governor Timelock can take on roles of MINTER_ADMIN orMINTERto provide access to ZK tokens. As a result, a Token Program Proposal can approve an address to mint ZK tokens or directly mint ZK tokens and send them to a specific recipient.

These onchain actions — minter address approvals and direct mints — are the two primary connectors available to access ZK tokens for a mechanic:

Minter Address Approval: 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.

For more information about the ZKsyncTokenGovernor, Timelock Contract, and ZK Token, you can visit https://github.com/ZKsync-Association. As a reminder, 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.

Onchain Action Example 1: Minter Address Approval for up to 100 ZK tokens

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”
1. ZKTokenGovernor-Timelock acts as MINTER_ADMIN for ZKtokenV2.sol
2. Mechanic_ZKCappedMinter is set as MINTER role of ZKtokenV2.sol
3. MechanicManager is set as ADMIN of Mechanic_ZKCappedMinter
  1. Note: Capped Minter has immutable Cap, which cannot be changed by ADMIN or any other party
Alice's Token Program Proposal has calldata that:
1. Calls _grantRole on ZKtokenV2.sol
2. Assigns MINTER_ROLE to Mechanic_ZKCappedMinter
  1. 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 https://github.com/ZKsync-Association/zk-governance/blob/master/l2-contracts/src/ZkCappedMinter.sol. An example can be viewed on the ZKsync Block Explorer, using the deployment logs which specify the ContractDeployed event with bytecodeHash of 0x0100007911f29707ff4a93ecdc84a682cbc3969469865c43bb233b35c3068b24
  2. 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.

Onchain Action Example 2: Direct mint of 100 ZK tokens

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”
1. ZKTokenGovernor-Timelock acts as MINTER for ZKtokenV2.sol
Alice's Token Program Proposal has calldata that:
1. Sets _mintReceiver as MechanicManager
2. Sets _mintAmount to 100
3. 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.

ℹ️ If you need support drafting the executable proposal code for your proposal, please reach out to the ZKsync Association for support at forum.zknation.io.

Token Program Cancellation

A Token Program can be cancelled by the Token Assembly or the Token Program manager if the program is not performing as expected. If a Token Program is to be cancelled by program managers or the Token Assembly at any point before the end of the program, disbursements for work-to-date should be made at the discretion of the program managers before they lose access to minting rights. After necessary tokens have been minted and distributed to cover outstanding program payments, the capped minters will be deactivated in one of the following two ways:

Cancellation by program manager: Upon decision to cancel the program, the program manager is responsible for the final distribution of disbursements for work-to-date within a reasonable timeframe. After all necessary tokens have been minted and distributed, the capped minters will be destroyed by sending admin rights of relevant capped minters to a burn address. There should not be any unallocated minted tokens from any of the capped minters.
Cancellation by Token Assembly: The Token Assembly may cancel the Token Program by passing a TPP on the Token Governor to revoke the minter role from all capped minters related to the given Token Program. In the event that the Token Program is cancelled by the Token Assembly, by passing a proposal to remove the minter role from all capped minters, the program manager is responsible for making any necessary final distributions of disbursements for work-to-date prior to the end of the timelock period for the relevant cancellation proposal. Upon execution of the proposal no further tokens will be able to be distributed as part of the given Token Program.

ℹ️ All minted tokens from any capped minter in relation to a Token Program need to be allocated as specified, as they cannot be sent back to the Token Assembly.

Proposal Process/Timeline

Please refer to the Token Governor Proposal Process for a detailed outline of the TPP process and timeline.