Orchestrate all the Things - API3, the first-party blockchain oracle, is releasing beacon data feeds with Amberdata. Featuring API3 co-founder Heikki Vänttinen

Episode Date: January 19, 2022

In theory, Web3 is all about decentralization. In practice, it can be very centralized. API3 is a bold effort to achieve decentralization in connecting Web3 applications to the outside world. Article published on ZDNet

Welcome to the Orchestrate All the Things podcast. I'm George Amadiotis and we'll be connecting the dots together. In theory, Web3 is all about decentralization. In practice, it can be very centralized. API3 is a bold effort to achieve decentralization in connecting Web3 applications to the outside world. The so-called first-party blockchain Oracle is releasing beacon data feeds with AmberData.

I hope you will enjoy the podcast. If you like my work, you can follow Link Data Orchestration on Twitter, LinkedIn, and Facebook. My name is Heikki Vantinen. I'm originally from Finland. And I guess what I should start with is kind of the background into the blockchain entry and then moving on to how we got started on API 3. So I kind of got involved with blockchain technology back in 2017-18, started off in kind of the business development and marketing consulting uh side of it and uh and i have basically a background in in those areas uh uh from when i when i was working outside of the blockchain space and and consulted on on multiple projects uh with with these areas of focus and

and then really working in the space got really really interested in, in Oracle's as a, as a technology, basically how to connect real world data to smart contracts and decentralized applications and smart contracts if you can connect them with what's happening outside of the blockchain and to facilitate this connection you need middleware and that middleware is basically called oracles and at that time decentralized oracles were just becoming a thing and were posed to unlock a lot of value in the form of decentralized finance. So decentralized finance was just kind of like getting started. And yeah, we got really interested in basically working on this problem with a small group of people that were also interested in oracles and and then we we started

building basically an api marketplace that would allow smart contract developers to access access application programming interfaces that would be useful for their decentralized application uh for pulling data like uh you know the prices of assets or weather data about the weather at a certain location or sports scores or what have you. But then we decided the technology that we're building that API marketplace on top of, in terms of the oracles that were powering it uh we deemed to not be you know fully aligned with the interests of of the data providers that we were talking to on a daily basis so essentially there were issues like uh data attribution where the data provider wouldn't be able to

know um if they were getting attribution for serving certain data feed on chain, because the, there was basically this middleman problem, which we'll get to in a second, um, um, where essentially the, the on-chain user, and we basically, if it's a decentralized application is basically what we call on-chain on-chain usage of the data. Uh, they weren't able to see all the way to the source of the data. So they weren't actually knowing which API the data was coming from necessarily. So the data providers would want to do stuff like data attribution, like signing

the data or providing some sort of metadata in the transaction that would show that this came from this source. And also the the the kind of the the the Oracle design that we were building on top of, which was this third party Oracle model, which would basically have a middleman existent between the source provider of the data and the on-chain user of the data, that the middleman would also kind of like impose this middleman tax, which was kind of like financially misaligned with the data provider. So essentially, we learned that a lot of the data providers that we were working with were not very happy about the technology that we were kind of using

as the foundation layer of what we were building. So then that led to essentially API3 as the solution to a lot of those problems, like the financial misalignment and the data attribution and so on and so forth. Okay, so would you be so kind as to share when was it that you officially, let's say, started API3? I'm assuming that you have incorporated some kind of entity, so I'm just asking so we get a sense of the space you've covered, basically.

Right, yeah, so we've been around for a little over a year in public, and then before that, we were working on this for about six months in so-called stealth mode. So, yeah, we're about 18 months down the road at the moment. Okay. And may I also ask if you have gotten any funding so far? And if you can share a few key metrics, like how many people are in the organization or that kind of thing.

Right. Yeah, yeah. So we've raised funding. We've raised a seed round from a lot of notable investor or some notable investors in the Web3 space, such as Placeholder and Pantera and CoinFund and DCG Accomplice, Hash. I think that's the list for the the big six so to speak um and then uh we did also a initial token offering um a decentralized distribution of our token to government participants so basically the token allows you to govern the project and

and to achieve decentralized governance we have to distribute it um and so so we also did that and when it comes to the number of participants in terms of like contributors who are building api3 and the technology that powers api3 which is called the air node uh we have about 50 people in in the organization which is a dow and what a DAO is, is a decentralized autonomous organization, which is basically like an on-chain equivalent of something of a decentralized company structure. So that's basically how we've decided to structure the project. And it allows you to do things like decentralized governance for the data products that we're looking to offer. So it's beneficial from that perspective as well. Yeah, I think most people in the crypto, let's say, space are familiar with DAOs.

