[ZIP-12] Standardisation of ZIP processes


The purpose of this proposal is to standardise the Zilliqa Improvement Proposal (ZIP) introduction, voting, and implementation process that governs the Zilliqa protocol.

Snapshot Voting link



  1. All proposals must be discussed for at least 3 days with a forum poll before they will be assigned a ZIP number and move to Snapshot voting.
  2. The Snapshot vote requires ≥ 30 $gZIL to initiate. It will be binding, and must be open for at least 7 days. At least 20% quorum must be reached, and more than 50% of those votes must vote “For” the proposal for it to pass.
  3. Most open-source protocol updates do not require ZIPs; this process only governs those changes or proposals that wish to be discussed and enacted as ZIPs.


This proposal formalises the process for introducing, voting, and implementing ZIPs. Valid proposals are to be discussed for at least 3 days on Zilliqa’s governance forum[1] and include a forum poll to gauge sentiment. If after at least three days there is a 25% “For” vote in the forum poll it may then move to formal voting via Snapshot. In order for a vote to pass it must have a quorum of > 20% of the token total supply and a majority support of > 50% of the minimum quorum, after at least five days of voting. Following a successful vote, necessary changes will be implemented by Zilliqa’s protocol team and the network’s upgrade timeline will be announced after the implementation is completed. Changes to this policy, including quorum requirements or what constitutes a majority vote, can only be enacted by a valid ZIP that overwrites this policy.


Although there are several informal standards governing the ZIP introduction, voting, and implementation process there is no single, clear policy. ZIP 0[2] outlined this process, but it focused largely on the proposal only after it has transitioned to the voting/ZIP stage, and was enacted when all voting was on-chain. So far, no ZIP or formal policy has been implemented that specifies votes conducted via Snapshot are formal and binding. This ZIP would define and formalise the process in order for proposals to be valid and binding, and reduce any confusion in the ZIP introduction and voting process.


Introducing the ZIP

In order to submit a potential ZIP for voting a user must first create a thread for the proposal on the Zilliqa governance forum[1]. Complete the auto-populated fields that appear when creating a proposal on the forum. A screenshot of these fields are below:

Here are some pointers on how to create a proper proposal:

  • Stick to the auto-generated template.
  • Write concise title with no number. The number will be added by mods once on-chain voting starts.
  • Add understandable aka non-tech aka ELI-5 summary.
  • Add an abstract: what will be done if the ZIP is implemented (keep it below 200 words).
  • Write a longer motivation with links and references if necessary.
  • Add specifications if necessary.
  • Formulate clear For and Against positions.

Additionally, the thread should include a poll from the governance forum to gauge interest from the wider governance community. This poll must be conducted using Discourse’s native poll. After the thread has been on the governance forum for at least 3 days and has received > 25% “For” votes, it can proceed to formal voting via Snapshot. This allows the community to suggest potential changes to the proposal before it moves to the formal voting phase on Snapshot. Please do not assign your proposal a ZIP number; numbers will be assigned by moderators prior to a vote taking place.

If a proposal was introduced on the governance forum and achieved at least a 25% “For” from the poll, but is not submitted to Snapshot within 30 days, the author of the proposal must re-submit the proposal to the governance forum and restart the process. This ensures that proposals that previously received support from governance still retain support from the community.

Formal Voting Phase

Snapshot is used for formal, binding votes. The user who authored the ZIP will also create the proposal on Snapshot[3]. Snapshot requires > 30 $gZIL[4] in a user’s wallet to create a proposal. If the author does not meet this requirement, then contact a moderator who will submit the proposal on your behalf. Before creating the Snapshot vote, please wait for a moderator to assign your ZIP a number and begin your Snapshot title with it.

A minimum of 168 hours (7 days) for voting, and a 20% quorum requirement is required for ZIPs voting processes. This wide time period for voting, coupled with an active communication of ZIPs via the governance forum and on social media channels should help ensure that no ZIPs slip by and no malicious ones are approved.

The block selected for the Snapshot vote will be block number at the Snapshot submission. In order for a vote to pass it needs to have a majority approval (>50%) by the minimum quorum required. The eligible vote is defined as $gZIL held in the wallets to the token holders at the snapshot block. If the Snapshot vote does not meet > 50% majority approval, then the vote is rejected and no changes will be enacted. Authors of proposals that are rejected may resubmit their proposal, but should include significant changes that address issues that may have prevented the ZIP from passing during the initial vote.


