API3 Core Technical Team Report, December 2021
As promised in the November report, we released Airnode v0.3 on December 7th. We started working on v0.4, which is largely focused on revising how the requests are handled to:
- Enable unlimited scaling (to the point that the cloud provider allows) and chain-specific provisioning of concurrency, which will allow a single node deployment to serve the needs of all API providers, regardless of the number of chains being served or the expected volume. This means Airnode will be deployed the same way — without requiring additional orchestration — if it’s only for testing, serving a single production use-case or serving many production use-cases across many blockchains.
- Allow requesters to specify the API provider to sign the response, yet a separate reporter to submit the fulfillment transaction (see the second figure here, or Section 4.1.1 from our whitepaper). This potentially solves some significant business problems and makes new use-cases possible. We will elaborate on this feature as it comes closer to fruition.
In the meantime, we are also working on the v1.x protocol contracts, which include PSP (publish–subscribe protocol), RRP+PSP Beacons, dAPIs, token lock-up and payment functionality for automating access to API3 services.
After Certik, Sigma Prime has completed a second audit of the v0.x protocol contracts. The audit report can be accessed through our monorepo. No vulnerabilities have been uncovered in the protocol, and releases v0.2 and v0.3 are once again confirmed to be safe to use. Nevertheless, it is planned for the v0.4 release to use a new iteration of the contracts where the suggestions from the audit report are implemented.
This month, we published an article introducing Beacons. A Beacon is a data feed that is powered by a single first-party oracle. It can either be used by itself, or multiple of them can be combined to form dAPIs. This relates to the core technical team in that the Beacons and the Beacon-based dAPI architecture is our design. In other words, similar to what has happened with the authoritative DAO, the core technical team has claimed dAPI (and Beacon) development and operations, despite them not being a part of our responsibilities according to our most recent proposal.
The core technical team is responsible for building a scalable infrastructure, which increases the leverage of the ecosystem participants. Developing ecosystems commonly don’t have participants that can utilize the available tools to their full potential. A common pitfall here is for the core technical team to go in and show ’em how it’s done. This is done by choosing a few, large enough clients and bending over backwards for them. This will result in some short-term success and mutual backslapping, but it ends up poisoning the project because:
- The core technical team stops thinking about the untapped potential and only about the needs of the few clients. This is fine if the goal is to become a service provider, but not if it is to build a protocol and an ecosystem on it — imagine Ethereum developed with specific dApps in mind. This stunts the development of the protocol, and the general ecosystem participants will leave for greener pastures because they are not being cared for.
- Once the vision for an ecosystem is lost, the future of the project is now hinged on keeping the existing clients, which means continually building what is asked for rather than the grand vision, so it’s a downward spiral from here.
These observations delayed us from participating in dAPI development, noting that building Beacons or dAPIs wouldn’t have been enough, they would also need to be actively operated, which would take up a considerable amount of time that we could spend developing the node and the protocol (which can be used for much more than Beacons and dAPIs). That being said, we are indeed the best people available to operate these services reliably. We have a two-fold solution to this:
- Build towards a level of readiness where we would be comfortable with allocating some of our resources towards operations. This has been partly achieved by the recent Airnode releases, which is why we have stepped in now and not earlier.
- Continue the core development in a way to feasibly offload the operations in the future, which would be made possible by data feed operation to be more of a set-and-forget matter, most importantly through the implementation of PSP.
In summary, the core technical team has taken over development and technical operation of Beacons, and dAPIs by implication. This work will be carefully balanced with infrastructure development to uphold the long-term interests of API3. From a general point of view, the core technical team is on track with building the deliverables from the whitepaper in the stated three years (of which one has passed) without requiring outside help (assuming that our proposals pass). We are still carefully optimistic about external dAPI operation teams (meaning “external to the core technical team”), and will be designing and documenting the Beacon and dAPI operation process in a way to make that feasible.
Thanks for reading our report, Happy Holidays and best wishes for the New Year for the API3 community!
