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.