Implement Fees on Pyth Core Across Networks

[Pepito]

Background

In 2024, the Pyth DAO made a significant move by implementing oracle fees on opBNB 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 and internal data. Shown below are the monthly averages of price updates per chains.

Key Metrics Across EVM Networks

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.

[abwrld]

This is a positive proposal for the growth of the Pyth Network in 2025, and the community should support with full force.

[Derrp]

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?

[PilotSB]

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”

[lowkeigh]

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.

[ed_pyth]

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.)

[arguer]

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.

[Pepito]

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

[Pepito]

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.

[bats4]

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

[kenxyz]

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.

[Pepito]

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.

[meter]

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.

[SOLAR]

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.

[Pepito]

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.

[Pepito]

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.

[SOLAR]

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.

[architehc]

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.

2. 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.

3. 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.

4. 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.

5. 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

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

   • Anyone (protocol, user, keeper) that wants an on-chain price refresh pays a fee.
   • This aligns actual usage with payment, minimizing waste and high overhead typical of push-based models.
   • Encourages protocols to only update when data is needed, keeping on-chain congestion and costs manageable.

2. Fee Structure & Adjustments

   • Chain-Specific Pricing: Different blockchains have unique cost structures. Fees will be set proportionally, ensuring total (gas + oracle fee) remains competitive.
   • Volume-Based Discounts: High-frequency updaters can stake PYTH or prepay for credits to receive discounts, preventing runaway costs for power users.
   • Sponsored Feeds: The DAO or external sponsors can subsidize specific feeds. This shields smaller dApps from costs and supports critical assets.
   • Technical Considerations: Batched transactions can bundle multiple feeds in one update call, lowering overall gas and fees.

3. Impact on PYTH Tokenomics

1. Boosting PYTH Token Demand

   • If oracle fees are denominated in the chain’s native currency, proceeds can be swapped for PYTH, then distributed or burned—directly increasing buy pressure.
   • Alternatively, dApps can pay in PYTH itself for a discount, increasing demand as usage scales.

2. Fee Distribution Mechanisms

   • Staking Rewards: A portion of fees can flow to Oracle Integrity Staking, increasing APY for stakers and publishers. This attracts more tokens into staking, reducing circulating supply.
   • Buy & Burn: The DAO can vote to use part of the revenue to buy PYTH and burn it, creating a deflationary effect.
   • Treasury & Ecosystem Growth: The DAO might allocate remaining fees to development grants, data publisher incentives, and ecosystem partnerships.

3. Long-Term Sustainability

   • Over time, as more dApps integrate Pyth, fee-based revenue grows.
   • This supports ongoing publisher rewards, reducing reliance on pure token emissions.
   • Result: a self-funding network where usage growth drives token value and security.

4. Countermeasures for Community Concerns

1. Excessive Fees & Gas Costs

   • Limit Oracle Fee to a small fraction of typical gas costs on each chain.
   • Dynamic Fee Adjustments if gas spikes to avoid “double punishment.”
   • Volume Breakpoints ensuring heavy updaters pay proportionally less.

2. Incentive Alignment

   • Hybrid approach for sponsored feeds: heavy usage is partially subsidized, so user-driven updates don’t always incur full costs.
   • OIS, rebates, and multi-feed discounting all help ensure updates remain affordable.

3. Preventing Forks of Contracts

   • The open-source nature of Pyth can be a double-edged sword.
   • If forks emerge that bypass fee mechanisms, Pyth can deploy contract upgrades that break compatibility with unauthorized forks.

5. Adoption Strategy: New vs. Established Chains

1. Emerging High-Growth Ecosystems

   • Offer very low or even zero fees initially, co-funded by the DAO or data publishers.
   • Attract dApps early, capture market share, then gradually introduce standard fees once the ecosystem matures.

2. Established Networks (Ethereum, BNB, Polygon, etc.)

   • Implement fees that reflect the chain’s transaction profile.
   • Position Pyth as a faster, more cost-effective solution than incumbents (Chainlink), focusing on advanced features like low-latency updates.
   • Provide flexible volume discounts to keep large DeFi players onboard.

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

   • Introduce fees on select EVM chains (e.g., Avalanche, Aurora, Cronos) with conservative rates.
   • Collect data on usage changes, gather community feedback.

2. Phase 2: Gradual Rollout & Governance Refinements

   • Extend fee model to more chains, adjusting rates based on usage insights.
   • Enable advanced features: volume-based discounts, partial or full subsidy for critical feeds.

3. Phase 3: Full Exploitation & Self-Sustainability

   • Solidify the fee structure network-wide, funnel meaningful revenue into staking rewards, publisher compensation, and treasury.
   • Monitor and refine as needed to remain competitive, using governance votes for adjustments.

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.

[SOLAR]

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.

[arguer]

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?