After giving it some consideration, Sikka is going to vote NoWithVeto for a couple of reasons.
-
The Cosmos Hub is intended to be a relatively lightweight chain focused on being a secure hub and optimizing for IBC transfers and other hub-specific functionality, such as peg zones, shared security, etc. Issuing tokens on the hub seems to be, perhaps not necessarily counter-intuitive to, but at least pretty orthogonal to that goal. We would prefer to keep the Cosmos Hub’s state machine relatively simple and focused on the features it needs to be able to act as a successful hub.
-
As I alluded to in my tweet, we do not believe we should burden governance with having to manually approve each token that wants to be issued on the hub. This may potentially create a legal liability for voters in the governance process of approving tokens to be issued. As an example, let’s say e-Money wishes to issue a token called e-EURO on the Cosmos Hub. If the Cosmos Hub stakers choose to approve this, are we inherently signalling to users that we think the e-EURO will maintain a peg price of 1 Euro? Do I have to go research the relevant regulations in my jurisdiction in order to figure out the answer to that question? I think this places undue burden upon the Cosmos Hub stakers. A permissionless token issuance system on the other hand, makes it such that we do not have control over the right to issue tokens, and thus likely have less legal liability (same as how Ethereum miners likely don’t have legal liability over which tokens get issued on the Ethereum blockchain. Keep in mind, I am not a lawyer, and this is all legal speculation on my behalf. We would be far more in favor of something like the permissionless namespacing-by-issuer-address mechanism that @zaki proposed above. However, we still need to be convinced that this is worth our concerns from #1.
-
The proposal is particularly around the issuance of an unlimited supply token issued by a single issuer address or multisig. In our opinion, such a token would not benefit greatly from the security of a chain like the Cosmos Hub, as the integrity of such a token could be compromised by compromising the keys of the issuer of the token. For this reason, we suggest that anyone interesting in creating such a token to launch a new Cosmos chain with the intended participants of the issuer multisig as the validators of the new chain. This new chain can include the ability to transfer the tokens, and will achieve essentially similar functionality to what an issued token on the Hub, pre-IBC, would achieve. Once IBC is launched and enabled on the Cosmos Hub, this new chain can connect to the Hub and the tokens issued on that chain can flow into the Hub.
-
In the proposal, there is a table that specifies the “Voting Options” which tries the define what voting No and NoWithVeto mean, which differ pretty significantly from their intended meanings of “against” and “strongly against”. Hopefully, this governance proposal that Sikka will propose soon may help clear this up.
We recognize that this proposal design was largely caused by a lack of a “multiple choice”-style proposal type on the Cosmos Hub, and in our opinion, such a ProposalType should be created. However, in the meantime, we do not want to condone redefining the definitions of the different voting options. One alternative that could have been used instead for example is that the proposal could have requested people signal their opinion on the “multiple choice” using the memo field of their vote transaction.
We welcome further discussion on this topic and if we are successfully persuaded, we are happy to change our vote before the end of the VotingPeriod of this proposal 