Introduction:
Given the upcoming launch of ICS 2.0, referred to as Partial Set Security (PSS), we have been tasked to build a financial model as part of a grant submission to the Atom Accelerator DAO (AADAO). Given the prevalent misconceptions regarding shared security models, we recognized the critical need to address this matter. Our proposed solution involved developing a comprehensive financial model to elucidate the underlying mechanics and propose paths to create equitable and durable Consumer Chain (CC) agreements. A dynamic sheet to visualize the model is linked at the bottom of this post, and a website front-end for this is currently being developed by AADAO to enhance the tool’s usability.
Abstract:
The model is constructed to consider the perspectives of four key stakeholder groups in PSS design: consumers, validators, delegators, and the Hub. We propose a solution that addresses the interests of all parties, seeking a financially viable compromise. To facilitate analysis, we have included examples and examined the underlying trends in PSS’ variables as they evolve across diverse revenue models. This forum post is meant to decrypt the model itself as well as all of the underlying conclusions this analysis depicts.
Context:
Previously, all validators on the Cosmos Hub had to participate in securing consumers, also known as ICS 1.0 or Replicated Security. PSS eases this requirement. Now, only a subset of validators needs to secure each consumer chain. This allows for:
- Scalability: More consumer chains can be launched without overwhelming the validator set.
- Specialization: Validators can choose which chains they want to secure, potentially leading to better expertise.
- Consumer Chain Control: Consumer chains gain more control over their security, choosing specific validators they trust to participate in their security and limiting the voting power to prevent centralization.
- Efficiency: By reducing the overall workload on validators, PSS can improve efficiency within the Atom Economic Zone (AEZ).
To clarify the financial structure of PSS, we must examine the essential component of the agreement between the Provider Chains (Hub) and Consumer Chains (CC).
OVERVIEW:
During this presentation, we will delve into numerous details to explain all the underlying complexities this system involves and the proper ways to find a durable balance. Before we proceed, we would like to offer a simplified streamline overview highlighting all the major steps a consumer candidate should follow:
A. THE SECURITY BUDGET:
A key initial task for a balanced PSS agreement is to establish the security budget, including validator set costs, and delegators’ compensation. Validators incur infrastructure expenses to operate a consumer, estimated at a conservative 500$ per operator (annualized at 6,000$), assuming a decrease over time from Cosmos SDK and infrastructure advancements. To contextualize, @ChorusOne-Research had previously estimated this to 15,000$ annually in an older document you can visualize here.
To evaluate the security budget, it’s necessary to estimate revenue projections for the consumer candidate. However, as this involves forecasting, it’s crucial to have financial experts review the assessments. We have included a “monthly estimated revenue” field and a “revenue growth rate” in the model. For more personalized revenue projections, consumers can input their own numbers in the “Data” tab, for a 30-month period.
This example illustrates a hypothetical, intricate revenue forecast that incorporates cycles, showcasing the extensive customization capabilities.
The implementation of a revenue-based structure, using a dollar amount, in the proposed model is intended to enable complete abstraction of the native token. This design choice, rather than a drawback, aims to exclude supply inflation and speculative price fluctuation dynamics from the PSS agreement, thereby minimizing unnecessary volatility. To accomplish this, we recommend utilizing ATOM or a stablecoin for security budget. A viable approach is to establish them as native gas token in the consumer chain, or even consider gas-less systems via subscription models or service fees, thereby creating various revenue streams. These streams can then be easily converted into ATOMs before being distributed, as per the pre-established conditions. In essence, this is merely a suggestion, as consumers can still pay security providers using their local currency. Yet, this method transfers the risk of currency value changes to the validators and the delegators.
We believe PSS allows us to completely review the current paradigm consisting in using inflationary native token supplies to finance security costs, developer teams and early investors. We expect most ICS Cosmos chains to function without a native token.
To fund validator fixed costs, we must examine their net cash flows, subtracting infrastructure expenses. For precise financial forecasting, we calculate the cumulative “Discounted Cash Flow” (DCF), which accounts for the time value of money. This method determines the present value of all the future cash flow (money you expect to make). Our research covers a 30-month duration, meaning the cumulative DCF represents the validator’s total expected profits over this span, considering a 5% devalued cost of capital per year. This 5% parameter can be adjusted in the model.
Understanding that validators are for-profit entities, we suggest a quantitative framework where their earnings are aligned to consumer income. To achieve this we developed a novel approach we called “Validators/Chain Revenue Ratio”**. This ratio allows us to estimate the relative share of the value distribution going to validators as a percent of the revenue going to the consumer chain. Fundamentally this is a ratio between the 30 months cumulative DCF projection of both entities. Our study revealed the following:
- below 1% : extremely low.
- between 2-5% : healthy ratio.
- above 10% : extremely high.
Put simply, a 2-5% ratio implies that, after a 30-month outlook of the revenue model, validators would earn 2-5% compared to what the chain does, therefore directly tying their profit margin. This is the most efficient solution to foster a thoughtful partnership with shared interests.
Our model also provides a plot of each individual monthly cash flow (red line), which should mostly remain in positive territory, otherwise signaling operators performing at a loss over infrastructure costs. This can be acceptable for a short period of time, only if future cash flows compensate for the temporary lack of performance. But other mechanisms can be used to supplement the low-revenue phase of such early stage projects.
Utilizing the model, we quickly realized that there would be multiple cases in which early stage project may encounter validator profitability problems during an initial low-revenue phase. We took inspiration from @Neutron 's case which decided to grant validators with a vested 10000 NTRN token allocation to compensate for these exact problems. We thought it was essential to include this in our model.
For consistency, we have set this allocation in $ terms. To ensure accurate valuation, consumers must compute the real value of their allocation, including discounted supply inflation. If you require assistance with financial calculations, please reach out to us directly via email.
The model enables you to set an amount and vesting duration to gradually release an initial subsidy to compensate validators for infrastructure costs until revenue can support them directly. Alternatively, you can manually set monthly values in the “Data” tab of the model to bypass the proposed linear vesting system.
If we examine a practical example, on the left chart, we see that validators operate at a loss for nearly a year, as the monthly cash flows corresponding to the red line are negative. Accounting for the accumulated losses over that period, it would take a second year to reach net profitability, when the cumulative DCF turns positive as well. We can use that duration to define the necessary support required to alleviate that loss, therefore setting the “Incentive Vesting” parameter to 24 months. Then, searching for the appropriate incentive grant amount in order to align with the required 2-5% revenue ratio we saw previously. In this example, delivering 100,000$ over 24 months would correspond to transforming the left chart into the right chart, where the early loss is nearly canceled.
The genuine profit distribution requires the inclusion of delegators, who indirectly assume the risk of default from validators through downtime or misconduct. The reference parameter linking the delegator’s share is the Validators %fee. Although validators can set their own fee, an average value is provided as a guideline in this model. The concept of “fairness” aims to facilitate individual decision-making, promoting wholesome competition while preventing excessive deviation from the proposed value.
Consider a prototype consumer seeking to make a prudent decision that balances various PSS parameters. For instance, suppose this consumer anticipates a monthly revenue of $100,000. In our model, we input this figure with a stable 1% growth rate. The next variable to consider is the security budget or the number of validators, as these two values are interdependent. Assuming the consumer aims to operate the lowest possible security budget, we can proceed accordingly.
| Step 1 | Step 2 | Step 3 | Step 4 | Step 5 | |
|---|---|---|---|---|---|
| Revenue for Security | 3% | 4% | 5% | 6% | 6% |
| Number of Active Validators | 4 | 4 | 4 | 4 | 5 |
| Annual Security Budget | $41,742 | $55,656 | $69,570 | $83,484 | $83,484 |
| Validators/Chain Revenue Ratio | 1.19% | 2.25% | 2.27% | 2.23% | 2.02% |
| Validators %fee | 100% | 100% | 80% | 70% | 70% |
We input four validators, constituting the reasonable minimum for cometBFT consensus, while adjusting the validator fee at 100% to minimize expenses (Step 1). However, the revenue ratio is below 2% with a 3% security budget. To meet the minimum ratio of 2%, the security budget is increased to 4% (Step 2). Unfortunately, in this case, all the security budget would be allocated to validators, leaving none for delegators. To decrease the validator fee, the security budget must be raised (Step 3). For instance, with a 5% security budget, the ratio remains at 2.27%, while 20% of the fee is allocated to delegators, with the remaining 80% going to validators. Alternatively, with a 6% security budget, the fee can be reduced to 70% (Step 4). Moreover, at a 6% security budget, a fifth validator could be considered, as the ratio would be 2.02% (Step 5).
Consider an alternate scene where, instead of prioritizing low-cost, we seek to establish a foundational level of decentralization, hypothesizing that approximately 25 validators are necessary. In this case, we will attempt to quantify the revenue allocation for security purposes, employing a comparable iterative approach.
| Step 1 | Step 2 | Step 3 | Step 4 | Step 5 | |
|---|---|---|---|---|---|
| Revenue for Security | 13% | 14% | 17% | 19% | 20% |
| Number of Active Validators | 25 | 25 | 25 | 25 | 26 |
| Annual Security Budget | $180,881 | $194,795 | $236,537 | $264,365 | $278,279 |
| Validators/Chain Revenue Ratio | 1.71% | 2.90% | 2.52% | 2.21% | 2.54% |
| Validators %fee | 100% | 100% | 80% | 70% | 70% |
In a validator configuration of 25, a ratio of over 2% is achieved when 14% of the revenue is allocated for security (Steps 1 and 2). This represents the minimum security cost for this particular setup at around 200,000$. To decrease the validator fee to 80%, the budget must be increased to 17% (Step 3). If the goal is to further lower the fee, then 70% require 19% of the budget (Step 4) and so on. With 20% of the budget, an additional validator can be added in (Step 5).
Once we determined the appropriate distribution mechanism based on the consumer chain’s financial resources, we can proceed to the next step of the model…
B. THE VALIDATOR SET:
If you’re not familiar with these terms, don’t worry - we’ll break it down. TL;DR: PSS offers two options for maximum flexibility in consumer candidates. Top-N ensures that at least a minimum percentage of the Hub’s security is replicated. With a 50% parameter, for example, the first 50% of validators in the Hub must participate in consensus for the consumer. If they refuse, they’ll face a downtime slashing of ATOMs. However, using Top-N requires a majority vote on the Cosmos Hub’s on-chain governance, so candidates need to align with the community and convince ATOM holders. Our model can help visualize the set of validators that correspond to your desired “N” parameter, showing the number of validators, total collateral, and average revenue per year. We’ll explore the VotePower Cap later.
On the contrary Opt-In resembles more a free-market for security offerings. The consumer chain presents its project to the governance, seeking validators’ approval to operate. Validators casting a YES vote signal their choice to operate the chain, otherwise abstain. Casting a NO or VETO vote can be an option to alert against dangerous propositions. The system enables the consumer candidate to operate with a subset of the Hub’s validators, thereby lowering the substantial initial obstacle imposed by the replicated security model of ICS v1.0.
If you want a more in-depth technical look at the Top-N and Opt-In options, we invite you to have a look at Partial Set Security | Interchain Security and CHIPs discussion phase: Partial Set Security (updated). The key takeaway is that validators can choose to join or leave the network at any time, except for the top-n validators. This creates a dynamic system that evolves over time. To ensure stability and mitigate potential turnover, the consumer chain can set other important parameters that we will discuss next.
One critical aspect of the PSS economic balance is the ability to curate the validator set. This allows the consumer candidate to create tailor made validator set using one of two lists:
-
AllowListset the validators that are whitelisted to operate the chain, if the consumer chain declares such a list, only the validators in this list can operate the chain. Others are unable to. For example, this allows consumers to craft custom deals with certain validators and prevent others from joining and diluting the revenue share. We expect this feature to be widely popular among high-profile opt-in consumer chains willing to retain control of a healthy economic balance with their operators. -
DenyListis the exact opposite, it defines a blacklist of operators the chain doesn’t want. Leaving an open market for all the remaining ones to opt-in and opt-out as they see fit. For instance, an Opt-In chain may utilize this parameter to eliminate the first prominent validators, thereby enhancing the decentralization of stakes. Additionally, it can filter out lower-quality operators to ensure optimal performance execution.
To cater to individual preferences, our model features a customizable tab that enables users to select validators either via the AllowList or DenyList based on quantifiable quality metrics, curating a personalized set that aligns with their unique tastes.
We implemented a point-based system to highlight top-quality operators and incentivize all participants to improve their statistics and compete towards the top of the validator set. This approach encourages a race to the top, rather than a race to the bottom with 0% fee validators.
After a consumer candidate determines their PSS economic model and establishes a curated validator set via the previously mentioned filters, it is essential to set a Validator Number Cap parameter for the chain. This parameter limitingly sets the maximum number of validators the chain can operate. We suggest setting this parameter to the chain’s maximum affordable validator number, as determined by the method outlined in chapter 1 (targeting a 2-5% Revenue Ratio between the chain and the validator set). The validators are subsequently ranked by their VotePower, and those that exceed the cap do not participate in consensus or receive rewards. Periodic rank updates allow for fair competition, enabling those on the “waitlist” to secure a slot if they improve their rank within the set.
Note: In this context, the term “hard-cap” denotes a strict limit, which, when applied to other parameters, may lead to an overemphasis on them. For instance, in a “Top-N” model, if the number of validators is tightly restricted, it could potentially decrease the defined %level of Hub’s security as determined by the consumer chain.
To optimize the security agreement, consumer chains can utilize a useful parameter that effectively limits the influence of validators. This cap ensures that no single validator holds excessive power, promoting a more balanced distribution of votepower. With a lower cap, the votepower is distributed more evenly, potentially even eliminating all disparities and ensuring that all participants have an equal say. Here are some examples with the same validator set and different VotePower Cap parameters to illustrate this feature:
The chart highlights the significant impact of the VotePowerCap parameter on the APR per validator. Delegating to a more “capped” validator can result in a lower APR, as shown by the dotted red line. The effect this has on the profit distribution is crucial as it can greatly modify the APR across validators, creating some interesting economic effects. In the example above, the extreme 1% VotePowerCap alters the APR by a factor of 10, meaning that the biggest validator’s reward is 10 times lower than the one delivered by the smallest validator.
By leveraging tailored sets of validators through AllowList or DenyList, and implementing strict VotePowerCap, ICS2.0 can create a positive feedback loop. This fosters healthy competition among validators to provide the highest APR to their delegators, while also ensuring that no cartel can dominate the network. As validators grow in size, they are limited in their growth relative to others by the cap reduced APR, which maintains decentralization and ensures that all validators have an equal opportunity to succeed.
Building upon our comprehensive grasp of the PSS model’s fundamental parameters and their implications, we can now proceed to the next section of our model.
C. REWARDS DISTRIBUTION:
In addition to our initial mandate with the AADAO, we have decided to incorporate a financing model to facilitate the allocation of capital to consumer chains. This decision was made to support our strategic vision, which forecasts the Hub as a decentralized commercial bank offering financing services among other things, as we highlighted in this post. To ensure sound investments, we have established financial guidelines for funding consumer chains, which may be provided through grants from the AADAO, independent Treasury DAOs, or direct contributions from the community pool.
The initial investors can determine an appropriate financial balance between their invested amount and the share of the consumer chain revenue they will receive in return. The model will calculate the Internal Rate of Return (IRR) by discounting the cash flows of these investments over the 30-month study period, and output the net profit or loss. A positive IRR is the minimum requirement for investing in a consumer chain.
A complete revenue share distribution diagram is available in the front model page, as well as in the “Data” tab. This sums up all the cash flows to 100% and displays their relative dispersion across the 4 cohorts of our model (consumers, validators, delegators, investors).
It is crucial to acknowledge that all participants bear certain risks:
- Consumer risk: the potential for failing to find market fit, resulting in no rewards despite significant efforts.
- Validator risk: unpaid infrastructure costs and operator time spent without compensation.
- Delegators risk: the possibility of facing slashing if the operator validates too many worthless chains.
- Investors risk: unmet expectations, which may result in capital losses.
Ensuring a fair and transparent distribution of rewards to compensate for the risks involved is crucial for a sustainable long-term partnership. While there is no one-size-fits-all guideline, each situation must be assessed on its own merits to determine an appropriate compensation structure.
To ensure a successful setup, we reviewed the essential elements to strike a balance between risk and reward from the outset. However, this balance is not fixed and may need to be adjusted as inputs change over time.
D. DYNAMIC EVOLUTION:
To further assist participants understand the dynamics of this system we have provided a comprehensive analysis highlighting the underlying trends we observed as we built the model and played extensively around the parameters to find “sweet-spots” offering a good balance. With this first scenario, the parameters were adjusted to maintain a healthy validators/chain Revenue Ratio as we raise the chain’s revenue.
From that angle our study reveals that, as the Consumer Chain’s revenue increases, they may request to add more Validators for greater security. Meanwhile, delegators may push for a share of the rewards, encouraging Validators to reduce fees. To counteract this, the Consumer Chain might decrease the Vote Power Cap to prevent centralization of voting power among Validators lowering fees too aggressively to attract more stake (left chart).
We suggest that the Hub financially support the most promising chain applications, with the understanding of a revenue-sharing arrangement. This initial funding can be obtained through the community pool, TreasuryDAOs, or organizations such as AtomAcceleratorDAO, which are well-suited for this role. The chart on the right serves as a guide to estimate the minimum %revenue to ask for in order to find a positive IRR.
With this second scenario, the target is to minimize security costs as much as possible while trying to operate validators near financial equilibrium and an Revenue Ratio around 1%. This showcases a model for low-revenue public-good chains and how they could evolve as they scale their revenue in a top-n environment.
In a Top-N setup, low-revenue chains can leverage their persuasive power over CosmosHub governance instead of validators who must operate if the vote succeeds. We envision these chains adopting a public-good profile, sometimes financed by the Hub. Rewards may be distributed to ATOM holders or the community pool, while the top validators operate at a loss for the common good.
As revenue increases, it’s essential to strike a balance in validator expenses to motivate them to accept these consumers in on-chain voting. Keeping security costs at a minimum, they require durable economic alignment with the Hub. Most validators might choose a 100% fee, figuring that delegators’ rewards will be insignificant anyway (left chart).
We suggest allocating initial funding from the Hub to support, either partially or completely, the upfront building costs for consumers deployment. Initial financial support to worthy candidates may be considered a means to establish long-term economic alignment with the ATOM community. This support could manifest in various ways, such as direct funding from an on-chain proposal, a targeted grant overseen by the @ATOMAcceleratorDAO , or more intricate TreasuryDAO systems… Nevertheless, the profitability of the investment should be tied to the success of the blockchain (IRR should increase proportionally). This example demonstrates a $150,000 initial investment and its projected profitability growth. Initially, this low-revenue blockchain should direct the majority of its revenue to the Hub, but as it scales, it can reduce this share to increase protocol rewards while maintaining a rising IRR to compensate the Hub for the initial risk taken (right chart).
If we compare the variables of Top-N and Opt-in, we can observe that they exhibit distinct variable management trends, despite sharing some similarities. While the overall patterns may be comparable, the relative levels appear to differ.
In comparison to Opt-In, Top-N protocols typically require lower revenue sharing with providers, who may take a 100% fee for the lower-cost option. Additionally, these protocols often rely on a larger number of validators, some of whom may be compelled to participate, and utilize tighter VotePowerCaps than Opt-in protocols. These trends are not universal and should be considered as general guidelines rather than strict requirements.
Remember that changing AllowList, DenyList, ValidatorNumberCap, and VotePowerCap on the Cosmos Hub requires new on-chain votes. To prevent chain congestion, such changes should be infrequent. However, adjusting revenue share and validator fees doesn’t need new votes. It’s crucial to prioritize these changes before considering others. A PSS deal is a contract between validators and consumers, including the Hub governance for Top-N.
Delegators are indirectly involved as their chosen validator’s decisions impact their risk/reward balance. An efficient delegation market should favor operators who maximize rewards with minimal risk, this ultimately poses the quantity over quality debate. Competition in this field is expected to be intense, and less effective strategies will eventually be weeded out. It’s also possible that validators will work together to reduce the costs of numerous negotiation efforts, leading to an interesting collaborative framework.
To further study the complex relationships between PSS participants, we invite the community to look at the interesting research published by @darcyallen on behalf of the RMIT University Blockchain Innovation Hub. Discussion: Governance of ICS - RMIT AADAO Project Update, and Discussion: Principles for Onboarding Consumer Chains into the AEZ.
In light of our analysis of the underlying mechanisms and evolution trends in both systems, we decided to investigate the applicability of this model to real-world businesses. Our findings were intriguing, and we believe they are worth sharing.
Bonus: Real Business Application
Introduction:
To begin, it is important to acknowledge that the current cost of banking services for businesses is approximately 2%. This includes expenses related to deposits, lending, payment services, and cash management. The utilization of blockchain technology has the potential to replace certain commercial bank offerings by providing a fully sovereign Cosmos Chain solution. This does not take into account the numerous benefits that integration with web3 technology can bring, such as enhanced interoperability and on-chain partnerships.
Analysis:
Consider a practical example involving a French company, Maison Du Monde, represented by the ticker MDM. This firm possesses a valuation of 200 million euros, representing just one of the myriad small capitalizations globally.
- Annual revenue : 1.16B€
- Cost of Goods Sold (COGS) : 805m (which relates to the physical costs of producing goods, we deduct these costs to input the gross profits in our model)
source: MAISONS DU MONDE Financial Statements – EURONEXT:MDM – TradingView
The model indicates that this company can achieve a profitable revenue sharing model, with just 2% allocated to blockchain expenses, comparable to current commercial banking costs (ref. appendix). By dividing this fee equally between validators and delegators, each operator can earn an average of 157k€ annually, assuming 24 validators. Delegators, on the other hand, can expect an average return of 0.5% APR on their ATOMs. With this blockchain infrastructure, the company can process online payments with instant settlement, securely store deposits, tokenize assets, and more, with verifiable on-chain accounting and transparent regulatory reporting. It also enables access to decentralized finance for lending and borrowing, and interoperability with potential partners including supply chain coordination and secure data exchange via private IBC channels. This is just the beginning, as many more practical use cases are yet to be discovered.
One could easily argue that the main challenge in adopting a proprietary blockchain is the upfront cost of financing and building it. Yet, everyone can leverage pre-existing, open-source modules from the Cosmos SDK to drastically reduce these costs. For instance, integrating unique modules for MDM applications may only cost $100,000. However, an established, profitable business can easily outsource these technical complexities. A Cosmos developer DAO could propose constructing this blockchain, requesting a 0.1% redirection of the gross profit for 30 months, resulting in a 30% internal rate of return according to the model. We could also imagine validators’ with development capabilities grouping to offer blockchain scaffolding as a service as part of their product offering.
Scaling:
By doubling the size of this average French enterprise, offering the same profit distribution to validators and delegators would be achieved with only 1% costs, as opposed to 2%. As the size of the company increases, the blockchain fee decreases, offering a very interesting network effect potential once adoption passes certain critical thresholds. Now, envision scaling this single company by an additional 10 entities, resulting in a 1.4m$ validator profit and 5% net APR for delegators, with real-world company profits distributed, and no inflation of magic tokens. Finally, consider expanding to 50 companies, allowing for the mutualization of blockchain operating costs, while maintaining balance for all participants. We think this is the future for Cosmos, offering fully sovereign Business to Business to Customer infrastructure. This is a prospective that we highlighted in greater details in our report, Cosmos Ecosystem : A permissionless B2B2C network.
Approximately 5,000 companies worldwide have a market capitalization between $300 million and $3 billion, while over 2,000 companies have a market capitalization ranging from $3 billion to $30 billion. Assuming a 1% conversion rate corresponding to early-market adoption, this results in 50 small-cap and 20 mid-cap candidates. We estimate that the transition cost for a mid-cap company would be less than 0.25% of their gross profits. Our approach is deliberately conservative.
Following this thorough review of parameters, mechanics, trends and real-world application use cases, we will conclude with a comprehensive review of our analysis of PSS economics.
CONCLUSION:
We extend our gratitude to the teams that have diligently contributed to the development of the ICS v2.0 design updates. The initial full set security version aimed to trial the security sharing between Cosmos chains, but it was not designed for scalability. This limitation was recognized early on, with Partial Set Security (PSS) originally intended to provide increased flexibility and lower the high entry barrier for candidates. Balancing flexibility and complexity was the main challenge, but we have found that the combination of AllowList, DenyList, Validator Number Cap, and VotePowerCap achieves this balance effectively.
The proposed “Opt-In” and “Top-N” subsystems provide different models for aligning blockchain candidates with validators and the Hub. The Top-N model is well-suited for candidates focused on public goods, beginning with strong alignment to the Hub and gradually developing independent governance as they mature and become self-sustaining. In contrast, the Opt-In model offers flexibility for almost all other use cases. It also has the potential to significantly impact the validator landscape by encouraging positive competition. Validators may take on business development roles to attract consumers by offering superior service quality. This could spur innovation as new features emerge from validators’ efforts to differentiate themselves within the active set. Ultimately, we forecast PSS will transform validators’ functions to include risk management, business development, and broadening Cosmos security far beyond the Hub vicinity.
In this study, we also explored potential economic models for transitioning existing profitable enterprises to provide foundational adoption supporting the Cosmos blockchain network. We hypothesize that in the coming years, ICS 2.0 may be recognized as a pivotal point in achieving meaningful adoption of the Cosmos vision within the broader cryptocurrency technology landscape. The Cosmos network offers a novel design approach, scaling through fully sovereign horizontal partitioning with instant finality and shared security while enabling native interoperability. In contrast, some other networks still rely on either slow finality time, or probabilistic signature aggregation schemes with bridges to achieve interoperability.
Link to the full model: PSS Economics - Google Sheets
To conclude, we express our gratitude to those who will thoroughly examine the concepts discussed herein. We encourage interested parties to generate a copy of the model and experiment with the parameters, so as to deepen their understanding of the interdependencies between the various elements. We also encourage every Consumer Chain candidate to use it extensively in order to build the most durable and equitable security agreement with their operators. If you need any assistance using the model, feel free to send us an email.
Thank you for reading,
Govmos.
