Summer 2024 Token Accountability MVP Program Summary

Token Mechanics TPP Builders
1

The Token Accountability MVP Program was launched in June 2024, with the goal to innovate on current token distribution methods.

Developer teams were invited to build token program accountability templates on ZKsync in collaboration with the ZKsync Governance Team. Each template would include a smart-contract connecting the capped minter to an distributor contract.

Program Details

Program Goals:

  • Test the Token Governor prior to ZKsync Governance Launch
  • Migrate current tooling, fork it, or create new contracts that Token Program Proposal builders can use in their proposals.
  • Choose one of two possible paths for the MVP development, or a combination of both:
    • Accountable Streams: Autonomous and continuous token distributions (e.g. X over a period of time to list of addresses, may include increase in flow based on certain criteria).
    • Accountable Milestones: Pre-defined milestone-based token distributions (e.g. X split across specific addresses at A-B-C dates, X per externally validated achieved milestone).

Minimal specifications:

  • Permissions to mint tokens from the Token Governor is assigned to a single contract address with accountability template. In other words, streams or milestone-based permissions are automatically deployed if/when governance proposal is approved.
  • Token distributions must be cancellable and/or subject to clawback if unclaimed. This could be done via an onchain oracle or a proposer-defined accountability council (i.e. multisig oversight).
  • Contract must be immutable, only changeable with significant delay (e.g. 14 days), or subject to accountability council consensus. In short, the proposing token program builder can’t change contract terms unilaterally.
  • Contract must be set as “the target address to mint” by the proposal author, not part of the Token Governor itself. Proposers can choose a contract of their choice.
  • (Optional) token allocations may have eligibility, for example having attestations or roles (e.g. valid KYC at point of asset release, security audit, UX review etc.).

Delivery Requirements MVP

  1. Code uploaded to ZKsync Association Github repository
  2. Onchain smart-contracts on ZKsync Testnet, tested using ZKsync Token Governor
  3. 1-page document explaining the design choices in written prose form
  4. 1-page document with contract specification in written prose form

Program Participants and Selection Process

Potential program participants were identified based on feedback from governance teams across Ethereum, and invited to participate based on the following eligibility:

  1. Aligned values to the ZK Credo
  2. The technology facilitated decentralized accountability
  3. Contracts were already in production on mainnet
  4. Accepted terms of grant (as defined below)

The program gave priority to builders that had successfully deployed on ZKsync (Sablier and Hedgey), and to any builders creating novel mechanics (Hats and MetaLeX). All potential builders had a meeting with the Governance Team to understand their tooling.

Four teams were selected to participate in the program:

  1. Hedgey
  2. Sablier
  3. MetaLeX
  4. Hats Protocol

These builders represented the current diversity of onchain token mechanics: Streaming, Vesting, Legal Accountability, and Roles.

Builders are encouraged to post the recording of their demos in this thread, as well as post an introductory post on the Token Mechanics Builders forum category.

Program Calendar Summary

Kick-off: June 28th 2024

Demo Days:

  • Hats: August 15th 2024
  • Hedgey: August 23rd 2024
  • Sablier: August 22nd 2024
  • MetaLex: November 31st 2024

Teams are requested to post their preferred demo recordings below.

Program Outcomes

The demos helped validate the design of the Token Governor launched on September 12th 2025, and confirm the design of the Capped Minter V1. The outcomes of this work, in combination with feedback from the [TPP-1] ZKsync Ignite Program, informed the design specification for the ZK Capped Minter V2 that was completed in October 2024.

Next Steps

There are no plans for future MVP programs at the moment. However, the Governance Team is able to help with introductions upon request. If you are building a proposal, feel free to reach out to any of these teams, or others working on token mechanics. You can also reach out to the Governance Team to help coordinate an introduction.

4 Likes
2

Thanks for the great summary @rafa! You can find a full guide on the mechanics of Sablier in the context of zkSync, as well as a full guide on how to create a zkSync proposal incuding a Sablier stream here:

1 Like
3

Thanks for starting this thread @rafa

(I wasn’t able to embed images into our post, so sharing a link to our presentation and deck from the program)

