Principles for Onboarding Consumer Chains into the AEZ
Authors: Darcy Allen, Chris Berg and Sinclair Davidson – RMIT Blockchain Innovation Hub
Across the interchain there have been many conversations about the onboarding and structure of interchain security (ICS) relationships. These conversations have included:
- general community responses to the proposals of Stride, Neutron and Composable (e.g. fee size, protocol owned liquidity, alignment between chains)
- concerns around the microeconomics of validation and the potential for centralisation from ICS
- tips for lowering onboarding frictions
- the use of new structures of governance such as Swiss Booklets in formulating proposals
- in our most recent post we emphasised the need for reviews and governance structures that would allow for agreements to evolve in the light of changing circumstances.
In this post we build on these community contributions, combined with our research through funding from the Atom Accelerator DAO (AADAO), to ask how the Cosmos Hub should navigate the onboarding of new consumer chains into the Atom Economic Zone (AEZ).
We do not provide a specific one-size-fits all answer. Each producer-consumer chain relationship is unique. That’s the great thing about the Cosmos ecosystem – sovereign chains are heterogeneous chains that can experiment with different revenue and business models. But that means that each ICS relationship will differ, particularly in terms of how the consumer chain compensates the Hub for security (e.g. revenue share vs token swap models).
In a future post, we plan to publish a decision tree that takes into account the heterogeneous types of consumer chains (such as those which have a native token and those which do not, those which are existing projects and those which launch with ICS) and map them to the range of potential mechanisms. In this post, we outline some general principles through which we believe the Cosmos Hub community should craft and negotiate ICS agreements. We welcome any feedback on these principles.
Infrastructure or venture?
There is a basic question underpinning how we onboard consumer chains that we don’t think has been adequately explored: what is the fundamental objective of an ICS relationship? Or what sort of business is ICS?
We propose that there are two distinct ways to think about ICS relationships:
- as an infrastructure relationship, or
- as a venture relationship.
Infrastructure
If we think of ICS as infrastructure relationships, then consumer chains are buying specialised services of the Cosmos Hub to generate new, predictable and ongoing revenue streams. The Cosmos Hub is selling or leasing high quality and comparative low cost security to consumer chains and in return receives some stable income. Put another way, the Cosmos Hub is a service provider. There are all sorts of benefits from this relationship of course (such as alignment with the Hub and all the consumer chains within) but fundamentally to think about ICS as an infrastructure business is to think about it as service provision, and it should be priced as such.
Venture
Alternatively, the community might think of ICS as a venture relationship. In this way of thinking, the Hub is providing security as part of its investment in a sovereign chain, in the same way that venture capital provides advice and networking for firms it invests in. Through ICS the Cosmos Hub can support smaller chains and receive upside (or downside) on those relationships. Here, the objective for the Hub is not primarily about ongoing stable revenue, but rather that the Hub will make potentially loss-leading investments (e.g. subsidising the security of chains) while hoping for future potential upside.
How we view ICS relationships changes how to structure them
The way that the Cosmos Hub views their relationship with any given consumer chain changes the way they should structure those agreements. The relationship type impacts the effective agreement structure both because (1) the objectives of the agreement differ; and (2) the fundamental risks of the agreement differ. That is, the structure should be guided by different contracting risks that come along with each chain, and the different purposes of the contract is to achieve different things. From this perspective we can start to think through what structures are available to different types of relationships (e.g. fee for service vs revenue share vs token swap).
Nevertheless, we propose that the design of all agreements should be guided around two aims:
- The relationship is mutually beneficial: everyone should stay happy.
- The relationship mitigates hazards: mitigate the unique contracting risks of the relationship that result in the relationship to collapse (either in vertical integration or exit).
While each agreement will address some common headings (e.g. payment terms, governance processes, exit clauses), the features of each of these will differ. There is a large range of mechanisms which can be part of a consumer-producer relationship, only some of which have been adopted in the ICS relationships thus far. Note that these are not mutually exclusive (e.g., a revenue share model could be matched with a one-time payment).
- Revenue share: The consumer chain pays a share of their revenues to the producer chain. Revenues could include transaction fees, inflation, MEV revenue, and so on. Those revenues may change over time as the chain evolves (both in terms of the types of revenues a chain receives, and the volume of revenues). Revenue share could be paid in either ATOM or the native token of the consumer chain (if they have one).
- Fee for service: Consumer chains pay a price per transaction (or some other defined unit, such as a price per block) in either ATOM or the native token of the consumer chain.
- Token swap: The consumer chain and producer chain undertake a treasury swap, where they swap their own native assets in some determined ratio (e.g. ATOM for the native asset of the consumer chain).
- Bond: The consumer chain passes control of a quantity of a yield generating asset (such as staked ATOM) to the Cosmos Hub. The generated yield is owned by the Hub. When the relationship between the consumer chain and the Hub ends, the bond is returned. If the consumer chain violates the terms of any of its agreement, the bond can be slashed or confiscated. This is obviously most suitable for agreements that have a fixed term.
- One-time payment: The consumer chain makes a large upfront payment for ongoing security provision. This is most useful where there are high fixed costs for onboarding chains.
- Debt: The consumer chain borrows a valuable asset up front from the Cosmos Hub (e.g., ATOM), and pays the principal and interest down over time.
Deciding on a payment structure
As these examples suggest, these mechanisms are highly dependent on the economic characteristics of the chain – as well as the availability of enforcement mechanisms. As we noted in the previous post, every chain in the AEZ is sovereign, so ultimately a consumer chain will always have the ability to end its relationships with the Cosmos Hub. But that also gives the consumer chain flexibility to change its revenue sources in a way that might disfavour the Cosmos Hub. Mechanisms should be chosen with an eye to minimising the governance risks embedded in contractual relationships with fully sovereign counterparties.
An infrastructure relationship
If a proposed consumer chain primarily fits the category of a service relationship, then the relationship should tend towards:
- Favour fee for service or revenue share models.
- Denominate revenues in ATOM.
- Longer periods between agreement reviews.
Typically these relationships will be for more established chains, with less variance in their project revenues, and with an established user base. A infrastructure relationship could differ in several ways to meet the objectives outlined earlier:
- The revenue share model can be set on some declining schedule, with higher revenue share in early periods and lowering as the consumer chain (potentially) grows.
- The revenue share can be stepped, with a higher rate until some fixed cost for the validators is paid off (e.g. there is rate prior to some value being paid off, and then rate declines once that is paid).
A venture relationship
If a proposed consumer chain primarily fits the category of a venture relationship, then the relationship should tend towards two things:
- Favour payment models such as token swaps
- Denominate agreements in the native token of consumer chain
- Shorter periods between reviews (because of the rapid change of pace in the relationship)
Typically these relationships will be for new or smaller chains, and are more speculative. The purpose of these relationships for the Cosmos Hub is to take on risk with onboarding consumer chains. Note that this risk constitutes the opportunity cost of onboarding (i.e. the Hub could be onboarding a different chain) but also the fixed costs that are borne disproportionately by the validators.
Some mechanisms are less appropriate or useful for venture based relationships. For example, the Hub and consumer chains should be wary of imposing fees on chains that it wishes to maximise the upside on as any such fees may shrink the path to success for that chain. Venture investments are long term and do not typically involve the imposition of direct costs on the invested entity, not least from the moment of their creation.
The critical problem of foreign exchange risk
The distinction between infrastructure and venture relationships helps us understand one of the most critical decisions that have to be made when onboarding to ICS: whether payments (or bonds, or debt) is denominated in ATOM or in another token (such as the consumer chain’s native token, another generally accepted valuable token such as wETH or wBTC, or a stablecoin).
The fundamental issue is whether the Cosmos Hub wishes to accept foreign exchange risk should the payment token diverge in price from ATOM. This is one of the most significant risks to the success of an ICS agreement: the value of the payment token dropping such that it is uneconomical for validators to continue to validate the consumer chain and thus putting their participation in validation of the Cosmos Hub under question.
If we think of ICS as infrastructure relationships, then (downside) foreign exchange needs to be mitigated. Ideally, payment for service would be in a token that maximises stability, and therefore the stability of revenue.
Let us imagine the ideal approach from the Cosmos Hub’s perspective. At the first instance, this could be a stablecoin (after all, validators are likely to pay for their equipment and other services in fiat currency). The payment would be structured such that it paid for the services produced: so rather than a revenue share model, the payments would be a fee-for-service one based on block production.
However, insisting on stablecoin payments could impose a cost on the consumer chain, potentially requiring them to exchange their transaction fee token to stablecoin and shifting the foreign exchange risk to the consumer chain. The consumer chain would be correct to insist on a discounted payment to the Hub to compensate for that risk. Likewise, a consumer chain would find a fee-for-service model would be difficult to commit to when the success of the chain is uncertain.
A more realistic and reasonable model is to require payment in ATOM. This has the advantage of reducing foreign exchange risk (ATOM price could go up or down but by definition validators and ATOM holders are already exposed to this risk) and providing additional demand for the ATOM token. However, it is most suitable for chains that are already using ATOM as a fee token.
The infrastructure approach means that the Cosmos Hub fails to capture the upside of a consumer chain’s success but at the same time it is (modestly or entirely) protected against the downside. This is appropriate for a service based relationship.
Viewing ICS as a venture relationship makes for very different considerations. For a venture relationship, the foreign exchange risk is a positive – the Cosmos Hub wants to be exposed to an asset that it believes has a likelihood of success. Thus, as noted above, the Hub would be seeking to acquire significant quantities of the consumer chain’s native token as early as possible in the relationship (minimising the ‘entry price’ of the investment).
The potential failure of that asset is a known hazard in investing and is mitigated by ensuring that there are a lot of ‘bets’ out in the market. For the venture approach, the Hub should be seeking to onboard a significant number of consumer chains (say 10-20). Note that the cost of onboarding borne by validators remains – thus some external party (either the consumer chain or the Cosmos Hub) might seek to compensate the validators for their work, or some part of the investment returns might be ring fenced to provide bonus rewards to the validators should the consumer chain succeed.
Overarching considerations
What we have outlined above are two broad categories by which we can think about producer-consumer chain relationships. In practice there will be many projects that merge both the objective of an infrastructure relationship with a venture relationship.
In any case, there is still the question of pricing the agreement (e.g. what should the revenue share, fee or token swap be). Generally a useful guide for pricing is that agreement should:
- Cover the variable cost of the validator
- Cover the fixed cost of the validator (onboarding costs) in the long term
- Result in profits to both the producer and consumer chains
Within each of these categories – either service relationships or venture relationships – there are several factors that shift the parameters (e.g. higher or lower revenue share percentages). Two of the major factors are:
- The risk profile of the consumer chain in terms of generating revenues. This can be demonstrated through evidence-based fee proposals, but is nevertheless speculative. For projects with higher risk the revenue share or fees should increase. New chains will typically have higher risk profiles.
- The governance of the consumer chain. This describes the extent to which the consumer chain has governance rights that enable them to act opportunistically around the proposed agreement. Consumer chains with governance rights (and particularly where payment is denominated in a native token) tend towards a higher rate.
We have no doubt that there are a wide variety of views in the Cosmos ecosystem as to the desirability of the infrastructure or venture view. There are clearly situations where one or both are the better view. However, in our view, the Cosmos Hub should be wary of over-reliance on the venture model. Venture investing is a specialised field that requires not just a specific skill-set (much of which can be found in the community) but also strict governance controls to ensure that investments are realised. Decentralised governance – particularly that of a fully open community such as Cosmos – is not necessarily the ideal venue for making realistic decisions for both investing and profit-taking. Potential governance overlap between the Cosmos Hub and a consumer chain might add additional complications.
We welcome any feedback and discussion on this post – particularly on the distinction between an infrastructure and venture view of ICS relationships.
Darcy Allen, Chris Berg, Sinclair Davidson
RMIT Blockchain Innovation Hub