Preparing for Replicated Security

[lexa]

Introduction

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:

1. What is Replicated Security?
2. What kinds of consumer chains can we expect to see?
3. What freedoms do consumer chains need to have?
4. What models can we use to think about consumer-provider relationships?
5. How can consumer chains and provider chains benefit from their economic relationship?
6. What kind of norms exist in the contract formed between the consumer and provider?
7. 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.

1) Replicated Security

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.

2) Types of consumer chains

I expect that we’ll see two distinct kinds of consumer chains which will have very different needs and relationships with their provider chains.

2.1) Core consumer 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.

2.2) Sovereign consumer chains

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.

3) Self-determination

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.

4) Modelling good relationships

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.

4.1) Investing in consumer chains

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.

4.2) Providing a service

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.

5) Economic co-operation

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.

5.1) Baseline agreement

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.

5.2) Ongoing fair compensation

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.

6) Respecting the contract

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.

6.1) Operating in good faith

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.

6.2) Graceful offboarding

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 chain proposal 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 chain proposal. 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.

7) Communication norms

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.

Conclusion

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.

[Ghazni_Stakecito]

Skimmed through the post and I echo the sentiment of subsidising the early consumer chains.

I feel like there will be some chains which will underpay the validator set (specially problematic for lower ranked validators) for the value they provide. Can we also subsidise such validators?

Will also like to see some data to study the incentive alignment between {cost to run consumer chain infra + slashing risk} vs the incentive structure of the consumer chain vs {the amount of stake needed on Hub for a validator to break even on a particular consumer chain}

[tknox35]

Maybe a simple solution is to create a form for small validators to apply for grants. Throw them some Atom to assist with up front costs in this initial phase. I think that suits the interests of the hub community to keep these small validators afloat and supported while this new tech is being ironed out.

[common_spelling]

other than circle, what benefits do the other potential consumer chains offer to ATOM? im not entirely sure how many consumer chains validators will be expected to include, but why would the chain fund consumer chains at a loss to both small validators and the chain?

[lexa]

@tknox35
Interesting thought. I think it leads us to a broad question - is it the responsibility of the Hub to keep the small validators afloat during Replicated Security, or is it the responsibility of each consumer chain? Or a combination (e.g., Some Hub support and some consumer chain subsidy as well)?

@common_spelling
My perspective is that by coming together in a shared economic system, consumer chains are incentivized to act with the wellbeing of ATOM in mind. One of the ideas I mention is of a token swap, which would keep ATOM on the balance sheet of the consumer chain, which would be motivated to act in the best interests of ATOM - I think that’s sort of a heavy-handed example of what I mean by an incentive though!

That would be my personal expectation for why the Hub could fund consumer chains even if there’s an expected initial loss. Realistically, I don’t think the Hub would continue to secure chains operating at a significant loss.

There is no number of consumer chains that validators will be expected to include. The launch of Replicated Security is just about making it possible, and there isn’t a consensus on how many chains the Hub should provide for. I think it’s actually impossible to pin down that number - depends too much on how lucrative each project is, what kinds of returns the Hub gets, and how much effort it is to provide for them. We just don’t have those answers yet, and I don’t think we can get them without actually trying it out.

I do think the onus is on the prospective consumer chain to prove that a relationship between it and the Hub makes sense. And by approving Game of Chains and Prop 72, the Hub has indicated that it’s going to give these chains a fair shot to make their case.

[LeonoorsCryptoman]

To understand correctly:

• (2.1) with core consumer chains you mean for example a chain focussed on smart contracts which is tightly bound to the provider chain? Such that without implementing the smart contract code in the provider chain, you still have the benefits of that feature?
• (3) With the completely same validator set, how can you expect to run fully sovereign? Is that only applicable if you lease a subset of the provider chain? Otherwise local governance would be quite hard to achieve imo. Furthermore if the provider chain validators can choose to drop a consumer chain, you will never get a fully sovereign set, unless they fork away.
• (7) Adding the regular call option in there makes RS automatically only suited for bigger validators. Smaller validators who are running (near) solo who are expected to keep their infrastructure up-to-date AND participate in calls… that is a lot to ask imo.

