# Implement Fees on Pyth Core Across Networks #2 **URL:** \ **Category:** Ideas Bank\ **Created:** [April 25, 2025, 12:59pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks-2/2114 "2025-04-25T12:59:44Z")\ **Posts on this page:** 1\ **Showing post:** 17
**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 5, 2025, 8:42am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks-2/2114/17 "2025-05-05T08:42:49Z")
> [@scp](#): > > A subscription model might not be perfect, but it offers predictable pricing — which could be more attractive for many protocols. Long-term partnerships could even benefit from volume-based discounts or premium tiers. We can also have different subscription tiers, for example: a basic tier for pyth core, a mid-tier for 200ms pyth laser, a top-tier for 1ms pyth laser. 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. > [@scp](#): > > Additionally, I’m curious why the fees are denominated in their native token ($RON) instead of USD 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. > [@scp](#): > > Nobody can say for sure whether the current “optimal” fee reflects real value or just temporary market conditions. A different “optimal” fee could emerge two months from now. 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. > [@TRiLeZ](#): > > I want to suggest grandfathering existing customers into any new pricing models. Existing customers will appreciate a greater horizon of fee stability to plan and budget accordingly. 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. > [@TRiLeZ](#): > > Together with the grandfathering mechanism, this could allow pre-customers with plans of integration enough time to lock in the current rates, considering that they’ve done planning and budgeting with the current pricing structure in mind. 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. --- _[View the full topic](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks-2/2114)._