And I also think it's probably one of your key differentiation points compared to other oracles in that space. But we'll get to that later. Actually the occasion today is that you're announcing something called Beacon but I think in order to be able to frame it better it's best if we refer at least superficially let's say to your tech architecture. So I've looked around a little bit and as far as I've been able to tell it looks like it's mostly centered around the Airnode which encapsulates a few of the key architectural decisions that you already outlined in your introduction. So around attribution and well giving

fair share let's say, to API providers. And then you also have the API search and something else called the APIs. I think it's probably best, in my understanding at least, it starts with the APIs. You implement the concept of the APIs in the Airnode and everything else is on top of that. But I'm sure you can explain it far better than I can.

Yeah, yeah, yeah. And if you abstract it a little bit, like the conversation is really about like third-party oracles and first-party oracles. And the difference there is between whether the design utilizes a middleman or if the data provider is also the Oracle node operator. So to kind of like understand the distinction between first party and third party oracles and kind of like the the evolution of uh the oracle problem and the solutions to the

oracle problem as a whole i think it just makes sense to they take this sort of historical approach to or or this sort of a historical view into how we got to this point where we're proposing first-party oracles and more specifically the Airnode as the ideal solution for bringing data on-chain from the real world. And, you know, originally back in, you know, the times when I was getting into the industry, 2017 and so on, the Oracle problem really meant that you had, and kind of like the initial description of the Oracle problem is that you have basically an on-chain application or smart contract that needs access to a data point off-chain and that's generally delivered through an API, but those two are incompatible technically. So the on-chain application can't call the API in the same way

that a Web2 application could just call an API for a value. And so then the initially proposed solution is that you just basically introduce this middleman that would be relaying the data, basically providing a connection on one end to the on-chain contract and then on the other end to the API and would be relaying requests and data between these two. But then obviously you would have a centralization point, a central point of failure in that middleman and then the argument was that like if you have a centralization point in in the in in the mix like in in this significant of a manner um what is the reason you're using blockchain in the first place like if you have if you have a single entity that can manipulate the smart contract that is requesting

data from it uh at will anytime they want then why are you even on the blockchain which is deriving a lot of its security through being utilizing multiple nodes and if you're centralizing at one node then what's the benefit so then the the the the progression from there was that like you would decentralize that middleman like the the third party designs of the decentralized oracle networks that we most of us know are are basically this this uh this incremental improvement on on the sort of centralized oracle uh approach where instead of the the one single uh middlemanman in between the requester and the provider, you have multiple node operators. So that means that if one node operator that's running the

Oracle middleware decides to attack, then essentially they can be removed from the equation. If you take the median function, then that removes all outliers. And then on top of that, maybe you propose some sort of a staking and slashing mechanism, which would disincentivize any sort of attempted manipulation of the end value on the chain. So basically that's the kind of the current status quo when it comes to Oracle solutions, where basically you're getting as many Oracle node operators in between the requester and the provider as possible so as to make it as unlikely as possible that the middleware operators are able to manipulate the data that's hitting the decentralized application that needs the data. Now, what we propose is that instead of creating this very decentralized middleware layer

in between the requester and the provider, what you actually do is you get the data provider to become their own Oracle. So essentially, that cuts off the need for this decentralized middleware layer completely because uh you know as as many nodes as you as you have on that layer it cannot be more uh trustless and secure than if the source provider run the oracle themselves because the source provider can always manipulate the data if they have an adequate incentive to do so. And then you basically have to, when you select these off-chain providers,

you have to take into account things like the provider's reputation and their long standingness and the history of providing data for valuable use cases and so on. Like that's things that you can take into account when you're assessing the data provider, things like the brand and their yearly revenue. Would it make sense for them to attack this application on-chain?

So essentially, the AirNode enables you as a data provider to do exactly this. So the Airnode is technology that allows you to, you know, quote unquote, oracleize your API and offer your data directly to the on-chain application without having to pass it through multiple middlemen so as to make sure that it's not being manipulated with. And then you can actually serve that directly to the on-chain user or, and this is basically the beacon. A beacon is, is, is essentially, And you can actually serve that directly to the on-chain user. And this is basically the beacon. A beacon is essentially a first-party Oracle, so an API that is running an error node and

has those effectively oracleized themselves and is updating a contract on-chain that is basically the Oracle portion that the consumer application is called when they need the data point, the most up-to-date data point for, let's say, the price of an asset. So that is a beacon. Beacon is basically a first-party Oracle that updates a contract continuously on-chain. decentralized version of this, the more distributed version of this is the DAPI, which is then just a collection of beacons where you have multiple first-party oracles being aggregated into one single point on-chain.

Okay. Well, that actually invites lots of follow-up questions, but I'll try to squeeze in as many as possible. So, thanks for introducing the beacon into this conversation because well it's supposed to be the focal point of it all. So I think you kind of confirmed what my initial understanding was that it's basically, how

