The point above was to illustrate that your picture of “api3 produces less updates” is based on 2 seperate configurations of chainlink and api3. 0.5% deviation at 1 hour heartbeats vs 1% at 24 hour heartbeats. Claiming things like
“and that API3 has the highest deviations of all” and " They show that the Chainlink feed updates more frequently (12 times) than API3 (3 times)" are pretty moot if you’re simply reiterating configurations, because the result should be more than obvious.
Which essentially just means that decentralization on this front is an option and not really a requirement ;)
Pretty untrue statement wouldn’t you say, as push based approaches have time and time proven that any oracle node is able to submit the transaction, which means that every node that is supplying data for a specific data feed has the ability to push the price on-chain. Since nodes are ran by multiple independent parties (in API3’s and Chainlink’s case alike)… i think you get the gist
This is where i beg to differ heavily. During times of high congestion API3 and Chainlink services will always be available on-chain directly since we have dedicated infrastructure runnig that is purely used for our respective oracle services. During times of high congestion and/or black swan events you’re simply trusting that users (who mostly use public RPCs, lets be honest here) will be able to actually update prices, which is a bold statement to make. When users and/or liquidators are actually unable to rely on RPCs (e.g. recent nukes or Airdrop events) to push prices themselves, AAVE is going to be left potentially holding the bag when prices aren’t updated when they were supposed to. There is a reason dedicated infrastucture is typically made available for high stakes services and while i do “get” the idea of oursourcing parts of price pushing to the respective users, solely relying on them and their ability to manage/monitor/deal with RPCs is a risky bet to make, especially for AAVE when we’re talking millions in potential bad debt because prices have not been published when they should have been. It is also a heavy ask to simply go to a protocol and tell them to run a “price pusher” while also making sure to monitor respective infrastructure that this price pusher relies on (hosted where, uses what rpcs, etc) for simply consuming prices. You’re also asking these dApps to additionally pay for gas costs on this endavour.
Untrue again, as we also use signed price updates on our contracts. The current gas usage for self-funded dAPIs (due to their single source nature) is 37k gas, whereas your updates consume 270-280k for a single price update. The cost for our managed dAPIs will range from 75-100k (due to more signatures being verified), which is still going to be miles cheaper than what you’re accomplishing on-chain.
No, what you’re doing is asking each and every AAVE user to pay (at current times) 2.4$ every time they want to interact with the AAVE protocol on zkEVM and the price is not “fresh” enough, whereas we make sure that the price is fresh enough for a fraction of the cost that you’re accomplishing this (and doing so not in a centralized way as you claim) without requiring the user to pay a single penny for updating the oracle. I get that this works for e.g. derivatives platforms because it is mostly EV+ for a user to update the oracle to receive the “freshest” price for opening a 20x position, but for something like a lending protocol it is more than suboptimal.
The reduced cost also means that these things are actually affordable by chains and dapps alike and we’re charging exactly at cost of operating these products without rolling the cost onto the users (or even dApps by making them run an instance of a price pusher).
An additional benefit is that once data is on-chain it can be read by anyone for free and our conversations with chains have already proven that it is EV+ for them to pay at operating cost so that dApps (and most importantly their users) can benefit from free oracle services.