Hi, you will need a poll option for people to vote for or against the idea for minimal of 3 days. Check if this can be assigned a Zip by the team to then put up for voting.
before setting up a poll I wanted to receive more comments and input from the community on the proposal. Once you set a poll you can’t change the content of the proposal anymore.
That’s great! As long as we know what’s at play.
Thanks for bringing this up. Looking forward to the Dev’s input as reliance on miners and stakers would also be an important point of incentive to maintain network etc.
I have no idea on the impact in terms of overall sustainability on the infrastructure and agree moving ETH to POS will impact much more vs this change.
I support declining inflation for both staking rewards and mining. If we cut staking rewards I’d also like to see the unbonding period removed or drastically shortened though. Lower % apy plus a 12 day unbonding would not be very enticing for new users.
Wow Julian - nice pickup out of the whitepaper. I like it, and makes sense, and is to the vision set out in the whitepaper. I also support declining inflation.
The main question for me - if this is in the whitepaper - is it something that needs to go through a vote?
@Drew im also with you about the unbonding period, but that I believe is already being discussed in here? its better off to not confuse/compound lots of things into 1 proposal.
Im not sure why it never progressed, but it should do in some fashion.
I agree with @darthgus that we should not confuse too many different topics into one proposal. Let’s go one by one. The proposal below is about early unstaking, I think we should discuss about it there:
thank you for the nice words.
Why do we even have to vote for this? Well, you have valid point there. I think it is more about the HOW and not IF this should be implemented.
First of all I would like to thank all of the amazing humans who have had a role in bringing Zilliqa to life. Secondly I’m not sure why this topic has not been brought up sooner. My problem is with the onboarding of new ways to spend your crypto and how more people will find utility in some and hodl others.How will Zilliqa compete going forward? I have been an investor for about two years now so I’ve reaped many benefits that Zilliqa has sowed. I would love to keep going forward with this project to see how it matures, but in all honesty I feel there is a disconnect from milestones delivered and price appreciation from said goals. Is this a bi product of the high inflation rate? Idk for sure. I’m not sure if deflating the issuance going forward will help this project gain traction going forward. I for one feel better about getting your total supply in to circulation as soon as possible. That’s when you’ll get true price discovery. Good luck to all that have read this. You are way ahead of the “curve”.
thank you for your comment.
If we continue the rewards at the current rate, the total supply will be reached in less than three years. This would be a total of 6 years of operation. At this point, all necessary rewards have to be covered by transaction fees.
In fact, Ethereum achieved to gain enough traction within the last 6 years to reach this state. Conservatively speaking, I would not bet Zilliqa can grow at the same pace as Ethereum as it is missing the first-mover advantage in the smart contract platform field.
Considering this, I tend to disagree with you and stick to my proposal to lengthen the reward distribution by reducing the reward issuance - as of course already indicated in the white paper.
With that being said and after 1 week of discussion, I will:
- Add a PRO and CONS section to the proposal based on the feedback provided by you and
- Activate the informal forum voting.
I’ve initiated the forum vote on the proposal.
You have one week for voting to indicate your interest in the proposal. This is the basis for going forward to a snapshot vote.
I noted the voting is live at 1% quorum.
But not sure if it met the original ZIP12 criteria of 20% quorum instead? Or that had been addressed?
Another way to look at it is achieving 2000% before it can be enacted.
First, to state my personal position, I am not against a reduction of inflation.
However, there are a few issues in the proposal I will like to surface out.
Jan 31 may not be realistic as it will need to be timed with the next major upgrade, which will likely not be ready by then. Forcing a premature upgrade or an upgrade containing this change will not be ideal. The timeline should be more flexible. The next upgrade is critical for DApp dev and we will want to properly test it out. i.e Scilla External lib, gas limit adjust, max edges, lots of fixes, improvement etc…
The impact on reduction of staking reward is not well defined. The proposal should clearly quantify it.
Why 1% Quorum? I have trouble to comply with the 20% quorum requirement from ZIP-12 any longer. A lot has changed since ZIP-12, a significant amount of $gZIL is locked in other protocols, e.g. Pillar, and CEXs where it can’t be used to participate in the governance process aynmore.
I do not have an immediate solution to this problem, but there is another thread addressing this issue: https://gov.zilliqa.com/t/revamp-governance-voting-rules-7-days-max-low-quorum/1022
For now, I can only ask you for as much participation as possible no matter of quorum has been met already or not. Maybe we even reach the 2000%
But one thing is clear: We can’t afford a dysfunctional governance process which does not allow us reaching consensus as a community.
thank you a lot for sharing your thoughts with us!
I understand your concerns about the schedule. In fact, 31 Jan, was only used as it is a symbolic date. If a mainnet upgrade is not ready at this point in time, then it is simply not possible. Rigorous testing always has the priority!
In fact, the implementation of the update does not require a specific start date. With the next possible mainnet upgrade the smooth reduction of block rewards will start and should last for the next 20,000 DS epochs.
Do you have any suggestions on the possible impacts of the proposal?
1% quorum is too little. we will end up with problems faced by uniswap community.
I agree the process needs to be revamped but the core team may need more time to revamp the process. We are currently extremely tight and the festive season makes it even tighter.
Streamlining the process, consulting the core team on feasibility, and adjusting quorum is like some of it. Right now, some proposals are not implementable, others have an unrealistic timeline, other is namedrop team members for implementation without consultation with the specific team member.
I am open to suggestions. Ideally, supplement it with dev call and other forms of engagement to come up with a high-quality proposal.
For such a proposal, it will be more ideal to keep the date open and propose the core team provide a monthly update on the progress. Right now, the community might assume it will happen on 31 Jan if the proposal pass and that will backfire hard on the proposal and the community as a whole if it didn’t happen.
As for impact, ideally something like what we did at ZIP/zip-9.md at master · Zilliqa/ZIP · GitHub
Basically, provide an updated table to show the community the impact in a clear and concise manner.
Again, thanks for your proposal. As mentioned, I am not against it, but what I am trying to do is to look at it more holistically and ensure the proposal is clear and balance to everyone.
I hear you that 1% quorum is too little. What do you suggest, 10% ?
After one week of voting, we have reached only 6,79% participation. We also have to consider 26K $gZIL are locked in Pillar protocol and are not able to vote!
I believe the proposal has been already widespread in the community, but may I ask you to retweet my tweet below with the @Zilliqa twitter account for maximum reach? Let’s see how much participation we can get!
the $gZIL community has decided on this proposal. The vote has ended on Dec 29, 2021. With 9,1% participation the 20% quorum has not been met, but under the current circumstances - with $gZIL locked at multiple places where it can not be used to participate in the governance process - a significant amount of participation has taken place. With three weeks being live, everyone who has interest in the future of Zilliqa had time to put their $gZIL to vote.
Breakdown on some $gZIL whales:
ZilSwap DEX: 34.4k $gZIL (6.13%)  ( → can vote, but LPs somewhat sleep on their voting rights )
PILLAR Protocol: 22.5k $gZIL (4%)  ( → can NOT vote )
KuCoin CEX: 9.2k $gZIL (1.65 %)  ( → can NOT vote )
Inactive Wallet: 8.2k $gZIL (1.48%)  ( → forgot about his $gZIL ?! )
Ignite DAO Whale: 4.95k $gZIL (0.89%)  ( → has voted )
CEXIO: 4.6k $gZIL (0.83%)  ( → can NOT vote )
The list might go on, but I stop here.
ZilSwap LP whales:
0x0edf36512b28a4622b583bb9530640995528f1b7 : 3772 $gZIL
0x6acece49dfe686544596c75c64b1a2b7cc1c46b3 : 6959 $gZIL
0x8e2ff2cb199dc2ef8f988065b9315766a29aa355 : 3000 $gZIL
0xa71a7d32762c2db2937897a035907a1ce81b898b : 3208 $gZIL
0xf730d558cc2ed02ee883c232b980bcbf61148aaf : 4415 $gZIL
Surprisingly none of them has voted. Currently, I do not LP my $gZIL so I don’t know if voting while providing liquidity was possible on this vote. But I remember it usually worked.
Long story short, IMHO meaningful participation has been achieved and I consider this vote as successful. Also, as pointed out by @darthgus earlier, as this is in the white paper, a vote on this is not necessarily needed at all.
With respect to implementation of this proposal, I suggest this happens on the next planned network upgrade ensuring meaningful testing of the new feature - the specific date given in the proposal was non-sense.
For: 37.44k $gZIL (73.26%)
Against: 13.63k $gZIL (26.74%)
→ Link to Snapshot
@junhaotan @maqstik Do you agree with that or do you suggest a different way forward?
Thanks for the discussion @yusa. Seems that the quorum has not been met. 1% or <10% is way too low IMO. Especially for crucial decisions like these that directly change the game theory for the economics and security of the network. Perhaps 20% is too high but we can discuss this together. I have also decent amount of gZIL and I didn’t vote because i wasn’t sure yet and needed some time thinking. I was leaning towards no and I spoke to others as well that have a lot of gZIL that were still uncertain. Because people do not vote does not mean that they are not lurking. Decisions like these will have long-term impact for the protocol and the voting period was also very short.
Just as a thought experiment regarding quorum, let’s say there is another vote for an upgrade that 100% of the network fees will go to gZIL and 0 to ZIL. Then 1% - 5% votes on this proposal and the gZIL holders work together to pass it. Should this be approved?
Edit: I will come back soon to write my own concerns with this proposal (not as a Zilliqa team member but as a community member mostly)
Hello! My main concern right now is incentives. Currently miners are incentivized to secure the network and the assumption is that similar to a Bitcoin halvening it will compensate for the price. However, the halvening argument even for Bitcoin, the most robust and advanced network, is still speculative. Plan B’s S2F arguably is almost ‘invalid’ as it still hasn’t gravitated towards 100k BTC (as predicated that would happen around this time). If the security of the network gets in danger we would compromise a lot more. Currently it seems that the proposal is aimed to reduce inflation. I would suggest to perhaps wait a bit till the network is more advanced and there are more transactions on the network (e.g. from XCAD, Lunr, Metapolis etc.) and see how that will go (as this counters the inflation more & more). Also, implementing this will directly take resources from the dev team that could work on other stuff that may be more beneficial. Lastly, network effects around miners can also be useful. Just because miners get rewards doesn’t mean that they are just dumping it. Look at Nano for example. It still isn’t really taking off and is been around for years. A good argument for it is because there is no incentive to run a node and there is no real economy behind it. Miners, as with Bitcoin, are crucial not just from a security point of view but also from a capital point of view to inject inside the ecosystem. Additionally, stakers never like when they receive less ROI so it could also decrease network effects. So I’m still not sure about this. Inflation in crypto, mostly in a bull market, is a catalyst for growth (look at all the (hyper) inflation in DeFi).
Thanks for your update Milan. I voted against, I think it is a good point to wait a little longer and see how things work out. With the huge developments currently in the Zilliqa ecosystem, I also wouldn’t be surprised that transaction fees will counter the inflation. Let’s see how this plays out. The biggest part of my crypto portfolio is staked Zilliqa. I invest my rewards back in the Zilliqa ecosystem.
I will revisit this proposal once the snapshot voting is fixed and $gZIL owners are able to vote across the Zilliqa DeFi landscape. Otherwise, my efforts are simply not worth it.
I understand that it is almost impossible to account for all protocols that are locking up gZIL, especially if more are upcoming. Each contract does gZIL lockup in a specific way and it can’t be generalized.
One possible solution IMHO, if liquidity is owned by a contract, e.g. ZilSwap, Pillar, or XCAD, the voting rights go to the protocol. The community around that protocol is now responsible to vote. In the case of ZilSwap ZWAP holders shall vote on how the gZIL locked up in the ZilSwap contract shall vote on a given vote. This would have a nice benefit to strengthen the value ZWAP token as well, win-win. In XCAD DEX the dXCAD holders are in power and in Pillar and Torch Wallet protocols it will be the respective gZIL stakers themselves. I think this would have a quite inclusive effect on the whole Zilliqa community and ecosystem.
With respect to this proposal: I would be open to discussing the parameters of the proposal, e.g. currently the proposal aims for 0.5B ZIL issuance rate. I think if one could make a trade-off table with three scenarios this would be great.
- Scenario: Stay with the current issuance rate.
- Scenario: Reduce the issuance rate to 1B ZIL annually.
- Scenario: Reduce the issuance rate to 0.5B ZIL annually.
Zil-governance newb, here, but
I’m in favor of this proposal. I’m surprised that this hasn’t been part of the core from genesis, especially if it’s in the whitepaper.
On the gZIL thing, I’m in favor of eliminating it as a force of governance authority completely. Other successful dPoS chains rely on staked(delegated)-value for voting power. Delegated-stake is skin-in-game, while gZIL is just another token for trading.
If we must use gZIL as a governance token, then my suggestion is that it must be resident in the voting wallet in its native gZIL form and not locked in contract. In fact, a method of preventing contract-locked gZIL from voting is needed. Still, I would prefer to use delegated-ZIL (staked value) as the driving governance force.