# Pyth Reserve v2: Ratio-Based Treasury Management

**URL:** <https://forum.pyth.network/t/pyth-reserve-v2-ratio-based-treasury-management/2533>\
**Category:** Ideas Bank\
**Created:** [May 13, 2026, 12:33pm UTC](https://forum.pyth.network/t/pyth-reserve-v2-ratio-based-treasury-management/2533 "2026-05-13T12:33:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**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:** [May 13, 2026, 12:33pm UTC](https://forum.pyth.network/t/pyth-reserve-v2-ratio-based-treasury-management/2533/1 "2026-05-13T12:33:16Z")

</div>

#### **Summary**

With CO-PIP-105 enabling Douro Labs to pay DAO revenue in PYTH tokens (instead of only USDC), the dynamics of the Pyth Reserve program change significantly. This post proposes evolving the current monthly purchase model into a ratio-based framework that adapts to how revenue arrives.

**Core idea:** Maintain a target PYTH:USDC ratio (e.g., 50/50) rather than automatically converting a fixed percentage of stables to PYTH each month. **The DAO never sells PYTH** ; rebalancing only happens by adjusting _purchases_, not sales.

#### Background

1. **Current Program (OP-PIP-87)**

The existing Pyth Reserve, established in December 2025, works as follows:

- Monthly, 1/3 of non-PYTH treasury is transferred to the Pythian Council Ops Multisig

- Council executes DCA purchases of PYTH via Squads (max 5% slippage, max $25K/tx)

- Purchased PYTH is returned to DAO Treasury

This made sense when all DAO revenue arrived in USDC. The DAO wanted to accumulate PYTH, so converting stables (or SOL or others) to PYTH was the path.

1. **What Changes with CO-PIP-105**

If CO-PIP-105 passes, Douro Labs can pay Pyth Pro, LaaS, and Marketplace revenue in:

- USDC

- PYTH tokens

- A combination

If Douro pays mostly or entirely in PYTH, the DAO receives PYTH directly. The original rationale for purchases (convert stables → PYTH) becomes less relevant. The treasury could accumulate $2M–$10M in PYTH monthly without any purchases.

This raises questions:

- Should the DAO still buy PYTH when it’s already receiving PYTH directly?

- Should it preserve stables for runway/stability instead?

- How do we decide when to buy vs. hold?

1. **Industry Research: How Other Protocols Handle This**

Before proposing a new framework, I researched buyback and treasury programs across DeFi:

**Fixed Percentage of Revenue**

| Protocol | Allocation | Mechanism |
| --- | --- | --- |
| Jupiter | 50% of fees → “Litterbox Trust” | Accumulated to reserve, community decides on burn/use |
| Maple Finance | 25% of revenue → SYRUP buybacks | Replaced inflationary rewards (MIP-019) |
| Lighter | 50% of trading fees → LIT buybacks | Daily 24-hour TWAPs for stability |
| Fluid | 100% of mainnet revenue (first month) | Adjustable by governance |

**Price Threshold Trigger**

| Protocol | Trigger | Mechanism |
| --- | --- | --- |
| EtherFi | Only when ETHFI \< $3 | $50M authorized, but only executes when “undervalued” |
| Hyperliquid | Board discretion | $30M authorized over 12 months, triggered when management believes price doesn’t reflect value |

**Aggressive / Full Allocation**

| Protocol | Approach |
| --- | --- |
| Sky (MakerDAO) | $1M USDS per day buyback rate via “Smart Burn Engine” |
| Pump.fun | 100% of daily revenue → PUMP buybacks |

**Utility-Driven (Non-Revenue Based)**

| Protocol | Approach |
| --- | --- |
| Helium | Burn-and-mint economics tied to network usage, not revenue |

1. **Key Takeaways**

- Most protocols use a fixed % of revenue (25–50%), not fixed amounts

- Price thresholds can prevent buying at unfavorable prices

- Reserves vs. burns — Jupiter’s Litterbox holds tokens for future decisions rather than immediate burns

- Flexibility matters — Fluid’s model lets governance adjust allocation over time

1. **Real-World Context: April 2026 Distribution**

On May 4th, 2026, Douro Labs made its [first PYTH-denominated distribution](https://forum.pyth.network/t/pyth-pro-douro-labs-report-april-2026/2508) under CO-PIP-104:

The DAO just received ~5M PYTH directly ; no purchases needed. Under the current OP-PIP-87 framework, the Council would still be obligated to convert 1/3 of stables to PYTH each month. But if revenue keeps arriving in PYTH, that logic breaks down:

- **Why buy PYTH when you’re already receiving PYTH?**

- **Why deplete stables when they provide runway?**

This distribution validates the need for a ratio-based approach that adapts to how revenue actually arrives.

#### Proposed Framework: Ratio-Based Treasury Management

**Core Principles**

1. Maximize PYTH accumulation — primary goal remains unchanged

2. Maintain stability buffer — keep USDC runway for operations, grants, contingencies

3. Never sell PYTH — DAO can distribute PYTH (councils, contributors) but never sells on open market

4. Adapt to revenue composition — if PYTH arrives directly, don’t force additional purchases

**Target Ratio**

**`50% PYTH : 50% USDC`**

This ensures:

- Continued PYTH accumulation

- Meaningful stablecoin buffer

- Clear decision rule for when to act

Alternative ratios to consider:

- 2:1 (66% PYTH / 33% USDC) — more aggressive

- 3:1 (75% PYTH / 25% USDC) — leanest runway

**Asset Classification**

| Asset | Treatment |
| --- | --- |
| USDC / USDT | Hold as stables (target: 50%) |
| PYTH | Hold permanently (target: 50%) |
| SOL / other volatile | Convert to USDC or PYTH (whatever is need to target/achieve the 50/50 ratio) |

**Asset Valuation**

| Asset Type | Pricing Method |
| --- | --- |
| USDC, USDT | Face value (1:1 USD) |
| PYTH | 30-day TWAP (Pyth Lazer PYTH/USD feed) |
| SOL | 30-day TWAP (Pyth Lazer SOL/USD feed) |
| Other volatile tokens | 30-day TWAP (respective Pyth Lazer feed) |

This aligns with CO-PIP-105’s pricing methodology and avoids spot price fluctuations.

**Decision Logic**

On the 5th of each month:

1. Value all treasury assets (using 30-day TWAP for volatile, face value for stables)

2. Step 1: Calculate ratio

3. Step 2: Rebalance to maintain minimum 50% PYTH

**Monthly Cycle**

| Date | Action |
| --- | --- |
| 1st–5th | Douro completes monthly distributions |
| 5th | Pythian Council calculates treasury ratio |
| 5th–7th | Council determines if purchase needed, drafts OP-PIP if yes |
| 7th–14th | OP-PIP vote (if purchases proposed) |
| 15th onwards | Council executes approved purchases |

**Reporting**

Pythian Council produces a monthly Treasury Report including:

1. Holdings Snapshot

2. Ratio Calculation

3. Douro Distribution Breakdown

4. Recommendation

**Example Scenarios**

1. **Scenario A: USDC-Heavy Treasury**

- Current USDC balance: $8M

- Current (dollarized) PYTH balance: $2M

- Ratio: 80% USDC / 20% PYTH

- Target: 50% USDC / 50% PYTH = $5M each

**→ Action: Purchase $3M worth of PYTH to reach target. At PYTH = $0.05, that’s 60,000,000 PYTH.**

1. **Scenario B: PYTH-Heavy Treasury**

- Current USDC balance: $2M

- Current PYTH balance: $8M

- Ratio: 20% USDC / 80% PYTH

**→ Action: No purchase. USDC below target. Hold stables.**

1. **Scenario C: Balanced Treasury**

- Current USDC balance: $5M

- Current PYTH balance: $5M

- Ratio: 50% USDC / 50% PYTH

**→ Action: At target. Maintain current allocation.**

#### Open Questions for Discussion

1. Is 50/50 the right ratio? Or should we target 2:1 (66/33) for more PYTH accumulation?

2. Should there be a floor for stables? e.g., “Never let USDC drop below $500K regardless of ratio”

3. What about price-based triggers? Like EtherFi’s “only buy below $X” — should Pyth consider this?

4. Sunset clause? Should this framework be reviewed after 6–12 months?

#### Next Steps

1. Gather community feedback on this framework

2. Refine ratio target and parameters based on discussion

3. Draft formal OP-PIP to amend/replace OP-PIP-87

---

<div class="post-metadata">

**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:** [May 13, 2026, 4:57pm UTC](https://forum.pyth.network/t/pyth-reserve-v2-ratio-based-treasury-management/2533/2 "2026-05-13T16:57:33Z")

</div>

60.40?

I would go for no buy if above that % and the vote timeframe for purchase schould be short

---

<div class="post-metadata">

**Author:** ![lowkeigh](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lowkeigh](https://forum.pyth.network/u/lowkeigh)\
**Post date:** [May 21, 2026, 8:20pm UTC](https://forum.pyth.network/t/pyth-reserve-v2-ratio-based-treasury-management/2533/3 "2026-05-21T20:20:57Z")

</div>

Great proposal Marc, I’d like to extend it with a burn mechanism for excess PYTH above the target ratio. I know burns weren’t part of your original framework, but I think the time has now come to start giving this genuine consideration

**The extension:** rather than letting PYTH accumulate indefinitely above the target, excess PYTH above a defined band gets burned. This proposal allows for permanent supply reduction and an emission-free show of commitment to Pyth the token, while the band structure and USDC floor preserve DAO flexibility for funding requirements..

**Proposed structure:** target 50/50, with a 50–65% PYTH band. Once the ratio hits 65%, burn the excess back to 50%. The band is deliberately wide. This produces fewer, larger burns rather than continuous micro-rebalancing. Benefits: Meaningfully lower governance overhead if each burn requires an OP-PIP vote, it is also more marketable to post about larger burns rather than constant micro burns.

**One important guard:** burns should only execute if USDC holdings remain above 12 months of operational runway, as calculated by the Pythian Council in the monthly treasury reports already proposed in your framework. Realistically the treasury will sit comfortably above this given current revenue, but it ensures burns can never deplete operational capacity in tail scenarios. Supply reduction shouldn’t come at the cost of runway.

**On reviews:** I’d suggest a 6-month review built into the framework. The case for flexibility is strongest with burns specifically. Burned tokens can’t be unburned, so if a better mechanism emerges or market context shifts, we want to be able to adjust without past decisions locking us in.

---

<div class="post-metadata">

**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:** [May 22, 2026, 12:12am UTC](https://forum.pyth.network/t/pyth-reserve-v2-ratio-based-treasury-management/2533/4 "2026-05-22T00:12:39Z")

</div>

Personally, I think a more aggressive approach targeting a 66% $PYTH allocation would be better

A strict stablecoin floor might not be that critical since stables already make up a significant portion of the treasury anyway. Everything depends on market conditions and specific circumstances, so it would definitely make sense to review that in 6 months, or even trigger an earlier review in the extreme market volatility, rather than just relying on a fixed timeframe

I also really like how EtherFi handles it. In my opinion, it provides strong psychological support, as well as a solid price floor for the token