This specification aims to clarify which proposals should move to the ZIP stage, how long they should be discussed for, and how long the vote should be open for. By only allowing proposals to move to ZIP/voting after several days of discussion, we ensure that everyone’s voice is heard, and proposals should more accurately reflect community consensus.

Additionally, while some may think that 3 days is too short to adequately discuss a proposal, this is simply the minimum requirement. We expect most discussions to last for significantly longer than this, with only a select few well-planned and researched proposals with near unanimous approval moving through so quickly. This proposal also will not stifle the open source protocol improvements that are made daily by dozens of Zilliqa’s contributors. It only aims to govern those proposals that seek community feedback and ratification as ZIPs.

Other Uses for Snapshot

Snapshot may still be used for informal signal voting, including community contests, but its primary purpose will be to conduct formal and binding votes.


  1. https://gov.zilliqa.com/
  2. ZIP/zip-0.md at master · Zilliqa/ZIP · GitHub
  3. https://governance.zilliqa.com/
  4. gZIL Governance Token | ViewBlock
Proceed to vote on [ZIP-12]
  • For
  • Against

0 voters


Excited to see this underway! Curious where a the users voting record be displayed within the profile?


25% of what total? registered users on this forum? what if only 20 people sign up for forum??


Yes, voting record would be great, also maybe add some kind of user activity level.


Why do I get a vote just for creating an account? Shouldn’t I have to cross verify this with some gzil ownership?


Hi Matt, all the user’s voting record will be recorded on the IPFS server, and then displayed on the Snapshot voting portal. There is no voting history page for a particular user’s account though, you are only able to see your votes for all past proposal that your participated.

1 Like

This is a signalling vote. It is non-binding. All ZIPs must go through this platform to garner enough interest in order to move on to the formal, binding voting process that will take place on Snapshot. Once there, the vote weightage will be 1 $gZIL = 1 vote. You will need a Proof-Of-Balance to sign off your vote.


Yes, 25% of the total vote signalling interest “For” the proposal. After this discussion & signalling phase is completed, we can move on to the formal, binding voting process on Snapshot.


Hi there,
What happens to gZIL that one uses for voting? Does it get locked for the duration of the voting period?
EDIT: Does any of it get burnt

1 Like

A snapshot will be taken a certain block. It captures your $gZIL holding. When you submit your vote, no $gZIL will be consumed. You will be signing over your vote and submitting to IPFS. From there, the governance portal compute the amount of vote you casted based on the $gZIL at block number when the snapshot is captured.


Voting is off-chain. So, gZIL does not even move from the owner’s wallet.


I think the voters should be charged a small amount even 0.001 gZil, so that no one abuses the voting system and only productive proposals are brought forward as well as the voting is done in a useful way.

1 Like

Any abuse of the system is prevented at three levels:

  1. Signalling on forum: No proposal can be put to a formal vote unless it has been first discussed on the forum and has garnered sufficient positive signals, i.e., 25% of the signalling votes must be “FOR” the proposal.

  2. Putting the proposal to formal voting on the Governance Portal: Even if someone is able to garner enough signalling votes, he must have at least 30 gZIL to be able to put that proposal to a formal vote.

  3. Quorum: In order for any formal voting on the Governance Portal to be valid, the total number of Yes and No votes must be 20% of the total gZIL supply captured in the snapshot.


That makes me feel very positive about the future of the project. Godspeed.

1 Like

Why wouldn’t it be 50% of signalling votes need to be ‘FOR’ the proposal?

I guess it can also be changed through proposal and voting, in future.

Yeah that’s what this forum is for. Well that’s the way I read it. This proposal is put forward and is discussed on the forum for 3 days before being sent

1 Like

Exactly! So, it is a no-brainer. :wink:

The argument is that signalling votes and the actual binding votes will be very different as the people who can vote will be different. (On the forum anyone can participate, on the portal only $gZIL holders have a say)

If there is enough people signalling “FOR” (currently set at 25% of total votes), then we will say the proposal is contentious enough to go into the formal voting phase to make the proper, final decision.