KYVE Fundamentals Level 2

KYVE’s Architecture Breakdown

First, it’s important to break down KYVE’s unique blockchain architecture and how exactly it reliably stores and validates data, building up a Web3 data lake…

Starting in April of 2022, KYVE became its own Layer 1 blockchain* built with the Cosmos* standard development kit (SDK*) Learn more on this in our Cosmos course. KYVE’s blockchain is split into two important layers: the chain and protocol.

The Consensus Layer

The consensus layer is the backbone of KYVE and is an entirely sovereign Delegated Proof of Stake* (DPoS) blockchain built with the Cosmos SDK and uses Tendermint as the consensus engine. It’s run by independent validators, which enable users to support and secure the KYVE blockchain.

The Protocol Layer

Sitting on top of the consensus layer is the protocol layer, which enables the actual use case of KYVE. This includes pools, funding, staking, and delegation.

The protocol layer has its own validators, as illustrated in the Level 1 course, which are responsible for collecting data from a data source, bundling and uploading it to any decentralized storage solution, and then validating it, keeping track of which data is truly valid for its users to tap into. This enables KYVE to store any data permanently and in a decentralized manner, building a Web3 data lake. 

To tie the network together, KYVE has its own native token, $KYVE. $KYVE is used on the chain layer for staking and delegating, which secures the network through DPoS. On the protocol layer, it’s used for funding, staking, and delegating, incentivizing users to behave accordingly. The chain layer also uses the DPoS mechanism, ensuring all node network participants behave in favor of the KYVE blockchain. Later on in this course, we’ll delve further into the tokenomics* of $KYVE.

• Dive deeper into KYVE’s architecture by visiting our docs.
• Run into a few words you weren’t aware of? The words marked with * in this article are defined in KYVE’s Glossary!

Extra Security

Building the leading source of trustless, valid data in Web3, it’s imperative that, while staying fully decentralized, maximum security is achieved. Being a DPoS* blockchain built on the Cosmos SDK* already provides a secure base for KYVE by making sure network participants stay incentivized to behave in the best interest of the blockchain. 

However, there is much more that needs to been put in place on top of this to ensure KYVE’s specific features and ability to fetch, store, and validate data remain truly decentralized and tamper-proof. Which is why, throughout this past year, KYVE’s code infrastructure has been tailored to best secure the consensus and protocol, weeding out possible points for error or attack.

This includes: 

• Custom slashes toward misbehaving or inactive validators
• Staying up to date on the most recent Cosmos SDK version
• Making KYVE governance as efficient as possible
• Weighted voting power
• Restricted commission changes for protocol validators to avoid them taking advantage of delegators’ tokens
• An unbonding feature on the consensus layer enforcing a 21-day unbond from a pool in order to avoid users staking into a pool and then immediately unstaking
• An unbonding feature on the protocol layer enforcing a 1-day unbonding time on delegations, along with only allowing 5 redelegations within the span of 5 days per user. 

And many more, all working toward avoiding a powerful single party taking over. Not to mention, a major key to KYVE’s security being the Inter-Pool Security feature.

This feature decreases the possibility of high-staked validators taking over a pool by allowing them to be active in numerous pools at once, securing them with their stake and delegation. However, getting slashed in one pool affects the validator’s entire stake, making them more incentivized to behave accordingly. 

Overall, each feature and implementation has been thoroughly tested via KYVE’s tesnet Korellia, allowing our team to prepare as best as possible in providing a secure KYVE mainnet.

• Want to learn more about KYVE’s Inter-Pool Security Feature? Read this article.
• Find a word marked with * that you’re not familiar with? Be sure to visit KYVE’s Glossary to find out what it means!

How KYVE Handles Data

Starting from the top: The process of protocol validators fetching data to bring into KYVE pools is called bundling. A bundle can receive new data items for either x minutes or x amount. 

Example: We add data items for 10 minutes or until we reach 100 data items in this bundle before closing and submitting it.

After a bundle is closed, it is submitted from the uploader onto a storage provider.

Storing Data Through KYVE

Seeing that KYVE’s original use case was archiving blockchain data, it was imperative to go with an immutable storage solution, therefore KYVE stores data by default onto Arweave, the permanent data storage platform.

However, KYVE is storage agnostic, meaning it can store data onto any storage provider that is scripted into the pool configurations. This allows those who create a pool to decide, depending on their use case, which storage provider they prefer or would be best.
Currently, KYVE supports both Arweave and Bundlr as storage solutions. There is also the option to create your own custom storage provider. Once mainnet is launched, more storage solutions will become available to choose from.
Once the data is stored, it goes through the validation process of the protocol validators.

Once consensus is reached on whether the data is valid or not, the details get sent to KYVE’s consensus validators to keep track of and display to data users via the REST-API.

Accessing KYVE’s Trustless Data

