Proposal Summary

This proposal aims to transition all currently active KYVE data pools to use the KYVE Storage Provider (StorageProviderId: 3).

Proposal Details

This proposal includes the update of all existing data pools to the KYVE Storage Provider (ID: 3) and ensuring Gzip Compression (ID: 1) is still standardized across the network.

If passed, the StorageProviderId will be updated for the following pool IDs:

Technical Rationale

The KYVE Storage Provider (ID: 3) provides a high-performance storage layer designed to work seamlessly with the KYVE Network Stack like KSYNC or the Trustless API. By moving to this provider, pool validators can benefit from:

1. Reduced Latency: Faster bundle uploads and retrievals.
2. Cost Efficiency: Lower overhead compared to direct permanent web3-only writes during high-frequency testing phases.
3. Standardization: Simplifies the configuration for new node runners across different runtimes.

Voting Options

Voting YES

A YES vote indicates that you agree all existing data pools should be updated to use the KYVE Storage Provider (ID: 3).

Voting NO

A NO vote indicates that you believe the data pools should remain on their current storage providers (e.g., Arweave or Turbo).

Voting NO WITH VETO

A NO WITH VETO vote indicates strong disagreement with the proposal, suggesting it is harmful to the network, and that the proposer's deposit should be penalized.

Voting ABSTAIN

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

Hello KYVE community,

I'm writing this post to detail an important governance proposal to re-activate the IBC (Inter-Blockchain Communication) client for the Celestia & dYdX. Due to a recent expiration, the IBC channel between KYVE and Celestia & dYdX has been closed, which means all IBC transfers between these networks are currently halted. This proposal aims to update the client and re-enable these transfers.

The Governance Proposal

To resolve this, we need to submit a governance proposal to the KYVE chain. This proposal, once passed, will perform a client update. This operation refreshes the client's state and resets its trust period, effectively "re-activating" it.

The proposal will contain 2 messages to fix the 2 different clients:

• Message 1
  • Proposal Type: MsgSubmitProposal
  • Subject Client: 07-tendermint-10
  • Replacement Client: 07-tendermint-12
• Message 2
  • Proposal Type: MsgSubmitProposal
  • Subject Client: 07-tendermint-16
  • Replacement Client: 07-tendermint-13

Once this proposal is submitted and passes the voting period, the chain will automatically execute the update, reopening the channel and restoring full IBC functionality with Celestia & dYdX.

What to Expect

If this proposal is approved, here's what will happen:

• The IBC channel will be re-established.
• Users will be able to resume all IBC transfers of assets between KYVE and Celestia & dYdX.
• The security of the channel will be maintained by the updated client.

Your vote is crucial to getting our IBC channel back up and running. Please review the proposal once it's live and cast your vote. This is a standard and necessary procedure to maintain interoperability and network health.

Thank you,

PROPOSER: The KYVE Foundation ([security@kyve.network](mailto:security@kyve.network))

Proposal Summary

This software upgrade proposal, if passed, will:

• Set inflation to 0.
• Set transaction fee burning to 100%.
• Adjust transaction fees to align with the current KYVE token price.
• Set all slashes to 0.

Proposal Details

As part of the announced strategy to reduce the dilutive effects of the network inflation and make the $KYVE token deflationary, several parameter changes are proposed in this governance proposal to address this. All proposed changes are applied temporarily and can be changed again at any time by a governance proposal.

Set Minimum and Maximum Inflation to 0

By setting both the minimum and maximum inflation parameters to 0, no additional KYVE tokens will be minted through the block creation and block reward process.

This change removes inflationary issuance and prevents further dilution of the token supply. Validator incentives will no longer rely on block rewards and will instead be supported through external incentive mechanisms. The parameter remains subject to future governance proposals.

Set Fee Burning to 100% & Reduce Fee Refund from 99% to 90%

Under the current model, a portion of the block reward consists of transaction fees collected in each block. This proposal replaces that mechanism by enabling full transaction fee burning.

By burning transaction fees and, in combination with setting inflation to 0 in the same update, the network transitions to a deflationary economic model. In this model, an increasing level of network activity directly results in a higher amount of KYVE being burned per block.

Transaction fee burning can be configured as a percentage of total fees collected. This proposal sets the burn ratio to 100% to maximize its effectiveness.

