This is a Signaling Proposal for the Cosmos Hub community to deploy a front-end for Permissionless ICS. The Cosmos Hub forum post and discussion about this topic can be found here.
A user-facing frontend for Permissionless ICS has been developed by Informal Systems, which aims to address several issues:
The platform aims to improve UX for three main user groups - for delegators, validators, and chain developers. We are focusing on the delegator experience for the launch, and are working with concerned parties to launch the front-end on cosmos.network.
The chain listing screen will list consumer chains, along with basic information. At launch, users will be able to filter chains by project phase, with additional filtering and search functionality planned for future updates. There will also be functionality to rank chains by size, reward rate, newest, and more.
A key challenge for the chain listing screen is spam and scams. With permissionless ICS, anyone will be able to create a consumer chain, and without filtering, it will show up on this listing. Since this is a front end to a permissionless blockchain, spam filtering will not be done in a centralized manner.
Initially, we will filter consumer chains to include only those with at least one active Hub validator opted in. This criteria should effectively reduce the risk of spam, but we may refine it over time. Future enhancements could include allowing approval from prominent community members or a governance-elected DAO. This approach would make it easier for new chains to be listed even if they don’t yet have validators opted in, while still maintaining a level of quality control.
The chain detail screen is where the magic happens. This screen contains all relevant details about a chain, but it mostly has two points of end-user interaction:
ATOM delegators cannot receive staking rewards from a consumer chain without delegating to a validator who runs that chain. At the bottom of the chain detail screen, delegators can see a list of validators opted in to each chain, and delegate to them right in the interface.
In the upper right corner is the section for “badges”. Badges are interactive widgets from other applications that offer additional ways for ATOM delegators to engage with the chain beyond simple delegation. Our first integration will be with Hydro, a Cosmos Hub ATOM liquidity platform. However, this feature is designed to be extensible, allowing integration with third-party platforms such as airdrop providers, IDOs, or governance and community forums.
For the initial launch we will be focusing on the delegator experience, and adding chains manually, but as the number of Cosmos Hub consumer chains grows, we want the platform to become a self-serve experience for new consumer chain projects. The frontend should guide developers through 4 phases:
Due to the variety of tools that validators have at their disposal, they are a primary target user group like delegators or developers for this front-end. However, their participation is very important as they run the chains. When it comes to validators, the goal of the frontend is to make the process of finding consumer chains, opting in to them, and joining testnet and mainnet as smooth as possible.
Validators are expected to continue to do administration of their Cosmos Hub and consumer chain infrastructure using their own methods (usually hardware wallets, CLIs, and multisigs), but the validator dashboard will play an important informational role.
Validators will be able to register or input some key contact information such as email and Discord usernames of their technical contacts. This information will not go on-chain, but will only be privately supplied to developers of consumer chains that a given validator has opted into.
Validators will be able to access a notification dashboard where they will receive notifications about important events and communications from consumer chains they are opted in to, including testnet launches, mainnet launches, upgrades, and emergency patches.
The following items summarize the voting options and what they mean for this proposal:
Upon a YES vote:
Upon a NO vote:
NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned
ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal