List of speakers:
Ugur - Marketing
Camron - Integrations
Dave - Business Development
Mark F - Operations
Optimistic or ZK Rollups? Any plans on integrating either one? (David)
With Optimistic Rollups, there is a slightly different virtual machine - the Optimistic Virtual Machine (OVM) compared to the Ethereum Virtual Machine (EVM). The Airnode was successfully tested with an OVM so there are plans to integrate with Optimistic Rollups. More information will follow in the future.
Most ZK Rollups use a different way of computing the code. It may be a little bit more work with most ZK Rollups but we’re looking at ones that are potentially using the EVM as well. Thus, plans for those are in the works and we are looking to release more information about it.
Can DApps decide to use API provider data feeds and not subscribe to API3 risk protection? (Ugur, Dave)
You can subscribe to Airnodes without buying coverage. As of now, the plan is that risk protection and access are two different modules that can be combined. Therefore, you can technically gain access to a dAPI without buying coverage for the product. However, that is not set in stone yet and a work in progress.
Some people might not want risk protection if they think it would get them cheaper access to the data feed and even if they take the risk protection, it might not have the full value that’s insured which would effectively be partly having some of it uninsured anyway.
Are you done now that you have 125 partners? (Mark, Dave, Ugur)
No, definitely not. In terms of data feeds, it’s just a question of integrating whatever the customer delivers via APIs onto the actual product. Considering the product runs through an AWS or other hosted cloud mechanism the customer chooses to use, it’s just a question of integrating them. There is no scale limit so we just keep going because the more APIs we can provide in terms of the entire space, the more projects can build and the more services can be provisioned, realized and maybe monetized as well. So, we’re definitely not stopping at 125.
The BD API team put out another proposal so there’s actually a team that is still going at it and signing more partnerships.
Are you going to tweet each new alliance member from now on? How will the community know if we have new partners? (Mark, Ugur)
For the foreseeable future, that will continue but it will be subject to constant review by the marketing team. Whether or not there will be a single announcement for every new partner is a marketing decision after all.
How many alliance members run Airnode already? (Camron)
As of 19th August, we have 18 providers that are running Airnodes. Those providers are already providing data on chain and are ready to go. The way the integration works is we prepare the deployment package and the integration. Then we reach out to the provider and they deploy the Airnode within ten minutes. As far as deployment packages and integrations go, we have 38 of those done and ready for the provider’s deployment.
How easy is it to integrate Airnode? How long does it typically take? (Camron)
If you have an actual swagger doc or OpenAPI spec which is a mapping for your API, we can get your deployment package or integration done within an hour. The actual deployment only consists of putting your credentials into the deployment script and running it. It usually takes about five to ten minutes. That’s it. If you want to make any changes, you make those changes in the deployment package and you can redeploy in the same amount of time.
When can we expect the partners to be live? (Ugur, Camron, Dave)
It’s going to be a growing list. We are not done at 125, the API3 Alliance will keep growing. Generally, we do around 30 integrations per month.
With Airnode, we are having some extra work done to convert it to a beta version that’s more suited for production use. This should be ready within the next month. However, people can use the pre-alpha version already but we’re suggesting for the time being that they wait for the beta version. We have users ready to use this as soon as it’s done.
I want to use some of your data on Polygon. When will this be possible? (Ugur, Dave)
The pre-alpha version of Airnode allows this. However, even though it’s technically possible, we advise to wait until the beta version of Airnode is released. Lastly, Polygon is one of the first networks that we’re planning on launching a use case on as well. Technically, any of the networks will be supported.
How do API providers or API3 make money? (Ugur)
A potential customer needs to be whitelisted on the Airnode in order to be able to make calls. This is done through so-called authorizers. There is an API3 authorizer which is an authorizer that the DAO controls and there is a self-authorizer which is an authorizer the provider controls. The authorizer whitelists an address indefinitely or for a specified amount of time. Only because the DAO controls the API3 authorizer does not imply that we have full control over the Airnode of the provider. The provider can always deny access and are in full control over their data.
Example:
Finage is running an Airnode. The API3 authorizer is whitelisting potential customers and is in control over the Airnode’s whitelisting process. The API3 DAO controls that specific authorizer.
If there is a specific customer that wants access to the feed, they would actually request it from the DAO and then the DAO would technically vote on whitelisting that customer. This would not be very scalable. Imagine we have 100 customers that want access to that Airnode. That would be 100 separate votes to whitelist them. This is not how we envisioned it. Instead, you can give away control of the authorizer. The DAO can technically give away control to a multisig, a wallet or even to a contract that uses the API3 authorizer to whitelist addresses. For example, a contract could be set up in a way where you would need to require API3 to be whitelisted for one day, i.e. one API3 to be whitelisted for one day that is programmed into the contract. Now a customer could technically engage with the contract and lock 100 API3. The contract would then whitelist that address for 100 days. This allows us to completely automate this process and also give away the listing process to the contract that does it based on customer engagement. Important here to note is that in this setup, the provider is not paid by the customer. The customer engages with the contract and then with the DAO. There would need to be an agreement between the DAO and the potential provider to pay them out x amount of money on the basis of how many users request access. This could be done either through fiat or cryptocurrencies - whatever the provider requests.
ChainAPI will be the UI for that contract interface. You will be able to select an Airnode, lock up x amount of API3 and in the background, interact with the contract that then whitelists you for x amount of time.
The self-authorizer also controls the Airnode and is controlled by the API provider. The API provider could manually whitelist whichever address they want. If a potential customer approaches an API provider and pays him (this can be done off-chain or on-chain), the API provider can in return whitelist the potential customer. The provider could also give away this control to a smart contract that requires a payment and does it in an automated way. The API provider can decide which payment he would like for it. The DAO will go for API3 tokens that have to be locked to gain access. The provider could also go with UNI or SUSHI and automate it in that fashion.
Could you elaborate a bit about what in the Airnode is already working and which aspects should be worked up in your opinion before a stable version can be launched? Same for the risk protection. (Camron, Dave)
The pre-alpha version of Airnode is really stable. It’s definitely usable if you want to experiment with Airnode. You can find the Airnode starter which is on our github and in the documentation. This runs you through the process of deploying an Airnode if you were a provider and it also takes you through the role of the requester and actually using a provider’s Airnode. The next versions will be more focused around the authorizers functions, improvements to save costs etc.
In regards to risk protection, we are planning for the long term by putting together plans to create a viable risk protection product. We are also looking at something more short-term that could be brought in shortly after the first use cases are live. Once the first kind of product has been fleshed out in more detail, there will be an article about it. Nothing is finalized yet.
What’s your marketing strategy moving forward? (Ugur)
This has been covered a lot in community calls. Marketing efforts have to go beyond crypto. We have to talk to businesses, we have to talk to enterprises and we have to talk to potential customers that are crypto-native. Our marketing efforts have to go into three different directions instead of just one. We have campaigns and initiatives to actually talk to API providers. Mason gave a presentation at API days which is one of the biggest global API provider events there is and he introduced Airnode and how API providers can monetize their data. We also have been part of EthCC which was more crypto-native and talked to a couple of projects and blockchains. We also have some communities stuff prepared that is currently in the works and also educational material to educate people how oracles work.
What’s the role of ChainAPI in the “lock tokens” scenario? (Dave, Ugur)
Initially, there will be a locking mechanism as an incentive for people to use it. The plan is to gradually progress to a burning model rather than having tokens just locked up for people to access APIs. The locking mechanism allows people to access APIs to test if everything is working and it also helps them to get used to the whole process.
Is ChainAPI mandatory or optional in that scenario? (Ugur)
It is not mandatory. You can do it on a contract level. However, the UI will make it easier for people to interact with it both for the data requester side and for the providers. On ChainAPI, they can put in their OpenAPI specifications which automatically translates it into the oracle integration specifications. They get all of the necessary files directly on ChainAPI and are able to deploy and manage their Airnode directly through the UI without the need to ever interact with API3. Considering how many potential API providers are out there, it’s important to have an automated process because API3 only has limited resources to manually integrate them.
Have providers indicated which of the authorizer options they prefer most? (Camron, Ugur)
A lot of the authorizers information is brand new and hasn’t been documented yet. The main concern of providers is around authorization, controlling users and monetization. We have plenty of options for solutions and we definitely have it as a priority in the development team who is fully aware of how big of a deal this is. In the next iterations of Airnode, we will see a lot more UX improvements on this type of stuff.
Using the self-authorizer means that you’re making transactions (whitelisting somebody is a transaction). If the provider does not want to transact in any way on the Blockchain, the way over the API3 DAO would most likely be the preferred way. Once we set up the smart contract that automates everything, the data requesters cover all transaction costs and we pay out the providers based on the deal that the DAO has with them.
Why has the total supply increased by 1.7 million tokens? (Ugur)
Rewards are inflationary. If you are staking, you are receiving inflationary rewards that are minted (newly created) after each epoch (7 days).
How do you separate yourselves from being compared to Link? (Mark)
We are a general API delivery platform which is focusing on bringing as many different types of data onto the on-chain space as possible so there is a different business and project focus. Also, how Airnode and the Chainlink product works both functionally and in terms of the code base is completely different (First-Party vs Third-Party Oracles).
What’s the expectation for average count of integrations in the future? To what grade will ChainAPI easen/ speed up (the already quick) integrations leading to a higher average? (Camron)
30 integrations per month is a conservative estimate and at the beginning of the cycle, we’re focusing a lot on preparing to scale. We are building out a lot of training documentation and bringing in members to help us, i.e. an integration engineer that just works on integrations all day long, a deployment engineer and a communication manager. So basically, we are building out the team to anticipate this influx of providers and integrations. It is expected that this number increases exponentially especially with the release of ChainAPI because it will remove API3 as the bottleneck.
Isn’t Link more focused on off-chain features and API3 is on-chain 100%? (Ugur)
Right now, we’re focused on actually making APIs available on chain in a trust-minimized manner. Basically everything that APIs allow you to do, i.e. sending an email, receiving a 2FA-authentication, accessing your bank account, getting weather data or looking for the next flight, we will make it possible over the Blockchain. As API3 is a DAO, this focus could change.
What are the actual use cases for the API3 token? (Mark, Dave)
Right now, it is governance. Later on, API3 tokens will be useable for people to lock them and eventually burning them to gain access to APIs or data feeds once they’re live.