New Features: Transparency and Justification

Hello fellow Cosmonauts.

I want to touch on the topic of Risk evaluation and due diligence when suggesting new features that are altering the core of Cosmos to the point the suggested ones do.

New features = New revenue streams.

This is correct, yet not absolute. New revenue streams can come from product robustness, longevity and security as well. In software development, whenever a product reaches a supposed stalemate in development, the new features are used to drive new capital in and push development. However this does not come without a cost.

Enter, Software Development Entropy Acceleration.

The new features albeit driving new capital, are consuming resources, the development cost goes up, and the risk ratio rises. New features albeit alluring and capital inducing at first, in the long run inevitably drive the product to development entropy in a more accelerated manner.

Disclaimer: I am not advocating for software stagnation and a supposed equilibrium. This is an impossibility in Software Engineering. The point i am trying to make here, is to prevent high levels of entropy by introducing rushed new features.

No new features? NGMI!

I do not agree at all with this sentiment. Protocols that take huge risks and development leaps of “new feature === then price go up” are getting sacrificed in the altar of acceleration and we need only to look outside our comfortable and secure Cosmos bubble(with minor exceptions of course). Cosmos is a safehaven in that regard because of robustness and it wins by minimalism. (Cosmos hub minimalism is a matter for another time though)

The Burden of Proof

Lies only to the proposer of drastic changes. The demand for transparency is not something that the hub devs or anyone for that matter should think its an “optional” request. It is not. I am not trying to be disrespectful and i appreciate the development done so far. BUT. We are at the crossroads of BoP(Burden of Proof) and accountability.

In traditional fintech SENG companies, If a lead architect/product owner/CTO etc. want to change the business logic of an application, or even change something on a runtime engine, or anything altering the initial scope and product mission there is accountability and approvals that need to be made. From whom? By board of directors and shareholders. There is ZERO times in any serious business, where someone said, lets change the application entirely and the stakeholders just shrugged.

**Any change proposed should come with a transparent publicly available Risk Assesment Report. **
Any claim of New Feature === Price goe up should come with a publicly available Return on Investment Report.

Again, forgive my forthcomingness, but you (the change proponents) are obliged and mandated to produce such reports. There is risk analysis/marketing/product team for the hub, no? It falls into this jurisdictional level. This is also to ensure Liability.

Another analogy:
When a bridge is made, if the bridge at some point collapses out of material/design negligence, the parties involved are and will be subject to legal repercussions. This is what skin in the game, accountability and liability is and why i love these concepts so much. You suggest x modification will account for price increase? Perfect! I am not saying it wont. I am also not saying it explicitly will. We have to put our logic first and then sentiment. And logic dictates calculation, thus the need for the above mentioned results.

If the new features fail, who is accountable?
If the new features do not deliver, whose money are gone?
If such analysis was not made, how can we suggest price go up with such certainty?

I am making this thread in the governance section for the following reasons:

Before an onchain proposal goes live, it is my opinion that these matters should be addressed and used as a point of reference for accountability and transparency. It is owed to the cosmonauts and investors. It is the sane, logical and safe way forward and again, imo, if those criteria are not met, no proposal of such significance and with such hub altering elements should see the blocks of a chain.

Tax increase is directly linked with new features and the suggested new features of the hub that were pointed out in Atom2.0 and albeit atom 2.0 died with the NwV prop, the ghost of Atom2.0 past still lingers on with concepts like MEV,Liquid staking etc (another reason why the above-mentioned reports are needed)

The elephant in the room: ICS

YES to ICS. I am a very big proponent of moving forward with ICS.
However now we are reaching a point where we are debating the funding of the remainder of the ICS completion(bootstrapping new consumer chains) and i have to ask(out of ignorance essentially) Was this not calculated in the first ICS cost allocation? If not, why at least not on a high level? Discussions about which chains would be bootstrapped first and which later are not something done with a flick of a switch so this could be estimated, or at worst, sized up by a range that translates to monetary value in terms of costing.

I shall make a different thread regarding the community tax and how i think it should be handled, because this is purely to raise awareness and to point out this obvious thing:
We need more transparency and less blind faith.

Sincerely, your friendly neighbourhood helicopter operator

PS. If adequate analysis was done and i am ignorant on it, please provide below and i will be very pleased to correct my critical judgment with less scepticism.



