This is a thoughtful suggestion. That said, the current design of Pyth Core doesn’t support such a model easily — implementing it would likely require significant changes to the protocol architecture. Still, it’s a promising direction for the future.
In the meantime, I believe it’s important to start raising fees incrementally. This not only reflects the value of the service but also helps establish a reference point for any future subscription-based pricing models.
This is currently how fees are structured across all supported chains. I agree that USD-denominated pricing would offer a clearer cost reference, and it’s something that could become more feasible with a future shift to a subscription model.
Completely agree — “perfect” pricing is a moving target, and trying to optimize for every user on every chain isn’t realistic, especially under the current design of Pyth Core.
That said, introducing a reasonable baseline — somewhere in the range of $0.005 to $0.02 — provides a useful starting point. It helps us gather real-world data, which will be critical for refining future pricing strategies.
This suggestion makes sense in principle, but the challenge lies in execution. Implementing grandfathering would introduce considerable operational complexity, especially since only the DAO can approve and enforce such onchain exceptions.
I don’t think locking in current rates is a viable option — the existing Pyth fees are effectively zero, and maintaining that would mean foregoing any meaningful revenue.
While I understand the need for cost predictability, a one-time increase in fees is generally manageable. For instance, if fees go up 5x, a user could simply reduce the frequency of updates (e.g., from every 1s to every 5s) to stay within budget.