[PROPOSAL #4][REJECTED] Proposal for enabling issuance of fungible tokens on the Cosmos Hub

• Moderator edit to include link to on-chain proposal: #4 Proposal for issuance of fungible tokens directly on the Cosmos Hub

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.

Please visit the proposal at cosmoshub-proposals/issuance-proposal.md at master · validator-network/cosmoshub-proposals · GitHub and add your comments below or directly to us through Telegram (@mdyring and @haasted).

Questions

• Are we only going to fixed supply tokens? or some kind of inflationary token also in scope?

• Are names first come/ first served?

One idea here is just specify a multisig account that issue more supply.

Thanks for feedback Zaki.

We’ve added sections on supply (unrestricted) as we see fixed supply as a subset problem, detailed in “not in scope”.

Also added section on token identifiers as “not in scope”, as we expect the subsequent governance proposals for token listings to handle this.

Also added multisig as suggestion (not requirement), but it is sensible to do with multisig

As there have been a bit of communication outside of this forum, we believe most suggestions have been incorporated and concerns addressed.

Current ETA to submit the proposal is Monday, April 15th.

Some additional points of view:

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.

https://hubble.figment.network/chains/cosmoshub-1/governance/proposals/4

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?

Thanks for your feedback Kwun.

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.

We just uploaded the interview: https://youtu.be/Yjl_lH5Cx_U
Thanks for joining Brian for this!

We are working on our own evaluation and will hopefully release our evaluation and vote on this issue at latest beginning of next week.

Perfect, thanks Felix!

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.

So I was reading @sunnya97’s comment on governance proposals being the wrong tool for token issuance.

Sunny Aggarwal (sunnya97)

So there is a lot of token issuance I could support but not under the top level hub namespace. This should be saved for truly special things.

I think accounts should be able to issue tokens under their own name space as they please just by paying gas to do this.

The token denom would cosmos1something_something/name_of_choice. There would be some gas price to do this but accounts could just do this.

I think this sets us up for tokenized staking and other things we will want to do in the future.

this would allow an account designate by e-money to just issue tokens as they please.

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.

I think using governance as an issuance mechanism sets on a road to trying to become self regulating organization. https://en.wikipedia.org/wiki/Self-regulatory_organization

I think being an SRO for the Hub namespace and permissions for other namespaces in the Cosmos Network is coherent position.

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…

Excerpt (1199 of 3803 characters). Read the whole post on the forum ↗

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.

Excellent choice given the circumstances.

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…

Excerpt (1197 of 2339 characters). Read the whole post on the forum ↗

Thanks for the response! Gonna reply to some of the points here: I think proposal 4 is NOT orthogonal to the vision of cosmos. It’s agree that it is not orthogonal to the vision of the Cosmos Network, but in my opinion, it is orthogonal to the vision of the Cosmos Hub. 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. There is far more to the Cosmos vision than just preventing “ethereumization” of the Hub. While the Cosmos Interchain model benefits from application-specific state machines as you allude to, another important benefit is its efficient allocation of security. The Cosmos model is intended to allow different use cases with different security requirements to figure out an appropriate security model for their chain. As I mention in my point #3 , the tokens of the type focused on in this proposal do not quite benefit from the security of the Cosmos Hub, and would probably be better suited to be issued on a permissioned chain whose validator set consists…

Excerpt (1198 of 3532 characters). Read the whole post on the forum ↗

• I meant cosmos hub. Programmers are too obsessed with “consistency”. It is helpful to build a program, but not very helpful to build a community imo. Programmers should aware that they are good at programming but not necessarily good at growing blockchain community because of such pursue of strict consistency. • Please elaborate more about security wording. I believe security is not the only thing cosmos hub wants to grow. I dont see issuance function on different chain as a practical plan-B right now. I think it is out of topic, so we dont need to talk about it in this thread. (We might want to talk about it after the decision of proposal 4, but it is practically very difficult thing to achieve.) Let’s discuss more practically and only focused on current issue. Benefit of stable coin issuance on hub : stable coin on hub does not need to build their own validator set, needing less incentive structure to delegators & validators of the zone, result in more user-benefitting stablecoin without much operating cost. Benefit of IOU on hub : projects willing to build a zone on cosmos can issue IOU token to give investors liquidity before mainnet launch. It can be a good…

Excerpt (1193 of 3148 characters). Read the whole post on the forum ↗

Programmers should aware that they are good at programming but not necessarily good at growing blockchain community because of such pursue of strict consistency. Sorry, but this comes across as a bit "ad hominem"y. I just want to point out that I have built successful blockchain communities before, such as Blockchain at Berkeley . And I think consistency and structure were very important to the success of that organization. I dont see issuance function on different chain as a practical plan-B right now. I think it is out of topic, so we dont need to talk about it in this thread. Why is this not a practical “plan B”? First you said I wasn’t proposing a Plan B, and now you’re just dismissing it as “out of topic”. Benefit of stable coin issuance on hub : stable coin on hub does not need to build their own validator set, needing less incentive structure to delegators & validators of the zone In my suggestion, I proposed it being a permissioned validator set consisting of the issuers of the token. It does not need to be a Proof of Stake system, as using Proof of Stake to secure the chain doesn’t contribute to the security of the token when it can be infinitely…

Excerpt (1194 of 3919 characters). Read the whole post on the forum ↗

Well pointed out sunny! I hope to clarify some issues in my reply. • Permissioned on the issuance of token on the hub does not imply permissioned of the hub because zones are permissionless. Building chains in the zones of cosmos hub are permissionless. Only token issuance on the hub is permissioned in the proposal. • The major necessity of the proposal is to support issuance of tokens • without dapp • without validator group It is really difficult to build a decentralized well-skilled validator set. That is why I said building in a different chain is not a practical plan B right now. • Any token issued in hub can be with limited/unlimited supply.(unlimited for most stable coin, limited for IOU) I think the scope of functionality should cover both cases. It is rather a topic to discuss after the pass of the proposal. • I also think that consistency, theoretical correctness are important. What I meant is that we should have a good balance of those philosophy against practical inclusiveness of the hub. Sometime we can bend little bit of those philosophy to welcome more usecase of the hub. Although I agree proposal 4, I think sunny’s points also have…

Excerpt (1194 of 1274 characters). Read the whole post on the forum ↗

As P2P Validator we vote - No with Veto.

We’ll not support any permissioned token issuance.
Longterm we think that Ethermint(we don’t need special ICO zone) will be good place for token issuance, where you can create any logic you wish.

For now we can make simple design. For example we can take one namespace SimpleToken, make special parameters for this type of tokens - like issuance supply(the number of parameters depends on the complexity), and give the opportunity to create tokens without permission, if they burn 10 atoms for example. So the token name will be SimpleToken:Example.

Sunny, thanks for taking the time to provide feedback. First I’d like to clarify that our proposal does not specify the exact implementation, but is intended to gauge support for issuance of tokens on the Hub using the governance mechanism for sanity checks. One possible implementation, which I am warming up to, would be to introduce human-readable (not address) namespaces, which will be needed anyway for IBC to track source zones. The governance mechanism could then be used to assign a namespace to an issuer, who is then free to create any number of token denom within that namespace. Would love to hear your thoughts on an implementation like this. Below I’ve commented on some of your key concerns, hopefully clarifying the intention of the proposal. • 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. My initial idea of Cosmos Hub was also well aligned with this. From my perspective, as the Hub arrived without IBC, it currently has minimal utility to the detriment of validators, delegators and integrators…

Excerpt (1199 of 4543 characters). Read the whole post on the forum ↗

Thanks your for the feedback.

I believe what you are looking for, unlimited listing of tokens inside a namespace could be a possible implementation (see reply to Sunny above).

What is your view on namespace assignment?

Hi everyone, after some consideration, we at Staking Facilities decided to vote “NO (VETO)” on the proposal #4 token issuance of fungible tokens on the Cosmos Hub. This decision is based on the following concerns: • We believe the Cosmos Hubs core purpose lies in enabling secure and consistent IBC transfers (together with some other IBC features). Since this is a complex and challenging task, we think the Cosmos Hub state machine has to stay as simple and straight forward as possible. We are still in an early stage of the Hub, and we shouldn’t waste any time on a temporary token issuance solution before enabling the core features. Longterm, we think it would make sense to have one chain attached to the Hub via IBC that exclusively focusses on the issuance of new tokens. We like Sunny`s idea of the “ICO zone”. The Ethermint zone will also provide a place in the hub that allows the issuance of new tokens. • We believe token issuance should be permissionless and a token should validate itself by its use case and adoption. Besides that, it takes a lot of time to do a detailed analysis and validation of a new token. This would distract validators and delegators from their…

Excerpt (1196 of 1993 characters). Read the whole post on the forum ↗

Chorus One just voted “No” after some internal discussions. Our reasoning corresponds with the concerns that others have also brought up in this thread, especially around the permissioned nature of using the governance process.

Quick summary of the proposal and our evaluation + vote:

Proposal #4 Evaluation: Token Issuance on the Cosmos Hub

A summary of the proposal to issue fungible tokens directly on the Cosmos Hub (#4) including the reasoning for our "No" vote.

Forbole has voted “No” on proposal 4. The vote was committed in this transaction https://cosmos.bigdipper.live/transactions/7852F78059A6766228ACCECB3FE3643327168AB21AAEEB38E31E880698214827 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…

Excerpt (1199 of 2088 characters). Read the whole post on the forum ↗

Dear fellow Cosmonauts,

As voting on proposal #4 has come to an end, resulting in a rejection, we’d like to thank everybody for healthy discussion and careful consideration.

It seems clear that at least some of the concerns raised are not easily fixed by technology, but are of a more legal or philosophical nature.

Therefore we will not put forward an amended proposal or explore further options for issuance within the Hub.

With regards to our e-Money business, we’ll now focus on launching our sovereign zone in the coming months, with the clear expectation that an IBC implementation supporting credit transfers is forthcoming.

In relation to that, we are preparing a token sale for strategic partners and looking for validators. Feel free to reach out to signal interest: [email protected].

BR,
Martin

I would be very open to revisiting this if IBC has not made enough progress by August.

Second I think iqlusion would be very open to launching a sovereign chain with these features in the near term.