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

Hub Proposals Signaling/Text
21

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 of the issuers of the token, as that would give it an equivalent utility as being issued on the Hub, pre-IBC would.

Only possible tokenizations on cosmos hub are “stable-coin” and “iou”,

How do stablecoins and IOUs align with the mission of being a secure Hub for the Cosmos ecosystem? As I mentioned in my point #3, these tokens do not really benefit from the security of the Cosmos Hub, and so should not be natively issued on the Hub.

But still, entire ethereum community is not threatened by crucial legal risk

As I mentioned in my post, the issuance of tokens on the Ethereum blockchain is permissionless, and thus the miners and operators of the chain do not carry the same liability as a permissioned model would.

A network should have some braveness to welcome potential ecosystem contributors and become more inclusive community.

Agreed. The Cosmos Network should be inclusive to all sorts of different applications, asset types, and use cases. I’m happy to personally help anyone interested in building an asset issuance chain to architect and get started building such a chain using the Cosmos SDK.

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.

This was just one example of such an issue where it places Atom Holders in a tough spot where they need to do a decent amount of research to understand their legal liability in voting Yes. There are likely many more such cases.

I think #3 just describes non-allowance of issuance functionality, not providing any plan B. It is always possible to build new chain.

I did provide a plan B: “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…”

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.

I agree with this, and for this reason, I believe we should reject this proposal for now until it has time to be more thoroughly discussed, than be rushed through to acceptance in the next 8 days.

22

  1. 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.

  2. 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 incubating system of projects who want to be part of the cosmos hub.
Those 2 types of token do not harm much on the hub. The only harm can be “too much transaction generated by those tokens”. But as a matter of fact, I think it is actually a good early testbed of the challenge of scalability on cosmos hub. We might need to consider parallelism to gain the scalability. But I think it is a opportunity for the hub to grow faster than pure IBC utility chain.

  1. Permission of issuance does not imply legal responsibility of the token. At least I believe so but it needs professional review.

  2. If issuance is too much, it is actually very good thing for the hub because the use-case is growing very fast. I understand the burden of governance, in that case, most delegators can delegate their votes to trustful validators who can decide well for the entire community of cosmos hub. Real world also works that way. And for validators, I think it is crucial duty, and even if there exists governance proposal every week, they should research and vote. It is not a HOBBY. It is not an automated operation. It needs serious human times.

  3. Even though I agree that we need more discussion before decide, for me it feels like rejection to reject. I think if the proposal passes, it proves that we actually dont need more time to decide the functionality is necessary or not, but we only need more time to discuss the detail scope of the fuctionality. If proposal is rejected, it implies community needs more time to discuss, so we can continute the discussion.

B-Harvest wants to give the community opinions with direction of becoming “inclusive” network for the cosmos hub for the enrichness of the network and value of atom. Strictness, consistency, theoretical correctness, extreme principal driven argument might harm the potential widespreading of our hub. It is helpful to develop the codebase, but not very helpful to enrich the community.

23

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”. :frowning:

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 issued by a permissioned set of issuers. Because it does not have to be Proof of Stake, you don’t have to worry about incentivizing delegators, and supposedly the validators, being the issuers, already have some incentive.

Please elaborate more about security wording.

One of the ideas of the Cosmos sovereign chain model instead of enforcing a one security paradigm fits all model for all applications, it allows different applications to design the incentives that meets their needs. i.e. Cryptokitties probably doesn’t need equivalent security to Augur. As mentioned above, I don’t think a centrally issued stablecoin needs the security of the Cosmos Hub, it would be far better served by a chain with a permissioned validator set.

Benefit of IOU on hub : projects willing to build a zone on cosmos can issue IOU token to give investors liquidity before mainnet launch.

In my experience, almost every project that has issued “IOU tokens” in the past usually comes with some sort of the state machine enforced limitations, usually a supply cap at the very least. Because this proposal is concerned with unlimited issuance tokens, I personally don’t think that this mechanism would be the best way to satisfy the use case of most IOU projects.

I would be interested in helping brainstorm an architecture for a general purpose “ICO zone” that’s specially designed to help zones issue tokens to achieve the benefits you mentioned. For example, I think it would be cool to have a Uniswap module on that chain in order to provide some low volume instant liquidity to the tokens issued there.

