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.