Axelar

Archway

Osmosis

# KYVE Validator Delegation Program Update

**PROPOSER**: The KYVE Foundation (governance@kyve.foundation)

## Proposal Summary

Since the launch of the protocol layer, the [KYVE Validator Delegation Program](https://blog.kyve.network/kyve-validator-delegation-program-update-mainnet-delegation-and-curated-airdrop-2c615b8ee76f) (rewarding the top Incentivized Testnet participants, KVDP) is the layer’s largest source of delegation.

We have become aware that certain validators within this program are taking advantage of the situation and setting their commission rate to 100% to get the most economic benefit. In doing so, those who delegate to them do not receive a part of the rewards, discouraging delegation.

In order to give new protocol validators a fair chance, increase network competition, and further support delegation, we propose limiting the commission rate to 50% for those within the KYVE Validator Delegation Program. These validators would have 96 hours (4 days) to comply with the new limit, along with a second chance option for those who missed the implementation of this new rule.

## Proposal Details

**Objectives:** Lowering the commission rate is a way for validators to attract more delegation by incentivizing delegators. The main objectives of this proposal are to encourage best practices on the protocol layer for those with the advantage of receiving delegation from the KVDP, as well as further motivate delegation on the protocol layer, in turn, further decentralizing and securing KYVE.

**Terms & Timeline:** To enforce this new rule, we propose a delay of **96 hours (4 days)** after the proposal has passed for the validators within the program to initiate the lowering of their commission rate. If a validator **does not comply** with initiating the lowering of commission within this set timeline, **they will lose their delegation from the program**. Once their delegation is lost, they will have **one chance** to lower their commission rate to be re-delegated to.

However, if after the 4 days from the proposal passing, a validator receives delegation and sets their commission rate above 50%, they will immediately lose their delegation as they have not complied with this set limitation.

**Impact Assessment:**
- **Technical Impact:** The protocol validators within the program would need to update their commission rate.
- **Economic Impact:** This would positively impact KYVE’s overall protocol layer economics and security, which rely heavily on delegation. It would also help achieve a stake ratio balance between the two layers.
- **Social Impact:** This would encourage further delegation to protocol validators, overall enhancing KYVE’s decentralization and network security. It would also give the other validators who are already following best practices more opportunity to receive delegation from our users.

*Please note that this proposal is addressing 100% commission on the delegation from the KYVE Validator Delegation Program, not personal funds.

**The Foundation’s block rewards earned from the program’s delegations are used to refund the pool(s) in order to continue feeding into network participation, as well as possible community activities.

## Voting Options

### Voting YES

- A YES vote on this proposal indicates that a commission rate limit of 50% SHOULD be enacted for protocol validators in the KYVE Validator Delegation Program, with 96 hours (4 days) to lower their rate from the proposal passing.

### Voting NO

- A NO vote on this proposal indicates that a commission rate limit of 50% SHOULD NOT be enacted for protocol validators in the KYVE Validator Delegation Program.

### Voting NO WITH VETO

- A NO WITH VETO vote on this proposal indicates that a commission rate limit of 50% SHOULD NOT be enacted for protocol validators in the KYVE Validator Delegation Program; and that the proposal depositors should be penalized.

### Voting ABSTAIN

- An ABSTAIN vote on this proposal indicates that you decline to give a specific opinion on this proposal while maintaining active governance participation.

## Conclusion
Overall, our aim is to provide a fully decentralized, secure platform for our network participants and technology to thrive. By encouraging best practices on the protocol decided on by our governance, we hope to reach these goals.
Please note that this proposal follows a template that will later be finalized through a governance discussion around processes.

KYVE Validator Delegation Program Update

# `v1.3.0` Software Upgrade

**PROPOSER:** The KYVE Foundation (governance@kyve.foundation)

## Proposal Summary

If approved, this proposed software upgrade would introduce a weighted round-robin method for selecting uploaders and also incorporate a split of inflation between the chain and protocol. Additionally, this upgrade would correctly track the delegations from investor accounts affected in the `v1.1.0` upgrade.

## Proposal Details

In order to enhance the selection of uploaders, we transitioned from a weighted pseudo random selection method to a weighted round-robin approach. This change has made the selection process even more transparent and equitable. For more details, please refer to this [pull-request](https://github.com/KYVENetwork/chain/pull/99).

Additionally, we aim to implement inflation splitting, a mechanism that involves redirecting a portion of the newly minted inflation from each block to the protocol layer. The objective of this approach is to maintain a balanced stake distribution between the chain and the protocol, ensuring optimal security for both. For a more comprehensive discussion on this topic, please refer to [this link](https://commonwealth.im/kyve/discussion/12000-suggested-feature-inflation-splitting), and you can find the implementation details in this [pull-request](https://github.com/KYVENetwork/chain/pull/98).

Furthermore, uploader rewards are not paid out anymore directly to the uploader, instead it needs to be claimed. Please see this [pull-request](https://github.com/KYVENetwork/chain/pull/72).

Moreover, finalized bundles now store information about the relative stake security. Additionally, the schema was updated and is now more robust to changes. The new schema is available at `/kyve/v1/bundles`. The current query (`/kyve/query/v1beta1/finalized_bundles`) will then be removed.

Lastly, this upgrade will accurately track the delegation of accounts that were impacted by the adjustment of their vesting schedules in the `v1.1.0` upgrade. Please see this [pull-request](https://github.com/KYVENetwork/chain/pull/96).

## Upgrade Process

When the network reaches the defined upgrade height (**2061100**), block production on the KYVE network will be halted. Block production will not resume until significant voting power has switched to the new release. Validators can either manually replace the old binary with the new one or utilise [Cosmovisor](https://docs.cosmos.network/v0.47/tooling/cosmovisor) to automate this process.

## Voting Options

### Voting YES

- A YES vote on this proposal indicates that the KYVE network **SHOULD** be upgraded; and that the validators should start running the [`v1.3.0`](https://github.com/KYVENetwork/chain/releases/tag/v1.3.0) release.

### Voting NO

- A NO vote on this proposal indicates that the KYVE network **SHOULD NOT** be upgraded; and that the validators should continue running the [`v1.2.x`](https://github.com/KYVENetwork/chain/releases/tag/v1.2.0) release.

### Voting NO WITH VETO

- A NO WITH VETO vote on this proposal indicates that the KYVE network **SHOULD NOT** be upgraded; and that the proposal depositors should be penalised.

### Voting ABSTAIN

- An ABSTAIN vote on this proposal indicates that you decline to give a specific opinion on this proposal while maintaining active governance participation.

## Conclusion

The forum discussion for this proposal can be found [here](https://commonwealth.im/kyve/discussion/12056-v130-software-upgrade).

This upgrade has been tested on the Kaon network (our testnet). You can find the proposal [here](https://testnet.mintscan.io/kyve-testnet/proposals/8).

Please note that this proposal follows a template that will later be finalised through a governance discussion around processes.

v1.3.0

v1.3.0 Software Upgrade

# Proposal Summary

Efficient Frontier is publishing this proposal to seek the KYVE community’s approval for a market making agreement. The proposal would entail the following:

- Authorizing Efficient Frontier as an official KYVE market maker
- KYVE Foundation transferring $1,225,000 worth of KYVE and additional $125,000 worth of USDC to Efficient Frontier over a series of tranches as a loan for the purpose of market making
- The ultimate amount of KYVE that is transferred will be calculated based on the prices at the time of delivery of tokens to Efficient Frontier.
- Efficient Frontier will commit to make markets on CeFi exchanges and on the Osmosis pool (DEX).
- Efficient Frontier will either return the loaned amount at the end of the market making period or purchase the tokens at a series of strike prices (The strike price calculations are elaborated below).

# Proposal Details

## About Efficient Frontier

- Efficient Frontier is a cryptocurrency algorithmic trading and market making firm. We spun out of a traditional finance high-frequency trading firm in 2017 and have since grown to become one of the leading market makers in the cryptocurrency ecosystem. Our team is composed of traditional finance quants and traders, as well as experienced crypto-natives, all of whom share a passion for making cryptocurrency markets transparent and fair. As a designated market maker, we are proud to provide the highest standard of service and ethics in Web 3 markets.

## Services

### CeFi

- Efficient Frontier will make markets for the KYVE token on centralized exchanges. We provide two-sided quotes on the token’s order books so that traders and users can trade efficiently.
- All trading is done through the exchange API, with 24/7 human monitoring to adjust the parameters based upon market conditions.

### DeFi

- Efficient Frontier will provide liquidity to the Osmosis pool so that traders and users can also trade KYVE on-chain.

# Commercial Terms

## Loan Terms

| Initial Funding                                 | Loan Repayment                                | Explanation                                                                           |
|-------------------------------------------------|------------------------------------------------|---------------------------------------------------------------------------------------|
| $1,225,000 worth of KYVE and $125,000 worth of USDC (to purchase OSMO) | $1,350,000 worth of KYVE at the time of the transfer | EF will take out a loan in KYVE and USDC, which is ultimately only returned in KYVE.  If only part of the options are exercised, then the remaining loan shall be returned to the KYVE Foundation |

## Option Terms

| Option Tranche             | Size                        | Strike and Explanation                                                                              |
|----------------------------|-----------------------------|----------------------------------------------------------------------------------------------------|
| 18 Month Option - Tranche 1| $250,000 worth of KYVE      | Option to purchase the KYVE token. At the end of the 18 month period, Efficient Frontier can exercise the option. Strike price is set at the listing price on Osmosis relative to $OSMO. |
| 18 Month Option - Tranche 2| $400,000 worth of KYVE      | Strike price is set at the average price of the first 7 days of trading starting from the first supported CeFi listing. |
| 15 Month Option - Tranche 3| $300,000 worth of KYVE      | Strike price is set at the average price of the first 7 days of trading starting 90 days from the first supported CeFi listing. |
| 12 Month Option - Tranche 4| $200,000 worth of KYVE      | Strike price is set at the average price of the first 7 days of trading starting 180 from the first supported CeFi listing. |
| 9 Month Option - Tranche 5 | $200,000 worth of KYVE | Strike price is set at the average price of the first 7      days of trading starting 270 days from the first supported CeFi listing. 

## Additional Terms

| Service               | Cost             | Explanation                                                                                                  |
|-----------------------|------------------|--------------------------------------------------------------------------------------------------------------|
| CeFi Market Making    | Included with Option | Includes Market Making, Dedicated Account Manager, Telegram Support, 24/7 Monitoring, Reporting.             |
| DeFi Liquidity Provision | Included with Option | Liquidity providing and rebalancing on Osmosis. We will LP with 60% of the $250K DeFi tranche ($150K) to start and rebalance the pool as the price moves. |

**Objective**: To provide healthy liquidity for the KYVE ecosystem on both centralized and decentralized exchanges 

**Benefits**: Liquidity is very important for traders and users to be able to properly buy and sell the KYVE token. Our goal here is to make markets and provide liquidity to the KYVE ecosystem so that people can easily and efficiently enter and exit their holdings. 

#### Covered Exchanges and Pairs: 
With the full loan size (including all tranches), we can cover up to 6 pairs. 

#### Impact Assessment:

- Technical Impact: N/A
- Economic Impact: Market making plays a key role in facilitating liquidity for the ecosystem and allows buyers and sellers to be able to efficiently trade.
- Social Impact: In the long run, the market will naturally find price discovery, regardless of whether this is upwards or downwards. A market maker is a facilitator of this price discovery but shouldn’t directly move the price up or down.

#### Efficient Frontier Warrants:

- Authority and Competence – Efficient Frontier has the full right, power and capacity to perform its obligations and provide the services under the offer and it shall exercise a degree of competence and professionalism which would reasonably be expected from a skilled and experienced provider engaged in the same type of business as Efficient Frontier;
- No conflict - performing the market making services shall under the offer not breach any regulatory or contractual requirement governing Efficient Frontier is subject to;
- No actions - To Efficient Frontier’s knowledge, there is no action or threatened action against Efficient Frontier which would substantially impair its right to perform the market making services or adversely affect its financial condition;
- Efficient Frontier shall defend and hold harmless the DAO, the KYVE Foundation and DAO members from and against all third-party claims or actions, costs and expenses arising from or in connection with (a) any claims by third parties resulting from or in connection with the provision by Efficient Frontier of the market making Services, or (c) any breach by Efficient Frontier or its agents or sub-contractors of applicable laws or regulations. The indemnification shall be subject to the following conditions: (i) the party seeking indemnification shall notify Efficient Frontier in writing of the applicable claim, promptly after becoming aware of the claim, and (ii) the party seeking indemnification shall provide Efficient Frontier with the right to exclusively conduct the defense of such claim, and shall assist with such defense as may be reasonably requested by Efficient Frontier. In the event that any DAO members seek indemnification, they must appoint one representative with the full authority to represent them vis-à-vis Efficient Frontier with respect to such matter, and Efficient Frontier will be required to interact only with such representative
- Efficient Frontier shall have sole responsibility for complying with all legislative and regulatory requirements relating to the market making services and has the means, resources and know-how to satisfy such requirements.

## Voting Options:

**Voting YES**
A YES vote on this proposal indicates that the above terms for market making SHOULD be approved, AND the KYVE tokens should be lent to Efficient Frontier and Efficient Frontier shall have the option to either (i) return the loan in KYVE or (ii) purchase the loan in whole or in part at the strike prices (and return any remaining part of the KYVE loan). 

**Voting NO**
A NO vote on this proposal indicates that the above terms for market making SHOULD NOT be approved, and there should be NO lending of KYVE tokens to Efficient Frontier for market making. 

**Voting NO WITH VETO**
A NO WITH VETO vote on this proposal indicates that the above terms for market making SHOULD NOT be approved and there should be no lending of KYVE tokens to Efficient Frontier for market making; and that the proposal depositors should be penalized.

**Voting ABSTAIN**
An ABSTAIN vote on this proposal indicates that you decline to give a specific opinion on this proposal while maintaining active governance participation.

## Conclusion:

Market making is a key function to building efficient markets. Efficient Frontier proposes to make markets for KYVE with a loan and option model, which we take a loan in the KYVE token and receive an option to purchase this loan after the term ends. We look forward to answering any questions here and working together with the KYVE DAO to provide liquidity to the KYVE ecosystem.

Efficient Frontier – KYVE Market Making Proposal

Cosmos Hub

# `v1.2.0` Software Upgrade

**PROPOSER:** The KYVE Foundation (governance@kyve.foundation)

## Proposal Summary

This software upgrade proposal, if passed, would enable full Ledger support for **all** of KYVE's custom transactions.

## Proposal Details

It was brought to the attention of the KYVE Development Team that Ledger needed to be supported for KYVE's custom transactions. After further investigation, it turns out no [Amino](https://docs.cosmos.network/v0.47/core/encoding#amino) types were registered (this is how Ledger understands the transaction information). This release resolves this issue but requires an on-chain software upgrade as this is consensus-breaking.

Additionally, this upgrade adjusts the vesting schedules of two KYVE Core Team members. Please see this [pull request](https://github.com/KYVENetwork/chain/pull/45).

## Upgrade Process

When the network reaches the defined upgrade height ([**1135000**](https://www.mintscan.io/kyve/blocks/1135000)), block production on the KYVE network will be halted. Block production will not resume until significant voting power has switched to the new release. Validators can either manually replace the old binary with the new one or utilise [Cosmovisor](https://docs.cosmos.network/v0.47/tooling/cosmovisor) to automate this process.

## Voting Options

### Voting YES

- A YES vote on this proposal indicates that the KYVE network **SHOULD** be upgraded; and that the validators should start running the [`v1.2.0`](https://github.com/KYVENetwork/chain/releases/tag/v1.2.0) release.

### Voting NO

- A NO vote on this proposal indicates that the KYVE network **SHOULD NOT** be upgraded; and that the validators should continue running the [`v1.1.x`](https://github.com/KYVENetwork/chain/releases/tag/v1.1.0) release.

### Voting NO WITH VETO

- A NO WITH VETO vote on this proposal indicates that the KYVE network **SHOULD NOT** be upgraded; and that the proposal depositors should be penalised.

### Voting ABSTAIN

- An ABSTAIN vote on this proposal indicates that you decline to give a specific opinion on this proposal while maintaining active governance participation.

## Conclusion

The forum discussion for this proposal can be found [here](https://commonwealth.im/kyve/discussion/11439-kaon-v120-software-upgrade).

This upgrade has been tested on the Kaon network (our testnet). You can find the proposal [here](https://testnet.mintscan.io/kyve-testnet/proposals/6).

Please note that this proposal follows a template that will later be finalised through a governance discussion around processes.

v1.2.0

v1.2.0 Software Upgrade

# `v1.1.0` Software Upgrade

**PROPOSER:** The KYVE Foundation (governance@kyve.foundation)

## Proposal Summary

Recently, while undergoing an independent code review, we found a few non-critical issues. If passed, this software upgrade proposal would implement fixes and improvements to resolve these issues on the KYVE network. Additionally, if passed, token transfers via IBC would be enabled.

## Proposal Details

A few non-critical issues were discovered while an independent code review was undertaken on KYVE's consensus codebase. This software upgrade includes fixes and improvements to all these issues. For a more detailed description of these changes, see this [pull request](https://github.com/KYVENetwork/chain/pull/22).

Additionally, while monitoring the network after launch, the KYVE Development Team noticed that the vesting schedules of our investors that participated in our second funding round needed to be corrected. According to our tokenomics, the correct vesting schedule is a six-month cliff with two-year continuous vesting after. However, included in genesis was a schedule of a 1.5-year cliff with two-year continuous vesting after that. This software upgrade realigns these schedules.

Finally, to maximise security during our launch, the team decided to disable token transfers via IBC. This software upgrade enables sending and receiving of tokens.

For a more technically in-depth list of changes made in this release, please refer to the [CHANGELOG](https://github.com/KYVENetwork/chain/blob/v1.1.0/CHANGELOG.md) file.

## Upgrade Process

When the network reaches the defined upgrade height ([**826000**](https://mintscan.io/kyve/blocks/826000)), block production on the KYVE network will be halted. Block production will not resume until significant voting power has switched to the new release. Validators can either manually replace the old binary with the new one or utilise [Cosmovisor](https://docs.cosmos.network/v0.47/tooling/cosmovisor) to automate this process.

## Voting Options

### Voting YES

- A YES vote on this proposal indicated that the KYVE network **SHOULD** be upgraded; and that the validators should start running the [`v1.1.0`](https://github.com/KYVENetwork/chain/releases/tag/v1.1.0) release.

### Voting NO

- A NO vote on this proposal indicated that the KYVE network **SHOULD NOT** be upgraded; and that the validators should continue running the current binary.

### Voting NO WITH VETO

- A NO WITH VETO vote on this proposal indicates that the KYVE network **SHOULD NOT** be upgraded; and that the proposal depositors should be penalized.

### Voting ABSTAIN

- An ABSTAIN vote on this proposal indicates that you decline to give a specific opinion on this proposal while maintaining active governance participation.

## Conclusion

The forum discussion for this proposal can be found [here](https://commonwealth.im/kyve/discussion/11172-kaon-v110-software-upgrade).

This upgrade has been tested on the Kaon network (our testnet). You can find the proposal [here](https://testnet.mintscan.io/kyve-testnet/proposals/2).

Please note that this proposal follows a template that will later be finalised through a governance discussion around processes.

v1.1.0

v1.1.0 Software Upgrade

# Parameter Change: Enabling Inflation

**PROPOSER:** The KYVE Foundation (gov@kyve.foundation)

Currently, inflation has been disabled on the KYVE network while we rolled out our Foundation Delegation Program. This proposal, if passed, will enable inflation to be set to our default parameters, aiming to reach an APY of 20%.

## Voting Options

### Voting YES

- A YES vote on this proposal indicates inflation **SHOULD** be enabled.

### Voting NO

- A NO vote on this proposal indicates inflation **SHOULD NOT** be enabled.

### Voting NO WITH VETO

- A NO WITH VETO vote on this proposal indicates inflation **SHOULD NOT** be enabled; and that the proposal depositors should be penalized.

### Voting ABSTAIN

- An ABSTAIN vote on this proposal indicates that you decline to give a specific opinion on this proposal while maintaining active governance participation.

## Proposal Details

As described in our [Mainnet Day 0 Roadmap Announcement](https://blog.kyve.network/kyves-genesis-file-finalized-unveiling-mainnet-day-0-roadmap-f1c5c6bb7a8b), in order to properly roll out our Foundation Delegation Program, we needed to disable certain features on network launch. This proposal aims to bring the KYVE network to its true state.

To add proper incentivization on the network, it's crucial to find a balance between the APY and inflation, to reward participants correctly while not devaluing the token over time.

The default parameters: `InflationMin` 7% and  `InflationMax` 10%, were calculated considering the staking ratio at genesis. The goal is to reach an APY of 20%, a reference value influenced by other Cosmos networks.

Parameter Change: Enabling Inflation

# Parameter Change: Enabling Validator Creation, Increasing Voting Period

**PROPOSER:** The KYVE Foundation (gov@kyve.foundation)

Currently, it is not possible to create a validator, and the voting period is set to 1 hour. If passed, this parameter change proposal would enable validator creation on the KYVE network and increase the voting period to 1 week for optimal governance participation.

## Voting Options

### Voting YES

- A YES vote on this proposal indicates validator creation **SHOULD** be enabled on the KYVE network, and the voting period **SHOULD** be increased to 1 week.

### Voting NO

- A NO vote on this proposal indicates validator creation **SHOULD NOT** be enabled, and the voting period **SHOULD NOT** be increased.

### Voting NO WITH VETO

- A NO WITH VETO vote on this proposal indicates validator creation **SHOULD NOT** be enabled, and the voting period **SHOULD NOT** be increased. The proposal depositors should be penalized.

### Voting ABSTAIN

- An ABSTAIN vote on this proposal indicates that you decline to give a specific opinion on this proposal while maintaining active governance participation.

## Proposal Details

As described in our [Mainnet Day 0 Roadmap Announcement](https://blog.kyve.network/kyves-genesis-file-finalized-unveiling-mainnet-day-0-roadmap-f1c5c6bb7a8b), in order to properly roll out our Foundation Delegation Program, we needed to disable certain features on network launch. This proposal aims to take part in bringing the KYVE network to its true state.

In our aim for true decentralization, it’s best to decentralize the validator set from the initial genesis selection provided by the KYVE Foundation.

Having a voting period of 1 week gives everyone in the network enough time to make an educated vote on the proposal and the future and further development of the network.

KYVE

Kyve

Governance

#14

#13

#12

#11

#10

#9

#8

#7

#6

#5

#4

#3

#2

#1