# Implement Fees on Pyth Core Across Networks **URL:** \ **Category:** Ideas Bank\ **Created:** [January 21, 2025, 10:48am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899 "2025-01-21T10:48:59Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Pepito](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/pepito/32/471_2.png) [@Pepito](https://forum.pyth.network/u/Pepito)\ **Post date:** [January 21, 2025, 10:48am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/1 "2025-01-21T10:48:59Z")
## Background In 2024, the Pyth DAO made a significant move by [implementing oracle fees on opBNB](https://forum.pyth.network/t/closed-deploy-pyth-s-pull-oracle-to-opbnb/191) at 0.000186 BNB ($0.13 at current prices). This initiative, spearheaded by KiloEx, marked the first instance of Pyth charging for oracle usage. Despite initial concerns about the cost, adoption has been encouraging: - Approximately 45,000 transactions have been processed (primarily from APX and MYX) - Generated revenue: 8.5 BNB (approximately $6,000) for the Pyth DAO ## Proposal Overview Building on this successful experiment, I propose that the Pyth DAO begin implementing fees for Pyth Core Price Feeds across its ~100 deployed blockchains. This implementation should be gradual and carefully managed to minimize any potential impact on adoption and builder activity. ### Strategic Benefits Implementing fees enables Pyth’s economic model through: 1. Fee-based compensation for data publishers 2. Increased network attractiveness for new publishers, driving competition in uptime and data quality 3. Enhanced service quality through competitive data provision directly benefit Pyth data consumers To note, the DAO has not approved any rewards distribution mechanisms at this stage. ## Current Network Usage Analysis _Data as of January 17th, 2025, sourced from [Dune Dashboard](https://dune.com/synthquest/pyth) and internal data. Shown below are the monthly averages of price updates per chains._ ### Key Metrics Across EVM Networks ![Chart from Google Docs](https://us1.discourse-cdn.com/flex001/uploads/pyth_dao/original/1X/5f7c9e1e99702734bca04aefbb3e6c893cdc71f3.png) Background | Chains | Average Monthly Updates | Pyth TVS (M of $) | Number of dApps using Pyth | | --- | --- | --- | --- | | Apechain | 71,108 | $0.1M | 1 | | Arbitrum | 434,049 | $52M | 48 | | Aurora | 37,850 | $1M | 1 | | Avalanche | 157,019 | $0.7M | 4 | | Base | 224,978 | $70M | 29 | | Blast | 135,258 | $11M | 8 | | Boba | 1,894 | $0.2M | 2 | | BNB Chain | 30,342 | $65M | 22 | | Celo | 3,123 | $0.2M | 3 | | Conflux | 13,583 | $0.1M | 2 | | CoreDAO | 699,431 | $125M | 4 | | Cronos | 57,093 | $11M | 1 | | EOS | 3,574 | $0M | 0 | | Ethereum | 4,629 | $450M | 26 | | Etherlink | 180,675 | $0.4M | 1 | | EVMOS | 219,482 | $0.1M | 2 | | Flow | 3,943 | $1M | 1 | | Gnosis | 873,845 | $0.1M | 2 | | Gravity | 165,005 | $0M | 0 | | Hedera | 4,279 | $0M | 0 | | Horizen | 3,798 | $0.3M | 1 | | Kava | 51,566 | $40M | 3 | | KCC | 7,216 | $0.1M | 1 | | Lightlink | 1,450,838 | $0.1M | 1 | | Linea | 16,977 | $27M | 11 | | Manta | 4,021 | $14M | 5 | | Mantle | 128,296 | $22M | 9 | | Meter | 121,870 | $0.6M | 2 | | Mode | 22,224 | $85M | 6 | | Neon EVM | 1,739 | $0.1M | 2 | | Optimism | 68,282 | $160M | 16 | | Polygon | 9,579 | $1M | 16 | | Ronin | 804,534 | $1M | 1 | | Scroll | 2,352 | $2M | 6 | | Sei | 343,252 | $0.1M | 1 | | Shimmer | 571,884 | $0.1M | 1 | | Taiko | 2,890 | $88M | 5 | | Zetachain | 299,807 | $0M | 0 | | zkSync | 122,876 | $35M | 16 | ## Implementation Strategy ### Selection Criteria The optimal fee implementation strategy should consider: 1. **Market Competition** : Chains with limited oracle alternatives present better opportunities for initial fee implementation 2. **Economic Activity** : Prioritize chains with lower TVL and derivatives volume 3. **Usage Patterns** : Consider the distribution of updates across protocols ### Target Networks Based on these criteria, we propose to start implementing fees on on the blockchains below: - Aurora - Avalanche - Conflux - Cronos - Meter - Ronin - Sei - Shimmer ### Fee Structure Considerations Three key factors influence fee determination: 1. **Per-Feed Application** : Fees apply to each price feed across the entire chain 2. **Update Frequency** : Charges occur per price feed update 3. **Transaction Costs** : Keep oracle fees as a reasonable percentage of total transaction costs, while recognizing that some chains have artificially low gas fees that don’t reflect true value ## Proposed Fee Structure ### Aurora In 2024, there was on average 37,000 price updated every month ; and there’s about $1M in TVS by Pyth. Checking onchain activity, a single (1) address is triggering price updates for 7 feeds on Aurora (0xf9D72FED253bF10924cb501f254eFf112B6Fa203). Transactions cost about 0.00002328641 ETH or $0.08 thus the current monthly cost to do 5,285 transactions (updating 37,000 price updates) is about $425. —\> Target a $0.01 in update fees per feed for the Aurora deployment —\> Set the update fee to 0.000003 ETH per feed At current usage, this would bring $370 per month to the Pyth DAO ### Avalanche In 2024, there was on average 150,000 price updated every month ; and there’s about $1M in TVS by Pyth. Checking onchain activity, two (2) recurrent users were found to update price feeds on Avalanche (0x7b51Dd3B546A9e4a2a894620eCa083af252C52Db and 0x66690f1D92B1F7E629EcE0ad238E3ecE82283725), with their respective transactions costing in between $0.01 and $0.05 to update 1 to 2 prices together. —\> Target a $0.01 in update fees per feed for the Avalanche deployment —\> Set the update fee to 0.00025 AVAX per feed At current usage, this would bring $1,500 per month to the Pyth DAO ### Conflux In 2024, there was on average 14,000 price updated every month ; and there’s about $0.1M in TVS by Pyth. Checking onchain activity, a single (1) address is triggering price updates for 6 feeds on Conflux (0xE2B01f896873B3D8971311A970b5E41a1CD74743). Transactions cost about 0.0089031 CFX or $0.0015 thus the current monthly cost to do 2,333 transactions (updating 14,000 price updates) is about $3. —\> Target a $0.015 in update fees per feed for the Conflux deployment —\> Set the update fee to 0.1 CFX per feed At current usage, this would bring $210 per month to the Pyth DAO ### Cronos In 2024, there was on average 57,000 price updated every month ; and there’s about $10M in TVS by Pyth. Checking onchain activity, a single (1) address is triggering price updates for 21 feeds on Cronos (0xf1111aD835eb6e66c7e6FC252486e03c792B0FDE). Transactions cost about 3\*\*.\*\*4524426 CRO or $0.50 thus the current monthly cost to do 2,714 transactions (updating 57,000 price updates) is about $1,350. —\> Target a $0.01 in update fees per feeds —\> Set the update fee to 0.06 CRO per feed At current usage, this would bring $450 per month to the Pyth DAO ### Meter In 2024, there was on average 122,000 price updated every month ; and there’s about $0.6M in TVS by Pyth. Checking onchain activity, a single (1) address is triggering price updates for 6 feeds on Meter (0x77723e81D59EC4F20600A7d4CB0344ED271316af). Transactions cost about 0.0269214 MTR or $0.015 thus the current monthly cost to do 20,333 transactions (updating 122,000 price updates) is about $305. —\> Target a $0.01 in update fees per feed for the Meter deployment —\> Set the update fee to 0.02 MTR per feed At current usage, this would bring $1,200 per month to the Pyth DAO ### Ronin In 2024, there was on average 800,000 price updated every month ; and there’s about $1M in TVS by Pyth. Checking onchain activity, a single (1) address is triggering price updates for 4 feeds on Ronin (0xf4deb00ff7ee423381a4fe05b47dab82fd49c21d). Transactions cost about 0.004478 RON or $0.008 thus the current monthly cost to do 200,000 transactions (updating 800,000 price updates) is about $1,630. —\> Target a $0.01 in update fees per transaction for the Ronin deployment —\> Set the update fee to 0.001 RON per feed At current usage, this would bring $1,280 per month to the Pyth DAO ### Sei In 2024, there was on average 340,000 price updated every month ; and there’s about $0.1M in TVS by Pyth. Checking onchain activity, a single (1) address is triggering price updates for 6 feeds on Sei EVM (0x70F67735D4b4D9FcFb3014da2470e2f82a8744c7). Transactions cost about 0.00035367281935161 SEI or $0.00015 thus the current monthly cost to do 56,000 transactions (updating 340,000 price updates) is about $10. —\> Target a $0.005 in update fees per feed for the Sei deployment —\> Set the update fee to 0.01 SEI per feed At current usage, this would bring $1,200 per month to the Pyth DAO ### Shimmer In 2024, there was on average 570,000 price updated every month ; and there’s about $0.1M in TVS by Pyth. Checking onchain activity, a single (1) address is triggering price updates for 9 feeds on Shimmer (0x669a1dA59bF2216Ec31D2432c6B467788961A8Ce). Transactions cost about 0.282432 SMR or $0.00035346082368 thus the current monthly cost to do 63,333 transactions (updating 570,000 price updates) is about $25. —\> Target a $0.01 in update fees per transaction for the Shimmer deployment —\> Set the update fee to 1 SMR per feed At current usage, this would bring $570 per month to the Pyth DAO ### Summary of Proposed Fees | Blockchain | Oracle Update Fee | Denomination | Cost in $ per feed | Monthly Average # of price updates | Expected DAO Revenue ($) | | --- | --- | --- | --- | --- | --- | | Aurora | 0.000003 | ETH | $0.01 | 37,000 | $370 | | Avalanche | 0.00025 | AVAX | $0.01 | 150,000 | $1,500 | | Conflux | 0.1 | CFX | $0.015 | 14,000 | $210 | | Cronos | 0.06 | CRO | $0.008 | 57,000 | $445 | | Meter | 0.02 | MTR | $0.01 | 122,000 | $1,220 | | Ronin | 0.001 | RON | $0.0016 | 800,000 | $1,280 | | Sei | 0.01 | SEI | $0.0035 | 340,000 | $1,190 | | Shimmer | 1 | SMR | $0.001 | 570,000 | $570 | ## Expected Outcomes - Projected monthly revenue: ~$6,870 - Future opportunities for fee adjustments based on market response - Foundation for sustainable oracle economics ## Next Steps This proposal focuses exclusively on fee implementation strategy. The allocation and usage of generated fees will require separate discussion and governance decisions. ## Community Feedback We welcome input from all stakeholders: - Publishers - Oracle users - Committed Pythians Your insights will be valuable in refining this proposal and guiding the DAO’s decision-making process. ---
**Author:** ![abwrld](https://avatars.discourse-cdn.com/v4/letter/a/9d8465/32.png) [@abwrld](https://forum.pyth.network/u/abwrld)\ **Post date:** [January 21, 2025, 1:20pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/2 "2025-01-21T13:20:15Z")
This is a positive proposal for the growth of the Pyth Network in 2025, and the community should support with full force. ---
**Author:** ![Derrp](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/derrp/32/670_2.png) [@Derrp](https://forum.pyth.network/u/Derrp)\ **Post date:** [January 21, 2025, 2:00pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/3 "2025-01-21T14:00:52Z")
Reading through, this is a modest increase. In most cases: still less than the transaction fees inherent in retrieving the price feeds themselves. I think there may be a small error on the SMR Expected DAO revenue by a factor of 10? Should be $570? ---
**Author:** ![PilotSB](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/pilotsb/32/484_2.png) [@PilotSB](https://forum.pyth.network/u/PilotSB)\ **Post date:** [January 21, 2025, 8:12pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/4 "2025-01-21T20:12:05Z")
first of all i saw i post from pepito on x and than i read the propasal carefully, i got impress by the detail breakdown. i had an insight at areas of User Experience (UX). “Avoid volatile fee structures that could deter developers. Consider gas-sponsored transactions or upfront pricing” ---
**Author:** ![lowkeigh](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lowkeigh](https://forum.pyth.network/u/lowkeigh)\ **Post date:** [January 22, 2025, 9:10am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/5 "2025-01-22T09:10:07Z")
It has to happen at some point, I think this is a good way to dip toes in the water. I do think it is important to do this in such a way that it won’t be a deterrent for builders on these chains. Also a good point about firstly targeting chains with limited alternatives too. All for this idea, I do think it will be very important to be receptive to any feedback from the chains themselves. ---
**Author:** ![ed\_pyth](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/ed_pyth/32/12_2.png) [@ed\_pyth](https://forum.pyth.network/u/ed_pyth)\ **Post date:** [January 22, 2025, 3:44pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/6 "2025-01-22T15:44:42Z")
A thorough and comprehensive layout of prospective chains for significant fee changes. Love to see it Perhaps worth modelling, or testing for after implementation, is changes in price updates “demand” in response to the fee changes. Worth discussing now in parallel could include what should happen to generated fees. (Currently, all generated fees just sit on-chain.) ---
**Author:** ![arguer](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/arguer/32/39_2.png) [@arguer](https://forum.pyth.network/u/arguer)\ **Post date:** [January 23, 2025, 7:53am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/7 "2025-01-23T07:53:12Z")
Thanks for the comprehensive proposal @Pepito! It sounds like one of the key objectives is to assess market response. So, to build on @ed_pyth’s point on modelling/testing and comparing “demand” post implementation, I believe it is also important to consider the types of applications that will be affected, and factor that into the evaluation process. Specifically, I am referring to whether the apps pay price update fees themselves or pass them on to their end users. _(Side note: It would also be nice to get a rough idea of the proportions of each approach - app pays vs end user pays - across all the Pyth-powered apps.)_ In my opinion, apps that pass the fees on to the end users will probably be less concerned/affected by any changes to the price update fees - which is an important consideration since **it is ultimately the apps that choose to use Pyth** , not the end users. ---
**Author:** ![Pepito](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/pepito/32/471_2.png) [@Pepito](https://forum.pyth.network/u/Pepito)\ **Post date:** [January 23, 2025, 10:08am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/8 "2025-01-23T10:08:39Z")
This will definitely need some post implementation analysis to judge how the fee implementation and its amount impacts apps and downstream users. Goal is to find the fee amount that best gauge the value of Pyth on each of these chains ---
**Author:** ![Pepito](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/pepito/32/471_2.png) [@Pepito](https://forum.pyth.network/u/Pepito)\ **Post date:** [January 23, 2025, 10:15am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/9 "2025-01-23T10:15:15Z")
Lots of great points here Arguer. Thank you for this! And I agree. We are in the early discussion steps of the fee switch and lots will be analyzed if it gets approval from the community and implemented on these blockchains. As for what apps decide to do about the fee (pay themselves or pass to downstream user), it will be an arbitrage on their end to make. Bottom line for us Pythians is to find to fee amount that best reflects the value of a Pyth price update that keeps app builders using Pyth and its superior product, regardless of the ‘added’ cost. ---
**Author:** ![bats4](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/bats4/32/7_2.png) [@bats4](https://forum.pyth.network/u/bats4)\ **Post date:** [January 27, 2025, 12:32pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/10 "2025-01-27T12:32:51Z")
I appreciate the very detailed proposal (specially the summary!). Update fee on the mentioned chains are around 10% or less from the update fee on opBNB, which i think is a great start of the fee implementation on multiple chains to minimize impact on adoption. > [@Pepito](#): > > In 2024, the Pyth DAO made a significant move by [implementing oracle fees on opBNB](https://forum.pyth.network/t/closed-deploy-pyth-s-pull-oracle-to-opbnb/191) at 0.000186 BNB ($0.13 at current prices) as mentioned by @ed_pyth , i also believe there will be a need for monitoring on the “demand” after changes of update fees. maybe also have a Dune/Flipside of every Pyth powered chain and the number of price updates so every Pythian can see the data for themselves. > [@ed\_pyth](#): > > Perhaps worth modelling, or testing for after implementation, is changes in price updates “demand” in response to the fee changes. A great start indeed and i think its time for update on those fees as Pyth are earning close to $0 from each Pyth price updates eversince! (except opBNB from around June) Notes for myself: opBNB price update fees generated approximately **$6,000 in about 6-7 months**. Expected outcome of current proposal is about **$7,000 in a month** with increasing update fees on **8 chains** with about **10% of fees on opBNB**. ---
**Author:** ![kenxyz](https://avatars.discourse-cdn.com/v4/letter/k/3bc359/32.png) [@kenxyz](https://forum.pyth.network/u/kenxyz)\ **Post date:** [January 31, 2025, 7:31pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/11 "2025-01-31T19:31:21Z")
Thank you very much for starting this valuable discussion. As a builder leveraging Pyth on Cronos: I agree that one of the responsibilities of the Pyth DAO is to make the Pyth protocol sustainable economically. However, I would like to challenge the logic of proposing an uneven playing field across dapps / chains. First, as Pyth uses a “pull” model, apps / chains are paying for their own infrastructure costs when it comes to retrieving prices and posting them on their respective chain. It’s not clear to me that some chains cost more than others to the DAO. Second, the “market competition” criteria basically means, if you are a chain who decided to go with Pyth as a preferred / recommended oracle protocol, your loyalty and commitment now become a liability. You are now incentivized to seek other oracle integrations in order to avoid future penalties from the DAO. There is a risk that this “first step” of discriminated pricing becomes the de facto end state, because it is the low hanging fruit. Wouldn’t it make more sense to introduce a standard pricing for all dapps / all chains uniformly, potentially at a lower level in order to test market reaction, and then increase the pricing if needed ? A market test focused on chains that have not encouraged alternative oracle options may not generate much insights into how the users of other chains will react. ---
**Author:** ![Pepito](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/pepito/32/471_2.png) [@Pepito](https://forum.pyth.network/u/Pepito)\ **Post date:** [February 3, 2025, 12:46pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/12 "2025-02-03T12:46:26Z")
hey @kenxyz Thanks a lot for the comment and feedback! Regarding the uneven playing field concern about some chains not seeing immediate fee increases - this status quo won’t stay for long. To put things in perspective for Cronos: with the suggested changes and assuming equal usage, monthly costs would increase by about 30% (from ~$1,400 to ~$1,900), keeping annual costs below $25,000. The proposal aims to implement fees across all chains, but for practical reasons, the community moves forward in batches (8-10 chains), building on our successful opBNB implementation. Importantly, the community can revert or adapt any changes if needed based on what we learn. This means the playing field remains even for all apps using Pyth on the same chain. As for chain-specific pricing: different pricing across chains actually makes the most sense. Here’s why: a typical transaction on Ethereum costs $10, while on Solana it’s $0.01. A $0.10 oracle fee would be just 1% extra cost for Ethereum users, but would increase Solana users’ costs by 10x (1000%). Therefore, to optimize Pyth’s offering on each chain, I personally think each chain needs tailored pricing. This pricing is reasonable considering Pyth supports about 700 price feeds on Cronos (and other chains) and remains the only oracle network providing economic security through Oracle Integrity Staking - regardless of which price feeds or chains you’re using. Bottom line: I don’t believe any oracle network offers as much value as Pyth while maintaining a lower price tag. ---
**Author:** ![meter](https://avatars.discourse-cdn.com/v4/letter/m/e9bcb4/32.png) [@meter](https://forum.pyth.network/u/meter)\ **Post date:** [February 4, 2025, 4:54pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/13 "2025-02-04T16:54:22Z")
I represent Meter in the discussion. There is a special situation for the Meter blockchain. There are two tokens on Meter. The gas is paid in a flatcoin called MTR (current price around $0.5). There is only around 400k MTR in circulation (they have to be created through SHA256 based PoW process). The price feeds are updated by the team. Since Meter blockchain has a gas reimbursement program, the gas fee simply cycles. There is no way to support $1200 worth of MTR payment to maintain the Pyth price feed without impact the price. There are also 4 other oracles on Meter. We chose Pyth because we could update the price more frequently. $100/month makes more sense from our perspective. ---
**Author:** ![SOLAR](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/solar/32/475_2.png) [@SOLAR](https://forum.pyth.network/u/SOLAR)\ **Post date:** [February 4, 2025, 11:21pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/14 "2025-02-04T23:21:28Z")
Pretty interesting metrics here for sure. Just wondering why SUI isn’t included here since I’ve been using some Dapps on SUI which are already using pyth price feeds. ---
**Author:** ![Pepito](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/pepito/32/471_2.png) [@Pepito](https://forum.pyth.network/u/Pepito)\ **Post date:** [February 5, 2025, 2:57pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/15 "2025-02-05T14:57:53Z")
hey @meter Thanks for providing more context on the Meter activity. Based on your input, I think we need to find a middle ground that balances both sides. A possible approach could be: - Reduce oracle fee to 0.01 MTR per feed (50% of original proposal) - Cut update frequency by 50% or more to lower total costs - This would bring monthly costs closer to your target range That said, consider Pyth’s unique value: - 800+ price feeds, all backed by Oracle Integrity Staking - Support for MTR/MTRG feeds despite low liquidity and trading volume - Cross-chain availability on 100+ networks While we aim for a workable solution, Pyth’s comprehensive offering and security features justify costs above $100/month. ---
**Author:** ![Pepito](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/pepito/32/471_2.png) [@Pepito](https://forum.pyth.network/u/Pepito)\ **Post date:** [February 5, 2025, 3:00pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/16 "2025-02-05T15:00:02Z")
hey @solar You’re right—some dApps on Sui rely on Pyth price feeds to function properly. The reasons why Sui wasn’t included in this first one: - Integrating fee changes on Sui isn’t as straightforward as on EVM chains, which we can handle in batches. - This first phase is designed to gather feedback and data following the fee increase. Given that Sui is one of the most active chains for Pyth, it makes sense to test the changes elsewhere first. That said, implementing fees on Sui (along with Aptos, Solana, and others) is likely to happen after community discussions on the forum. ---
**Author:** ![SOLAR](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/solar/32/475_2.png) [@SOLAR](https://forum.pyth.network/u/SOLAR)\ **Post date:** [February 5, 2025, 5:50pm UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/17 "2025-02-05T17:50:41Z")
Gotcha! So at the moment majority of revenue being made are coming from EVMs price feeds right? Been doing some research for a post Im about to share here soon and so far what’ve concluded is majority of revenue being made on pyth are coming from price feeds. With that said I think this topic is crucial for PYTH long term growth. ---
**Author:** ![architehc](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/architehc/32/412_2.png) [@architehc](https://forum.pyth.network/u/architehc)\ **Post date:** [February 10, 2025, 12:00am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/18 "2025-02-10T00:00:15Z")
## **Proposal TL;DR** 1. **Adopt a Pull-Based, Usage-Driven Billing Model** : - Users pay only when they request on-chain updates of Pyth price feeds. - Encourages cost-efficiency, scalability, and better price discovery. 1. **Introduce Dynamic, Chain-Specific Fees** : - Low or zero fees for new/strategic chains to promote adoption. - Adjust fees gradually on established chains to capture value without deterring users. - Consider volume-based discounts and partial fee waivers for sponsors. 1. **Tie Fees to PYTH Token Economics** : - Portion of collected fees is distributed to publishers and stakers. - Potential for burn mechanisms to reduce supply and boost PYTH value. - Increases PYTH token’s utility and drives further adoption of the network. 1. **Protect Network Growth While Generating Revenue** : - Start with modest fees and observe market reactions. - Actively refine price structure based on usage data and community feedback. 1. **Remain Competitive vs. Chainlink** : - Emphasize faster update speeds, richer data coverage, and pay-per-update flexibility. - Leverage Pyth’s advantage in cross-chain capabilities and first-party data. ## [Full research is available here](https://docs.google.com/document/d/1I8Z5GZR9TRXy18NyBhyF-GF36zAV2lUljwxDg77Fa3c/edit?usp=sharing) ## **Integrated Proposal: Pyth Network Billing Model & Tokenomics Alignment** ### **1. Rationale and Overview** The Pyth Network has experienced exponential growth, driven by its high-speed and first-party oracle data. To cement its long-term sustainability, Pyth should introduce **fees** for on-chain price feed usage. 1. **Leverage a pull-based billing model** with data consumers paying **only when** they request a new on-chain update. 2. **Integrate fees** into the existing tokenomics—using them to compensate publishers, stakers, and potentially reduce circulating supply through buybacks/burns. 3. **Address community concerns** , such as equitable pricing for large volume users, preventing excessive fees, and ensuring optional “free baseline” for strategic feeds or sponsored updates. 4. **Preserve network growth** by introducing gradual, chain-specific fees, focusing on new emerging chains versus established ones differently. ### **2. Billing Model Mechanics** 1. **Pull-Based Updates** 2. **Fee Structure & Adjustments** ### **3. Impact on PYTH Tokenomics** 1. **Boosting PYTH Token Demand** 2. **Fee Distribution Mechanisms** 3. **Long-Term Sustainability** ### **4. Countermeasures for Community Concerns** 1. **Excessive Fees & Gas Costs** 2. **Incentive Alignment** 3. **Preventing Forks of Contracts** ### **5. Adoption Strategy: New vs. Established Chains** 1. **Emerging High-Growth Ecosystems** 2. **Established Networks (Ethereum, BNB, Polygon, etc.)** ### **6. Comparisons & Competitiveness with Chainlink** 1. **Usage Model** : Chainlink primarily uses a push-based, sponsor-funded approach. Pyth’s pull-based, pay-per-use system can lower overhead for many use cases, enabling faster, more granular updates. 2. **Data Coverage** : Pyth delivers high-fidelity first-party data across numerous assets (including equities, commodities) that Chainlink often lacks. 3. **Cost & Scalability** : With volume discounts and optional fee token payments, Pyth can be more cost-competitive while keeping reliability and security on par or better. ### **7. Implementation Roadmap** 1. **Phase 1: Experimental & Pilot Programs** 2. **Phase 2: Gradual Rollout & Governance Refinements** 3. **Phase 3: Full Exploitation & Self-Sustainability** ### **8. Conclusion & Next Steps** This combined proposal strikes a balance between **monetization and ecosystem growth** , leveraging Pyth’s unique pull-based oracle design to ensure fees scale with usage. By integrating fee revenues into PYTH’s tokenomics—through staking rewards, potential buy-and-burn, and treasury allocations—the network gains a sustainable revenue stream that supports publishers, secures data integrity, and potentially boosts PYTH token value over time. **Next Steps** : - Approve the pilot fee introduction on target EVM chains. - Finalize details on distribution (percentages for staking, treasury, potential burns). - Launch governance discussion to refine discount tiers, sponsor programs, and chain-specific rollout schedules. Through this holistic approach, Pyth can outpace incumbent oracles while building a **self-sustaining, community-driven** oracle economy. ---
**Author:** ![SOLAR](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/solar/32/475_2.png) [@SOLAR](https://forum.pyth.network/u/SOLAR)\ **Post date:** [February 10, 2025, 1:17am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/19 "2025-02-10T01:17:34Z")
Great insights here for sure sir! Im trying to share a similar post about the same topic you mentioned here (just waiting to reach level 2 tho), despite your proposal being more complete. Only point Im mentioning more is about staking. ---
**Author:** ![arguer](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.pyth.network/arguer/32/39_2.png) [@arguer](https://forum.pyth.network/u/arguer)\ **Post date:** [February 10, 2025, 7:42am UTC](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899/20 "2025-02-10T07:42:56Z")
Could we have a TLDR of your TLDR? 😂 Your proposal is very comprehensive, and I believe a lot of what you mentioned already reflects the current realities and approaches. Perhaps you could zero in a little more directly on how you feel about the specifics of @Pepito’s original proposal (from the app builder perspective). For example, are the proposed fees reasonable? How would this affect an app builder who wants to integrate Pyth price feeds? I’m also curious - for Trebuchet, would the price update fees be passed on to the end user, or would it be borne by the application? [Next page](https://forum.pyth.network/t/implement-fees-on-pyth-core-across-networks/1899.md?page=2)