Idea: Pyth Reserve Evolution: Ratio-Based Management + Sustainable Partial Burns

Ideas Bank
1

Summary

We propose evolving the Pyth Reserve from pure accumulation to accumulation + sustainable deflation. This framework maintains strong PYTH holdings for DAO alignment, governance power, grants, and protocol support, while introducing predictable burns tied to revenue growth.

It merges:

  • Ratio-based treasury management
  • Fixed partial burn split on new purchases
  • Excess burn rule (inspired by Lowkeigh)

Inspired by:

Background

The current Pyth Reserve (OP-PIP-87, established December 2025) works as follows:

  • Monthly, 1/3 of non-PYTH treasury assets are transferred to the Pythian Council Ops Multisig.
  • Council executes DCA purchases of PYTH (max 5% slippage, max $25K/tx).
  • All purchased PYTH is returned to the DAO Treasury and held in the Reserve.

-> Full details: OP-PIP-87: PYTH Token Phase 2

With growing enterprise revenue and flexible Douro Labs remittances (60% to DAO in USDC, PYTH, or mix via CO-PIP-105), we need a smarter system that avoids over-concentration while delivering real supply reduction.

Proposed Framework

Monthly Process (Builds directly on existing 33% mechanism):

  1. Douro Labs remits certain % of revenue (unchanged, subjected to different products).
  2. Execute 33% DCA buys (same rules as today).
  3. Fixed Partial Split on all newly bought PYTH:
    • 45% burned immediately to a dead address (transparent on-chain).
    • 55% held in the DAO Treasury / Reserve.
  4. Excess Burn Rule: (subjected to periodic governance votes on burning)
    • Eg. if PYTH allocation > 65% and runway guardrail is met → burn excess PYTH down to 55%.]
    • This will be subject to a regular governance vote (e.g., monthly or quarterly).

Runway Guardrail (Safety First)

Burns (fixed split or excess) may only be executed if the projected post-burn USDC Runway is ≥ 12 months.

How Runway is Calculated (objective & transparent):

Runway (months) = Total Liquid Stables in DAO Treasury Ă· Average Monthly Operating Expenses

  • Liquid Stables: USDC + USDT (face value). Exclude PYTH and volatile assets.
  • Average Monthly Operating Expenses: Rolling 3–6 month average of actual outflows (grants, incentives, council operations, infrastructure, legal, audits, etc.), as reported in prior Treasury Reports.
  • The Pythian Council will publish the exact runway figure, raw numbers, and a verification link (Dune dashboard or Google Sheet) in every monthly Treasury Report.

Why 12 months?

  • Provides a strong safety buffer in case enterprise revenue becomes temporarily lumpy or delayed.
  • Allows the DAO to continue funding grants, publisher incentives, staker rewards, and operational needs without pressure.
  • Aligns with common DAO best practices (12–18 months is typical for sustainable treasuries).
  • Protects the core purpose of the Reserve: long-term alignment and protocol support.
  • If expenses grow significantly in the future, the runway number will naturally tighten and pause burns automatically — no extra governance needed.

Additional Guardrails:

  • Never burn PYTH that is already earmarked/allocated for specific programs (grants, incentives, etc.).
  • 6-month formal review clause (governance can adjust split, bands, or runway threshold).
  • Full transparency: Monthly reports must include “Bought / Burned / Held / Runway” breakdown.

Benefits

  • Token holders: Steady monthly burns + occasional larger burns create meaningful deflation tied to enterprise adoption (SEDA-style flywheel).
  • DAO & Community: Reserve continues to grow (55% hold rate + most direct PYTH inflows), preserving strong alignment and resources for grants/incentives.
  • Existing users: Zero impact — burns happen only at treasury level after revenue arrives.
  • Governance: Minimal overhead thanks to wide bands and clear rules.

Open Questions for Community Discussion

  1. Fixed split: 45/55 (as proposed), 50/50, or 40/60?
  2. Target ratio / upper band comfortable?
  3. Runway threshold: 12 months ideal, or prefer 15 / 18?
  4. Excess Burn governance vote period?
  5. Ready for 6-month pilot?

This proposal turns Pyth’s enterprise success into sustainable token scarcity while keeping the Reserve’s core mission intact. Looking forward to feedback before formalizing as an OP-PIP.

From SCP with Love,
Community Council

5 Likes
Complementary Proposal to Pyth Reserve Evolution: Onchain Burn for Pyth Entropy Protocol Fees
2

Hi there legend :rightwards_hand:t4::leftwards_hand:t4:

Epic work as allways. I ll be short and str8

Fixed split: 45/55 (as proposed), 50/50, or 40/60?

  1. I think 55 or 60 not playing a major role so either of those.
  2. 50 50 just sounds boring :grinning_face:

12 months runway Threshold

7d vote period

Ready for 6-month pilot?

:100::fire:

3

The runway guardrail is the part that makes this proposal credible. A lot of burn mechanics in crypto skip the safety valve entirely — this one actually builds in an automatic pause if runway drops below 12 months, which means burns are tied to real financial health, not just token price optimism.

On the 45/55 split question — 45% burn feels aggressive for an early-stage reserve. The 40/60 option might be worth piloting first, with a governance option to move to 45/55 after the 6-month review if runway stays healthy. Starting conservative and burning more later is easier to defend than reversing an aggressive burn rate if revenue gets lumpy.

One thing worth clarifying: how are “Average Monthly Operating Expenses” handled during periods when Douro remits in PYTH instead of USDC? If the runway calculation only counts liquid stables, a PYTH-heavy remittance month could artificially tighten the runway number and pause burns even when the protocol is healthy.