Chainlink Price Feeds vs API3 Managed dAPIs and the state of “DeFi”
It has been quite a while since I put out an article about a topic that I love to write about, since I am typically busy writing updates and product announcements for API3. Don’t get me wrong, this article is also going to be for API3 but more individually tailored towards me and my writing style about topics that are dear to my heart.
We’ve recently launched our managed dAPIs and one of the many things that I’ve been asked in the past months from chains, developers and dApps alike is “How is this different from Chainlink Price Feeds?” With that in mind, I thought it might be a good idea to simply write out a comparison article that people can be pointed towards instead of reiterating the same points every other week to somebody new.
I’ve also thought hard and long about how precisely I should tackle this article since there is obviously a little bit of bias attached. Even if I did my very best in being as neutral as possible in this article, people would still use my association with API3 to “fud” the comparison. For that reason, here goes my biased unbiased opinion on Chainlink Price Feeds vs API3 managed dAPIs and the current state of “DeFi”.
The Common Ground
There are going to be a bunch of differences mentioned in this article so why not start off with something that we have in common? Both Chainlink Price Feeds and API3 managed dAPIs are based on a push oracle infrastructure. Without getting too technical, this simply means that required data is pushed and maintained onto the respective chain that it is needed on (in part) by the oracles themselves.
This is in stark contrast to other solutions that specialise in pull oracle architecture. Take Pyth as an example. They maintain price information on their own respective chain where it can be pulled into any chain it is needed. This is great for things like perpetual protocols that rely on the most up-to-date data. However, this architecture comes with some severe disadvantages (what follows is a pretty big rant- feel free to skip if you know about pull vs push. Most of my information comes from debates I’ve had on the AAVE forum as well as reading through some other governance proposals in e.g. the Compound forum).
Firstly, you’re forced to rely on bridges. In the case of Pyth, Wormhole attests values available on Pythnet after which they can be made available for anyone to consume. This means that your data consumption is now tied directly to additional trust assumptions in a bridge, and considering the sheer amount of bridge exploits in recent years, it is a pretty big trust assumption to make. To this date, Wormhole still fills the number 5 spot in all time rekt only topped by SBF and *checks notes* 3 other bridge exploits.
Secondly, there is the availability of data after Wormhole. After the attestation of the values by Wormhole, they can be made available through an http-gateway (in the case of Pyth called the price service). This allows anyone to make API calls to the gateway for the values they need; however, who runs this service and what happens when it is down? According to the Pyth docs, they themselves run and maintain this Price Service and you’re free to spin up your own at any time to create “redundancy”, because if it’s down you’re not getting any values.
Translation: “Trust a centralized company or host your own stuff.”
Let’s take a little break here. All of this, and the data you want still isn’t even on your destination chain. You have also already been burdened with trusting a bridge, and are being forced to either trust the Pyth-ran Price Service or spin one up yourself. Cool.
Now, let’s dive to the third point: making data you need available on the chain you need it. The vast majority of DeFi dApps are architected around push oracles. May it be the likes of AAVE (and its numerous forks) or Compound (and its numerous forks). They simply want to read data and have even stated publicly that adapting their protocols for pull architecture just isn’t an option because it has too severe implications on things like protocol design and user experience. But no problemo, Pyth got you covered here. You can simply run something called a “Price Pusher” that maintains the required information on the chain you want it on according to deviation and heartbeat, just like, you know, a push oracle. But who hosts these and who pays for gas? This is where things get pretty hilarious.
In the AAVE governance forum, Pyth has suggested to become the fallback oracle for AAVE on Optimism. Their suggested implementation? Pyth runs a price pusher to accommodate the “push need” of AAVE and Pyth also sponsors the gas costs. This basically means that these “fallback” price feeds are relying on Wormhole, a price service hosted by a single entity (Pyth) and a price pusher hosted and funded by the (same) single entity (Pyth). Decentralisation.
Similar discussions appear to be held with Compound and a potential deployment on Consensys’ Linea. The difference on this proposal is the suggestion to use Pyth as the primary oracle and having three entities run a price pusher (namely Pyth, Consensys and Gelato). The issue? While the pushing is now “decentralised” (tho with more trust assumptions as oracles =! people pushing) there is no mention of anyone else running the also critical price service that actually allows you to even get data. This means that Pyth can still, at any point, rug this construct since it relies on a single entity. Decentralisation.
What am I getting at with this big Pyth rant in a “Chainlink v API3” article? For the better or worse, API3 and Chainlink have something in common that needs proper highlighting here. We maintain price information in a decentralised way directly on the consumer chain without requiring chains or dApps to host additional infrastructure (in the form of price services and pushers) and without forcing more trust assumptions down your throat (like a top 5 rekt bridge).
Immutability, Upgradable Contracts and the never ending tale of Multi-sigs
Right off the bat, both Chainlink and API3 currently have godlike multi-sigs that can kill any price feed at will. Yes, I’ve said it. This is not what you want to hear, but if Sergey & Co had a bad day tomorrow they could wipe out all of DeFi and there isn’t a thing in the world you can do to stop them from it if you’re solely relying on Chainlink. Same applies to API3 currently.
The only reason I’m highlighting this specific aspect is to first of all raise awareness about the existence of such multi-sigs, but also highlight our different approaches to dealing with them. In the case of API3, we consider this multi-sig a necessary evil to get started. We’ve just recently launched our managed dAPIs and similar to a lot of L2s and other early stage projects, consider ourselves operating on training wheels. Currently API3 possesses a multi-sig that has the ability to point a feed like “ETH/USD” anywhere it wants. This ability will be drastically reduced in future iterations, where redirections are only possible to DAO approved addresses and the amount of allowed redirections is also limited.
Opposed to that we have the Chainlink multi-sig. Among other things (and similar to API3) it has the power to point any data feed wherever it wants. The big difference is that Chainlink considers this multi-sig and the power it possesses necessary with no intentions of getting rid of it or drastically limiting what it can do. This was expressed time and time again, also being evident since it has existed since price feed inception nearly 4 years ago and is also getting justified repeatedly by their biggest followers like CLG.
The big difference lies between our intentions for these multi-sigs. API3 recognizes its power and trust implications and is thinking actively on how to reduce such reliance, whereas Chainlink deems it necessary forcing you to trust them *forever*.
Immutability vs Upgradability
Why would you want upgradable contracts to begin with? Well, users of oracle services typically want to offload the management of oracles to someone. As stated by CLG above, oracle networks are rarely static. Nodes can misreport and simply be completely offline in which case adjustments need to be made. Chainlink approaches this by being able to add or remove oracles nodes through their multi-sig, but also have upgradability available in order to go through more drastic changes (good or ‘evil’) when needed. (They could in theory change the entire logic of the contract on a whim)
Our contracts are immutable, but does that mean we can’t adapt to required changes? No, not at all. While our contracts are immutable, we’ve introduced the concept of dAPIs that allow us to manage the ever changing landscape of oracle networks. In essence, a dAPI is a pointer that points to a singular or a combination of data feeds, similar to how an ENS name points to an Ethereum Address. If you read an ‘ETH/USD’ dAPI and it is currently pointed to an aggregation between Coingecko, Coinbase and Binance, we could redirect this mapping if e.g. Binance begins acting up. This mechanism is currently controlled by the API3 dAPIs team multi-sig and as previously mentioned will be heavily restricted in power in the future.
So what? We both can essentially fiddle around with data feeds however we like, it doesn’t really matter that one is immutable and the other isn’t. Well, yes and no. What API3 is able to do is set dAPI mappings. That’s it and nothing will ever change since the underlying contract is immutable. The rules are clear and can’t be changed by us in any way. This is drastically different to Chainlink’s construct. They can upgrade their contracts to do practically anything. They can introduce new features that weren’t there before whenever. This difference is pretty drastic and I’ll tell you why. Let’s play a little game here. Assume the following scenario:
- A huge bridge was exploited somehow and the exploiter has gotten away with 250,000 ETH
- They’ve decided to deposit all of this money into AAVE
- AAVE, Compound and Synthetix are reading the same ETH/USD price feed
Is it possible to get the ETH back that a specific exploiter put into a lending protocol that utilises oracles? Abso-fucking-lutely.
In the case of API3, we’d have to maliciously point the entire ETH/USD dAPI to a wrong data feed, which would return e.g. 0.001$ instead of the true ETH/USD rate. This would allow us to borrow the ETH out of AAVE utilising other collateral. Since we heavily misrepresented the ETH/USD rate (by -99.999%) this would be very cost efficient and we’d be able to simply whitehack the funds back. The problem is that we’d be effectively rugging any other protocol also reading the ETH/USD dAPI at the same time. Compound and Synthetix would also be immediately rekt the moment this would happen.
This is the same with Chainlink, right? If Chainlink simply reported 0.001$, we could “save” the funds in AAVE but rekk Compound and Synthetix in the process. Well, not really. You could simply upgrade the Chainlink contracts so that they report the true ETH/USD rate for Synthetix and Compound, and report a malicious one for only AAVE. Chainlink would have no trouble whatsoever feeding a wrong rate to a specific dApp and targeting solely them. In a time where multi-sigs have already been court-ordered to do “malicious” code updates, you should probably think twice about how comfortable you are putting yourself into this position. In fact, one of the many reasons people prefer using DAI over USDC, despite calling it a glorified USDC wrapper, is the fact that they cannot be targeted. For some reason people don’t really consider this when it comes to oracles.
Fun Fact: After Oasis was court ordered to use their multi-sig to “hack” funds back, they went ahead and removed any upgradability. Yes, these contracts are immutable now after they realised they can be forced to abuse them.
So what does this little thought experiment mean? I simply wanted to illustrate that what API3 can do now is never gonna change. It is hardcoded and can’t change, not even if someone wants to force us. Compared to that, Chainlink can introduce any arbitrary logic at any given time and as usual you trust that they don’t do that (or hope that they’re not forced to).
Don’t trust, verify. Don’t trust, verify. Don’t trust, verify. Don’t trust, verify. Don’t trust, verify. Don’t trust, verify. Don’t trust, verify. Don’t trust, verify.
The above was already a lot to unpack, but oh boy do I have more coming. Have you ever wondered where the data you’re getting from Chainlink is actually coming from? I mean there are numerous articles that make claims about all the data providers that Chainlink is working together with, but do you actually know which ones are behind e.g. the BTC/USD price feed on mainnet Ethereum?
Note for those who don’t know: Chainlink is a network of mostly (95%+) third-party node operators that get data from somewhere and then report it on-chain. These nodes are actually not the data sources themselves, so if you see a feed (like BTC/USD) with 31 nodes, that doesn’t mean you have 31 APIs. For all you know it could be one or two.
It’s a bit of a mystery who these data sources are. On this page we merely see the node operators but not really where they actually get their data from. I mean, Chainlink would simply tell you, right? It’s all verifiable, right? It’s not paper promises, right? They’re known for cryptographic truth!
The above is from a governance call in the Celo community where Chainlink presented their proposal to bring Chainlink onto the Celo network (for a whopping 2 Million CELO a year (~$850,000 today), kek, more on that later down the line).
When simply requested to share which data sources are actually used by node operators, Chainlink answered that they cannot disclose that “due to security concerns”. But don’t trust my words, just listen in starting from minute 21.
I’m unsure if there is more I have to tell you about this topic really. The absolute source of truth, the gods of VRF, the company that goes to conferences with the slogan “say goodbye to paper promises” effectively tells you:
“Trust me bro.”
Some rando Chainlink Labs employee tells you it’s at least 5 data sources, so that has got to be it, right? Case shut. No need to worry anymore and you don’t actually need to be able to verify such claims because…. i mean.. it’s Chainlink after all….right?
Well, what if i told you this situation is in no way different than what recently happened with Multichain. For those that are unaware or don’t follow everything that is happening in the crypto world — Multichain is a bridge (or was lel), that claimed to be “decentralised”. The funny part is, nobody actually checked that or was able to verify it. They simply told their partners, among them big names like the Fantom Foundation and Andre Cronje, the following:
“Trust me bro.”
And I shit you not (yes, in this industry full of scams) they actually did. Lo and behold, Multichain blew up and it turned out it was hosted by a single person (true shocker).
Hilarious right? H-I-L-A-R-I-O-U-S. But you know what’s not hilarious? That we’re securing 12.1 Billion USD with the same “Trust me bro”.
So, am I claiming that the entire Chainlink network is only using one or two actual data sources? No, not really. I don’t think that’s the case, since i don’t think that they can be that malicious. I mean the rando Chainlink Labs employee in the Celo call ensured us it’s at least 5 (lmao). But that’s not the point, because none of you can actually verifiably prove to me that it isn’t a single data source and that should scare the living shit out of you.
Is this different with API3?
Sorry for my wording, but abso-fucking-lutely. Verifiability is our number one priority. We don’t give paper promises. No really. In fact we’re provably more decentralised than what Chainlink can claim and that’s a fact.
For anyone questioning that, I dare you to go ahead and prove to me (verifiable by anyone) right now how many APIs are actually utilised in the BTC/USD price feed on Ethereum Mainnet. Go ahead. I’ll be waiting.
API3 only utilises first-party oracles, which are oracles that are operated by the data sources themselves. In simple terms this just means that instead of utilising a third-party operator (like LinkPool) that claims to use e.g. NewChangeFXs API (or won’t even say anything about data origin), you get data from NewChangeFX *directly* running a node. This removes the entire middle layer that you need to trust with Chainlink, which also obfuscates where your data is actually coming from. The only thing that you need to do in our setup is to prove that a specific oracle address belongs to the data source. This is done by the data sources themselves through creating a DNS txt record with their oracle address. Only they have access to their DNS records and only they can make entries there that confirm ownership. There is a guide available here that runs you through the process of verification.
What does this mean? If API3 claims that a certain data feed is secured by 7 oracles, it effectively also means that it is secured by 7 data sources as data sources are the oracle in our setup. This is verifiable by anyone at any given time. No “trust me bro”. No paper promises. It’s all on-chain and provided to you by the data sources themselves. If Chainlink claims their data feed is secured by 31 nodes, you don’t know and can’t verify what is actually used under the hood. And if that’s not scary enough, the fact that they don’t even want to tell you, should be.
The hilarious part is that data providers like TwelveData, Finage, dxFeed, Kaiko and NewChangeFX are all powering Chainlink nodes as well. There are numerous press releases about these partnerships. So you can get their data, completely obfuscated through third-party nodes that you have to trust in addition to them, or you can get their data directly in a verifiable way.
Money, money, money.
The golden era for receiving oracle services for “free” is pretty much over. In the past years developers have enjoyed oracle services from Chainlink without requiring payments due to them being subsidised by Chainlink Labs. This might be hard to hear but any LINK token holder effectively contributed to dApps like AAVE, Compound and others not paying a single dime.
But those times seem to be relatively over. Chainlink wants to begin charging people that want their services and this is most likely due to the ever expanding landscape of alternative L1s and also L2s that keep popping up left and right. More chains, more gas costs to maintain price feeds and if they’d continue with the full subsidisation model it would equal in even more dumping of their own token for the benefit of others. So, in my eyes it is only natural to ask for payment, since you can’t be giving out free candy forever. However, how much they are asking for could be defined as a straight up scam.
With the Chainlink SCALE program, chains can partner up with Chainlink and pay them to offer Chainlink services on their chain, of which some (e.g. price feeds) can then be consumed for free by developers. Sounds good in theory right? Which chain wouldn’t want to do this? It’s a pretty neat thing to have Chainlink there and then also offer price feeds for free to projects building on your chain. Well, the big issue really comes with how much Chainlink is asking chains to be part of the SCALE program.
Remember CELO? Above I mentioned that there was a governance proposal to bring Chainlink onto the Celo Network for a whopping 5,980,314 CELO over 3 years (that’s ~2M CELO / year or $850k / year at current prices). The Celo community passed this proposal and several months later, in July, received the first service from Chainlink — Price Feeds. The Celo Network was blessed with a total of 7 price feeds, namely:
- BTC/USD at 0.5% deviation and 24 hour heartbeat
- CELO/USD at 0.5% deviation and 24 hour heartbeat
- ETH/USD at 0.5% deviation and 24 hour heartbeat
- LINK/USD at 0.5% deviation and 24 hour heartbeat
- EUR/USD at 0.5% deviation and 24 hour heartbeat
- USDC/USD at 0.5% deviation and 24 hour heartbeat
- USDT/USD at 0.5% deviation and 24 hour heartbeat
To draw a comparison to what this means in terms of cost we have to do several things. First of all, how many updates do these price feeds perform a year? As a reference point we could look at the ETH/USD price feed on Ethereum Mainnet that runs on the exact same configuration. In the second quarter of this year, that price feed generated a total of 4,277 transactions. There are still a few things to consider though:
- network activity is pretty low due to bear market
- volatility was essentially dead in the second quarter of this year
- network activity might pick up due to DeFi growth as Chainlink becomes available
The above are all reasons why gas costs and transaction amounts might increase in the future. However, we also have to consider that price feeds like USDC/USD, USDT/USD and EUR/USD won’t create the same amount of transactions as ETH/USD. So, for the sake of Chainlink i’m just going to assume the following in order to (maybe) help justify their ask:
- Every price feed creates the same amount of transactions (yes even the stablecoins)
- Increasing volatility will triple the amount of transactions
- Celo gas will increase ten fold due to network growth and bull market activity
If we make those assumptions we end up at the following transaction count:
- Multiply transaction count by 4 due to only representing a quarter: 17,108
- Multiply by seven due to seven price feeds: 119,756
- Multiply transaction count by 3 due to increase in volatility: 359,268
This gives us roughly an estimated 360,000 transactions per year for seven price feeds. So far, the Celo Network averages around 20 gwei for 2023. A Chainlink price feed update currently costs roughly 135,000 gas. At current gas levels a single Chainlink update transaction will cost roughly 0.0027 CELO or roughly $0.0012 (sometimes even less). With our estimated 360,000 yearly transactions we’re looking at gas costs of 972 CELO or roughly $408.24. If we assume the network activity increases tenfold we’re at 9720 CELO or $4082.4.
9720 CELO or $4082.4.
I could 10x these numbers again to 97200 CELO and it doesn’t even come remotely close to the 2 Million CELO ask of Chainlink. I could attribute 100k for personnel and infra costs and that still doesn’t justify asking for over roughly $850k a year. Networks like CELO are getting milked. There is no easy way to put this, but since Chainlink Labs wants to stop dumping their own token to subsidise price feeds, pay node operators and their salaries, they’re now looking elsewhere for that money and putting a heafty profit margin on top.
I’d love to say that Celo is a single case, but it is even one of the lowest numbers that are circulating. There are networks out there being asked for 8 figure sums per year to get Chainlink to deploy there. So if you’re out there wondering why Chainlink services aren’t available on a particular chain yet it is most likely because that network refuses to get scammed.
If Chainlink is scamming me, what are you charging?
Right off the bat, API3 doesn’t operate dAPIs to make profit. We have a (voluntary) add-on service coming that is built on-top of dAPIs which will be how we monetise oracle services. Does this mean any managed dAPI is available for free? No. We still have gas costs that we’re facing so we have to charge something, but what we charge, we charge to break even.
We continuously monitor network activity and asset volatility to price our service. When you buy a managed dAPI, you buy it for a specific amount of time, e.g. for 6 months on Polygon. Once you paid us for those 6 months, we guarantee uptime, even if we miscalculated gas and it turns out to be 10x as expensive to operate (that’s on us for miscalculating). When those 6 months are nearing their end, you can simply extend the service which will reflect current asset and network parameters (and hence might be more expensive or maybe even cheaper).
dAPIs are always free to read, which means that once upgraded and available on a particular chain, anyone can use them without additional cost. This model is particularly interesting for chains and we see them using our API3 Market to simply purchase managed dAPIs to give developers on their network access to free oracle services.
Obviously, we want to be on every chain, but expanding onto chains is resource draining and as such requires us to charge networks that want us initial money to expand. Particularly we charge 20,000 USD in stablecoins, which is used for infrastructure purposes of that specific chain (e.g. our own RPC infra for that specific chain) and an additional 10,000 USD worth of network tokens that is used for any type of contract deployments and setup of services. Any remaining amount of these network tokens will be kept on the respective chain and act as a fallback gas fund. These numbers are essentially the same for every chain.
What does this mean if we’re looking at Celo? With API3, Celo would have paid:
- 20,000 USD in integration fee
- 10,000 USD worth of Celo for deployments and backup gas fund
- (assuming the inflated CL numbers) 9720 CELO or $4082.4 for gas
That’s roughly $34,000 compared to $850,000.
34,000 vs 850,000.
Hey ChatGPT, what are the core benefits of blockchains?
Lets round things off by talking about why blockchains to begin with. Blockchains are (or maybe used to be?) about decentralisation, immutability and transparency, as well as trust minimization and verifiability. We can potentially sit here all day and debate the benefits of upgradability vs immutability, but i think that nearly everybody in crypto can agree on the following aspects:
- the things we use need to be (or should strive to be) decentralised.
- things should be verifiable by anyone
- we shouldn’t blindly trust (and strive to trust minimise)
It is for those reasons that it is so perplexing how we’re willing to let an entity such as Chainlink, that is violating nearly every aspect of the “crypto ethos”, secure over 12 Billion in TVL. For all we know this is the next Multichain and none of you can prove that it isn’t.
To finish things off, here is a little bit of a personal rant. In my eyes there is no such thing as “DeFi” currently. The truly decentralised and trustless things can be counted on your hands. The thing that blockchains were supposed to remove — trust — is the thing that builders on it rely on the most today. So far, we merely accomplished to exchange one all powerful group of people with another.
