# Complementary Proposal to Pyth Reserve Evolution: Onchain Burn for Pyth Entropy Protocol Fees **URL:** \ **Category:** Ideas Bank\ **Tags:** operational-pip\ **Created:** [June 7, 2026, 4:09pm UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602 "2026-06-07T16:09:56Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![scp](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/scp/32/627_2.png) [@scp](https://forum.pyth.network/u/scp)\ **Post date:** [June 7, 2026, 4:09pm UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602/1 "2026-06-07T16:09:56Z")
# Goal Add a simple, automatic onchain burn for Pyth Entropy protocol fees, creating a direct “usage = deflation” mechanism (SEDA-style). Before reading this proposal, refer to [Idea: Pyth Reserve Evolution: Ratio-Based Management + Sustainable Partial Burns](https://forum.pyth.network/t/idea-pyth-reserve-evolution-ratio-based-management-sustainable-partial-burns/2601) for general idea. ## Current Situation Entropy protocol fees (the DAO portion) are collected onchain and accumulate in smart contracts across chains. They are later withdrawn to the DAO treasury. ## Proposed Solution Update the Entropy contracts so that on every randomness request: - **50% of the protocol fee → automatically burned** on the same chain (to 0xdead… address) - **50% of the protocol fee → stays withdrawable** to the DAO treasury (to support the main 33% Reserve proposal) **Implementation** : One contract upgrade + governance vote. Can start with a pilot on high-volume chains. ## Benefits of Adding This (On Top of Treasury Proposal) - **Faster & More Automatic Burns:** Burns happen instantly with every Entropy request, instead of waiting for withdrawals and monthly DCA. - **Stronger Narrative:** Creates a clear usage-driven flywheel — more people use Entropy = more tokens burned automatically. - **Better Visibility:** Onchain burns are public and real-time, which looks stronger to the community. - **Diversified Deflation:** Treasury proposal handles offchain revenue + withdrawn fees. Entropy burn handles onchain usage directly. - **Zero Extra Cost to Users:** The protocol fee is already being charged — we’re just splitting it (burn vs treasury). - **End Result:** Similar total deflation to doing everything in the DAO, but faster and more transparent. This onchain burn complements the main treasury proposal perfectly: one is simple & broad (treasury), the other is automatic & usage-tied (Entropy). ## Open Questions 1. Burn split: 50/50 good, or 40/60? 2. Start with pilot or all chains? 3. Do this together with the treasury proposal or as Phase 2? From SCP with Love, Community Council ---
**Author:** ![Cakky](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/cakky/32/850_2.png) [@Cakky](https://forum.pyth.network/u/Cakky)\ **Post date:** [June 7, 2026, 7:24pm UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602/2 "2026-06-07T19:24:04Z")
Love this idea i would go for the 50-50 burn on all chains ---
**Author:** ![Mersault](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/mersault/32/651_2.png) [@Mersault](https://forum.pyth.network/u/Mersault)\ **Post date:** [June 7, 2026, 7:36pm UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602/3 "2026-06-07T19:36:10Z")
Entropy charges fees in native tokens rather than $PYTH. Therefore, in most cases, this mechanism will result in burning $ETH or other native chain coins rather than $PYTH itself. What effect will this have on $PYTH? ---
**Author:** ![SkyZ](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/skyz/32/788_2.png) [@SkyZ](https://forum.pyth.network/u/SkyZ)\ **Post date:** [June 8, 2026, 12:18pm UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602/4 "2026-06-08T12:18:44Z")
We could implement Entropy earnings for burn via pythwheel. Interesting 👀 ---
**Author:** ![lowkeigh](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lowkeigh](https://forum.pyth.network/u/lowkeigh)\ **Post date:** [June 9, 2026, 7:04am UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602/5 "2026-06-09T07:04:20Z")
I personally think 50/50 and go straight ahead with all chains. Keeping seperate from treasury proposal might be easier as this should be simpler to implement and use as a pilot of sorts ---
**Author:** ![Archibald322](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/archibald322/32/872_2.png) [@Archibald322](https://forum.pyth.network/u/Archibald322)\ **Post date:** [June 9, 2026, 2:17pm UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602/6 "2026-06-09T14:17:51Z")
Mersault raises the critical issue. Entropy fees are collected in native chain tokens — ETH on Ethereum, MON on Monad — not in PYTH. So burning 50% of protocol fees deflates those networks, not PYTH supply directly. The mechanism only creates PYTH deflation if those native tokens would have been converted to PYTH downstream in the treasury pipeline. What percentage of current Entropy withdrawals actually end up as PYTH purchases? If that number is high, the indirect deflation argument holds. If it’s low, the “usage = PYTH deflation” narrative doesn’t deliver what the proposal describes. The 50/50 vs 40/60 discussion is secondary to this — optimizing a split that may not create the expected token impact. ---
**Author:** ![KemarTiti](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/kemartiti/32/5_2.png) [@KemarTiti](https://forum.pyth.network/u/KemarTiti)\ **Post date:** [June 22, 2026, 2:07pm UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602/7 "2026-06-22T14:07:20Z")
Thanks for putting this together @scp. A few operational points worth flagging: **On withdrawals:** “They are later withdrawn to the DAO treasury” This hasn’t actually happened yet from any chain. Withdrawing requires a contract upgrade via Pythian Council (doable), but the trickier part is getting the tokens to Solana where the DAO operates. Bridging native tokens (say, ETH from Blast) back to Solana isn’t straightforward and it’s unclear which bridges even support those routes, and slippage/costs could be meaningful. Might make more sense to find a counterparty willing to receive tokens on the source chain rather than bridging everything. The counterparty could then send USDC directly to the DAO Treasury. **On onchain burns:** “50% of the protocol fee → automatically burned on the same chain (to 0xdead…)” As Mersault and Archibald322 pointed out, we’re collecting native tokens (MON, ETH, etc.), not PYTH. Burning these to 0xdead deflates those chains’ supply, not PYTH. And swapping to PYTH onchain isn’t practical since PYTH liquidity lives on Solana. Rather than burning or bridging piecemeal, what if we find a single counterparty willing to: - Receive accumulated native tokens across chains - Provide equivalent value to the DAO (same tokens, or USD-denominated) This would let the DAO consolidate everything cleanly and fold it into existing monthly PYTH purchases. It’s simpler operationally and achieves the same deflationary outcome without the bridge/swap complexity. ---
**Author:** ![scp](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/scp/32/627_2.png) [@scp](https://forum.pyth.network/u/scp)\ **Post date:** [July 10, 2026, 8:37am UTC](https://forum.pyth.network/t/complementary-proposal-to-pyth-reserve-evolution-onchain-burn-for-pyth-entropy-protocol-fees/2602/8 "2026-07-10T08:37:43Z")
> [@KemarTiti](#): > > Thanks for putting this together @scp. A few operational points worth flagging: > > **On withdrawals:** > > “They are later withdrawn to the DAO treasury” > > This hasn’t actually happened yet from any chain. Withdrawing requires a contract upgrade via Pythian Council (doable), but the trickier part is getting the tokens to Solana where the DAO operates. > > Bridging native tokens (say, ETH from Blast) back to Solana isn’t straightforward and it’s unclear which bridges even support those routes, and slippage/costs could be meaningful. Might make more sense to find a counterparty willing to receive tokens on the source chain rather than bridging everything. The counterparty could then send USDC directly to the DAO Treasury. > > **On onchain burns:** > > “50% of the protocol fee → automatically burned on the same chain (to 0xdead…)” > > As Mersault and Archibald322 pointed out, we’re collecting native tokens (MON, ETH, etc.), not PYTH. Burning these to 0xdead deflates those chains’ supply, not PYTH. And swapping to PYTH onchain isn’t practical since PYTH liquidity lives on Solana. > > Rather than burning or bridging piecemeal, what if we find a single counterparty willing to: > > - Receive accumulated native tokens across chains > - Provide equivalent value to the DAO (same tokens, or USD-denominated) > > This would let the DAO consolidate everything cleanly and fold it into existing monthly PYTH purchases. It’s simpler operationally and achieves the same deflationary outcome without the bridge/swap complexity Thanks @KemarTiti for the thoughtful feedback. I agree that bridging native assets from every chain back to Solana introduces operational complexity and costs, and I also agree that burning native gas tokens directly doesn’t achieve the intended deflationary effect for PYTH. My main objective is to establish a clear policy that a portion of Entropy protocol revenue should ultimately be used to create sustainable buy pressure for PYTH. If an OTC or market-making counterparty can consolidate assets across chains and deliver USDC (or equivalent value) directly to the DAO Treasury, that seems like a much more practical implementation than individual bridging and swaps. From my perspective, the implementation details can evolve over time, but the core principle remains the same: protocol revenue should contribute toward strengthening the PYTH ecosystem and the $PYTH token itself.