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.
Cheers,
Julian
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.