Demo: ZKsync Demo Day 3: Hedgy – 2024/08/23 16:59 CEST – Recording - Google Диск)
ZKSync Product Deck: DocSend

I’m Lindsey @ Hedgey. We participated in the TA MVP program to design a new token proposal system for ZK Sync from the ground up.

For context, Hedgey builds free-to-use onchain token vesting, lockups, and streams. We’ve been used by Wormhole, ENS, Arbitrum, Puffer, and hundreds of teams to manage employee, investor, and community distributions. For grants programs, we worked at the ground floor in Arbitrum during their STIP/LTIP program and experienced the human side of operating a grants program, as well as managing the token distribution to ~100 protocols over 9 months.

While we have existing streaming / claiming / lockup tools that are useful today for token awards, for the MVP program we saw the opportunity to leverage our experience along with feedback from the program leaders to design an optimized award distribution system for ZKsync.

Over the course of the program, we designed a smart contract architecture that allows program managers to create pre-issued, unfunded, forwardable distributions funded on an as-needed basis from the ZKsync capped minter contract.

We designed the smart contracts to maximize for transparency during the proposal phase of a program, accountability and control at multiple levels, the ability for recipients to forward on their streams to sub-recipients (which allows for program recipients to fund sub programs,) and add the ability to use Hats protocol to incorporate milestone/criteria based rewards from a program overseer at any/every level (to allow for KYC, milestone criteria, etc).

For the program, we executed a proof of concept via onchain proposal on Tally. (See Deck)

It’s important to note that these contracts were designed specifically for this MVP program and are not audited or at a stage for production level use. While our existing streaming infrastructure is capable of issuing and managing distributions on ZkSync, ultimately we’d love to see the new system go through audit and play a major role in supporting award programs on the network.

At the end of the program we proposed audits for our contracts, creating deeper integrations for Hats Protocol within the product, and designing the UI/UX to support a larger token program on ZKSync running on these contracts.

If you have any questions feel free to DM me here or @ goforlindsey on Telegram.

Cheers!
Lindsey

1 Like
4

Thanks @rafa for starting this thread.

Demo: recorded zoom call
Code: GitHub - Hats-Protocol/zksync-proposer-mvp

My name is Spencer, and I’m one of the cofounders of Haberdasher Labs, a core contributor to Hats Protocol. For those not familiar, Hats is a protocol for onchain roles, aka “hats” aka modular bundles of commitments, permissions/authorities/resources, eligibility criteria, accountability mechanisms, and compensation. Any account can have (“wear”) a hat, including EOAs, multisigs, DAOs, and other contracts.

For this MVP, we used Hats Protocol and several modular components to construct an onchain mechanism with the following properties:

  • A grant recipient is identified by passing a DAO proposal to issue (“mint”) a hat to their account
  • In order to fully receive the hat, the recipient must a) meet the necessary compliance requirements (denoted in this MVP as having been marked onchain as compliant by an authorized KYC provider), and b) commit to a set of policies to which they must adhere by signing an agreement onchain
  • The hat is scoped with the permission allowing its wearer to mint tokens and initiate a Sablier stream
  • At any time, an authorized accountability committee can determine that the recipient has not held to their commitment and revoke their hat
  • Since the stream destination is the hat itself (and not the recipient), this revocation also removes the recipients ability to withdraw any subsequently streamed tokens

One important thing to note is that Hats Protocol can integrate with any other mechanism, protocol, or app. In our mvp, we used Sablier to handle the token streaming, but we could also have used other token distribution mechanisms such as Hedgey, Drips, or FactoryDAO’s depending on the specific needs of the grants program. Hedgey incorporating Hats into their own mvp is a great example of the kind of permissionless composability we love.

This is a key part of our overall strategy and ethos: we embrace composability and have designed all of our technology to be maximally interoperable with other projects. We endeavor to make Hats easy to integrate into other systems.

This mvp was just that, an mvp, and only demonstrated a small slice of what is possible when using Hats Protocol to construct robust onchain mechanisms.

If you are designing a new TPP, we would love to talk with you about how you can use Hats to help bring your vision to fruition.

2 Likes