Pyth Reserve v2: Ratio-Based Treasury Management

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

Price Threshold Trigger

Aggressive / Full Allocation

Utility-Driven (Non-Revenue Based)

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 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 Valuation

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)

   • PYTH value

   • USDC/USDT value

   • SOL/other volatile value

2. Step 1: Calculate ratio

   • PYTH % = PYTH value / Total value

   • USDC % = USDC value / Total value

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

   IF PYTH % < 50%: → Convert volatile (SOL/other) to PYTH → Convert excess USDC to PYTH → Target: restore 50% PYTH

   IF PYTH % ≥ 50%: → Convert volatile (SOL/other) to USDC → No PYTH purchases needed → Hold stables

Monthly Cycle

Reporting

Pythian Council produces a monthly Treasury Report including:

1. Holdings Snapshot

   1. PYTH balance and USD value

   2. USDC balance

   3. Other assets (if any)

2. Ratio Calculation

   1. Current PYTH:USDC ratio

   2. Deviation from 50/50 target

3. Douro Distribution Breakdown

   1. Amount received in PYTH

   2. Amount received in USDC

   3. Products contributing (Pro, LaaS, Marketplace)

4. Recommendation

   1. Purchase (with amount) or Hold

   2. Rationale

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