Although I very much love the work you have put into this essay (for which I say; thanks @lexa!) I am a bit worried that this is only being discussed now, a few weeks before the proposal goes on-chain. Which means that (again) something is developed tech-wise without thinking about the softer factors how we actually want to manage this. That is really worrysome in the Cosmos-ecosystem, because this is done time after time again, without learning from these mistakes. Tech is just one side of the medal…

Regarding the idea from @Ghazni_Stakecito; in the beginning some kind of additional incentive might be useful. RS has to be used to prove its worth and become attractive for bigger, better and more lucrative chains. So keeping smaller validators afloat in the beginning would be a good move imo.

[lexa]

(2.1) - That could be an example of it, yes. When I was figuring out this thought, I was also thinking about things like the Allocator and Scheduler being hosted on core consumer chains.

(3) - Right now, there is no possibility for leasing only a subset of the provider chain, so I wasn’t thinking in terms of a semi-sovereign or sovereign validator set. More so that the Hub’s validators and community can vocally commit to giving a consumer chain the right to make their own decisions.

By ‘local governance’ I mean, for example, that if the consumer chain has a native token then the entire chain’s governance could operate as a DAO with that token, and the provider chain’s validators are not at all involved in the local governance of that DAO beyond also being DAO members by holding that token. ‘Local governance’ might involve budgeting for the consumer chain’s treasury, signaling proposals about new features, etc.

It would look bad for the Hub to secure a consumer chain and then start censoring blocks or changing their local gov decisions, so a commitment to allowing for ‘self-determinism’ is saying, at the very least: “We want you to have the power to make your own decisions, and we’re here to provide security based on the agreement but not to take over your project and force you to do things”.

(7) Very fair, that’s a good point. I’m curious if some of the groups that validators are forming would be able to help disseminate information that comes out of calls. Validator Commons, for example?

I generally prefer robust async communication, so I’d prefer making sure we have good tooling and notification policies over regular calls

Thanks for your thoughts! Always enjoy hearing from you.

[moyed_a41]

@lexa

By ‘local governance’ I mean, for example, that if the consumer chain has a native token then the entire chain’s governance could operate as a DAO with that token, and the provider chain’s validators are not at all involved in the local governance of that DAO beyond also being DAO members by holding that token. ‘Local governance’ might involve budgeting for the consumer chain’s treasury, signaling proposals about new features, etc.

I really appreciate the detailed thought about upcoming replicated security. I think it would be a game with whole new rules especially for consumer chains. About the local governance, I agree that it would be similar to DAO governance or Optimism’s model. One thing that stands out is that few(or, many) proposals would not only affect the consumer chain itself, but also the provider chain, hub especially.
So, how can we design a governance structure where soveriengty of consumer chain is preserved, but also hub’s stakeholders opinions are also reflected? Maybe a bicameralism like Lido? I don’t know, but I think its a topic we should deeply research & think about!

[VK_S16]

I’m interested in the economic cooperation between provider and consumer chains. As validators of course we would like to receive good revenue in exchange for our services of providing security. But we also think that projects would need time to be successful and generate a lot of revenue.

How do we assess the consumer chain performance? What are the metrics? Timeline?
How can we support them?

One question, if the consumer chain doesn’t have a token, they can pay in any currency?

Thanks.

[Cryptopital]

I am really impressed, “bravo” for this work, I will take the time to read everything carefully to make my comments.

Anyway, the idea of formalize the relationship between the HUB and the consumer chain is obviously very important and you did a nice job by bringing the subject to the table.

[common_spelling]

what does keep ATOM on the balance sheet mean? How does it motivate consumer chains to atom’s benefit?

@lexa

One of the ideas I mention is of a token swap, which would keep ATOM on the balance sheet of the consumer chain, which would be motivated to act in the best interests of ATOM - I think that’s sort of a heavy-handed example of what I mean by an incentive though!