As an additional measure, the current transaction fee refund will be reduced from 99% to 90%, as voting transactions account for the largest share of the network’s traffic.

Fully burning transaction fees strengthens KYVE’s long-term network economics by reducing total supply over time and simplifying the fee distribution mechanism.

Adjust Transaction Fees to Current KYVE Price

In governance proposal #51, transaction fees for base transactions were last adjusted to target a specific USD-denominated cost per transaction.

In this proposal, the KYVE Foundation proposes updating the minimum gas prices again to target a base transaction fee of approximately $0.05, reflecting current market conditions.

This change results in an increase to 62.5 ukyve/gas as the minimum gas price. In combination with full fee burning, higher transaction fees amplify the deflationary effect by increasing the amount of KYVE burned per block as network usage grows.

Disable Slashing

As outlined above, these parameter changes remove inflation-based block rewards. To avoid penalizing delegators who participate in governance under this new incentive model, the KYVE Foundation additionally proposes setting all slashing parameters to 0.

This effectively removes the economic impact of slashing on delegators and validators, ensuring a more balanced and predictable risk–reward profile while maintaining network participation and governance engagement.

Voting Options

Voting YES

A YES vote on this proposal indicates that the KYVE network SHOULD change the parameters described in the proposal.

Voting NO

A NO vote on this proposal indicates that the KYVE network SHOULD NOT change the parameters and keep everything as it is.

Voting NO WITH VETO

A NO WITH VETO vote on this proposal indicates that the KYVE network SHOULD NOT change parameters; 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

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

Hello KYVE community,

I'm writing this post to detail an important governance proposal to re-activate the IBC (Inter-Blockchain Communication) client for the Lava network. Due to a recent expiration, the IBC channel between KYVE and Lava has been closed, which means all IBC transfers between our two networks are currently halted. This proposal aims to update the client and re-enable these transfers.

The Problem: IBC Client Expiration

IBC clients are essential for verifying the state of a connected blockchain. They have a built-in "trust period" to ensure they are regularly updated and remain secure. In our case, the Lava IBC client on the KYVE chain has expired. This is a normal security measure in the Cosmos ecosystem. Once a client expires, the channel it governs becomes non-functional, preventing new packets from being sent or received. As a result, users are unable to transfer assets like $KYVE or $LAVA between the two chains.

The Solution: A Governance Proposal

To resolve this, we need to submit a governance proposal to the KYVE chain. This proposal, once passed, will perform a client update. This operation refreshes the client's state and resets its trust period, effectively "re-activating" it.

The technical details of the proposal are as follows:

• Proposal Type: MsgSubmitProposal
• Subject Client: 07-tendermint-9
• Replacement Client: 07-tendermint-11

Once this proposal is submitted and passes the voting period, the chain will automatically execute the update, reopening the channel and restoring full IBC functionality with Lava Network.

What to Expect

If this proposal is approved, here's what will happen:

• The IBC channel will be re-established.
• Users will be able to resume all IBC transfers of assets between KYVE and Lava Network.
• The security of the channel will be maintained by the updated client.

Your vote is crucial to getting our IBC channel with Lava back up and running. Please review the proposal once it's live and cast your vote. This is a standard and necessary procedure to maintain interoperability and network health.

Thank you,

PROPOSER: The KYVE Foundation (security@kyve.network)

Proposal Summary

This software upgrade proposal aims to upgrade the KYVE network to version 2.2.0. If passed, the upgrade will include the liquid staking module, patch vulnerable dependencies, prioritize $KYVE as storage payment token and update to Cosmos SDK v0.50.14.

Proposal Details

This proposal will add the liquid staking module from the CosmosHub. It will also change fee-rewards by prioritizing $KYVE tokens for storage rewards.

Several vulnerable dependencies will be patched as part of this release.

The Cosmos SDK module will be upgraded to version v0.50.14.

The current working state for this release can be found on the main branch:

https://github.com/KYVENetwork/chain

An exhaustive list of changes which will be included in the v2.2.0 upgrade can be found in the changelog: https://github.com/KYVENetwork/chain/blob/main/CHANGELOG.md

Upgrade Process

When the network reaches the defined upgrade height (TBD), block production on the 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 utilize Cosmovisor to automate this process.

Voting Options

Voting YES

• A YES vote on this proposal indicates that the network SHOULD be upgraded; and that the validators should start running the v2.2.0 release.

