Validator.network plans to submit the following proposal for a governance vote soon, unless feedback from the community leads us to do major revisions of the text.
In short, the proposal is to allow issuance of custom tokens on the Cosmos Hub. New tokens can be introduced through the governance process.
This is effectively a form of permissioned token issuance. Permissionlessness was always intended to be driven by IBC so I think this is fine.
I would also really prefer if this feature was implemented by some entity other than AiB. At the moment, AiB has no intention to implement but would most likely help with testing, integration and design as we would with an SDK module that was being upstreamed.
ValidatorđNetwork just published proposal #4 for enabling issuance of fungible tokens on the Cosmos Hub. We see this as a big step toward providing immediate utility and wider adoption for Cosmos Hub.
Hoping for strong community support - please get in touch with any questions.
My first impression is to put IBC and shared security at a higher priority in order to enable the issuance of fungible tokens. Iâm afraid it will diminish the value and importance of IBC if this is enabled before the existence of IBC. The role of the Cosmos Hub is to connect to different hubs and zones. If these tokens can be created on Cosmos Hub now, will this discourage the appearance of other hubs or zones?
We do not expect the implementation to be a distraction for IBC, as it looks like a non-Tendermint development will undertake the work.
IBC will continue to be a huge part of the value-proposition for Cosmos, giving services the ability to run their custom application logic on top of Tendermint while connecting via IBC. We do not see fungible token issuance as any kind of competition to IBC, but mainly as a way to provide immediate utility with what we have today.
One of the use-cases for fungible token issuance we see is to bootstrap new services for the Cosmos Network. Projects can do a fundraiser and initial distribution using fungible tokens, move on to building out the service/zone and finally connect it to the Hub. So we also see as a convenient way for new projects to join the network.
Weâve recorded an interview with Brian Crain from Chorus One, which explains our reasoning in more detail. Hope to be able to share that soon here.
One of the use-cases for fungible token issuance we see is to bootstrap new services for the Cosmos Network. Projects can do a fundraiser and initial distribution using fungible tokens, move on to building out the service/zone and finally connect it to the Hub. So we also see as a convenient way for new projects to join the network.
Thatâs a great use-case. If so, I would prefer those tokens have to be locked up once issued until the project is done. Once the project is online, those tokens can be transferred back to the zone via IBC.
I will change my vote from yes to no.
I thought the motivation of this proposal is pretty good. so i voted yes.
But this is not the right time. Cosmoshub is still at very early stage, new features should be added very carefully, because âUnexpectedâ plugins will not friendly to cosmoshub/cosmos-sdk. i will not support since the team(AiB) has no intention to implement.
Zaki I understand your point about not wanting to issue inside the Cosmos Hub namespace.
Since the Hub is already intended to support <namespace, denom> tokens for IBC, here namespace = source zone, I guess it could make sense to incorporate it into the implementation of proposal #5.
This would also support the use-case of bootstrapping new projects, where they they do an initial issuance inside their own namespace on the hub, and then migrate later on to their own zone. The new zone would then have a genesis state stating that X amount of its tokens are already on the Hub.
For our own part, e-money is fine to issue inside a namespace as well, we have no speciel preference for it happening under cosmos ns.
How would you feel if gov was required to register a new namespace, but creation of new tokens below this namespace is unrestricted? I think could work nicely for an implementation for proposal #5.
PS. Not a big fan of the per-account namespace, account identifiers does not seem like a natural namespace. Namespace to me means something more than an account.
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
We are agree here. Cant proposes listed tokens after governance. And more reasons. Like cosmos no need tokens, needs hubs peg zones and daps, no tokens today.
I want to express my opinion on proposal 4 by a form of replying sunnyâs opinion since it described the issues very well. Thank you for your writing btw!
I think proposal 4 is NOT orthogonal to the vision of cosmos. Main reason is that proposal does not open a future of ethereumization of cosmos, mainly because it does not support dapp. Tokens of certain utility needs their own dapp to run the blockchain, but a token in a hub cannot possess its own dapp like ethereum.
Only possible tokenizations on cosmos hub are âstable-coinâ and âiouâ, which does not need customized application to run.
So I think it might be 20~30 degree away from pure purpose of interchain, but I would like to give my hands to more âinclusiveâ nature of cosmos network.
I think permitted issuance of token is very safe and prudential way to deploy the issuance functionality in the beginning. We can control and prevent possible problems by reviewing those issuances.
If it becomes a burden to the governance, it can be classified as a spam, and veto or non-vote is our tool to prevent such spam. I think it is not an additional problem risen from proposal 4.
Of course the legal part is always bearing risks. But still, entire ethereum community is not threatened by crucial legal risk, meaning that even though subset of a hub has a problem, it will not significantly affect whole network. A network should have some braveness to welcome potential ecosystem contributors and become more inclusive community.
Naming of token is very local issue. We can find out wisdom how to name the tokens so that we can minimize the risk of misunderstanding by each issuance governance. Dont need to freak out from minor problems.
I think #3 just describes non-allowance of issuance functionality, not providing any plan B. It is always possible to build new chain.
I agree that the option provided is not inclusive enough to comprehend the real intention of community members. I think proposal 4 deserves more than just a voting process. It needs more extended period of time for discussion about pros&cons of the functionality and also scope of functionality.
While I generally agree with proposal 4, I would like to see further development of reasoning of necessity of issuance functionality regardless of the approvement of the proposal.