should I call it, kind of a rebranding of API providers running their own AirNodes, basically, right? Right. Well, yes, you can run an AirNode as an API provider and then offer that as effectively an on-chain API, but that assumes that the request threat application initiates each request to your API separately. But then a beacon is basically something that is continuously updated and just shows the precious data point on, let's say the price of ETHUSD or whatever you may need on chain. So the differences between being kind of like request response versus like data streaming to a public contract that can be read by whitelisted addresses.

Okay, so you're saying that it's not a request response model, but rather it's a streaming one. Yeah, exactly. So it continuously updates the price on chain for things like if you need to set a DeFi application that follows the price of an asset, like synthetic assets, for example, that requires you to have the most up-to-date value of the tracked asset on chain. And then you can point that to a beacon, which has the price of ETHUSD,

for example, or the price of gold or oil or or or some you know whatever stock or commodity or you might want to track on chain as a synthetic asset um that's all all doable by beacons otherwise um in the request response realm you would have to like initiate each of these updates uh individually so yeah it's basically the difference between request response and what's generally referred to as a data feed in Web3. Okay, so the entity running the beacon would, in that scenario, and you can correct me if I'm wrong, would actually not be the API provider but probably some third-party entity who also responsible for recording that continuous data feed, those continuous values on chain, right?

Well, not exactly. Like actually the beacon is, the beauty of the beacon is that it's a first party data feed in the same sense that an API is a first party Oracle if it runs an AirNode. The beacon is basically built on top of the request response protocol of the AirNode paired up with what we call an airkeeper. So essentially the airkeeper monitors the price coming from the API and if it deviates

from the set threshold by, or if it deviates from the set threshold by, or if it deviates from the price on chain, you know, above a certain threshold that's set, then it updates the price. And this is all run by the data provider themselves instead of a third party entity. And so everything is basically operated by the data provider, which means that you're not reliant on any third parties

for the operation of the beacon, which means that it's as trustless as, or let's say, as provider operated as a normal AirNode operating API, aka first party. Okay, but then in that scenario, that would also mean that the API provider would have to spend ether to continually update the incoming values on-chain, right? Yeah, so obviously the updating the feed requires Ether, and so this is not something that we're proposing for every API provider, but where there's a specific need for the data point in this updated data feed fashion on chain, then it becomes relevant. But yes, you need basically gas to update the value. Okay, okay, that makes sense.

And then in that scenario, it kind of invites the question. So what does API, where does api3 fit in that picture in that scenario what you're describing so every api provider is self-sufficient basically and clients that want to use those apis can if you know i i know in advance like okay i want to get that that data feed and i know you know the address where the server is running, I can directly connect with that, and API 3 is entirely out of the picture. So how does that come together in your business model, basically?

Right. Well, I think one of the core value propositions of API 3 in and of itself, besides the open source technology that powers beacons and the APIs and request response on-chain APIs is insurance. Essentially API three can provide quantifiable security to these data feeds in the form of insurance where essentially this has been already built into our DAO. Essentially when you take part in the form of insurance, where essentially this has been already built

into our DAO. Essentially when you take part in the governance of API3, what you're doing is you're staking API3 tokens into a pool of collateral, which can then be used to secure the data feeds against malfunctions where essentially if one of the users faces some sort of a malfunction, the data feeds a false value or is down when it's needed, and that leads to some loss of value on the part of the decentralized application of the consumer of the beacon, then they can file a claim, and that claim will be paid out if it's valid from that collateral pool.

So essentially API3 you can kind of think of as an insurance business from the business perspective. Okay, interesting. That's an interesting business model and to be honest with you, I don't think I've come across something exactly like that before in that space. So it's innovative, nothing else. I think you can think of it as like governance level staking. It's basically the governors of the API3 project taking on direct liability for the services that API three provides and enables. And then also it enables API three to also

extract value from that sort of design. So essentially this would be insurance premiums that would be included in the subscription prices of the beacons. So yeah, I mean, that's really the, in the white paper even, it's really the core value driver for the organization. Okay, interesting. Actually, yeah, I read the white paper even superficially because I didn't have the time to entirely absorb it. But there were a few things that piqued my interest, and this was one of them. And in there, yeah, it was also mentioned that there is, or at least there was supposed to be, that's the question, a collaboration with CLIROS,

which is a third-party entity that is like a dispute settler, let's say, simplistically. And I was wondering if this has actually been implemented, if it's ongoing, and what's the status there? And whether this model that you just outlined is actually operational? I know that you have a rather large ecosystem of API providers that you work with? And yeah, I was just wondering what's going on there, basically. Yeah, so essentially, we're working very closely with Kleros on implementing what's in the white paper. But to be clear and transparent, Beacons