Currently, there are two ways to access KYVE’s trustless data. One being via KYVE’s Data Pipeline*. This is a no-code, customizable option for easily importing KYVE’s data into a preferred data backend before transforming the data into the format needed. For those who are more code-savvy, there’s the second option providing a native way to access data in a completely trustless way via coding your own solution: using KYVE’s REST-API. The REST-API is a resource model outlining the major details you need to know about a given piece of data. For example, where and how it’s being stored. For KYVE, its data is available through the REST-API exposed by its consensus validators. More solutions for accessing KYVE’s data will come in the near future. And either way, accessing KYVE’s data is completely free for all!

• Want to read further into how KYVE handles data? Read into KYVE’s Docs.
• Find out more on how KYVE data is validated and accessed in this article. 

$KYVE Tokenomics

$KYVE on the Consensus Layer

As mentioned, $KYVE is used on the Consensus Layer to secure the network through DPoS, as well as enable staking and delegating. There is also an added notion of inflation. The consensus level includes inflation to incentivize validators in the case of low activity within the network. However, if there’s high network activity, inflation is counterbalanced by fee burning. Overall, promoting a stable incentivization.

$KYVE on the Protocol Layer

In order to participate on the protocol level, protocol validators must stake $KYVE tokens. In order to gain rewards and or further delegation from other users, they must behave correctly within the pool.

Example: If a validator proposes to upload a data bundle and the other validators have determined that it is correct, AKA behaving correctly, the uploader will be rewarded directly in $KYVE. (If they misbehave, a percentage of their staked $KYVE will get slashed, as explained further in this course).

There are also further security measures put in place using $KYVE, such as a minimum amount needed to stake in order to participate, or a minimum amount total stake of $KYVE within each pool. This helps avoid whales from taking over.

Example: If the 50th validator in the pool has staked 100 $KYVE, in order to take this validator’s spot, you would need to stake at least 100.01 $KYVE.

Continue on to the next chapter to go further into depth on how $KYVE is implemented in KYVE’s overall economics → 

• Want to read further into KYVE’s Tokenomics? Visit our Website.

KYVE’s Consensus & Protocol Economics

As mentioned in the previous chapter, the $KYVE is a key component of KYVE’s functionality, not just for the Protocol Layer but the Consensus Layer as well. 

For the Consensus Layer, $KYVE is staked by consensus validators, earning rewards when behaving correctly and getting slashed when behaving incorrectly. 

Consensus validators’ missions include mining the transactions produced by the protocol layer or by the users, for example, transfer transactions. Once the transactions are collected, they must be voted on by consensus validators to reach consensus and store all valid bundle references, exposing them through the REST-API. 

They are incentivized to behave properly by the $KYVE rewards payout as explained below:

The fee collector module collects all the transaction fees generated by the mint module and network traffic. The fee collector distributes these fees to the distribution module and the temporary team module (Team tokens are minted rather than staked). Then the remaining $KYVE goes to both the community pool (treasury) and the validators as rewards.

To understand $KYVE’s role in the Protocol Layer, we need to review the basic terms first:

• Funders: provide $KYVE tokens to fund a pool;
• Protocol Validators: rewarded for positive behavior in collecting, bundling, uploading, and submitting data;
• Delegators: lend validators $KYVE tokens, together earning more rewards.

As explained in the previous chapters, the Protocol Layer is made up of different storage pools, with each pool being run by funders, delegators, and protocol validators. 

A pool becomes active once a funder provides the minimum amount of $KYVE tokens required in order to incentivize the network participants. This means the tokens funded will be used to reward the protocol validators and NOT returned to the funders.

**Please note: A funder can stop funding at any time, and the data that has already been stored and validated will remain available.

Why Fund a Pool? 

Any developer, data engineer, node operator, or anyone in need of valid and archived data is motivated to fund a pool, as it gives them streamlined and continuous access to the data they need. Once they stop funding, the pool will stop working as the protocol validators are no longer incentivized. Therefore, no new data will be archived and validated. 

Currently, there are only 50 funding slots available per pool, with only those who fund the highest amount claiming a funding slot. This system ensures that only people with the highest interest in archiving the data can operate as a funder. The more funders there are in a pool, the more the cost is divided, meaning it will be cheaper for each funder.

Once tokens enter a pool, validators are immediately incentivized to participate and start uploading and validating data. If the validators behave correctly, they will receive bundle rewards in $KYVE. It’s important to note that there is a minor network fee, typically of 1%.

Then, the delegators come into the picture… 

Delegators lend validators $KYVE in order to help them earn more rewards and to have a better chance at being selected to upload a bundle or to produce a block depending on the layer. The rewards delegators receive are determined by the validator’s set commission.

The incorporation of $KYVE is specifically designed in order to incentivize all network participants to behave correctly, maintaining a proper flow of archived, validated data. In the end, making not only the blockchain and protocol function properly, but also increase the use and therefore rarity of $KYVE.