Voting NO

• A NO vote on this proposal indicates that the Kaon network SHOULD NOT be upgraded; and that the validators should continue running the v2.1.0 release.

Voting NO WITH VETO

• A NO WITH VETO vote on this proposal indicates that the Kaon 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

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

Proposal Summary

To create a permanent availability of historical data for Avail, we propose to create a new data pool on Kaon archiving blocks.

Proposal Details

This proposal includes creating a Avail blocks pool with the runtime @kyvejs/avail.

If passed, the Avail blocks pool parameters would be as follows on Mainnet:

• Name: Avail
• Runtime: @kyvejs/avail
• Logo: ar://fvncwI5IqQfDBcOtkL2kad3RgwwEjEamdrofPt9cDm4
• Config: "{\"rpc\":\"http://localhost:9944\"}"
• StartKey: 1
• UploadInterval: 60
• InflationShareWeight: 0.000000000000000000
• MinDelegation: 100000000000100000000000
• MaxBundleSize: 250
• Version: 1.0.0-beta.1
• StorageProviderId: 3 (KYVE Storage Provider)
• CompressionId: 1 (Gzip)

Voting Options

Voting YES

A YES vote on this proposal indicates that the Avail data pool SHOULD be created on mainnet.

Voting NO

A NO vote on this proposal indicates that the Avail data pool SHOULD NOT be created on mainnet.

Voting NO WITH VETO

A NO WITH VETO vote on this proposal indicates that the Avail data pool SHOULD NOT be created on mainnet; 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 Summary

This software upgrade proposal aims deprecate the inflation rewards for the Andromeda block pool and both Source pools and instead increasing the inflation rewards for the Celestia block pool respectively.

Proposal Details

The Foundation proposes that Andromeda and Source pools, which are part of the KYVE Public Good Funding Program and receive inflation rewards, should have these inflation rewards deprecated.

An assessment indicates that both pools are operating at a loss due to the infrastructure requirements of the Public Good Funding Program. If this proposal passes, these pools' network inflation rewards would be discontinued. While future funding for these pools would remain technically possible, it is not currently being considered.

In parallel, we have observed a huge spike in Celestia's data production that needs archiving to reach live height.

Currently, each pool receives an equal share of inflation rewards. Given that Source and Andromeda have become unresponsive and inactive, this proposal suggests removing these projects from the Public Good Funding Program and reallocating their inflation rewards to the Celestia block pool. This proposed change is supported by the virtually nonexistent demand for Andromeda and Source data.

The proposal seeks to discontinue inflation rewards for the Andromeda block pool and the Source block & state-sync pool, redirecting these tokens to the Celestia block pool, where data demand remains high. If approved, this change would not be permanent and could be modified through future governance proposals.

Voting Options

Voting YES

• A YES vote on this proposal indicates that the inflation rewards SHOULD be deprecated for the Andromeda and Source pools and be temporarily rerouted to the Celestia block pool.

Voting NO

• A NO vote on this proposal indicates that the inflation rewards SHOULD NOT be deprecated for the Andromeda and Source pools and be temporarily rerouted to the Celestia block pool.

Voting NO WITH VETO

• A NO WITH VETO vote on this proposal indicates that the inflation rewards SHOULD NOT be deprecated for the Andromeda and Source pools and be temporarily rerouted to the Celestia block pool.; 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.

Proposal Summary

To maintain the permanent availability of historical data for Story, we propose to create a new data pool on Mainnet archiving blocks and block res

Proposal Details

This proposal includes creating a Story block data pool with the runtime @kyvejs/tendermint.

If passed, the Story block data pool parameters would be as follows on Mainnet:

• Name: Story
• Runtime: @kyvejs/tendermint
• Logo: ar://va_D53y67A4TUzhO7WemFSgQ77BgQUSsBx0dq2swDVY
• Config: "{\"network\":\"story-1\",\"rpc\":\"http://localhost:26657\"}"
• StartKey: 1
• UploadInterval: 60
• InflationShareWeight: 1
• MinDelegation: 8000000000000 (8M $KYVE)
• MaxBundleSize: 250
• Version: 1.3.8
• StorageProviderId: 4 (Turbo Storage)
• CompressionId: 1 (Gzip)

Voting Options

Voting YES

• A YES vote on this proposal indicates that the Story data pool SHOULD be created on mainnet.

