# Validator Set Sustainability Plan

The current validator set of the Juno network consists of 150 active validators, with a total of 58 million $JUNO staked. Of this amount, 10 million $JUNO comes from the delegation program and belongs to the community. Given the current total supply of 107 million $JUNO, approximately 54% of the supply is staked.

Currently, the distribution of the stake is rather centralized. The bottom half of the validator set (75 validators) has less voting power than a single validator (Cosmostation). Additionally, the collusion of only 9 validators can halt the chain, as they control over 33% of the voting power.

Furthermore, due to this unequal distribution, many validators are operating at a loss. Even if validators are passionate about a chain, ongoing monthly losses might lead them to stop validating. Recently, DAIC Capital and Simply Staking announced they would shut down their validators; they are neither the first nor the last to do so.

To address this issue, we should strive to create an environment where validators receive enough revenue to break even or at least have a clear path to achieve this. The following five points outline the proposed action plan to create this environment and aim to increase the decentralization and resilience of the chain.

**Overview:**

**1. Short-Term Plan (0-6 months):**

* **Validator Set Size Reduction (Step 1):** Implement a reduction of the current validator set size from 150 to 85.
* **Delegation Programme (New Criteria):** Establish a new delegation program focusing on verifiable on-chain criteria.
* **Strategic Reserve Creation & Deployment:** Request 5 million $JUNO from the community pool to establish a new sub-DAO under the council for a strategic reserve.

**2. Mid-Term Plan (6-12 months):**

* **Validator Set Size Reduction (Step 2):** Encourage more even distribution of existing delegations among the reduced validator set.
* **Drip Module Modifications:** Adjust the drip module to distribute tokens in a way that favors smaller validators.

**3. Long-Term Plan (12+ months):**

* **Partial Separation of Governance and Validators:** Form a working group to explore separating governance and validator roles.
* **Development and Implementation of new revenue function:** Form a working group to explore and develop a compensation structure that ensures all validators receive basic remuneration and cost to run the network does not increase linearly with its marketcap.

---

**1. Validator set size reduction (short-term)**

At current prices ($0.17), the validator set can't be sustained unless validators significantly increase their commissions, which they are unlikely to do due to the fear of losing delegations.

According to Juno's tokenomics, the supply change in the current phase is about 10.9 million $JUNO. Considering a 10% community pool tax and an average commission fee of 5%, this results in validator revenue of 490k $JUNO per year for the entire set. (As a marginal note, these are the annual costs of operating the chain. At current prices, this amounts to well under $100k USD). Unless transaction fees and other revenue sources increase, this revenue will decline over the next few years until it hits zero. At current prices, this revenue is worth $84k USD. Even if delegations were distributed perfectly equally among all validators, each validator would only make about $555 USD per year.

In return for these commissions, we expect our validators not only to validate our chain but also to stay up to date with our governance, make further contributions to our cause, and be highly responsive to upgrade the software in case of an emergency. Given the yearly revenue, this demand might be too high.

I asked a few validators to estimate their monthly cost to validate the Juno network. The estimates varied significantly, ranging from $40 to $300 per month ($480 to $3600 on a yearly basis). These differences can be attributed to various factors, including whether validators have accounted for their own time (wages). However, monthly costs of $200 ($2400 on a yearly basis) seem to be a realistic average. To break even, a validator needs delegations of at least 1.7 million $JUNO, a threshold currently met by only six validators.

This leads me to conclude that we should reduce our validator set as a first step, so the fixed commission is distributed among a smaller group of validators. In the second step, we need to encourage more even distribution of existing delegations among these validators, making the validator set more sustainable overall. This will also increase decentralization and, ceteris paribus, enhance the resilience of our network.

I propose reducing the current validator set size from 150 to 85. This is a decrease of more than 40%, which may sound drastic, but only 4.4% of the total stake is affected by this change, making it seem negligible. However, this move allows us to spread the delegation program to a larger group of recipients than before, maintaining its effectiveness.