Thank you for your well detailed feedback. I think that as community member you have all the rights to feel worried for the future of the Hub and ask for more deep analysis.

A risk assessment report for any big change in the tokenomics is something that I also suggested with a group of friends in the Charter thread:

The recent events showed that the community deeply care about the Hub and it is definitely important to build a stronger connection and transparency between builders, validators and community members/ Stakeholders.

A lesson to learn is that the community should be part of the decision making progress and feel always considered in decision that move the Hub towards new innovation, we should work to create more collaboration.

I don’t agree completely in the comparison with traditional finance, because a decentralized network is obviously not comparable to a traditional fintech. We have yet to discover the best practice for communication in a decentralized network. DAO or Council seems the tools in the Crypto space that could provide the report that you are asking. So this is something to be considered for example with a spend proposal, to fund for example a team that can provide specific reports, if we aim to follow to have a more decentralized Hub.

I don’t agree to define the upcoming Community Tax proposal as tokenomics change or something that need a risk assessment report, because it is not a proposal that requires the introduction of new tools.

The community Tax already exist by design, currently set at 2%. Increasing the tax requires only to change an existing parameter and it is an action already in the design of Cosmos chain. In this specific case the Community Tax increase is required because the Community Pool is the tool that the community can use to fund development and also eventually create spend proposals for have a team working on specific reports as you suggested.

The community pool is how a decentralized network can achieve an independent status, many Cosmos Chains with a lower market Cap currently have more funds of the Hub. The best example is Stargaze that with a 50M market cap, has a community pool valued 20M USD, the double of the Cosmos Hub valued at 10M USD.

This is the signal of a Community Pool that needs to be reinforced in order to reflect what the Hub currently is, a leading Cosmos Chain. The Hub should have a community pool well funded in order to accomplish multiple tasks and push forward development, indipendetly from the external companies that in the past took the effort of supporting the Hub.

The community tax, being already in the design, has been recognized as the best parameter to achieve the goal of funding the Community Pool. And it is our chance as community to make an effort to support the Hub and restart a collaborative environment after difficult weeks of discussion.

Blockquote I don’t agree completely in the comparison with traditional finance, because a decentralized network is obviously not comparable to a traditional fintech. We have yet to discover the best practice for communication in a decentralized network. DAO or Council seems the tools in the Crypto space that could provide the report that you are asking. So this is something to be considered for example with a spend proposal, to fund for example a team that can provide specific reports, if we aim to follow to have a more decentralized Hub.

There is little to almost no difference in the majority of things as cryptofi is today. Only the illusion of the difference really.

Anyhow, A Dao is an idea I can get behind more. Self generated transparent reports are very much needed, Yearn if im not mistaken has implemented something like this.

However, transparency reports are one part of the topic here. The other being, how can we justify innovative leaps with proper risk assessment? Again i would like to see if this could be possible via DAO instead of an elected council.

Thanks for this post @Binochet, I fully agree with you that:

and also that we need better processes for risk assessment with a minimization of stagnation.

I think the problems at hand are not only about transparency and reporting, but also our ability to comprehend and act on those reports effectively.

One possible idea (and note it is only a seed of an idea) is the development of a more coherent process for assessing risks and analyzing information as a community.

This has two components in which we have a decentralized knowledge base where we crowdsource as many possible opinions about an idea as possible. While in and of itself that would lead to incoherent outcomes, an epistemic-status proposal (text-proposal) can then be used to signal the epistemic-status of an idea, with super-majority approval indicating that it’s ready for the next steps (note: NO execution-strategy should be tied to the outcomes of an epistemic status proposal, its only purpose is to judge the collective confidence in an idea).

Anything short of super-majority approval might indicate that the idea still needs refinement (and to what degree). In this way we can better understand how confident the community is in an idea, and how / why they reached that level of confidence.

The core assumption here is, of course, that by leveraging multiple perspectives we can achieve better outcomes in the long-run. However, the cost of this method is increased cognitive load to process epistemic-proposals.

Leaving that there just to ideate on…

The interesting part in crypto is that on some points we are trying to reinvent the wheel. I am totally with you on the change of community tax not needing an extensive research as parameter change, but the plans what we are going to do with the funds needs one.
New code needs one.

I think that is the essence of @Binochet. Not necessarily to copy TradFi, but we can learn what already works there and copy it. And fix what doesn’t work.

1 Like