The following post was drafted by the ZKsync Governance Systems Team and aims to help the community better understand TPPs. The information included below is based off of questions that have been asked in the first few weeks after the launch of the ZKsync Governance System.
What are Token Program Proposals (TPPs)?
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 are a new way of thinking about adding new token utilities and providing access to the Token Assembly’s ZK token allocation. Instead of a single transfer (“bucket”) of tokens, the ZKsync community can deploy smart contracts that execute allocations of tokens based on meeting specified metrics (“Token Mechanics”). In other words, the Token Assembly can build pipes that autonomously mint and allocate tokens to projects, users, and organizations that meet certain requirements and/or achieve specific KPIs. In this way, Token Program Proposals add more specific, functional token allocation infrastructure, rather than function as unilateral distributions.
How should Delegates review and assess TPPs?
The program uses one or more ZkCappedMinters AND has at least one autonomous token allocation process (smart contract) or utility extension. For example, staking contracts, merkle distributors, etc.
The allocation of ZK tokens is tied to North Star metrics (Security, Assets, Builders, or Community). The relationship to the North Star metrics is specified in the proposal.
The proposed Token Program has an accessible application process. It is either a competitive RFP or an open participation mechanic.
All possible beneficiaries are not known. In other words, any team or individual who meets program requirements should be able to apply and participate.
The proposal and program operations have a fully public disclosure of specifications (all information from the proposal is public, with no background agreements)
The proposal builds open-source products to benefit the entire ZKsync ecosystem. Unless a specific exception is needed, this code is hosted on/uploaded to the ZKsync Association Github to increase accessibility and use in future programs.
The proposal creates a feedback loop, producing demand for the ZK token via new utility.
The TPP does not aim to fund a one-off event, especially with private commercial interests. Example: “Allocate 50k ZK for Alice’s Hackathon sponsorship”
The TPP does not benefit a single party, especially with private commercial interests. Example: “Allocate 100k ZK to build proprietary code that only works with Bob’s Company”
The Token Program is not for a speculative unproven product, business, or MVP. Example: “Allocate 50k ZK tokens for Charlie’s Team to build a proof-of-concept of an application.”
How do you transform a Token Transfer specification into a Token Mechanic specification?
Token Programs require reframing terms and mechanisms that have become typical for onchain organizations.
How can the ZKsync community push that envelope to develop new, neutral and verifiable allocation mechanisms to allocate ZK throughout the ecosystem?
It’s time to think onchain. Try starting with “Deploy a smart contract” and describe the token allocation methodology.
Instead of: Creating a “grants program”
Try: Deploy a smart contract that allocates ZK to individuals or teams that developed proven ZKsync smart contracts (no MVPs/speculative solutions) if they meet specific milestones.
Instead of: Fund a hackathon, community Happy Hour, meetup event
Try: Deploy a smart contract that allocates ZK to participants who meet specific eligibility criteria (e.g. won X hackathon).
Instead of: Fund (retroactively) a specific project for their work
Try: Deploy a smart contract that allocates ZK to a community-curated list of active projects on other chains that successfully deploy on ZKsync, as a percentage of the project’s development and auditing costs.
Instead of: Fund a specific entity to integrate/deploy
Try: Deploy a smart contract that allocates ZK for a competitive RFP process to build a public utility addressing major integration friction points, benefitting all builders in the space.
Instead of: Individual service provider engagements (probably governance-related)
Try: Deploy a smart contract that allocates ZK to the best solution (a Prize) for a specific problem/need. For example, the best interface for protocol upgrades submitted in the next 6 months. (best needs to be defined in KPIs).
Instead of: Anything relating to marketing
Try: Deploy a smart contract that allocates ZK tokens within a program to support marketing, based on metric achievement.
What are examples of Token Mechanics?
Token mechanics are not new. Many teams have experimented with autonomous token mechanics. Here are a variety of notable examples from across the Ethereum community:
- Quadratic Token Allocations (Gitcoin)
- Curated Registries (Protocol Guild)
- Token Contests (JokeRace)
- Oracle-based Distributions (Chainlink)
- Retroactive Public Goods Funding (Optimism)
- Token Staking (Tally Protocol)
- Augmented Bonding Curves (Commons Stack)
- Token Swap Auctions (Nouns)
- Automatic Grant Flows (Nouns)
- Token Access Roles (Hats)
- Automatic Dependency Streams (Drips)
- Vesting Contracts / Token Timelocks (Hedgey)
- Token Streams (Superfluid, Sablier)
- Token Splits and Royalty Systems (0xSplits)
- Token Prize Pools and No-Loss Lottery Systems (PoolTogether)
- Liquidity Pools (Uniswap)
- Encrypted Prizes (Autonomous Worlds)
There are undoubtedly many more. As you think about ZKsync, the question should be which mechanics (individually, composed together, or completely new) can be deployed in support of North Star metrics.
Describing a Token Mechanic
Here is an initial template to brainstorm token mechanics:
Deploy a(n) [Mechanic Type] smart-contract supporting [North Star Metric] that allocates ZK tokens based on _[Onchain Action Eligibility]
EXAMPLES:
- Deploy an Augmented Bonding Curve smart-contract supporting Asset Depth on ZKsync that allocates ZK tokens based on long-term liquidity of DeFi protocols who meet XYZ criteria
- Deploy a Curated Registry smart-contract supporting Independent ZKsync Community Developers that allocates ZK tokens based on attested contributions to protocol upgrades approved through the Token Governor
- Deploy an Encrypted Prize smart-contract supporting Protocol Security that allocates ZK tokens to solve an unsolved MEV problem
How can I get support with TPPs?
There are a lot of aspects to consider when creating and deploying a Token Program. Please read the TPP Guidelines and take a look at the proposal template.
The Gov Team is also working on evolving the documentation on TPPs and adding additional tooling/resources to make launching a Token Program more accessible. A few things the Gov Team is currently working on:
- Documenting additional details and order of operations to launch a Token Program
- Creating a “ZkCappedMinter Factory” to make deploying ZkCappedMinters simple for everyone
- Drafting a proposal code template to make it clear what needs to be in the call data for these proposals
- Creating testnet examples of a variety of token mechanics to enable experimentation
If you have any questions or need support sorting out the details of a TPP, please contact Rafa or Shelby from the Gov Team.