At the same time, the Juno network should commit to reevaluating the validator set size only once per year. This way, validators who stay with us while the price is low can have the confidence that if the price increases again, they can profit from their commissions without fearing an immediate increase in the set size and a reduction in delegations from the delegation program. Validators need a reliable framework.

---

**2. Delegation Programme (short-term)**

A direct way to influence the distribution of the staked asset is our delegation programme. Currently, 10m $JUNO are earmarked for this cause. The old delegation programme (https://medium.com/@JunoNetwork/juno-foundation-delegations-update-18394597059f) had technical and non-technical criteria and depended on many subjective assessments. All in all, it was a good programme, but due to the many things to evaluate, it took a very long time and although it should have been revisited after six months, this never happened. We still use the delegations from this evaluation, which is now 1 year old although some validators shut down their validators, new validators might now be eligible or old validators might not be eligible anymore. Furthermore, the subjective assessments led to disputes between validators and the working group. Not that the working group did anything wrong though. It is just the nature of such decisions.

As the resources of the network (especially contributor time) is limited at the moment, the new delegation programme should focus on verifiable on-chain criteria to be able to quickly determine whether a validator is eligible or not. This way we do not create much overhead and can choose short evaluation intervals (f.e. redelegations every three months). A similar approach was chosen by Injective and a dashboard (https://analytics.smartstake.io/injective/fdp/3) was built by smartstake (also a validator on Juno) to track whether the validators fulfill the criteria. I propose the following approach:

1. Set on-chain criteria
2. Determine who is eligible
3. Divide the total delegation programme by the number of eligible validators
4. Make adjustments to account for commission differences
5. Redelegate

*[add explanations. notes: on-chain criteria, max. voting power before delegation programme, slashing events last 3 months (if yes, ineligible), uptime last 90 days at least xx%, governance participation if proposals >1 at least 80% during last 90 days, upgraded in less than 2 hours during the last 90 days (if no, not eligible)]*

Additionally, in order not to spread the delegations too widely (and to risk to make the delegation programm ineffective) the number of eligible participants needs to be capped at 50. Assuming f.e. the top 15 validators are excluded from the delegation programme, because they exceed the max. voting power criteria and all other validators are eligible for the programme (which is unlikely), then the validators from rank 16 to rank 65 would receive delegations of 200k $JUNO each (before commission related adjustments). The residual validators from rank 66 to 85 would not receive delegations, unless other validators in front of them are ineligible.

With this design we do allow our validator set to become more fluid and do not erect high barriers for new validators to enter the set. If we decreased the size of the validator set even more and made everyone theoretically eligible for delegations from the DP, then a new validator would need to receive >200k $JUNO to even attempt to break into the active set. With this design, new validators have a realistic possibility to get into the active set and then become eligible for a delegation from the DP.

These changes would lead to a more decentralized and more sustainable validator set. We'd still have big validators at the top, but we would have a stronger centre than before and by excluding the last validators of the set, we still have the ability to integrate newcomers. At the same time, validators have a clear picture what is expected from them and the evaluation can happen in short intervals without much effort. And maybe the most important point: validators have a clear framework and better prospects than before.

---
**3. Strategic Reserve Creation & Deployment (short-term)**

To ensure the network's security, we currently rely on inflation. According to the inflation schedule, this rate will gradually decrease each year until it reaches zero. However, employing a fixed inflation schedule was initially a mistake, as it assumes that transaction fees and other revenue sources will miraculously increase at the same rate as the inflation decreases. There's a possibility that this may not occur, necessitating preemptive measures.

I propose requesting 5m $JUNO from the community pool to establish a new sub-DAO under the council. These funds would be delegated and designated as a strategic reserve for the network. In the future, if the staking APR becomes insufficient to attract adequate delegations or sustain our validators, we could utilize this reserve to raise the APR or directly compensate validators for their services.

The logic of delegations should follow the DP to increase its effectiveness. This would result in a delegation of 300k $JUNO to all eligible validators (before commission related adjustements).

---
**4. Drip Module Modifications (mid-term)**

The drip module, created by Dimi, enables individuals to distribute their tokens to the community gradually over an extended period, as opposed to a one-time airdrop. Participants can claim these tokens alongside their staking rewards.

Although unused thus far, we could initiate a project and distribute its token to the community utilizing the drip module. To enhance the decentralization of delegations, we need to make slight adjustments to the drip module. Instead of adhering to the conventional staking logic (where staking 1% of the total supply yields 1% of the total rewards), we must adopt the following approach:

For instance, suppose we aim to distribute 1.7 million tokens over a year. In this case, we allocate a certain percentage of this amount (e.g., 50%, but potentially lower) and divide it by the number of validators (85 in this example). Therefore, 1.7 million/2/85 equals 10,000 tokens per validator. The remaining half is distributed according to the usual logic.

This method ensures that stakers of smaller validators receive a relatively larger drip-drop (airdrop with the drip module :p) compared to those of larger validators, as the fixed share per validator is allocated to a smaller pool of staked $JUNO. Consequently, if the token holds value or multiple projects adopt this module, the APR (Annual Percentage Rate) will naturally shift in favor of smaller validators, attracting more delegations, which, in turn, may lower the APR but contribute to a more evenly distributed delegation.

Overall, the drop module presents a great opportunity as it enables users to farm other tokens while staking $JUNO.

---
**5. Partial Separation of Governance and Validators (long-term)**

Validators should focus on technical tasks such as evaluating updates and creating blocks, rather than involving themselves in governance topics like delegation programs and partnerships. As previously demonstrated, the typical validator on our chain is currently operating at a loss. It is unlikely that validators stay updated on ongoing governance discussions and contribute to these topics while simultaneously validating on multiple chains without compensation.

Therefore, we need to devise a new system. While I have some rough ideas, I propose that a working group convenes to explore this further. Considering that the previous working group (charter) was not compensated for their efforts, I suggest setting aside 20k $JUNO to form a DAO with the members of the old working group and enabling retroactive compensation. They would collectively vote on each other's past contributions, and based on this vote, distribute the 20k $JUNO among themselves. At current prices, this amounts to about 3.5k USD and serves more as a gesture of appreciation than adequate compensation for their efforts.

---
**6. Development and Implementation of new revenue function (long-term)**

In PoS chains, a validator’s revenue is influenced by their delegations, the current asset price, and the commission they charge. However, validators cannot influence the asset price, and while they can adjust their commission, doing so often has adverse effects. Due to minimal differentiation among validators, most must adhere to the average commission rate; increasing it typically results in losing delegations and failing to attract new ones. This creates a peculiar market dynamic where small validators struggle to cover their costs, whereas early validators (often present since the genesis block) earn substantial profits on chains like the Cosmos Hub or Osmosis.

The cost of running a validator does not correlate with revenue or received delegations. Thus, higher revenue directly translates to higher profits. Consequently, the strategic approach for any validator should be to join a new chain at genesis, offer zero commission to attract delegations, and invest in marketing efforts to increase delegations (or promise a stakedrop that might not materialize or in the end has no value). Once a validator secures a top position, they can scale back marketing expenses, only incurring the relatively small fixed costs necessary to maintain the validator. If the chain succeeds and the asset price appreciates, profits will increase accordingly.

(Chat GPT created this...I am impressed.)

Please note that the validator revenue represents the actual cost for the community to run the chain. Interestingly, while the cost for validators to validate the chain does not increase with the higher market cap of the chain, it becomes more costly for the community.

To address this imbalance, it would be more logical to implement a compensation structure that ensures all validators receive basic remuneration to cover their fixed costs (or at least a portion of them). Beyond this, revenue should be linked to both the asset price and the amount of delegation, but with a correlation coefficient of less than 1. A dedicated working group should explore and develop this model to create a more equitable and sustainable validation ecosystem and a more efficient way to run valuable networks.

---