it takes the permission of <25 validators to adopt a chain that 175 have to run nodes for.

why not create an auction consumer chain that lets people buy into project white papers instead of using the liquidity that secures the chain to bootstrap solutions looking for problems. allocator consumer chain etc.?

why would you subsidize a consumer chain with atom’s liquidity in addition to accepting its illiquid farming/fee token to use ATOM’s security?*

[lexa]

@VK_S16

How do we assess the consumer chain performance? What are the metrics? Timeline?
How can we support them?

Great questions. I think the low-hanging fruit of assessment (from the Hub’s perspective) would be in the revenue being generated, but I’m not sure how we would check on softer metrics. How do we measure the success/performance of any blockchain in the space?

The timeline is something I think each chain would present since their project leads are in a better position to lay out their intentions from the start.

One question, if the consumer chain doesn’t have a token, they can pay in any currency?

If the consumer chain doesn’t have a token, they’d pay in ATOM if the Hub is securing them.

However, the sdk allows chains to whitelist tokens that can be used for fees (‘fee tokens’) so it’s possible that a chain could use a token other than ATOM…I just don’t know why they would. Since Hub validators would be accepting the fees, it might have to be a token that’s enabled on the Hub too…and I think we only use ATOM right now. I’m a bit fuzzy on this detail so if anyone has a correction, I’m open to it

---

@common_spelling

what does keep ATOM on the balance sheet mean? How does it motivate consumer chains to atom’s benefit?

It means that when a chain looks at all its assets (various tokens), ATOM is on that list - it could be in their treasury or whatever equivalent of a community pool they have.

For example, I have ATOM on my own balance sheet. I’m an ATOM-holder I’m motivated to behave in ways that keep ATOM highly valued (since I want my own wallet to be worth more). If a consumer chain also holds a pile of ATOM, they will (presumably) want ATOM to remain high-value since that makes their holdings high value.

it takes the permission of <25 validators to adopt a chain that 175 have to run nodes for.
It’s a problem that goes way further back than any individual proposal. It takes the permission of a small subset of entities to make anything happen (just because of how the stake is distributed) and I’d love to see more conversation about how to address that directly. I don’t know how each proposal can make strides towards addressing this problem.

I don’t want to dismiss this out of hand, but I also don’t know how to solve it strictly in the context of ‘launching ICS’, y’know? On a personal level, I want this feature to launch so that we get the opportunity to see it in action and actually give these prospective consumer chains a chance to see how they’ll solve the problem. My hope is that some of these teams will have ideas that help us brainstorm ways to decentralize our validator set on the Hub itself.

why not create an auction consumer chain that lets people buy into project white papers instead of using the liquidity that secures the chain to bootstrap solutions looking for problems. allocator consumer chain etc.?

The ideas I threw out there about swapping liquidity are to create an initial values alignment where both parties are motivated to look out for each other’s best interests. In a buy-in auction (sort of like crowdfunding?) I don’t think we get that values alignment between the two chains.

why would you subsidize a consumer chain with atom’s liquidity in addition to accepting its illiquid farming/fee token to use ATOM’s security?*

I think it’s an investment - the Hub might offer this subsidy with the expectation that it will pay off later. I don’t think we can access lucrative investment opportunities without being willing to take some risks, and the actual risks we’re willing to tolerate are up to the voters. I’m generally risk averse, but I’d still rather have the opportunity to invest than not.

[LeonoorsCryptoman]

I don’t want to dismiss this out of hand, but I also don’t know how to solve it strictly in the context of ‘launching ICS’, y’know? On a personal level, I want this feature to launch so that we get the opportunity to see it in action and actually give these prospective consumer chains a chance to see how they’ll solve the problem. My hope is that some of these teams will have ideas that help us brainstorm ways to decentralize our validator set on the Hub itself.

Agreed on this
Maybe ICS can reward lower ranked validators a bit more than higher ranked. The high ranked will then still have a decent APR, but the lower ranked slightly more (just thinking out loud)

