Forbole has voted “No” on proposal 4. The vote was committed in this transaction:
We voted “No” as we support the issuance of fungible tokens on Cosmos Hub but would like to see another implementation of the proposal.
We support issuance of fungible tokens on Cosmos Hub as:
- It will increase the number of transactions on Cosmos Hub before IBC and validators and delegators will have better economical benefits during this period.
- It creates a platform for Cosmos Ecosystem projects to raise fund by operating token sale on Cosmos Hub. More ideas can be executed via this platform and expand the Cosmos Ecosystem.
However, we disagree on the proposal as:
- Validators and delegators have no obligation to scrutinize any proposed token. Issuance fungible tokens via governance will add another layer of responsibility to the validators and delegators. In a free market, this is not supposed to be the judgement of any of us. Project creators have the rights to propose, Cosmos users have their own rights to study and support individual projects.
- The function of the Cosmos Hub is to connect different hubs and zones. It should keep its internal overhead as low as possible and focus on the throughput in future traffic with other hubs or zones on IBC. While we support the idea of issuance of fungible tokens, we would suggest after issuing the tokens, those tokens should be locked up until the corresponding project is launched. They can then be transferred via IBC to the corresponding zones to achieve the designated utilities. This reduces unnecessary transactions, discourage low-quality token trade and will also avoid spammy projects.
There are still some hours before the end of the voting period and the voting ratio is still relatively low. We encourage every validators and delegators to voice out and submit your vote. Details and updated tally results of proposal 4 can always be found at
Forbole has voted NoWithVeto to proposal 5. We are very happy with exporting the state at height 500,000. However, we strongly disagree with these points in the proposal:
- The IPFS file stated wrong height at point 3 which can cause confusion.
- The genesis time of cosmoshub-2 is too close to the end of cosmoshub-1. The estimated block time of 500,000 will be around 22 Apr 14:40 UTC. It will be less than 3 hours from the proposed genesis time, which is 22 Apr 17:00 UTC. Although having some down time is not a big deal, I believe most validators would like to be online at genesis time.
- The upgrade process on gaia-13002 to gaia-13003 is different from that on the mainnet. It didn’t include state export. In such short time, validators need create the new genesis file, upgrade software and restart the node. I believe it will generate a some problems during the upgrade with those uncertainties. I’m not sure if the community can give enough support during the gap time while it’s the Easter holiday.
We hope Cosmos could be more diversified and inclusive, we suggest
- We do an upgrade practice from gaia-13003 to gaia-14k with state export.
- Have at least 12-hour room for validators to do the upgrade after the upgrade practice.