[PROPOSAL #947] [VOTING] CHIPs signaling phase: Permissionless ICS Frontend

[jtremback]

Informal is developing a user-facing frontend for Permissionless ICS. This application aims to address several issues:

• With the launch of permissionless ICS, ATOM delegators need a single platform to discover new consumer chains, explore staking rewards, delegate to validators, and engage with the chain’s community, including airdrops and liquidity provision.
• The process of navigating a Cosmos chain through devnet, testnet, and mainnet launch phases can be challenging. A comprehensive resource to guide developers through the entire launch process is essential.
• Putting together a validator set is often complex and opaque for projects. What’s needed is a single platform where chains could come together with validators to run their chain.

Forge offers three main user experiences- for delegators, validators,and chain developers. We are focusing on the delegator experience for the launch.

The delegator experience

Chain listing screen

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.

Spam filtering

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.

Chain detail screen

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:

Validators

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.

Badges

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.

The chain launch experience

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:

• Idea phase: In this phase, the developer reads documentation on Cosmos and bootstraps their chain. The ICS integration with Spawn (a chain bootstrapping tool) is important here. Part of every consumer chain’s repo will be a JSON file defining their chain detail screen, including stats, ICS settings, and badges. While developing their chain, a preview of the chain detail screen can be generated by inputting a link to the chain’s Github repository.
• Pre-launch phase: Once the chain is ready for publicity, it goes live on the frontend and can be found on the chain listing and chain detail screens. This is the phase in which consumer chains connect with the Cosmos Hub community, build an initial validator set, and can start engaging with ATOM delegators.
• Testnet phase: When a project starts the testnet phase, a consumer chain record is created on the Cosmos Hub testnet, and validators who opted in during the pre-launch phase are notified about the upcoming testnet, and chain developers can create a Discord server for validator communication. Chain developers can continue to update their chain detail screen and notify the community about the upcoming mainnet launch.
• Mainnet phase: When a chain is ready for prime time, it can enter the mainnet phase. At this point the consumer chain record (along with any adjustments to settings) goes onto the Cosmos Hub mainnet and the consumer chain’s mainnet starts as well. ATOM holders use the chain detail screen to delegate to validators to receive rewards, and to interact with the project in other ways such as the badges.

The validator experience

Although validators are not a large user group like delegators or developers, 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.

Contact information

Validators will be able to register 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 supplied to developers of consumer chains the validator has opted into.

Notification dashboard

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.

[Syed]

This is much more feature-rich than I expected - cudos!

Looking forward to this launching + integrating the PSS calculator to it at some point soon.

[jacobgadikian]

@Syed

Looking forward to this launching

Seems to have a hard dependency on hydro, looking forward to that too?

[Syed]

I don’t think it’s a hard dependency - I think Hydro-relation is just that box on the side of one screen.

The rest of the website is coming from onchain data / manual entry, e.g. for the phase 1 Delegator functions:

• Ability to see current/upcoming chains
• See each chains info
• Seeing which vals are validating a particular chain
• and then switching my delegations on the site as a result

[btruax]

@jacobgadikian

Seems to have a hard dependency on hydro, looking forward to that too?

I’ve done UX for both platforms, so can speak to this.

That’s a badge that may only be present on projects that are participating in Hydro.

The page is designed in a way that the badge could be present when applicable and not there when not applicable.

There is no dependency for Hydro in order to launch FORGE and there is no requirement for ICS chains to participate in Hydro.

We will hold an ATOM Zone in a few weeks where I can answer further questions on this platform and we’re open to more feedback, ideas and input via the forum in the interim.

[btruax]

@Syed

This is much more feature-rich than I expected - cudos!

Appreciate that ser!

[Tagu]

Great work! Can’t wait for all of this to be finalized, having few successful consumer chains launch and starting biding on Hydro

[Shotanate]

This looks to be a good UI project.

• I would suggest adding a list of key opinion leaders who can be contacted and used a s channels to distribute information about the upcoming chains off-chain (twitter, TG etc) to help them with traction.
• Could also be useful to add a token section per chain. So that forge offers more granular approach to delegators. The token section could list tokenomics, price and purchase venues for example.

[Seppmos]

Very interesting concept. I like the idea of having a frontend/platform where delegators, validators and aspiring ICS consumer chains can meet and learn about each other.

I’ve a question regarding this:

@jtremback

Validators

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.

So is it basically ATOM restaking what delegators have to do here, or is liquid ATOM required to be delegate to a consumer chain validator in order to earn staking rewards?

• Let’s suppose I delegated some ATOM to StakeCito on the Hub. Thus, does StakeCito also have to validate the respective consumer chain for me to restake/delegate ATOM on the consumer chain, or could I simply delegate ATOM to an alternative validator that is running this specific consumer chain?

[jtremback]

@Seppmos This is purely a frontend to functionality that exists on-chain. The delegate and redelegate functionality in the validator list is just regular Cosmos delegation stuff.

@Seppmos

Let’s suppose I delegated some ATOM to StakeCito on the Hub. Thus, does StakeCito also have to validate the respective consumer chain for me to restake/delegate ATOM on the consumer chain, or could I simply delegate ATOM to an alternative validator that is running this specific consumer chain?

For a given delegation from a delegator to a validator, the delegator will receive rewards for all consumer chains the validator is validating on.

There is currently no concept in ICS of a delegator’s tokens being delegated to different validators on different consumer chains, so the functionality exposed in Forge is just vanilla delegate and redelegate.

[Govmos]

We fully support this proposition and love the envisioned design and features. We also endorse the name being chosen “Forge” as well as the early logo design associated with the branding. Additionally, the notification ability is very welcomed.

Our only suggestion relates to the “idea phase”:

@jtremback

Idea phase: In this phase, the developer reads documentation on Cosmos and bootstraps their chain. The ICS integration with Spawn (a chain bootstrapping tool) is important here. Part of every consumer chain’s repo will be a JSON file defining their Forge chain detail screen, including stats, ICS settings, and badges. While developing their chain, a preview of the Forge detail screen can be generated by inputting a link to the chain’s Github repository.

A coordinated effort is currently underway within the AADAO to develop an interactive front-end experience for engaging with the ICS Financial modeling we released earlier this year: ICS 2.0 Economics: Partial Set Security (PSS) Financial Model.

We strongly recommend merging this initiative with your ongoing efforts with Forge, as they have significant synergies. Selecting the right ICS parameters for a consumer candidate is essential for a successful deployment. At present, consumers receive guidance from the AADAO, the Informal teams, or ourselves to fine-tune these parameters. However, this approach is not scalable in the long term. Therefore, we propose integrating a guided assistant based on the interactive app build by AADAO. This tool would allow consumers, delegators, and validators to understand and adjust parameters themselves, without relying on third-party assistance.

Implementing this solution would significantly reduce fragmentation and create a “one-stop-shop” for ICS, consolidating all necessary resources in one place. We will be happy to assist in making this joint effort between Informal and AADAO happen.

[btruax]

Thanks for these suggestions. I like both of them.

@Shotanate

I would suggest adding a list of key opinion leaders who can be contacted and used a s channels to distribute information about the upcoming chains off-chain (twitter, TG etc) to help them with traction.

This doesn’t feel right for Forge, but perhaps for another website. The initial thought is that this list must be community-managed, though. It sounds prone to drama. I could foresee potential controversy if a KoL is accidentally forgotten to be included, or there will be discussions/frustrations over why some were included because people disagree with their work/funding/impact. It’s not a bad idea, though, as it would be useful for all of Cosmos. It’s just not right for Forge.

@Shotanate

Could also be useful to add a token section per chain. So that forge offers more granular approach to delegators. The token section could list tokenomics, price and purchase venues for example.

This is already designed. These layers are just hidden in the screenshot above. We will go to market as is and then iterate based on feedback. We had the same thinking as you.