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, 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.
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
orMINTER
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 asMINTER
. 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”
ZKTokenGovernor-Timelock acts as
MINTER_ADMIN
for ZKtokenV2.solMechanic_ZKCappedMinter is set as
MINTER
role of ZKtokenV2.solMechanicManager is set as
ADMIN
of Mechanic_ZKCappedMinterNote: 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.solAssigns
MINTER_ROLE
to Mechanic_ZKCappedMinterThe 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 withbytecodeHash
of0x0100007911f29707ff4a93ecdc84a682cbc3969469865c43bb233b35c3068b24
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”
ZKTokenGovernor-Timelock acts as
MINTER
for ZKtokenV2.sol
Alice's Token Program Proposal has calldata that:
Sets
_mintReceiver
as MechanicManagerSets
_mintAmount
to100
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.
Proposal Process/Timeline
Please refer to the Token Governor Proposal Process for a detailed outline of the TPP process and timeline.
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.
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 (https://hedgey.finance/)
Merkl (https://merkl.angle.money/)
Superfluid (https://www.superfluid.finance/)
Drips (https://www.drips.network/)
Sablier (https://sablier.com/)
Last updated