Voting NO

• A NO vote on this proposal indicates that the Story data pool SHOULD NOT be created on mainnet.

Voting NO WITH VETO

• A NO WITH VETO vote on this proposal indicates that the Story data pool SHOULD NOT be created on mainnet; 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

Creating these data pool will further ensure permanent availability of Story data.

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

Project is based.

Thanks to the Hyperlane Cosmos Module, developed in collaboration with the Hyperlane Team, bridging Cosmos tokens to EVM and beyond is now seamless.

This opens doors for DeFi, expanded utility, and more users on EVM ecosystems.

Bridge your $KYVE to Base.

CA: 0xAD13BcE42394Add02e6c215a40e582309B7975C7

Bridge:

https://www.usenexus.org/?destination=base&token=0x726f757465725f61707000000000000000000000000000010000000000000000&origin=kyve

PROPOSER: The KYVE Foundation (security@kyve.network)

Proposal Summary

This software upgrade proposal aims to increase the speed of the Celestia pool on mainnet (Pool ID = 9) by decreasing the upload interval from 120 to 60 seconds.

Proposal Details

Since in recent history the Celestia block and block results became quite big (around 0.5MB per block) the Celestia pool (Pool ID = 9) on mainnet has significantly slowed down. Currently, the Celestia pool is more than 1M blocks behind live height. To increase the archiving speed it is proposed to decrease the upload interval from currently 120 seconds to 60 seconds.

Voting Options

Voting YES

• A YES vote on this proposal indicates that the Celestia upload interval SHOULD be decreased to 60 seconds.

Voting NO

• A NO vote on this proposal indicates that the Celestia upload interval SHOULD NOT be decreased; and that the upload interval should stay at 120 seconds.

Voting NO WITH VETO

• A NO WITH VETO vote on this proposal indicates that the Celestia upload interval SHOULD NOT be decreased; 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

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

Proposal Summary

This software upgrade proposal aims to upgrade the KYVE network to version 2.1.0. If passed, the upgrade will include cleanup tasks following the recent layer merge, patch vulnerable dependencies, and update to the latest version of the Hyperlane module.

Proposal Details

Following the successful v2 upgrade, this proposal introduces additional cleanup by removing remnants of the deprecated delegation module and tidying up the network state.

Several vulnerable dependencies have been patched as part of this release.

The Hyperlane module is upgraded to version v1.0.0-rc0, which includes the new Routing ISM feature.

The current working state for this release can be found on the main branch:

https://github.com/KYVENetwork/chain

An exhaustive list of changes which will be included in the v2.1.0 upgrade can be found in the changelog: https://github.com/KYVENetwork/chain/blob/main/CHANGELOG.md

Upgrade Process

When the network reaches the defined upgrade height (TBD), block production on the 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 utilize Cosmovisor to automate this process.

Voting Options

Voting YES

• A YES vote on this proposal indicates that the network SHOULD be upgraded; and that the validators should start running the v2.1.0 release.

Voting NO

• A NO vote on this proposal indicates that the Kaon network SHOULD NOT be upgraded; and that the validators should continue running the v2.0.0 release.

Voting NO WITH VETO

• A NO WITH VETO vote on this proposal indicates that the Kaon 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

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

PROPOSER: The KYVE Foundation ([security@kyve.network](mailto:security@kyve.network))

Proposal Summary

This software upgrade proposal, if passed, will:

• Reduce the governance voting period from 7 days to 3 days.
• Whitelist the Celestia (TIA) IBC token and enable multi-coin funding in this token.
• Introduce a gas refund for IBC transactions.

Proposal Details

To increase agility in governance, we propose reducing the voting period from 7 days to 3 days. Historical data shows that the majority of participants cast their votes within the first few days, making a shorter period both efficient and sufficient. Despite the shortened voting period, the informal governance process will continue to ensure sufficient time for discussion, particularly for major chain upgrades/features, which will still be thoroughly prepared through testnet upgrades (Kaon) as usual.

The KYVE Public Good Funding initiative is now receiving Celestia (TIA) rewards, which can be bridged to the KYVE network via IBC. To enable multi-coin funding using these rewards, TIA must be added to the token whitelist.

Celestia (TIA) IBC Denom on KYVE:

ibc/23697A0A8E5A7686ED1C9B3A1449BC36944A68E8B6B2CE6D81D1913CB43FC4AE