I think it’s an investment - the Hub might offer this subsidy with the expectation that it will pay off later. I don’t think we can access lucrative investment opportunities without being willing to take some risks, and the actual risks we’re willing to tolerate are up to the voters. I’m generally risk averse, but I’d still rather have the opportunity to invest than not.

Not to forget that RS adds a layer of utility to ATOM. Which means that subsidizing the concept (at least in the early stage) might prove the PoC and get it moving past the phase of experimentation and early adopters. So I would certainly vote for a little incentive to make the early chains a bit more financially stable to pay the validators for the groundwork.

[common_spelling]

@lexa

I think the low-hanging fruit of assessment (from the Hub’s perspective) would be in the revenue being generated,

what revenue? they are paying us back with an illiquid consumer chain token.

If we make the farming/fee token liquid using a token swap thing like the allocator, it is just bleeding Atom liquidity and security from the chain to validators and devs/founders that get oversized allocations.

@lexa

It means that when a chain looks at all its assets (various tokens), ATOM is on that list - it could be in their treasury or whatever equivalent of a community pool they have.

who controls their balance sheet? and how does an illiquid farming/fee token holding on to Atom or Atom Debt incentivize them to act in alignment with Atom?

[serejandmyself]

@common_spelling

they are paying us back with an illiquid consumer chain token.

I mean harsh intonation, but this:

they are paying us back with an illiquid consumer chain token

Is kinda true… I mean, what can be said here is the same what is applicable to supply chain rules in a free market. If a supplier delivers rotten tomatoes in one of the boxes which they keep hiding, they will lose reputation and the buyers will simply switch supplier. True. If a chain ends up being useless and that’s what they offer, I’m assuming, the validators would drop it. Or even more - that chain would lose all reputation as a consumer chain and will to be able to hire new validators. And then again… On a free market, there will always be someone willing to take on the job.

With all of that said. That sentence is still kinda true. And I think it should be thought about in detail

[common_spelling]

it seems like a mistake for ATOM to incentivize chains willy-nilly that dont offer clear benefit to the chain.

IMO LSD chains offer no value to the chain, adds cost to small validators, and pays for transactions with it’s minimally liquid farming token. Further funding such an obvious burden on the chain seems either negligent or corrupt.

circle has many obvious benefits. Neutron seems beneficial and provides a SC LSD. not sure what other consumer chains will be proposed, but I hope that economic impact isnt only gauged on, untested, projected volume when they are paying in an illiquid farming/fee token.

[lexa]

If a supplier delivers rotten tomatoes in one of the boxes which they keep hiding, they will lose reputation and the buyers will simply switch supplier.

This is pretty much it, imo. The Hub isn’t going to take on chains willy-nilly; we’re a premium provider and can afford to be choosy but we also have to treat our customers well. This is purely personal speculation, but I doubt we’ll end up securing more than a dozen chains at the absolute most. I think we’ll launch 3-6 (incl projects funded by prop #72) and the bar for quality will be super high.

Neutron and Circle are among the first consumer chain we’re going to see try to launch on the Hub and, as you’ve said, they seem to have obvious benefits. If we can conceive of consumer chains that have benefits to the Hub, why the uncertainty about Replicated Security as a feature? Am I misinterpreting what you’re concerned about?

[Guinch_Roze]

technically how many channels can be secured by the hub? is there a limit?

[lexa]

There’s no physical or technical limit that I know of. If we had all the infra and person-power in the world, we could keep adding forever.

More realistically, there are personal and business limits such as:

• Number of nodes validators are willing to run (since it takes one per chain)
• Decreasing ROI (return on investment) for securing new chains as we scale up
• (Maybe) Increased network activity affecting block time in the long run

These business reasons are why I personally think we’ll end up with a pretty low number of really high quality consumer chains. Chains other than the Hub will also likely become security providers, so in the future, consumer chains will probably be shopping around for a good provider and it’ll be about finding a good fit.

[Guinch_Roze]

suddenly the Hub could provide security to a subordinate hub which itself could provide its security technically? It could be the definition of really high quality consumer chains ?