# 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](https://github.com/zksync-association/zk-governance/blob/master/l2-contracts/src/ZkTokenGovernor.sol). Token Programs assign minting and burning rights of ZK tokens, 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 \[LINK TO NORTH STAR] * 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. Proposers are encouraged to follow the standard proposal template for Token Program Proposals, available [here](https://github.com/zksync-association/governance-resources/blob/main/proposal-templates/02_tpp_template_token_governor.md). > ℹ️ *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` or`MINTER`to 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 . 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:** 1. 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 2. 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 . An example can be viewed on the [ZKsync Block Explorer](https://era.zksync.network/address/0x00D3dc9676572d04665A64Ee72A78cF0358F6382#code), using the [deployment logs](https://www.notion.so/FINAL-Token-Governor-Proposal-Submission-Guidelines-NEW-SUBPAGE-1d697013caf546dabbebb9f8aeaefecd?pvs=21) which specify the `ContractDeployed` event with `bytecodeHash` of `0x0100007911f29707ff4a93ecdc84a682cbc3969469865c43bb233b35c3068b24` 2. The Mechanic\_ZKCappedMinter parameters would be set as follows for this proposal: 1. TOKEN = \[ZK Token Contract]; 2. ADMIN = MechanicManager; 3. CAP = 100; 3. 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:** 1. 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 2. Alice's Token Program Proposal has calldata that: 1. Sets `_mintReceiver` as MechanicManager 2. Sets `_mintAmount` to `100` 3. Calls `_mint(_mintReceiver, _mintAmount)` 3. If Alice's proposal passes, then MechanicManager receives 100 ZK tokens when the proposal is executed. 4. 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](http://forum.zknation.io/). ### Proposal Timeline/Process Please refer to the [Token Governor Proposal Process](https://docs.zknation.io/zksync-governance/schedule-1-standard-governance-procedures#id-4.-token-governor-proposal-process) for a detailed outline of the TPP timeline and process. ### Other Frequently Asked Questions #### Are token programs the right channel to ask for grants? 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 [ZKsync goal and KPI.](https://www.notion.so/FINAL-ZKsync-Governance-North-Star-NEW-SUBPAGE-f17b43f594bc467da62bef566cb48778?pvs=21) #### What tools are available for token mechanics? 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: * Hedgey () * Hats () * Merkl () * Superfluid () * Drips () * Sablier ()