Permissionless ICS marks the next evolution of Interchain Security: allowing anyone to launch a chain on the Hub, permissionlessly.
The first version of ICS, Replicated Security, required a governance proposal to add a consumer chain. This is because the majority of validators were obligated to run each consumer chain.
With ICS 2.0, the majority of consumer chains are expected to use a mode called opt-in security. With opt-in, validators are free to choose whether they want to run a given consumer chain. In principle, this should also enable consumer chains to be created permissionlessly, using a simple transaction instead of a governance proposal.
The current release of ICS still uses a governance proposal to create consumer chains, even though permissionless creation is possible in theory. This is because switching to fully permissionless chain creation will take some refactoring of the codebase and we wanted to stage the work to release something as soon as possible.
We’re about to start on this work and are releasing this discussion-phase CHIPs post to follow the process and just in case anyone has any different ideas or any good reasons to keep chain creation governance gated.
Consumer chain ownership
Consumer chains will also have a new feature called “ownership”. This will allow a DAO, or the consumer chain’s own on-chain governance to control many of a consumer chain’s settings. Some example use cases:
- The development/community DAO of a pre-launch consumer chain sets the spawn time to start the chain once development is complete and enough validators have opted in.
- A consumer chain’s on-chain governance modifies the consumer chain’s DenyList to exclude exchange validators.
- A consumer chain’s governance raises the ValidatorNumberCap to let more validators into its active set.
How it will work
- Anyone will be able to create a new consumer chain using a single transaction.
- A specific account will be the owner of each consumer chain. This account will be able to change metadata at any time, including settings such as validator number cap, validator power cap, validator allowlist, spawn time, etc.
- This could be a single user, but is more likely to be DAO, and in most cases will be controlled by the consumer chain’s own on-chain governance over IBC.
- The spawn time is one of the pieces of metadata that can be modified. This means that a consumer chain can set the spawn time in the future to give it some time to build an initial validator set, and then expedite or delay the launch if necessary.