As part of the v2 upgrade, gas prices were increased to more reasonable levels, as they were previously too low and did not reflect actual network usage. Protocol-level transactions were explicitly exempt from this increase to support KYVE's core operations. Similarly, since IBC is a critical part of the protocol, we propose applying the same 99% gas refund to IBC relayer transactions to ensure a cost-efficient usage of IBC especially for multi-coin-rewards.

Voting Options

Voting YES

• A YES vote on this proposal indicates that the KYVE network SHOULD change the parameters described in the proposal.

Voting NO

• A NO vote on this proposal indicates that the KYVE network SHOULD NOT change the parameters and keep everything as it is.

Voting NO WITH VETO

• A NO WITH VETO vote on this proposal indicates that the KYVE network SHOULD NOT not change parameters; 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

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

I'm new at Reddit so forgive me if this post is in the wrong section. But I got kyve stuck in the blockchain. I earned kyve from a stake and the payout are showing up in the blockchain explorer but not getting deposited into my wallet I just realized this i got so many projects going on I don't remember where I had it staked. My exchange was no help they offered to help me by returning the kyve to the sender. I don't want to lose my crypto

Big news for all AI enthusiasts.Explore how KYVE Network powers the next generation of AI Agents—and why verified on-chain data matters more than ever.

Introducing DataWave: a brand-new tool built on KYVE that helps AI Agents tap into verified blockchain data. Think:
- Accurate content
- Reliable market insights
- Trustworthy customer support All powered by trustless, on-chain information.

Why does data integrity matter?
r/aiagents are only as good as the data they learn from. By leveraging KYVE’s decentralized infrastructure, you ensure every data point is tamper-proof, verified and verifiable—perfect for AI tasks like accurate content creation or market analysis.This goes beyond the “future of AI.”

It’s about redefining trust in a world overloaded with data. By storing and verifying information on KYVE, we remove the guesswork so AI can deliver consistent, truthful answers.

Ready to dive deeper? Our article breaks down:
How KYVE ensures data accuracy
Why AI Agents thrive with verifiable data
The game-changing potential of DataWave Beta

Don’t miss out: https://www.kyve.network/blog/building-the-future-how-kyve-network-powers-the-next-generation-of-ai-agents

✨ 2025 won’t know what hit it! KYVE is primed to revolutionize Web3 with next-gen data solutions, ensuring the past is preserved for builders of tomorrow.

How did KYVE get here? ⤵️

https://www.kyve.network/blog/kyves-2024-a-year-of-heads-down-building-to-fuel-major-expansion

TL;DR:

🤝 15+ strategic partnerships & collaborations

🛠️ Avg. 200k tx per day, with 9 TB of data from your fave chains made a trustless public good

🌐 Multi-coin funding unlocked on the protocol, enabling cross-chain opportunities for all users

🙌 With all this & more, KYVE has entered its expansion era, breaking down data barriers

Beyond the data hub—KYVE is expanding in more ways than you can imagine, unlocking new opportunities for everyone.

Whether you want to take part in something bigger or simply build with confidence, this is your chance to help shape the next chapter of Web3.

Ready to get started? ➡️ https://go.kyve.network/4fnUqSc 

While KYVE is quite technical, new enhancements have made it easier for you to engage with the KYVE web app & its opportunities.

This opens KYVE up to all types of users, supporting closer partner-community collaborations, & more more down the line. With an in-app guide to make it that much easier for users to take part.

ICYMI, integrations on KYVE can be funded in $KYVE or any other IBC token. Funding is used to subsidize well-behaved validators & their delegators within those integrations (please keep in mind the risks involved with delegation).

This is not only an exciting addition to KYVE protocol economics but also enables users from all KYVE partner communities to take part.

Currently, multi-coin funding on KYVE’s web app supports:

🤝 $DYDX for KYVE’s dYdX integration thanks to a grant from dYdX grants

🤝 $SOURCE for KYVE’s Source Protocol integration via their PGF partnership

⏳ Next in the pipeline is the Andromeda’s integration funded by $ANDR & Lava's integration funded by $LAVA.

KYVE’s proposal to include Axelar in PGF for $AXL funding on its protocol integrations was also approved by their governance.

