Interchain Security (ICS) is launching in 2023 and the Cosmos Hub will become a security provider after the Lambda upgrade. After having funded Proposal #72 and Proposal #77 from the Community Pool, the community has already signalled soft consent around the adoption of Replicated Security, but the Lambda upgrade will finalize its inclusion in the Hub.
The Hub being able to offer security to new projects means accessing the upside of any projects launching on Hub-secured consumer chains. ATOM delegators can benefit from getting staking rewards made up of not only Hub block rewards, but also of the Hub’s portion of revenue on all consumer chains accessing Hub security.
This is a great opportunity to start conversation around the governance and business relationships between provider and consumer chains. Replicated Security will create an interconnected economic zone centred around a provider chain (such as the Hub), so we need to know what kind of partnerships and expectations we can have of both the provider and various consumer chains.
Some norms will evolve as we actively use the technology and learn more about it, but this essay is intended to lay out the basic principles of ICS relationships, point out some interesting ways that these chains interact, and kickstart discussion on developing norms and processes between projects.
In particular, I want to explore the following questions:
- What is Replicated Security?
- What kinds of consumer chains can we expect to see?
- What freedoms do consumer chains need to have?
- What models can we use to think about consumer-provider relationships?
- How can consumer chains and provider chains benefit from their economic relationship?
- What kind of norms exist in the contract formed between the consumer and provider?
- How can consumer chain teams and provider chain teams communicate effectively?
Much of the content I’ll present here is speculative and not intended as a statement of fact. Replicated Security is not active yet, and only a few consumer chain teams are preparing to launch when it’s ready. Both the technology and the norms around it are rapidly evolving and this is just a broad collection of thoughts and ideas about how it might all work out.
This first section, however, is factual about how Replicated Security will work based on its current development (see more in the forum post on the Replicated Security upgrade).
Using Replicated Security, consumer blockchains can lease security from a provider chain, thereby having their blocks produced by the validator set of the provider chain. The formal lease agreement begins with a
create consumer chain proposal passing on the provider chain and can be dissolved by a
remove consumer chain proposal or by the consumer chain forking away from the provider chain’s validator set.
‘Replicated’ means that the entire provider chain’s validator set is required to validate a consumer chain. Validators cannot individually opt-in or -out, and misbehaviour such as double-signing or downtime in producing consumer chain blocks carries the same penalties as it does on the provider chain.
Because the provider chain’s security is replicated entirely, consumer chains necessarily share some properties with their provider. Across all Interchain blockchains, 33% of the voting power is required to censor transactions, and 66% is required to control the chain. A consumer chain could be censored or stopped entirely by >33% of the voting power on its provider chain.
By leasing security from a provider, consumer chains benefit from the provider’s strong validator set and total stake - anyone trying to corrupt a consumer chain would need to take over the entire provider chain. This makes chains like the Hub, which have a lot of stake, excellent security providers because the cost to attack the Hub is so high.
To summarize, these are the key aspects of Replicated Security that form the basis for the security agreement between a provider and consumer chain.
- Governance gating: The addition of a consumer chain is always governance-gated on the provider chain - a new consumer chain must pass a provider chain governance proposal in order to access the provider’s security. The provider chain can also use governance to remove a consumer chain.
- Replicated means all-or-nothing: Once a consumer chain is approved (both by tokenholder governance and >2/3 of the provider chain’s validator set), all provider chain validators must produce blocks for the consumer chain.
- Consensus constraints: A consumer chain is subject to the same requirements as the provider chain - if validators comprising > 1/3 of the total voting power stop running a consumer chain, the chain will halt.
- Cost of corruption: Good provider chains are ones that are already extremely secure and costly to attack - providers confer this benefit onto their consumer chains as well.
There are other, more variable expectations that consumers and providers might have of one another. What follows are some of these more nuanced ideas.
I expect that we’ll see two distinct kinds of consumer chains which will have very different needs and relationships with their provider chains.
Core consumer chains will host integral parts of the provider chain as a way of promoting provider chain minimalism. These core consumer chains will be intentionally dependent on the provider chain, and can be thought of as extensions rather than separate entities leasing security. I think of them sort of like limbs attached to a central body. While core consumer chains are interesting in their own right, they are not the focus of this essay.
Sovereign consumer chains will have their own project, vision, and business case. These independent chains will be forming a business relationship with a provider chain, such as the Hub. A sovereign chain might choose a provider based on values alignment, sharing a vision for the future of the relationship, access to similarly minded developers or supporters, and for the stability that a provider chain can offer. At its core, this would be a business-oriented decision with benefits and commitments from both sides.
The scope of this document is the relationship and expectations between a provider chain and sovereign consumer chains.
Despite being dependent on the provider for security, sovereign chains should still have some measure of independence and ability to self-determine. Sovereign consumer chains have the right to end their lease on the provider’s security by exiting.
Similarly, provider chains should be able to end the lease at any time via governance. This might happen because of misalignment between the chains, because the consumer chain is no longer active, or any number of other reasons I haven’t thought of.
Aside from the agreement to lease security, non-core consumer chains should be empowered to exist as sovereign chains, with the accompanying rights and expectations agreed upon by their own governance system. Provider chains should not interfere in the consumer chain’s sovereignty as it manifests in freedoms such as:
- Censorship resistance
- Respect for property rights
- Participation in local governance
By guaranteeing the sovereignty of its consumer chains, a provider chain will position itself as a credibly neutral source of security. Provider chains will need to maintain good reputations as trustworthy providers of security services in order to attract consumer chains.
Depending on the type of chain being launched, I expect that there will be several different ways to look at the relationship between the two sides. Some chains may generate a lot of revenue from transaction fees or MEV, while others may rely more on the increasing value of their native tokens. Some chains may not even have an initial issuance, but choose to issue a token later on. Two mental models I have been using to think about the relationship between the provider and consumer chains are that of an investment agreement or a service contract.
Provider chain validators will need to take on upfront costs in acquiring hardware and additional labour hours in setup, onboarding, and maintenance. ICS is an emerging technology, and the benefits to both validators and consumer chains might not fully manifest until the technology solidifies.
The relationship between a provider and consumer can be seen as an investment that may not pay off until later. These investments might look like:
- A discount on security services for early consumer chain adopters of the technology who will help iron out bugs and work out issues that arise, such as the funding generated by Proposal 72. Investing in projects like this could also be way to attract talented teams to continue contributing to the ecosystem.
- An initial token swap between consumer and provider chains that could ensure that a consumer chain is well-capitalized early on, and that the provider will have direct exposure to how the project pays off in the long term.
On the other hand, the agreement to provide and lease security can be seen as a service provider relationship, in which the service provider (i.e., The validator set) expects to be evenly compensated throughout the relationship based on the contract terms. These terms could be set on a per-chain basis (e.g., Every consumer chain could propose their own detailed terms and agreements) or a provider chain could create a standard set of terms as the basis of later negotiations.
In either case, a ‘bootstrapping’ or ‘early stage’ agreement to ease the burden of upfront costs can lay the groundwork for good relations as the project matures. These early-stage agreements could look like:
- A consumer chain providing a temporary ‘bootstrapping’ bonus for provider chain validators to subsidize the initial costs of validating a consumer chain.
- A provider-heavy fee split that could decline as the revenue increases and reaches a steady state.
Regardless of whether we think about the consumer/provider relationship as an investment or a service contract, it will end up being some sort of financial relationship. I think it makes sense to understand the baseline economic dependency in addition to the sort of compensation we might see flow from consumer to provider.
Collectively, the provider chain and all of its consumer chains will need to generate enough revenue to satisfy the needs of at least 2/3 of the provider chain’s voting power (i.e., >66% of the voting power must be incentivized to remain online). If this baseline requirement is not met, it’s possible that validators simply can’t afford to operate their nodes and so the chain will halt. This minimum requirement is easy to theorize about, but identifying an actual number is much harder. I use this idea strictly as a way of creating a lower bound on what’s acceptable for a consumer to pay to the provider.
In order to onboard a consumer chain without violating this baseline need, an economic agreement is needed between provider and consumer.
This agreement could be based on a revenue-sharing split (where ‘revenue’ includes transaction fees, MEV, and any other economic benefit created through future partnerships between provider and consumer chain). It could also be formed from an exchange of network tokens, or a mix of both revenue-sharing and token exchange.
Consumer and provider chains have the right to share in revenue generated by the partnership, with the expectation that they can negotiate in the spirit of co-operation, not competition.
Leasing security will be a mutually beneficial arrangement - consumer chains get to access security and provider chain validators are compensated for providing the service. Fair compensation for the service means enabling validators to profit, not just cover their costs.
The compensation between the consumer chain and the provider chain validator set will presumably be established when the chain is accepted by the provider. The proposal put forward by a potential consumer chain will need to clearly lay out the compensation model, since this will be a factor in how provider chain governance decides to vote. I think the compensation model should also be open to adjustment via consumer and provider governance to ensure fair compensation as conditions change.
Some principles that could inform the development of a fair compensation deal:
- Cost for the consumer chain to run as a fully sovereign chain.
- Incremental cost to provider validators to secure an additional chain.
- Protecting a consumer chain from rent-seeking behaviour in which the provider chain is being paid without contributing value.
- Soft benefits of a relationship with a provider chain, such as on-ramps to CEXs, existing IBC connections, access to existing developer community.
Regardless of whether the long-term relationship is best modelled as an investment or a contract, I think considering it as a service-level agreement (SLA) lets us think about the spirit of the agreement. Both parties should continue to operate in good faith under their contract, which means accepting that the basis of the agreement is to pay for security services at a set rate.
Much of what I’m talking about in this essay is off-chain work that relies on social norms and a willingness to work together in good faith.
Behaviour which seeks to change the terms of the agreement without fair communication and negotiation can (and even should) be seen as a breach of the good faith under which the agreement was established. For example:
- Extortion: Forcing the consumer chain to do something through threats, such as being removed from the provider’s security without opportunity for conversation or problem-solving.
- Price manipulation: One chain intentionally manipulating the price of their own token to drastically change the value of the contract.
At some point, it may make sense to dissolve the relationship between a provider and consumer. This could be because of the project going inactive, the consumer chain wanting to become fully independent, or the provider not being compensated enough for the security provided. Regardless of the reason, offboarding a consumer chain should have strong norms to protect both sides. I don’t think the dissolution of this relationship should be taken lightly!
Abrupt and unexpected offboarding would be extremely detrimental to a consumer chain, because they would then need to establish an independent validator set to stay online after being removed from the provider’s security. New projects need a high level of stability from investors and service-providers alike - including their provider chain.
Likewise, a provider chain which forcibly removes consumer chains without due warning and communication will probably have a hard time attracting new projects and being able to invest in lucrative new opportunities. Establishing and committing to strong social norms around dissolving a partnership can only benefit a provider chain looking to partner with new projects.
Due process for offboarding a consumer chain could look like:
- A consumer chain going inactive (no new transactions or blocks for a certain amount of time) and being automatically removed.
- Consumer chain governance choosing to exit the agreement, establishing their own validator set, and putting forward a
remove consumer chainproposal on the provider chain to formalize their exit.
- Hosting polls and community calls between teams to discuss the relevant issues, with a commitment to making and executing a plan for the consumer or provider chain to dissolve the partnership after a set amount of time.
- A provider chain putting up a signalling proposal to gather soft consent for offboarding, then committing to a grace period (in which the consumer chain ought to establish their own validator set) before making the
remove consumer chainproposal. The minimum grace period is one voting period, since these two proposals would probably be sequential, but I think it makes more sense to give at least 2-4 voting periods (4-8 weeks) for a consumer chain to gracefully exit.
It’s also very possible that there will be consumer chains which propose their own specific way of being offboarded, and that will form part of the initial agreement between the provider and consumer.
We assume that some aspects of the security contract are invariant, but it’s still important to be prepared for the possibility of change. Processes around re-evaluating the security agreement will need to be developed long before they’re strictly necessary, and hopefully with the attitude that some amount of flexibility is needed from both provider and consumer.
While remaining within the provider chain’s security, a consumer chain should have the right to propose and discuss increased self-determination while continuing to rely on the provider for security, without fear of being forcibly removed. In order to do this, strong, well-defined norms around conversation and communication will be needed.
Conversation around governance can be hard to follow even at the best of times on a single chain. With Replicated Security, I anticipate that some proposals will be relevant mostly to the consumer chain (e.g., Business planning, budgetary decisions for the consumer chain’s treasury, other signalling proposals) and some will be relevant mostly to to the provider chain (e.g., Community Pool spending, adding new consumer chains, chain-specific signalling proposals). Provider chains, like the Hub, already have their own forums and governance discussion venues, and I expect that consumer chains will also create their own spaces for relevant governance conversation.
Other proposals, I find, are much harder to categorize.
For something like a consumer chain software upgrade proposal, both the consumer chain itself and the provider chain validators would need to know the details of the code that makes up the consumer chain. Such proposals could sensibly be discussed in either chain’s forum, but the important thing is that discussions are accessible to anyone to whom they are relevant. Some ways that this issue might be addressed are things like:
- Regular calls between teams involved in ICS (provider chain validators, consumer chain developers, etc).
- Adequate notification periods for proposal drafts.
- Post formatting to make them accessible to triage bots.
- Tooling to bridge forums and let people participate in both spaces at once.
- Social norms around linking to the provider or consumer chain discussion spaces.
Using Replicated Security, provider chains like the Hub will be able to lease security from their entire validator set to sovereign consumer chains.
I anticipate that consumer chains need self-determination in areas such as property rights, local governance, censorship resistance, and the ability to exit the provider chain’s security.
A provider chain being able to offer that sort of freedom will likely be very attractive to projects, which means being able to be selective over which consumer chains to support. Choosing the best (and most lucrative) projects will provide future economic benefit to the provider chain, its validators, and delegators.
The partnership between these chains will depend on a strong economic relationship in which both sides benefit. To do this, we will need norms around investment, compensation, service-level agreements, and offboarding.
The proposal draft for the Lambda upgrade is on the forum and it will be important for the Cosmos Hub community to have conversations about Replicated Security before consumer chains are onboarded. I’m looking forward to seeing community thoughts both here and on the Lambda upgrade post.