are really the first production service that API 3 is looking to provide. So this has not been implemented yet. But yeah, let's say, I guess, what I can say is that we're still fully aligned on this front with the white paper and we're working very closely with Kleros on implementing this. And yeah, so the role that Kleros plays is the role of an arbitrator in the claims. So essentially you don't want the API3 DAO to be deciding on its own, whether they should wait, whether they should pay the to the the requester or not um and you you want there to be

basically a third party arbitrator for that and that's basically the best decentralized solution for that is claret at the moment okay okay thanks yeah that helps put uh put things into perspective so i guess this is sort of a big deal because as you said you're rolling out what essentially looks to me like your your first let's say heads into commercial territory basically what enables you to actually implement your business model yeah exactly that's that's great okay so I think we're almost out of time but we do have still some time to discuss the broader picture, let's say.

So I'm sure you're aware that the so-called Web 3 is highly disputed, let's say. So there are some people that say, well, it's still early. And actually, most of the dispute is around centralization versus decentralization and it's a recurring theme and for very good reason and some of the things that you mentioned throughout our conversation are exactly around that so the thin the delicate balance let's say between centralization and decentralization and how you can actually make something that's functional while at the same time being decentralized and What picked my interest around that is that well in the press release that I saw that you're going to

To be publicizing around the release of beacons It's and I quote here. It says that data comes from a single reputable provider as API and meaning API3 so in my mind and I guess you know the the initial reaction of somebody reading that would be like well that's not that's actually the provider uh it's the provider of the data where the data comes from so API3 is not the reputable source that's uh to in the press release. Okay. So, yeah, my feedback on that would be like, it wasn't entirely clear to me. You know, reading that, I kind of assumed,

okay, so that refers to API 3. Now it's more clear. It's abundantly clear now that you've actually said that. And it's even clearer after having this conversation with you, but it wasn't entirely clear to me reading the initial press release. So you may still have time to edit it a little bit before it goes out. Yeah, we'll take a look at that and we'll try to make it more clear. Thanks for the edit request. I think that's valid. Probably more people than just you

would have maybe read it that way. So cheers. But yeah, the data is always coming from the provider themselves. And what that allows you to achieve is a lot more cost efficiency in terms of data fee. So you can actually access more data from on-chain than in models where you're basically making,

you know, multiple requests to middleman or local nodes that are then making multiple requests to, you know, one or more API providers. And that often is opaque with who those data providers and how many there are in the existing solutions. But when you're basically cutting out all that kind of redundant as we discussed decentralization and the middleware level uh what you get is a lot more cost efficiency and what that allows you to do is

power a lot more use cases on chain and build build a lot more you know varying types of decentralized applications and d5 applications that require this data and so yeah like essentially what we're trying to to enable here is is is is you know more data rich web3 uh through more cost efficiency and and transparency and and uh and also the inclusion of more data providers in a a direct sense to Web3. And the last one, a little bit, well, not many people would probably pick it up, but I did because I'm sure you're aware of something called PSD2, which is an EU regulation, basically directing banks to make their APIs available. And that's highly relevant to how you work, apparently.

And I guess this is the reason why you have partnered with the Open Banking Project. And I was wondering if you'd like to say a few words on that partnership and how it's playing out. Yeah, exactly. So we did partner with Open Bank Project and are really focusing quite heavily on this development in open banking and open banking APIs being implemented for essentially all banks at the moment. And then essentially there are a lot of like

these fundamental infrastructure level challenges and including these types of APIs into the web three realms, so to speak. So you have things like authentication and, I'm sorry, authentication, and then even like the specific types of data regulations that you need to take into consideration when you're exploring open banking use cases

in connection to Web3. So essentially, yeah, we're working very closely with Open Bank Project in solving these both from, let's say the technical foundational layer in terms of the solutions that are required before this sort of integration can happen, but also the regulatory side and also kind

of even the developer ecosystem side. So we've been quite active in, for example, the El Salvador Bitcoin banking movement. And we actually even had a pretty well attended hackathon in El Salvador called Bitcoin Bankathon, which was exploring exactly these topics. So yeah, a lot of development happening. Let's say it's still relatively early days, but it's certainly an exciting area of development for API 3. Yeah, it sounds like it.

And it's probably a good idea to plan some catch-up around that at some point in the future. I would be really interested in talking to the open banking people. Yeah, well, we can make some introductions. Great. Well, I think we're already over time, and it is late, so I'm going to, I guess, we'll have to wrap up around here. Thanks a lot for your time. It was a very interesting introduction to what you do.

And, yeah, good luck with the release of Beacon and everything else going forward. Thank you, George. It was a pleasure talking to you. I hope you enjoyed the podcast. If you like my work, you can follow Link Data Orchestration on Twitter, LinkedIn, and Facebook.