Hi Ugur — Thank you for your prompt response to our message. We appreciate and share your enthusiasm for a friendly competition and our shared desire to help the AAVE community choose the best oracle solution! We agree that healthy competition will allow us to better evaluate and select the most suitable solution for AAVE’s needs.
You point out that the configurations of the three oracles are different: Chainlink and API3 have different heartbeat-based push updates, while Pyth has a pull-based update model. That’s exactly the point we’re trying to convey in these graphs! We believe a pull-based model leads to a higher frequency and quality of consumable updates than the push-based model. You make the point that because these configurations are not the same, it’s unfair or impossible to do a comparison among the oracles, but to the contrary, the quantitative comparisons are illustrating the effects of choosing different configurations. We believe the pull-based configuration helps Pyth achieve higher-quality updates relative to the configurations of other oracles that depend on a centralized pusher to crank according to a heartbeat model that trades off between frequent updates/accurate tracking and financial sustainability (lower thresholds for updates —> more updates —> higher gas costs for push-based oracles).
With regard to your point about protocols running their own price service instance, this is not a requirement. As stated in our original post and our docs, the Pyth Data Association runs a production-level endpoint for anyone to query recent price updates to pull and consume on target chains. Thus, if Aave didn’t run a separate instance to start, they would be able to consume the updates available at the PDA’s price service instance just fine. As you quoted, we recommend protocols to run their own price service instances “for maximum reliability and decentralization” because decentralization is a desirable quality in Web3. While push-based oracles rely on a single centralized party (a single point of failure) to push updates on chain, we want to create the option for protocols invested in complete decentralization to be able to operate their own price service instance.
Regarding your point on the comparison between Pyth data points on Pythnet and API3 on target chain (in this case Polygon’s zkEVM), we understand that you have concerns about how we have conducted the comparison. First, we would like to clarify that we are comparing prices as soon as they become consumable. This means that Pyth prices are consumable upon reaching the price service, while API3/CL prices only become consumable once they actually hit the target chain. This distinction is important because it affects the timing of when the prices are available for use on Aave. In addition, Pyth-integrated protocols are configured to avoid the use of stale prices on-chain by setting maximum staleness thresholds. Since consumer protocols are aware of the availability of Pyth prices on Pythnet and the price service, and are configured to prevent the use of stale prices on-chain, they consider signed price updates as “ready to be consumed” on-chain and allow users to bundle a price update with a transaction. (As to your point about uptime/RPC issues, if there was an inability to land transactions to update the price on-chain, that would also mean an inability to land transactions to consume those prices on-chain. Thus Pyth introduces no new uptime weak links.) Consequently, it is appropriate to compare these ready-for-consumption price updates with the push-based oracles’ on-chain updates.
Gas costs for updates are indeed lower on API3 since price updates do not require signature verification of a signed price update. However, this comes at the explicit trade off of less granular pricing as we noted in the exhibits above. Having more accurate prices leads to better user price fulfillment and ultimately a safer pricing approach when valuing user positions on-chain.
Moreover, a per-message comparison is misleading because the entity who bears the cost is very different. In the push model, a centralized entity (such as API3) is responsible for the cost of all of the oracle updates. Thus, even a relatively small cost adds up over time as updates must be pushed consistently. In Pyth’s pull-model, the costs are distributed amongst all users of the protocol, which makes them more sustainable. Depending on grants from L1s is clearly not a sustainable strategy for maintaining an oracle feed in the long run.
In addition to this, we are continually working to decrease the gas cost through gas optimizations to our verifier contracts as well as some more technical rearchitecting to come in the near future—stay tuned for updates on our blog on this front!