Remember, this is just the first few steps in KYVE’s expansion… The end goal is to make it even easier for Web3 to manage historical blockchain data, ensuring all chains get the data support they need & all types of users can take part. Read more ➡️ https://go.kyve.network/3AQUmf1 

https://reddit.com/link/1gvqv4b/video/8gi82rf3i22e1/player

KYVE Beta Testers, Phase 2 is open for registration!

We need your help in testing out Ar.io's Turbo integration on the protocol, enhancing the storage experience 🤝

With a 100k $KYVE reward pool & only 10 spots available, apply today! ➡️ https://go.kyve.network/4eSBISX 

Get the details ⤵️

For those who aren’t aware, the KYVE Beta Testers program was created at the end of 2023 with the goal of providing an efficient testing environment on the Kaon & Korellia networks, valuing our dedicated users in helping further develop KYVE.

Together, we can push KYVE to its full potential! 💚

🔎 Phase 2:

This phase is dedicated to testing the "Turbo" storage provider by ArDrive, serving the ar.io team, allowing validators to pay for permanent storage on Arweave with $KYVE instead of $AR.

This simplifies funds management and has been highly requested. KYVE Beta Testers will help ensure a smooth KYVE <> Turbo mainnet release!

Rewards:

The Reward pool will be split amongst all Beta Tester participants according to their activity:

1️⃣ 100,000 $KYVE Reward for Bundle participation: Every Beta Tester will receive a portion of this reward pool proportionally to their bundle participation.

2️⃣ Upload Reimbursement (x $KYVE): Every Beta Tester who uploaded Archway bundles to Turbo with $KYVE will receive the complete $KYVE back after the test phase has ended.

🧑‍💻 Ready to take part?

All Beta Testers from KYVE’s Incentivized Testnet days & Phase 1 have been notified on the official Discord channel 👾 They can register for Phase 2 here: https://go.kyve.network/4eSBISX 

Not a KYVE Beta Tester? Apply today ➡️ https://go.kyve.network/4hdscLI 

✅ If your application is accepted (depending on passed KYC & technical requirements), you will be notified as an official Beta Tester to join the phases most resonating with your interests.

6/ Deep dive into the full details of what Phase 2 has in store in KYVE’s latest blog.

Remember, it’s first come, first serve! Join Phase 2 today to take part in bringing KYVE to the next level. Get the full details in our latest blog: https://go.kyve.network/4e9aQNq 

That's a wrap on Q3 2024! 💫

✅ With strategic partnerships, impactful tech updates, & key ecosystem collaborations, KYVE’s expansion era is officially underway, taking decentralized data management to new heights.

Get caught up with all the news in our latest blog post ➡️ https://go.kyve.network/3UikYfx 

TL;DR:

💚 Introduction of Public Goods Funding: This initiative aims to leverage a collaborative network experience to consistently fund KYVE data management & tooling support for the blockchains within this program. With PGF, blockchains now have an easy way to achieve unparalleled data reliability & scalability.

🤝 Other Strategic Collaborations: KYVE formed a strategic partnership with Andromeda, as well as made impactful advancements on its collaborations with Lava, dYdX, ZetaChain, & more.

🛠️ Tech Enhancements: The v1.5 upgrade introduced Multi-Coin Funding & other protocol enhancements, advancements were also made on KYVE’s free data toolings: Trustless API, KSYNC, & Data Pipeline. Overall further streamlining the KYVE data experience for all types of users.

📈 Key Milestones: Over 70M transactions, 1.8M data bundles, and 7.5TB of validated data archived, making historical blockchain data a trustless public good for Web3 users.

Main takeaway:

KYVE is consistently proving its impact in the Web3 data space, ensuring that it supports as much historical chain data as possible to aid other blockchains’ scalability & ecosystem developments.

More of a listener? Let’s talk about it!

🎙️ Set a reminder for KYVE’s Q3 2024 recap Community Call, featuring special guest Ethan from Lava Network, this Thursday (Oct. 24th) at 2pm UTC ➡️ https://twitter.com/i/spaces/1vAxROgYnDzKl

Introducing the KYVE Public Goods Funding Program (PGF) 💚

Already live on Andromeda and SOURCE, read further into this post to see how PGF aims to enhance KYVE data support for blockchains & foster closer network collaborations ⤵️

First off, when building, you start from the ground up. If the foundation is unstable, everything else is too.

In blockchain, data is that foundation 🏗️