• Learn more about KYVE’s pool economics by visiting our docs.
• Want to know more about pool funding? Check out this video.

$KYVE Staking

KYVE Governance

One of the fundamental building blocks of KYVE’s functionality and decentralization is its governance. 

Governance puts the decisions of key developments of the blockchain and community in the hands of its stakeholders, rather than just one single entity. 

With KYVE, our stakeholders not only have a say in the direction of KYVE’s growth and development, but they can create their own storage pools. As KYVE’s data lake is built to make data accessible for all Web3 developers, node runners, and more, they deserve the right to choose what type of data KYVE archives and validates.

KYVE bases its governance on the Cosmos SDK* which provides a classic governance system, allowing its participants to submit proposals, vote on changes, and receive penalties or inheritances depending on who participates in the vote. A majority vote determines what actions are to take place, with each user’s voting power depending on how many bonded tokens they have to a validator.

Now, let’s take a closer look at a few features that highly contribute to KYVE’s network security and stability…

The first being passive delegation, meaning if a user misses a vote, they will inherit the vote of the validator they are delegating to. Of course, if a participant wishes to vote differently from the validator they are delegating to, their vote will have priority.

→ This ensures a proposal reaches quorum in a timely manner, depending on validators that are constantly active in the network rather than waiting for every governance participant to connect.

Another is custom voting periods for each proposal, for example, creating a pool, chain, and protocol updates, etc. This ensures that the community has the time they need in order to look over the proposals’ details as well as allow our team to react quickly when needed. 

Example: A proposal to launch a new chain update might need more time to further investigate compared to a marketing budget decision.

Lastly, there’s the option to expedite a proposal in the case of an emergency or time-sensitive changes. This feature requires a lot more $KYVE than is typically required to submit a proposal in order to be activated.

**It’s important to note that all discussions around the proposals are happening off-chain on our forum & our Discord.

So, how does the proposal on-chain process work? The governance process is divided in a few steps that are outlined below:

1. Proposal submission

Proposals are submitted to the blockchain with a deposit of $KYVE. There are several types of proposal types: for example there are proposals to create a new pool, which requires fixed values (pool config, name of the pool, etc.), proposal to schedule a runtime upgrade or even raw text proposals.

2. Voting period

Voting:

• If a new governance proposal is submitted, it will immediately be shown in the governance section of our web-application
• Once deposit reaches a certain value (MinDeposit), proposal is confirmed and vote opens.
• Bonded $KYVE holders can then vote on the proposal with Yes, No, NoWithVeto and Abstain
  • NoWithVeto counts as No but also adds a Veto vote. Abstain option allows voters to signal that they do not intend to vote in favor or against the proposal but accept the result of the vote.
  • There is also a feature called weighted votes, which allows stakers to split their votes
    • For example, it could use 70% of its voting power to vote Yes and 30% of its voting power to vote No.
• The voting power of a staker is defined as the percentage of the bonded $KYVE of the validator in relation to the total bonded $KYVE

Quorum:

• Quorum is defined as the minimum percentage of voting power that needs to be cast on a proposal for the result to be valid. In our case it is 1/3 of the total bonded tokens. Threshold is defined as the minimum proportion of Yes votes (excluding Abstain votes) for the proposal to be accepted. In our case it is 1/2 of all votes excluding Abstain.
  • Keep in mind: even if the threshold is reached, the proposal could be rejected in cause of a not reached quorum

• Veto threshold is defined as the minimum proportion of NoWithVeto votes for the proposal to be rejected. In our case it is more than 1/3 of all votes excluding.
  • If the veto threshold is reached, the proposal won’t pass anyway

3. Execution

If a proposal passes, the proposed event is going to happen automatically. 

Example: If a CreatePool proposal passes, the pool with the included configuration, binaries, etc. the blockchain creates the pool after the voting end time (and a positive outcome).

Deposit:

• When a proposal is finalized, the tokens from the deposit are either refunded or burned according to the final tally of the proposal:
  • If the proposal is approved or rejected but not vetoed, each deposit will be automatically refunded to its respective depositor (transferred from the governance ModuleAccount).
  • When the proposal is vetoed with greater than 1/3, deposits will be burned from the governance ModuleAccount and the proposal information along with its deposit information will be removed from state.

There you have it! The basics of KYVE’s Governance. Want to learn more? 

• Read into KYVE’s Docs, or Cosmos Docs.
• Stay tuned for a course tutorial on submitting a governance proposal for KYVE!
• Found a word marked with * that you’re not familiar with? Check the KYVE Glossary.

Conclusion & Resources

Congratulations! You made it through the KYVE Fundamentals Level 2 course! You are now a KYVE Network pro!

Want to go deeper into the technology of KYVE? Feel free to check these resources:

• KYVE Docs
• KYVE Github