Permission of issuance does not imply legal responsibility of the token. At least I believe so but it needs professional review.

Why don’t we make issuance permissionless and remove the doubt altogether?

I think if the proposal passes, it proves that we actually dont need more time to decide the functionality is necessary or not, but we only need more time to discuss the detail scope of the fuctionality. If proposal is rejected, it implies community needs more time to discuss, so we can continute the discussion.

Sure. I personally urge any validator who wants more time to discuss this proposal further in a less time-sensitive manner to reject it for now. And we can revisit it again if we decide it is worth revisiting.

Strictness, consistency, theoretical correctness, extreme principal driven argument might harm the potential widespreading of our hub.

I disagree. In my opinion, consistency, theoretical correctness, and especially principle-driven argument are necessary for a well functioning governance system, which in turn will lead to the long term success of the Cosmos Hub.

24

Well pointed out sunny! I hope to clarify some issues in my reply.

  1. 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.

  2. 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.

  1. 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.

  2. 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 their own good reasons. Hope to see further discussion with other participants.

25

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.

1 Like
26

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 alike.

The proposal seeks to address this by providing an immediate use-case (transfer of other fungible tokens) while providing a mechanism for bootstrapping future zones/projects.

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.

By reusing the governance code, I do not expect our proposal to add much complexity to the state machine. I would estimate it to be extremely simple compared to IBC, while bringing immediate benefit.

I understand your governance burden and legal concerns.

The governance mechanism is primarily intended to solve the puzzle of namespace/token identifier assignment.

We considered if a permissionless, first-come-first-served scheme really is desirable for the Hub. How long until some joker registers BTC and ETH token identifiers? Same for namespaces and well-known names.

We then considered a fee-based mechanism, but that could still lead to squatting behaviour as seen with domains.

Our take is that the governance model, taking a more conservative approach, is more likely to gain support. Anyone is still free to propose removal of this mechanism down the line, but we see it as a sensible start.

It still allows anyone to propose new tokens while risking only the deposit. Of course there is the added work of preparing the proposal, but if it is accepted the listing is free.

Post-IBC we expect zones to arrive that allow permissionless issuance of tokens in their respective namespaces.

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?

Voters are only signalling that they believe the namespace/token identifier should be assigned to the issuer. It is up to the token issuer to comply with regulation as is practice today.

I believe using the governance for namespaces only would make this even clearer.

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.

Considering the skills required, along with the large investments validators are continuing to make to secure the Cosmos Hub, I disagree that anyone capable of securing a Ledger device is by extension capable of operating a validator.

By issuing on the Hub, new projects will be able to initially issue tokens there, while working to build the software and community required to launch their own zone.

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.

This seems wasteful with little apparent benefit. It might shave off minimal added complexity to the state machine, but requiring bootstrapping of a zone make the Cosmos ecosystem much harder to join.

Current stakeholders will also not benefit from transactions running on a different chain. The point of the proposal is to utilize the existing infrastructure, security and trust.

I would definitely support a proposal for adding a multiple-choice option for votes. We’re working with what we got, but until that changes it is great you post here to provide your position. :slight_smile:

27

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?

28

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:

  1. 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.

  2. 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 core task for the Cosmos hub which is guaranteeing secure and consistent IBC transfers.
    We also agree that it could create legal liabilities for delegators.

  3. In general, we don’t support a token model with a single issuer address. Keys can get compromised, and it grants to much power to a single entity. Even though multisig helps to spread the risk, we don’t believe this is the right approach to issue new tokens.

Generally, we support anyone who wants to bring value to the Cosmos Hub! That said, we still believe that we have to maintain a strict and straightforward Hub state machine until we are aware of all implications and duties coherent with IBC. We will follow the discussion here and will reconsider our vote if there are solutions/new approaches to our addressed concerns.

4 Likes
29

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:

30

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:

  1. It will increase the number of transactions on Cosmos Hub before IBC and validators and delegators will have better economical benefits during this period.

  2. 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:

  1. 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.

  2. 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

https://cosmos.bigdipper.live/proposals/4

1 Like
31

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: partners@e-money.com.

BR,
Martin

7 Likes
32

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.

5 Likes