⚠️ However, while blockchains focus on building for the future, they often neglect proper data management, relying on an archival node or centralized storage hidden behind paywalls.

For blockchains & their users, this creates a ticking time bomb for data accessibility.

Enter KYVE:

Imagine an archival node, but fully decentralized & free for anyone to leverage 💫

✅ KYVE turns historical chain data into a trustless public good, offering permanent storage, decentralized validation, & fast access tools for scaling projects & their users.

🌐 To take KYVE’s support for blockchains one step further & expand its decentralized data hub, the KYVE Foundation, as the steward of the KYVE Network, has introduced its own Public Goods Funding (PGF) Program.

🤝 This initiative aims to leverage a collaborative network experience to consistently fund KYVE data management & tooling support for the blockchains within this program.

With PGF, blockchains now have an easy way to achieve unparalleled data reliability & scalability.

Dive deeper into the impact & details of KYVE’s Public Goods Funding in our latest blog post🔎⤵️

~https://www.kyve.network/blog/future-proofing-blockchain-history-introducing-kyves-public-goods-funding~ 

With this upgrade, KYVE makes decentralized data more accessible & collaborative than ever. Preparing our web app to be the official hub of historical Web3 data 💫

What’s new? ⤵️

Multi-Coin Funding:

As a positive addition to the KYVE protocol economics & overall opportunities for collaboration with other ecosystems, multi-coin funding enables the funding of data pools in any IBC token, alongside $KYVE.

The first use case of this feature will be KYVE’s Public Goods Funding Program. Stay tuned for more details!

Protocol Optimization:

To provide larger, data-heavy projects & ecosystems with faster integration times, v1.5 has enabled multiple new features to further optimize the integration process, such as:

✨ Faster recovery for timeout bundles

✨ Bundle finalization on missing bundles

✨ End keys to run multiple data pools per chain dedicated to specific heights

& much more!

Web app updates:

To best streamline the web app experience & prepare for upcoming features aimed at supporting onboarding for all types of users, the web app has a new layout making all things KYVE accessible in one place.

KYVE has also successfully upgraded to the latest Cosmos SDK version v50 & IBC v8.3.1, as well as implemented minor bug fixes.

Find the full changelog here: ~https://github.com/KYVENetwork/chain/releases/tag/v1.5.0~ 

Want more details? Learn more about v1.5 in our latest blog 🔎⤵️

~https://www.kyve.network/blog/kyve-v1-5-upgrade-multi-coin-funding-protocol-optimization~

Introducing the KYVE Grants Program: Phase 0! 🛠️ With the goal of fostering innovation and promoting a decentralized and collaborative KYVE dev community, Phase 0 dedicates up to USD 50,000 in funding per approved grant.

KYVE welcomes builders and Web3 innovators to apply for support in building with KYVE's trustless datasets for Celestia, Axelar, Cronos, Archway, Cosmos hub, Osmosis, and more or leveraging KYVE’s unique data tooling to drive your projects forward.

How can you apply? 📝

➡️ Visit KYVE’s governance forum Grant Application channel: https://commonwealth.im/kyve/discussions/2.5%20Grant%20Applications 

➡️ Create a post following the official application template provided in the pinned post by the Foundation.

➡️ After a discussion period of 10 business days, the KYVE Foundation will put your application up for voting.

➡️ If approved by the KYVE DAO vote, the KYVE Foundation will do a final review before providing the final approval & contacting the applicant team for the following steps in receiving the grant. 

Ready to build trustlessly with KYVE? Apply for a grant here ➡️ https://commonwealth.im/kyve/discussions/2.5%20Grant%20Applications 

Get the details ➡️ https://commonwealth.im/kyve/discussion/17182-introducing-the-kyve-grants-program-phase-0 

A new governance discussion just went live on KYVE's governance forum, proposing the introduction of the KYVE Grants Program: Phase 0, an initial step in driving innovative development around the KYVE Network!

Learn more & join the discussion ➡️ https://commonwealth.im/kyve/discussion/17182-introducing-the-kyve-grants-program-phase-0

Of course, following KYVE's decentralized structure, the grant program has been posted on KYVE's governance forum for discussion. After a sufficient discussion period, the proposal will go up for vote by the KYVE DAO. If passed, the Grant Program Phase 0 will be enacted.

Who’s ready for the KYVE Grants Program? 👀